工作流与智能体：谁应该决定下一步的研究方向？
研究中的工作流与智能体：何时应硬编码搜索路径，何时应由模型决定下一步搜索方向——以LangGraph与Anthropic的网页工具设计为例。
一名研究助手看到“LangGraph支持持久化执行”这一描述后，在对比表中打勾并推荐该框架。你部署了一个本地应用，但进程随即终止，再也没有恢复。究竟是什么出了问题？
有某个条件被忽略了。“支持持久化”并不等同于“该应用已实现持久化功能”。一个值得使用的市场情报助手应当能察觉到这一差异，深入查看功能标签，有时还会根据发现的情况调整后续的提问方向。
在本系列的前文中，重点在于运行时本身；而此处的问题则是模型在那个运行时环境中有多少自由度。
调查同一任务任务的两种方法
假设任务要求仅依据官方文档，阐述LangGraph与Deep Agents之间的关系，以及Python研究服务实现重启恢复功能所需的条件。
一种方法是固定流程：你提供相应的页面，提取关键论点，比较其中的限制条件，然后生成一份带有引用信息的简报。这就是工作流。
另一种方法则让模型决定下一步行动：它进行搜索，打开页面，发现缺失的条件后选择接下来要深入研究的内容。这就是智能体。
这两种方法都可以使用模型、工具、分支结构以及重试机制。真正的区别在于由谁来决定路径。LangGraph关于工作流与智能体的说明清晰地划分了这两者。
一个实用的经验法则：
- 文档和步骤已经明确：优先选择工作流。
- 有用的信息只在研究过程中出现：尝试使用有限智能体。
- 输出结果必须可预测，而调查过程则不必：将两者结合使用。
这个项目属于第三类情况。
当某项发现改变了问题本身
乍看之下，这份简报似乎是在比较各种框架的性能。但随后对Deep Agents的概述表明，它实际上运行在LangGraph运行时之上，调查方向随之改变。
旧问题：哪个框架更胜一筹？
新发现：它们处于不同的层级。
更好的问题是：哪些任务应该由应用程序本身完成，哪些则应交由更高层的框架处理？
持久化存储也需要同样的重视。文档中介绍了本地图的检查点设置与线程标识方法，同时区分了内存存储与数据库存储，并指出Agent Server独自拥有其持久化基础设施。详见“持久化存储与检查点”部分。
一个有用的答案会考虑到这些条件，而仅靠功能列表中的勾选标记则无法做到。以下所有内容均直接来自文档阅读，而非对智能体对话的记录。
系统架构：围绕研究人员的流程
该应用负责确定任务要求、允许使用的资料来源、请求量上限以及输出处理方式。在既定框架内，模型负责选择搜索内容和文档。研究过程保持灵活性，而结果输出则十分明确。
涉及组件：
- LangGraph负责执行应用的外层流程。
- Anthropic SDK为模型提供原生网页搜索和数据获取工具。
- 保存的审计记录会包含资料来源、引用信息、使用情况以及工具错误。
一次服务提供商调用可包含多项搜索和读取操作。LangGraph负责整体流程控制，但并不需要为每个查询都自行设计。如此设计便于研究人员清晰了解流程边界。深度智能体则可在需要更多上下文管理或任务分配时再采取行动。更换服务提供商意味着需要重新编写相关工具和引用规则。
搜索用于查找页面；获取功能用于读取它们
该请求会同时使用这两种工具：
tools = [
{
"type": "web_search_20250305",
"name": "web_search",
"max_uses": 3,
},
{
"type": "web_fetch_20250910",
"name": "web_fetch",
"max_uses": 4,
"max_content_tokens": 6000,
"citations": {"enabled": True},
},
]
这些定义来自配套代码，并非完整的程序。您选择的模型必须支持文档中规定的工具版本。Anthropic在其开发者网站上将这两个工具分别归类在“Agents”和“Tools”下；请在那里查看最新的搜索与获取功能规范。
设计受到三项限制的约束。
- 每次请求都有上限。最多允许两次SDK调用，包括一次暂停后的继续调用，且不允许SDK自动重试。
- 在获取数据时有意启用引用功能，以便保留原始引用记录，而不仅仅是答案的正文内容。
- HTTP 200状态码并不能证明数据的有效性。即使API调用成功，其内部的获取操作也可能失败，因此还需要查看工具返回的结果部分。
这些上限限制了请求次数和可使用的工具数量。它们既不是费用上限，也不是严格的截止时间。
引用功能仍可起到辅助作用
想象有一份报告称该应用在崩溃后会自动恢复，并引用了关于可配置持久化的页面作为依据。该链接确实存在，但这一说法的范畴超出了现有证据所能支持的范围。
基本的审核会提出四个是/否问题：模型是否正常完成运行？它是否获取了至少一份文档？它是否返回了答案文本？最终响应是否包含原始引用？若全部通过则标记为needs_review；若任何必要检查未通过则标记为incomplete。
这两种标签都并不意味着相关说法是正确的。引用可能指向索引和段落位置而非URL，而原型系统仅存储这些记录，并不需要自行定义它们之间的对应关系。
一个有用的审核习惯是：选取一个具体的说法，查看其来源代码。是哪一种条件、异常情况或限制因素会改变推荐结果？
只有在能够衡量收益时才增加复杂性
长时间的调查可能需要选择性加载上下文、使用简洁的笔记，或是为不同分支分配独立的研究人员。这些理念体现在Anthropic关于为智能体打包上下文以及多智能体研究系统的文章中。对于这款应用而言，它们只是需要评估的选项，并非默认就会推出的升级功能。
四个检查标准可作为初步筛选标准：
- 它能否解释LangGraph与Deep Agents之间的关系？
- 它能否保持重启恢复的条件不变？
- 它能否在文档获取失败时及时察觉？
- 它是否承认仅凭文档无法确定最经济的部署方案？
将提供的文档处理流程与基于模型的搜索方式并列使用。保持模型和答案要求不变，明确指定各方可以查看的来源，并记录实际使用情况。对找到的结果、缺失的条件以及真实的不确定性进行评分，而不仅仅是依据引用次数。
目前的进展：使用模拟的HTTP环境，针对真实的SDK和LangGraph运行时已通过十项集成测试。由于尚未设置认证信息，因此尚未进行实时API测试，也就没有相关的质量、延迟或成本数据。
未来展望
现在有一种值得测试的设计：一种能够依据证据进行工作的研究工具，其运行过程会被记录在可查看的轨迹中。但问题出现在该流程在半途中断时——虽然保存的响应文件有助于了解发生了什么，却无法重新启动整个流程。接下来的改进方案是引入持久化的执行状态，并在全新的流程中测试恢复功能，依然使用这款网络研究应用。
相关阅读
- 2026年值得了解的10种AI智能体框架：LangGraph、CrewAI等 ——按智能体协调方式对10种框架进行分类，介绍各自的优缺点、最佳应用场景以及为团队选择框架的决策指南。