跳到主要内容

深度研究智能体:为什么大多数实现要么无限循环,要么过早停止

· 阅读需 11 分钟
Tian Pan
Software Engineer

传统的标准 LLM 在没有迭代检索的情况下,在多步网络研究基准测试中的得分低于 10%。深度研究代理(Deep research agents)——即在循环中进行搜索、阅读、综合和重新查询的系统 —— 得分则超过 50%。这种五倍的提升解释了为什么每个严肃的 AI 产品团队都在构建此类工具。但这无法解释为什么大多数实现要么在追逐无关的细枝末节时耗费 $15 的账单,要么在两次肤浅的搜索后就宣布胜利。

核心问题不在于构建循环,而在于知道循环何时应该停止。事实证明,这是一个出人意料的深度系统设计挑战,涉及收敛检测(convergence detection)、成本经济学、来源可靠性和多代理协作。

搜索-推理循环:理论简单,实践残酷

深度研究代理遵循一个看似简单的循环:制定查询、检索结果、阅读并提取信息、更新认知、决定是否需要更多搜索,然后细化查询或生成最终答案。这与单次 RAG(single-shot RAG)有着本质的区别,后者只需检索一次并生成一次。

这种差异至关重要,因为复杂的问题无法通过单次检索步骤来回答。“在共享 GPU 基础设施上运行微调模型的安全性影响是什么?”这类问题需要理解微调内部原理、GPU 内存隔离、多租户云架构以及最近的事件报告。没有任何单一查询能涵盖所有这些内容。代理需要在进行过程中发现自己不知道的东西。

生产环境的实现通常将其分为三层:

  • 检索层(Retrieval layer):获取原始内容的搜索 API、网页抓取工具和文档获取器。
  • 编排层(Orchestration layer):决定下一步搜索什么以及何时停止的控制逻辑。
  • 推理层(Reasoning layer):解释结果、识别差距并综合发现的 LLM。

这种分离至关重要,因为每一层都有不同的失效模式。检索层会因为糟糕的来源而失效。推理层会因为幻觉而失效。但编排层 —— 控制循环的部分 —— 的失效方式最为隐蔽:它看起来在工作,实则在悄悄烧钱或产生肤浅的结果。

收敛问题:代理何时学到了足够的信息?

深度研究代理中最难的工程决策是停止准则(stopping criterion)。一个没有明确停止条件的代理会无限循环。一个停止条件过于激进的代理则会产生与单次 RAG 同样肤浅的输出。

有几种实用的收敛检测方法,每种方法都有权衡:

信息增益阈值(Information gain thresholds)。在每次搜索迭代后,衡量提取的新信息量与代理已知信息的对比。当边际信息增益降至阈值以下时(例如,每次迭代的新事实少于 10%),代理宣布收敛。问题在于,如何精确地定义“新事实”以便进行自动化测量。

查询饱和(Query saturation)。跟踪代理生成的查询。当它开始产生与已执行查询语义相似的查询时,很可能已经穷尽了可访问的信息空间。这对于受限主题效果很好,但对于代理应该探索相邻领域的开放式研究则会失效。

覆盖率检查表(Coverage checklists)。代理在开始时将原始问题分解为子问题,然后跟踪哪些子问题已得到充分回答。收敛意味着所有子问题都已解决。这是最可靠的方法,但要求初始分解必须全面 —— 如果代理遗漏了一个重要的子问题,它将在一个不完整的答案上收敛。

基于预算的截断(Budget-based cutoffs)。最简单的方法:设置最大迭代次数、工具调用次数或 token 数量,并在达到限制时停止。Google 的 Gemini Deep Research 每个任务运行 80–160 次搜索。其他实现在达到固定金额时封顶。这根本不检测收敛 —— 它只是防止成本失控 —— 但在实践中,无论使用哪种策略,这都是每个生产系统所需的最后防线。

最稳健的实现结合了覆盖率检查表和基于预算的截断:力求完整,但保证终止。

迭代搜索的经济学

深度研究代理价格昂贵。一个多代理研究系统使用的 token 通常比标准聊天交互多出约 15 倍。对于中等复杂度的查询,单次会话的成本可能在 $2–5 之间,且该成本随问题复杂度而增加。

这造成了设计上的博弈。更广泛的搜索能产生更好的结果 —— 在研究基准测试中,token 使用量解释了约 80% 的性能差异 —— 但你不能在每个问题上都花 $50。生产系统需要一种能将努力程度与价值相匹配的成本分配策略。

努力程度缩放(Effort scaling) 是一种有效的模式。在开始研究循环之前,根据复杂度对输入的查询进行分类:

  • 简单事实查找:单代理,3–10 次工具调用
  • 直接对比:2–4 个并行代理,每个调用 10–15 次
  • 复杂的多元研究:10 个以上分工明确的专业代理

这种分类本身会消耗一次 LLM 调用,但与过度配置整个研究会话的成本相比,一次分类调用的成本可以忽略不计。核心见解是,预先规划几乎总是比在每一步进行推理更便宜。

并行执行 还能通过以延迟换取吞吐量来提高成本效率。与其让一个代理顺序探索问题的不同方面,不如生成多个并行搜索的专业代理。一个生产系统报告称,使用这种模式,复杂查询的研究时间减少了多达 90%。每个代理获取的页面较少,但能同时覆盖更广的空间。

然而,并行化引入了协作开销。主代理必须避免子代理之间的重复工作,合并可能矛盾的发现,并处理某个子代理发现的信息可能需要重新导向另一个代理搜索的情况。大多数生产实现使用同步检查点:子代理完成一批搜索并汇报,主代理决定下一轮的任务分配。

来源可靠性:“垃圾进,垃圾出”问题的放大

单次 RAG (Single-shot RAG) 存在来源质量问题。深度研究智能体 (Deep research agents) 的情况更糟,因为它们会在多次迭代中复合不可靠的信息。在第 2 次迭代中检索到的错误断言可能会重定向整个研究轨迹,导致智能体在第 3 到第 8 次迭代中都在基于错误的前提进行构建。

最危险的失败模式不是检索到明显错误的信息,而是从看起来权威的来源中检索到听起来合理但细微处错误的信息。在 LLM 生成的引用中,有 50% 到 90% 并未得到其引用源的充分支持,即使是带有网页搜索的检索增强系统,产生无根据陈述的概率也大约为 30%。

实际的可靠性防御措施包括:

  • 多源相互验证 (Multi-source corroboration)。要求断言在至少两个独立来源中出现,才将其视为既定事实。这能捕获大多数单源错误,但会增加搜索成本。
  • 来源类型权重 (Source type weighting)。将一级来源(文档、论文、官方公告)的权重设为高于二级来源(博客文章、论坛讨论)。这不能保证准确性,但它将错误分布转向了更易于验证的断言。
  • 矛盾检测 (Contradiction detection)。当来源意见不一时,应显式标记冲突,而不是默默选择其中一个。这就是推理层体现其价值的地方——LLM 非常擅长识别两个段落何时提出了不兼容的断言,即使它们并不总是能确定哪一个是正确的。
  • 动态可靠性评分 (Dynamic credibility scoring)。为智能体或来源分配可靠性分数,并根据其贡献与共识的契合程度进行更新。输出反复与其他来源相矛盾的智能体会被降权。这模仿了人类研究团队随着时间的推移对特定来源建立信任的过程。

这些方法都不是万无一失的。实际的做法是深度防御:使用多个可靠性信号,让终端用户看到系统的置信度,并提供引用以便人类核实关键断言。

真正关键的架构决策

一些架构决策始终将那些真正好用的研究智能体与那些演示效果好但在生产中失败的智能体区分开来:

外部存储是不可商榷的。研究会话可能会超过 200,000 个 token 的上下文。智能体的计划、积累的发现和来源索引必须存在于上下文窗口之外的结构化存储中。仅依赖上下文窗口的智能体随着会话的推进,会遗失早期的发现。

先宽后窄。那些从简短、宽泛的查询开始,并逐渐缩小关注范围的智能体,其表现始终优于那些从长且具体的查询开始的智能体。具体的查询返回的结果较少,智能体可能会错过重要的相邻信息。这模仿了人类研究人员的实际工作方式——在深入研究细节之前,先对全局进行勘测。

围绕非确定性推理的确定性支架。搜索循环本身应该是确定性的:重试逻辑、检查点、预算执行和超时处理都应该是常规代码,而不是 LLM 的决策。让 LLM 决定搜索什么以及如何解释结果,但不要让它决定是否遵守预算或是否重试失败的 API 调用。

从检查点恢复,而不是重新开始。长时间的研究会话会遇到失败——API 超时、速率限制、上下文窗口溢出。能够记录进度并在最后一次成功状态恢复的系统,其可靠性远高于从头开始的系统。这对于多智能体系统尤为重要,其中一个子智能体的失败不应使其他九个智能体的工作失效。

评估研究过程,而不只是输出结果。大多数团队通过对最终报告打分来评估他们的研究智能体。但一份报告可能写得很好却是错误的。评估还应衡量:智能体是否搜索了正确的内容?它是否正确识别了来源冲突?它是否在合适的时间停止了?追踪智能体的决策模式——而不必记录对话内容——提供了诊断和改进长期研究质量所需的观察性。

深度研究何时值得投入成本,以及何时不值得

深度研究智能体并不是对更简单检索模式的通用升级。它们在以下情况是有意义的:

  • 问题确实需要跨不同来源进行多步推理 (Multi-hop reasoning)
  • 不完整或错误答案的代价超过了研究会话的成本
  • 所需信息分布在许多来源中,没有单一的权威参考
  • 延迟容忍度以分钟计,而不是秒

它们在以下情况没有意义:

  • 单个数据库查询或 API 调用即可回答问题
  • 用户需要在 10 秒内得到回复
  • 该领域拥有结构良好的知识库,标准 RAG 即可处理得很好
  • 单次查询预算低于 0.50 美元

市场发展迅速——多智能体系统询盘在 2024 年第一季度至 2025 年第二季度之间增长了 1,400% 以上,通过 LangGraph、CrewAI 和 OpenAI Agents SDK 等框架,生产实现正变得更加触手可及。但收敛检测、成本控制和来源可靠性等基础工程挑战在一般情况下仍未解决。

那些交付成功的深度研究智能体的团队,并不是拥有最复杂架构的团队。而是那些在枯燥的基础设施上投入精力的团队:真正执行限制的预算控制、在失败中幸存的检查点机制、捕获质量倒退的评估框架,以及在智能体构建在沙基上时发出警报的可靠性机制。循环很容易实现。让循环在正确的时间、针对正确的答案、以正确的成本终止——这才是真正的工程挑战。

References:Let's stay in touch and Follow me for more thoughts and updates