深度研究 Agent 需要一个审查者：Jev 审查层做对了什么，以及我们在测试中发现的问题

带独立审查层的深度研究 Agent 是正确的设计：撰写报告的模型不应自行决定报告是否完成。我们阅读并测试了一个基于 Nemotron、Tavily 和 Jev 的开源项目。它在审查者故障时会放行、重试时不反馈原因，并且依据搜索摘要而非来源来判断论据支撑。以下是修复方案。

作者：MEI LIN · FDEINTERVIEWS 编辑部 · 更新于 2026 年 10 月 21 日 · 阅读时长 9 分钟

实践练习：什么是 Jev，TypeSafe 的 System One 模型 · System One 决策模型的概念 · RAG 与 Agent 设计问题 · 必知的 FDE 面试题

深度研究 Agent 不应给自己批改作业。在草稿和用户之间加入一个独立的审查层是正确的设计，而一个用 Nemotron 做研究、Tavily 做搜索、Jev 做审查的开源项目清晰地展示了这一模式。我们阅读了每一个文件并测试了审查路径。这个思路站得住脚，但实现中存在大多数研究 Agent 共有的三个缺陷：审查者故障时会放行；重试时不告诉 Agent 哪里出了问题；以及依据搜索摘要而非来源来检查论据支撑。每个缺陷都可以在不到一百行代码内修复，而修复它们正是让审查者从摆设变成关卡的关键。下文将介绍：这个项目如何运作、我们的发现、我们会交付给客户的设计，以及这一模式何时值得付出其成本。

项目本身，以及为什么这个设计是对的

The project is

deep_research_agent_with_review

in Sumanth P's Hands-On-AI-Engineering repository on GitHub, built during the Nebius AI Builder Program; the README discloses the program's credits. It is a Streamlit app with about 700 lines of Python, tests included. A

Deep Agent running

nvidia/Nemotron-3-Ultra-550b-a55b

on Nebius Token Factory plans the work and calls a

search_web

tool backed by Tavily (five results per query, deduplicated by URL, numbered as sources). It writes a Markdown report with numbered citations. A small function checks those citations. Then the report, the question, the sources and any citation issues go to Jev, TypeSafe's decision model, with three structured questions:

• evidence_coverage（是或否）：现有证据是否足以回答问题，没有重大遗漏？
• claim_grounding（是或否）：报告中的实质性论断是否得到其编号来源的支持？
• action（在 approve 或 research_again 中选择）。

概率达到 0.70 或更高即视为通过。如果 Jev 要求进一步研究，Agent 会再运行一次，然后 Jev 审查新报告。LangSmith 会追踪每一步。

README 中有一句值得保留的原则：Jev“不撰写报告”。这种分离正是关键所在。生成工作的模型是最不适合判断工作是否完成的裁判，因为它与产生这些缺口的盲点如出一辙。这就是银行业以及我们的 agentic 软件工厂指南中的“制作者-检查者”规则，它适用于研究 Agent 的理由与适用于代码的理由相同。使用快速决策模型作为检查者也是一个好选择：正如我们在“Jev 是什么”中所讲，它能在约十分之一秒内为结构化问题返回校准后的概率，而且按照我们 2026 年 9 月记录的输入价格（每百万 token $0.042，输出免费），对一份 5,000 token 状态的审查成本约为百分之二美分。

实际流程

来源：该项目的 workflow 与 review 实现。这是观察到的流程，包括第二次审查后的发布行为。

请阅读边上的标签。三个缺口就藏在那里。

我们测试审查路径时的发现

该项目的三个单元测试全部通过。它们覆盖了响应解析和引用验证。随后，我们用生产系统最终会遇到的真实输入调用了同样的函数。运行完整应用需要 Nebius、Tavily 和 Jev 的密钥，因此我们直接测试了决策逻辑；以下内容均不依赖模型行为。

第五行是最需要优先修复的。当审查响应解析结果为空（字段被重命名、网关返回带 200 状态码的错误页面、schema 变更）时，解析器会将审查标记为“已完成”，找不到任何拒绝，并写入默认解释——即批准。一个失败时放行的审查者只是一根进度条。而一个什么都没读到却报告“已批准”的审查者，比没有审查者更糟，因为它消除了用户自身的警惕。

我们还用常见格式测试了引用检查器：

这个正则表达式只匹配方括号中的单个数字，因此分组引用看起来就像完全没有引用一样，而且第二行中虚构的来源 9 也永远不会被标记。第四行的问题更大：只要任何地方出现一个真实引用，所有未引用的声明都能通过。作为检查的第一版还算合理，但它也说明了为什么引用检查应该按句子运行，而不是按整份报告运行。

三个缺口，以及各自付出的代价

1. Failing open. Covered above. In a demo this is harmless. In a customer deployment, the day the reviewer's API key rotates is the day every report ships unreviewed, and nobody notices because the UI still says "approved". Decide the failure policy explicitly: block, or show with a prominent unreviewed label, and alert someone either way.

2. Retrying without the reviewer's reasons. When Jev asks for more research, the second run starts from scratch: a new search collector, a new agent, the original question and one generic sentence saying evidence was weak. It does not receive the first report, the first sources or which check failed. The code asks Jev only for two booleans and a choice, so there are no reasons to pass along in any case. Research again without the reviewer's reasons is a re-roll, not a revision. You get a different report with different problems, and the second review grades a new draw from the same distribution.

3. Grounding against snippets. The search tool requests results with

include_raw_content

off, so each source is a title, a URL and a short snippet, and the review payload trims snippets to 1,200 characters. When Jev answers "are the claims supported by the numbered sources?", the sources it sees are teasers. A claim can match the snippet and contradict the page.

The fetch layer is part of the evidence: if the agent never read the page, nobody in the pipeline did.

这些都不是什么罕见的问题。我们在资金雄厚的团队构建的研究 Agent 中都见过这三种情况，这也是为什么这个小项目是一个很好的教学案例。

我们会交付的设计

这是我们提出的设计。修复会回到证据收集和起草阶段，然后重新运行引用、接地和覆盖检查。

按价值排序的改动：

• 按策略失败即阻断（fail closed）。任何审核员错误、缺失的 key、超时或无法解析的响应都会产生明确的“未审核”状态。绝不默认为批准。
• 把确定性检查作为门禁。解析 [1, 2]、[1-3] 和脚注样式。任何包含事实性声明但没有引用的句子，在任何模型看到报告之前就被移除或标记。
• 逐条声明对照原文进行接地验证。将报告拆分为若干声明，针对每条声明所引用的段落，向决策模型提出一个是/否问题。每次调用约需十分之一秒、花费不到一美分的零头，Jev 足够便宜，可以对每份报告运行二十次。逐条声明的结果还能明确告诉重试环节需要修复什么。
• 带着原因重试。将未通过的声明、未回答的子问题以及已收集的资料传给重试环节，要求进行有针对性的修复，而不是重新生成一份报告。
• 记录每一个概率。即使报告通过审核，也要保留覆盖率与接地分数。一个分数总是停留在 0.95 的门控等于什么都没把关，而只有从分数分布中才能看出这一点。
• 升级处理，不要循环。进行一次有针对性的重试后，就展示报告并列出其中未解决的缺口，如果风险足够高，再转交给人工处理。

这一设计将原本合并在一次调用中的三种不同职责分离开来：代码负责代码能检查的部分，一个快速的决策模型回答狭窄的事实性问题，剩下的交由人工处理。同样的拆分方式也适用于用 LLM 评审替代 Jev；对于狭窄的问题，决策模型只是更便宜、更快，而当你需要书面批评意见时，LLM 评审则更合适。

该模式的优缺点及适用场景

当错误答案代价高昂但速度慢一些可以接受时，可使用带评审的研究型 Agent：竞争与市场简报、供应商尽职调查、文献综述、客户会面前的客户调研、政策与法规摘要。对于前沿部署工程师而言，针对客户所在行业的会前简报是一个很好的首个应用场景：风险低、节省时间多，而且易于抽查。

在以下情况下不要使用它：答案必须精确到分钟级、资料位于 Agent 无法访问的登录墙之后，或者输出直接发送给客户而没有任何人工阅读。评审层只能降低错误率，并不能让一份无人阅读的报告变得可以安全发送。

关于成本，评审是其中便宜的部分。一次使用 5500 亿参数模型并执行十几次搜索的研究运行，其成本远高于二十次 Jev 调用，因此逐条声明的接地验证对账单的影响微乎其微。昂贵的错误恰恰相反：在评审上省下不到一美分，却发出一份建立在搜索摘要之上的、看似自信的报告。

关于复用此代码的说明

截至撰写本文时（2026 年 10 月 21 日），该仓库没有许可证文件。没有许可证的公开代码在法律意义上并不属于开源；默认情况下，作者保留所有权利。你可以阅读它、从中学习，但在将其复制到客户代码库之前，请先征得作者同意。设计思路本身不受此限制。

如果你正在准备应用 AI 工程师或 FDE 面试，“设计一个不会虚构引用的研究 Agent”如今已是常见的面试题。面试官期望的答案会将撰写者与检查者分离、明确失败策略、针对每条论断对照抓取的文本进行依据校验，并限制重试次数同时设置升级路径。请结合我们的 RAG 和 Agent 问题进行练习，并阅读关于幻觉和 RAG 评测的内容以掌握度量方法。

把它转化为 Offer。练习它所对应的真实问题和概念：

FAQ

审查层是一个独立的组件，用于判断研究报告是否足够好、可以展示，而不是让撰写报告的模型自行决定。它通常检查证据是否覆盖了问题，以及每条论断是否有引用来源支持，然后批准报告，或让 Agent 返回继续研究。将撰写者和审查者分离，就是应用于 Agent 的“制作者-检查者”原则。

Jev 是一个决策模型：它以大约十分之一秒的速度、每次审查不到一美分的成本，用概率回答结构化问题（是或否、一个选择、一个分数）。这适合一个在每份报告上运行的门控。LLM 评审员能更好地解释其推理并处理开放式批评，因此好的设计是使用快速决策模型作为门控，仅在它指出报告需要改进时才调用更强的模型。

失败放行（failing open）。如果审查器超时、缺少密钥或返回意外结果，许多实现仍会展示报告，有时甚至标记为已批准。一个在失败时不进行拦截的审查器只是一个进度条。请提前决定当审查器不可用时该怎么办，并让该路径对用户可见。

在重试时，把审查器给出的理由、未通过的论断以及已收集的来源一并交给它，并要求它针对这些问题进行修复。用一句泛泛的“做得更好”重新运行整个研究任务，那是重新掷骰子，而不是修订，可能会产生一份带有不同问题的新报告。限制重试次数，并在达到上限时升级给人工处理。

不能。只检查被引用的来源编号是否存在，只能证明引用格式正确。你还需要论断级别的依据校验：将报告拆分为一条条论断，并对照被引用的段落逐一检查，最好使用完整页面而非搜索摘要。没有引用的论断应被移除或标记，而不是因为别处存在一条引用就被容忍。

Discussion (4)

片段摘录正是团队在生产环境中容易忽视的地方。搜索 API 每条结果只返回几百个字符，审阅者如果只看这些内容，可能会批准一个完整页面在两段之后就被推翻的说法。如果事实依据（grounding）很重要，就应该抓取并存储整个页面，让审阅者阅读正文段落，而不是摘要片段。

读者提问：重试一次还是多次？

进行一次有针对性的重试，然后交给人工。根据我们的经验，第二次自动重试大多只是改写措辞，很少能找到新的证据。如果第一次重试没有弥合差距，问题很可能需要搜索工具无法触及的来源，此时应该让相关人员知晓。

值得补充的是：无论报告是否获批，都要记录审阅者给出的概率。一个月后，你可以将批准率与 0.7 的阈值进行对照绘图，看看这个阈值是否真的起作用，还是说每份报告都停留在 0.95，导致这道关卡从未真正拦截过任何内容。