Tavily Deep Research 是一个单一的 API 端点，它端到端地执行多步骤研究，返回结构化的、附带来源引用的报告，而不是让你在一堆链接中筛选。

输入一个问题，就能得到一份完整的研究报告。你可以将本地文件与网络搜索一起附加，定义一个输出模式，让响应直接适配你的工作流程，还可以在“mini”（用于快速聚焦查询）和“pro”（用于宽泛的多角度主题）之间进行选择。

域名过滤、引用格式和输出长度都可以按请求进行配置。

https://tavily.com/blog/research-en…

构建深度研究：我们如何实现最先进水平 | Tavily 博客

来源：https://www.tavily.com/blog/research-en 研究代理正迅速成为最重要的 AI 应用之一。研究是一项基础的知识工作：收集、阅读和综合信息支撑着从写作、决策到编码的方方面面。然而，人工驱动的研究受限于记忆力、阅读速度和时间。相比之下，AI 研究代理可以处理海量信息，即时综合见解，并且毫不费力地扩展。正因如此，研究代理正成为当今 AI 的首批用例之一，并且很快将成为跨内容生成、编码、销售等更广泛的代理工作流的核心子组件。在这篇文章中，我们将分享在构建最先进的研究代理过程中学到的技术和理念层面的经验，以及我们对该领域未来走向的看法。

为未来而构建

代理框架

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

这需要预测模型将如何演进，对其进步持乐观态度，限制假设，并避免手工作坊式的优化。

我们在七个月前就吃过这个苦头，当时我们不得不放弃第一次深度研究的尝试，从头重建整个系统。最初的架构复杂而精巧（我们当时认为这是一件好事），但当新一代模型到来时，它的假设变成了瓶颈。

模型

在过去的七个月里，模型能力悄然但深刻地进化了（尤其是在它们的工具调用能力方面）。这一单一的优化重点推动我们从工作流走向代理。我们相信，未来的模型将被训练来解决当前代理开发者面临的痛点。每个模型最终都由一个框架来消费，因此模型应该为服务该框架而进化。我们希望在以下方面看到模型的改进：高召回率摘要（用于上下文压缩）、工具调用可靠性以及写作的简洁性。

工具

同样，工具应该进化为支持 LLM 和广泛采用的代理框架。最好的工具应该在工具端执行一些上下文工程，对代理来说则是抽象的。它们应该只返回最相关的数据，而不是将大量 token 倾倒入上下文窗口。作为工具提供者，我们在高级搜索功能上投入了大量精力，该功能内置了上下文工程。这反过来降低了下游代理流程的幻觉和延迟。

要点

为了构建能够随时间改进的代理，我们遵循了一些指导原则：

1. 简化编排逻辑，倾向于自主性。
2. 密切关注模型和工具正在优化的方向，并利用它们的新兴能力。
3. 专注于上下文工程（下一节将详细介绍）。

上下文工程——一门筛选的艺术

长周期研究任务暴露了当前代理设计中的一个根本挑战：随着时间的推移维护一个干净、优化的上下文窗口的任务。如果工程师没有密切关注上下文筛选的任务，代理几乎注定会失败。以下概述了我们围绕深度研究领域内这个概念的想法。

上下文管理的网络检索

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

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

1. 确保代理只接触到新鲜信息。
2. 允许工程师识别信息范围何时变窄，并提示代理探索未触及的相关领域。
3. 有助于在后续生成过程中进行有效的来源归属。

在 Tavily，与网络交互是我们的看家本领。构建一个精心设计的、为深度研究而优化的网络检索系统，是我们整个深度研究代理设计的基础模块。

模拟人与网络的交互

人类进行研究本质上是非结构化和迭代的。我们首先定义任务：我们要完成什么以及我们需要什么信息。接着，我们从来源收集数据，提取关键见解并将其保存在短期记忆中，让这些提炼后的想法指导我们后续的行动。

这个循环不断重复：收集信息，提炼，决定下一步做什么。只有当我们收集了足够的理解来产生最终交付物时，我们才会回到原始来源，将它们作为参考来组装最终产品。

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

事半功倍

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

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

当比较两种方法时，每个代理节省的 token 因子为 (m+1)/2，当将其外推到多代理系统并以大规模消耗时，节省的 token 绝对值变得更加显著。

通过这种方法，我们能够将 token 消耗减少 66%（与 Open Deep Research 相比），同时在 DeepResearch Bench（https://huggingface.co/spaces/muset-ai/DeepResearch-Bench-Leaderboard）上实现了最先进水平——质量和效率的交集得到充分体现。

构建生产级代理是一项平衡的艺术。我们倾向于自主性以最大化性能和质量，同时仍然满足延迟、成本和可靠性的严格要求。

用非确定性进行工程

LLM 本质上是非确定性的，我们发现给予它们有护栏的自由来进行推理和迭代会产生最强结果。当自主性走偏时，会导致代理行为偏离轨道。工具可能被错误调用，LLM 可能过度拟合子主题，预期的推理模式可能中断。没有任何单一的保障措施能捕捉所有这些错误。

需要转变工程思维：将失败模式视为核心设计考虑，而不是事后考虑。像工具调用重试或模型级联这样的简单护栏有所帮助，但主动预测异常、在提示中强化正确模式以及进行边缘情况测试，才是实现生产级、长时间运行代理的关键。

最优工具配置——少即是多

根据我们的经验，向代理暴露小而精的工具集比暴露大而复杂的工具集更好。我们曾想过度工程化，添加许多理论上看起来有用的工具，但在实践中，这创造了新的失败模式，并使 LLM 更难一致地选择正确的工具并有效迭代。

评估

我们使用评估来指导我们的开发过程，但也认识到它们的不足。LLM 作为评判的评估很难信任：当前模型是非确定性的，其推理过程不可解释，并且可能成为瓶颈，特别是对于单次实验可能需要数天才能完成的长时间运行代理。

我们不是优化基准分数，而是优化方向性反馈。核心问题始终是：这个改变是否让代理在实践中更可靠、更有用？ 评估成为验证该方向的工具，而不是优化目标。直觉和仔细的代理跟踪监控始终提供比任何单个评估分数更强的信号。

总的来说，最好的结果很少是最高数字分数。对于生产系统，像减少 token 使用、提高可靠性、降低延迟和减少失败这样的改进，比在评估上提升一分更有价值。

如果你有兴趣在实践中体验这些发现的成果，请在此处注册早期访问 Tavily Research（https://deepresearch.tavily.com/）。