推荐语

AI研究代理如何突破人类认知极限？揭秘构建最先进Agent的核心技术。

核心内容：
1. 研究代理如何解决人类信息处理的三大瓶颈
2. 从失败案例中总结的三大架构设计原则
3. 上下文工程在长期研究任务中的关键实践

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

研究代理（Agent）正迅速成为人工智能最重要的应用之一。研究是一项基础性的知识工作：收集、阅读和综合信息是写作、决策乃至编程等一切活动的基础。然而，人类驱动的研究受到记忆力、阅读速度和时间的限制。相比之下，人工智能研究代理可以处理海量信息，即时综合洞见，并轻松扩展。正因如此，研究代理正成为当今人工智能的热门应用案例，并将很快成为内容生成、编程、销售等更广泛的代理工作流程的核心子组件。在本文中，我们将分享我们在构建最先进的研究代理过程中所汲取的技术和理念经验，以及我们对该领域未来发展方向的展望。

建设未来

代理

构建代理框架^[1]的任务是创建一个软件层，通过上下文管理、工具调用、循环控制、编排和错误处理来增强模型的运行时执行。然而，在快速改进的模型之上构建应用程序是当今工程领域的一项挑战。我们如何才能设计出能够吸收未来模型版本性能提升的软件呢？

这需要预测模型将如何演变，对其进展保持乐观，限制假设，并避免手工优化。

七个月前，我们为此付出了惨痛的代价。当时，我们不得不放弃第一次深度研究的尝试，从头开始重建整个系统。最初的架构复杂而精密（我们当时认为这是好事），但当新一代模型出现时，它的假设却成了瓶颈。

模型

过去七个月，模型能力悄然但意义重大地发展（尤其是在工具调用能力方面）。这种单一的优化方向促使我们从工作流转向智能体。我们相信，未来的模型将致力于解决智能体开发者当前面临的痛点。每个模型最终都会被一个框架所使用，因此模型的发展应服务于该框架。我们希望看到模型在提高召回率（用于上下文压缩）、增强工具调用可靠性以及提升代码简洁性方面得到改进。

工具

同样，工具也应该不断发展，以支持 LLM 和广泛采用的代理框架。优秀的工具应该在工具端进行一些上下文工程，使其与代理隔离。它们应该只返回最相关的数据，而不是将大量令牌倾倒到上下文窗口中。作为工具提供商，我们投入巨资开发了高级搜索^[2]功能，该功能内置了上下文工程。这反过来又降低了下游代理进程的延迟和信息丢失。

要点总结

为了构建能够随着时间推移而不断改进的智能体，我们遵循了一些指导原则：

1. 1. 简化编排逻辑，增强自主性。
2. 2. 密切关注哪些模型和工具正在被优化，并利用它们正在涌现的功能。
3. 3. 重点关注上下文工程（下一节将详细介绍）。

上下文工程—实践

长期研究任务揭示了当前智能体设计的一个根本挑战：如何长期维护一个清晰、优化的上下文窗口。如果工程师不重视上下文的管理，智能体几乎注定会失败。以下概述了我们在深度研究领域中围绕这一概念的思考。

上下文管理型网络检索

使用 Tavily 的高级搜索功能是克服这一挑战的自然第一步，因为它能够抽象化原始网页内容的处理过程，仅返回每个来源中最相关的内容片段。通过利用此功能，我们让 Tavily 搜索承担繁重的搜索工作，而 Tavily 研究则从中受益，以低延迟的方式收集最有价值的内容。

确保代理不会过度拟合单一研究方向是构建高效上下文收集流程的下一步。在这方面，全局状态持久化和源数据去重至关重要，在我们的案例中，它有三重帮助：

1. 1. 它确保代理人只能接触到最新信息。
2. 2. 它使工程师能够识别信息范围何时缩小，并提示代理探索尚未开发的相关领域。
3. 3. 它有助于在生成过程的后续阶段进行有效的来源归属。

在 Tavily，与网络互动是我们的核心业务。构建一个专为深度研究而设计的精细化网络检索系统，是我们整体深度研究代理设计的基础组成部分。

人机交互建模

人类的研究方式本质上是非结构化的、迭代式的。我们首先定义任务：我们想要达成什么目标，需要哪些信息。接下来，我们从各种来源收集数据，提取关键信息并将其存储在短期记忆中，让这些提炼出的思路指导我们后续的行动。

这个循环不断重复：收集信息、提炼信息、决定下一步行动。只有当我们积累了足够的信息来产出最终成果时，我们才会回到原始资料来源，将其作为参考来构建最终产品。

我们认为，深度研究代理的设计方式应该类似，即工具的输出应该提炼成反思，并且只有过去的反思才能作为工具调用者的上下文。与人类类似，只有当代理开始准备最终交付成果时，才需要提供原始信息作为上下文，以确保不会丢失任何信息。

以更少的资源做更多的事情

这种方法与基于 ReAct 代理架构中的传统上下文结构有所不同。通常，工具调用和输出会通过工具调用循环进行传播，先前检索/生成的令牌会在每次后续迭代中持久化到上下文窗口中。这种模式可以在LangChain 的 Open Deep Research^[3]代理实现中看到，从令牌消耗的角度来看，它可以用以下二次级数建模，其中_n_是每次工具调用迭代中调用工具调用模型时所使用的令牌数量，m是工具调用迭代次数。

n+2_n_+3_n_+⋯+mn=n⋅2_m_(m+1)

相反，我们提出的上下文工程方法消除了这种标记传播（因为知识蒸馏，即使聚合起来，与从网络上收集的标记数量相比也微不足道），并且可以通过以下线性级数建模。

n+n+n+⋯+n=nm

比较这两种方法，每个代理节省的令牌数量是原来的几倍2_m_+1并且，当将此推及多智能体系统并大规模消费时，所节省令牌的绝对价值就显得更加重要了。

通过这种方法，我们能够将令牌消耗量减少 66%（与 Open Deep Research 相比），同时在DeepResearch Bench^[4]上达到 SOTA——质量和效率的完美结合。

代理的生产化——一项持续的挑战

构建生产级代理是一项需要权衡的挑战。我们注重自主性以最大限度地提高性能和质量，同时还要满足对延迟、成本和可靠性的严格要求。

非确定性工程

LLM本质上是非确定性的，我们发现赋予它们一定的推理和迭代自由度（但需加以约束）能够产生最佳结果。自主性一旦失灵，就会导致智能体的行为偏离轨道。工具调用可能错误，LLM可能过度拟合某个子主题，预期的推理模式也可能失效。没有任何单一的保障措施能够解决所有这些问题。

工程思维需要转变：将故障模式视为核心设计考量因素，而非事后补救。诸如工具调用重试或模型级联之类的简单防护措施固然有所帮助，但主动预测异常情况、强化提示机制中的正确模式以及进行边缘案例测试，才是实现生产级、长时间运行的智能体的关键所在。

最佳工具选择——少即是多

根据我们的经验，向代理提供一套精简而必要的工具集比提供一套庞大而复杂的工具集要好得多。我们曾试图过度设计，添加许多理论上看似有用的工具，但实际上这反而会造成新的故障模式，并使生命周期管理（LLM）更难持续选择合适的工具并进行有效的迭代。

评价

我们利用评估结果来指导开发过程，但也意识到它们的不足之处。以LLM作为评判标准的评估结果难以令人信服：现有模型缺乏确定性，其推理过程难以解释，并且可能成为瓶颈，尤其对于运行时间较长的智能体而言，一次实验可能需要数天才能完成。

我们没有追求基准测试分数，而是追求方向性反馈。核心问题始终是：这项改动是否让代理在实践中更可靠、更有用？评估成为验证这一方向的工具，而非优化目标。直觉和细致的代理跟踪监控始终能提供比任何单一评估分数都更有价值、更直接的反馈。总而言之，最佳结果很少是最高的数值分数。对于生产系统而言，诸如减少令牌使用量、提高可靠性、降低延迟和减少故障等改进，比评估分数上的1分提升更有价值。

本文翻译自：https://huggingface.co/blog/Tavily/tavily-deep-research

引用链接

[1] 构建代理框架: https://translate.google.com/website?sl=auto&tl=zh-CN&hl=zh-CN&client=webapp&u=https://www.vtrivedy.com/posts/claude-code-sdk-haas-harness-as-a-service?ref%3Dblog.langchain.com
[2] 高级搜索: https://translate.google.com/website?sl=auto&tl=zh-CN&hl=zh-CN&client=webapp&u=https://docs.tavily.com/documentation/api-reference/endpoint/search%23body-search-depth
[3] LangChain 的 Open Deep Research: https://translate.google.com/website?sl=auto&tl=zh-CN&hl=zh-CN&client=webapp&u=https://github.com/langchain-ai/open_deep_research
[4] DeepResearch Bench: https://huggingface-co.translate.goog/spaces/muset-ai/DeepResearch-Bench-Leaderboard?_x_tr_sl=auto&_x_tr_tl=zh-CN&_x_tr_hl=zh-CN&_x_tr_pto=wapp