Open Deep Research 的工程底座：Supervisor、多智能体研究与上下文预算
LangChain 的 Open Deep Research 文章表面上是在介绍一个开源 deep research agent，真正值得看的是它背后的工程判断：研究不是一个固定 DAG，而是一个不断缩小不确定性的运行时过程。
所以它没有把系统做成“搜索十个网页，然后总结”。它把流程拆成 Scope、Research、Write 三段：先把用户请求变成可执行的 research brief，再让 supervisor 按任务复杂度决定是否并行派生子研究员，最后由单个写作模型基于清洗后的研究结果生成报告。
这篇不是逐句翻译，而是基于原文和开源实现的一次工程解构。重点放在：为什么 deep research 需要 supervisor，什么时候多智能体有用，如何控制上下文膨胀，怎样把证据链做成系统能力，而不是靠最后一个 prompt 祈祷模型别乱写。
关键不是多 agent，而是研究过程的状态机
Open Deep Research 的第一层设计是状态机，而不是角色扮演。
这个状态机里，research brief 是最重要的中间产物。用户原始对话可能很长，里面混着背景、偏好、例子、限制条件和后续补充。如果直接把整段聊天交给研究员，系统会在后续多轮工具调用里不断吞掉 token，最后 supervisor 既要理解原问题，又要从大量网页片段、失败工具调用和重复结果里判断下一步。
更稳的做法是先把对话压成 brief。brief 不只是摘要，而是合约：
- 研究目标是什么。
- 哪些问题必须回答。
- 哪些范围明确不做。
- 需要怎样的来源质量。
- 最终报告应如何组织。
- 什么时候可以认为研究足够。
这一步看起来像“整理需求”，其实是在给后面的 agent runtime 做控制面输入。没有 brief，supervisor 就只能凭当前上下文临场判断；有 brief，系统才有稳定的 north star。
Supervisor 的职责是调度预算，不是装成项目经理
很多多智能体 demo 会把角色写得很热闹：研究员、批判者、作家、编辑、审稿人互相聊天。Open Deep Research 的 supervisor 更克制。它主要做三件事：
- 判断 research brief 能否拆成相互独立的子问题。
- 决定本轮要派生多少个研究单元。
- 根据压缩后的发现判断是否继续深挖。
开源配置里能看到几个关键预算参数：
| 控制项 | 工程含义 | 失控后果 |
|---|---|---|
max_concurrent_research_units | 同一轮最多并行多少个子研究员 | 并发太大容易触发速率限制，也会产生大量重复证据 |
max_researcher_iterations | supervisor 最多反思和追加研究多少轮 | 轮数太高会把简单问题做成昂贵任务 |
max_react_tool_calls | 单个研究员最多执行多少轮工具调用 | 单个子题可能陷入无效搜索 |
max_content_length | 网页内容进入摘要前的长度上限 | 原始页面直接塞入上下文会拖垮成本和质量 |
这说明一个现实问题：deep research 的质量来自更多搜索和更多推理，但产品可用性来自预算边界。没有边界的研究 agent 会在两个方向上失败：要么太浅，像普通搜索摘要；要么太深，十几分钟后交付一份成本很高但边际价值很低的报告。
Supervisor 的价值就在这里。它不是为了“多一个智能体”，而是把研究深度变成运行时决策：简单事实核验可以单线程完成；竞品比较、政策梳理、候选人筛选、技术路线对比这类任务，才适合拆成多个独立分支并行探索。
多智能体适合研究，不一定适合写作和编码
原文里一个很重要的经验是：并行写报告很容易产生割裂感。不同子 agent 分别写不同章节，结果常常是术语不统一、判断标准不同、引用密度不一致，最后需要另一个模型强行拼接。
这和 Cognition 对多智能体的批评方向一致：一旦多个 agent 在没有完整共享上下文的情况下做相互依赖的决策，隐含假设就会冲突。编码任务尤其明显。一个 agent 改 UI 状态模型，另一个 agent 改 API 契约，第三个 agent 写测试，如果它们没有共享完整 trace，最终合并风险往往高于并行收益。
但研究任务有一个不同点：很多子问题天然可以隔离。
- 比较三家公司策略：每家公司可以独立收集资料。
- 找 20 个候选对象：不同来源或不同地区可以并行探索。
- 验证一个传言：可以分成一手资料、监管文件、媒体报道、反例搜索。
- 综述一个技术方向：可以分成论文、工程实现、产品案例、评测结果。
这些子任务之间不需要共享每一步决策，只需要最终交付结构化发现。也就是说，多智能体在这里的价值不是“协作”，而是“隔离上下文 + 并行压缩”。
这也是为什么 Open Deep Research 把多 agent 限制在研究阶段，而最终写作使用一次集中生成。研究阶段可以 map，写作阶段应该 reduce。
上下文工程是 deep research 的核心系统能力
研究型 agent 的最大成本不是搜索 API，而是上下文。
一个子研究员可能查十几个网页，每个网页几千到几万字；工具调用里还会混入失败结果、重复摘要、导航噪声、广告文本和低质量二手内容。如果这些原始反馈全部回流给 supervisor，token 会迅速膨胀，模型的注意力也会被无关内容污染。
Open Deep Research 的处理方式是让子研究员结束时做一次压缩：把工具调用轨迹转成干净的研究发现，再返回给 supervisor。这里的压缩不等于普通摘要，它至少要保留四类信息：
- 能直接回答子问题的结论。
- 支撑结论的来源和证据。
- 尚未解决的不确定点。
- 不应继续消耗预算的低价值方向。
可以把它理解成 agent 版 map-reduce：
raw web/tool traces
-> per-topic research loop
-> compressed findings with citations
-> supervisor gap analysis
-> final synthesis
真正难的是压缩边界。压得太狠，final writer 拿不到足够证据，只能泛泛而谈；压得太松，supervisor 又被 token 噪声淹没。一个可生产化的 deep research 系统最好把压缩结果做成结构化对象，而不是一段自由文本：
{
"subtopic": "pricing and deployment constraints",
"claims": [
{
"claim": "The project supports multiple search backends rather than binding to a single web search provider.",
"evidence": [
{
"url": "https://github.com/langchain-ai/open_deep_research",
"source_type": "repository",
"span": "configuration fields for Tavily, OpenAI native search, Anthropic native search and MCP"
}
],
"confidence": "high",
"open_questions": []
}
],
"discarded_context": [
"navigation boilerplate",
"duplicate product marketing copy"
]
}
一旦证据是结构化的，后续能力才容易做：引用核验、来源去重、主张-证据对齐、缓存复用、长程记忆、人工审阅和成本归因。
Deep research 需要证据流水线，而不是最后补引用
许多研究 agent 看起来有引用，但引用不一定可靠。常见问题有三类：
- 引用的页面存在，但不支持对应主张。
- 主张来自多个来源的综合推断，却只贴了一个看起来权威的链接。
- 子研究员收集过证据，但压缩时丢掉了 URL、时间、段落位置和访问上下文。
生产系统里，citation 不能只在最终报告阶段生成。更好的做法是从工具层开始记录 evidence object：
| 字段 | 作用 |
|---|---|
url / document_id | 定位来源 |
retrieved_at | 处理网页更新和可复现问题 |
source_type | 区分论文、官方文档、新闻、论坛、代码仓库 |
quote_span / line_range | 让引用能回到具体证据位置 |
content_hash | 判断来源是否变化 |
claim_ids | 建立主张到证据的映射 |
这样最终写作模型不是“凭记忆写报告并顺手贴链接”，而是在一个已经整理好的证据集合上做 synthesis。对高风险主题，还可以在写作后加一轮 verifier：逐条检查报告中的关键主张是否有证据支持，没有证据的句子要么降级成推测，要么删掉。
评测不能只看答案像不像
Deep research 的评测比普通问答复杂，因为同一个问题可以有多条合理搜索路径。要求 agent 每次走同样步骤没有意义，更应该评估结果质量和过程约束。
可以把评测拆成四层：
| 层级 | 评测对象 | 示例指标 |
|---|---|---|
| 任务完成 | 是否回答了 brief 的核心问题 | coverage、遗漏点、是否越界 |
| 事实可靠 | 主张是否被来源支持 | citation precision、unsupported claims |
| 来源质量 | 是否优先使用一手资料 | official / primary source ratio |
| 运行效率 | 是否用合理成本完成 | token、工具调用数、并发数、耗时 |
LangChain 的仓库提到 Deep Research Bench，这类基准有价值，因为它把任务做成更接近真实研究的问题，而不是简单检索题。但生产团队还需要自己的 eval set。原因很简单：企业内部 research 往往有行业偏好、来源白名单、合规边界、报告模板和成本上限。通用 benchmark 只能说明系统有基础能力，不能证明它适合你的业务。
一个可执行的内部评测样本最好包含：
- 10 个简单事实核验任务，用来防止过度研究。
- 10 个多对象比较任务，用来测试并行拆解。
- 10 个争议性问题，用来测试来源质量和反例搜索。
- 10 个长报告任务，用来测试上下文压缩和最终结构。
- 5 个陷阱任务，比如不存在的来源、旧信息、同名实体混淆。
这比一开始就做几百条大 benchmark 更现实。Agent 早期系统的失败模式通常很明显，小样本就能暴露调度、工具、prompt 和证据链的问题。
一个更可落地的生产架构
如果要把 Open Deep Research 的思路放进企业系统，我会把它拆成六个服务边界：
- Brief service：把用户对话压成 research brief，并记录澄清问题。
- Supervisor runtime：负责并发、深度、预算和停止条件。
- Research worker：只处理单个子题，拥有独立上下文和工具集。
- Evidence store：保存来源、片段、hash、主张映射和检索时间。
- Compression service：把 raw trace 压成结构化 findings。
- Report writer + verifier：统一写作，并检查主张是否有证据支撑。
这里不一定需要微服务化，单体也可以实现同样边界。关键是不要让所有东西都只存在于模型上下文里。上下文窗口是工作内存，不是数据库；agent trace 是调试材料，不是最终事实表；最终报告是交付物，不是证据存档。
成本模型要前置设计
Anthropic 在多智能体研究系统经验里提到，研究类多 agent 会显著增加 token 消耗。这个结论并不意外：并行子 agent 本质上是在用更多上下文窗口和更多工具调用换覆盖率。
可以用一个简单公式估算成本：
total_cost =
brief_tokens
+ supervisor_rounds * supervisor_tokens
+ sum(worker_tool_tokens + worker_reasoning_tokens + compression_tokens)
+ final_report_tokens
+ verifier_tokens
这个公式的重点不是精确计费，而是帮助系统做预算决策。比如：
- 用户只是问“某论文什么时候发表”，不应启动 5 个子研究员。
- 用户要求“比较 8 个供应商的技术、价格、风险和客户案例”，并发研究是合理的。
- 搜索结果高度重复时，应提前停止同类 query。
- 低质量来源过多时，应把预算转向一手资料，而不是继续扩大搜索。
- final report 很长时，应限制 worker 返回自由文本，改用结构化 findings。
换句话说，deep research 产品需要“研究深度旋钮”。这个旋钮不能只是 UI 上的 shallow / deep，而要落到并发数、工具调用数、来源优先级、压缩粒度、验证强度和最大成本上。
最容易被忽视的是失败恢复
研究 agent 是长任务。长任务一定会遇到工具超时、网页失效、模型 rate limit、上下文超限、某个 worker 产出低质量结果等问题。
如果系统没有 checkpoint，任何一次失败都可能让用户等了几分钟后拿到错误。更合理的运行时应该能保存：
- research brief。
- supervisor 当前轮次和已派生子题。
- 每个 worker 的状态、工具调用和压缩结果。
- evidence store 的增量写入。
- 已消耗预算和剩余预算。
- 失败原因与可重试边界。
这样系统可以做到局部重试。某个 worker 搜索失败，不必重跑整份研究；某个网页解析失败，可以换工具或降级成摘要；最终写作失败，可以基于已完成 findings 重新生成。
这也是 LangGraph 这类状态图框架适合 agent 的原因之一：它鼓励把 agent 过程显式建模成节点、边、状态和检查点，而不是把所有逻辑塞进一个 while loop。
结论：Deep research 是检索、调度、压缩和验证的组合系统
Open Deep Research 值得关注，不是因为它证明了“多智能体一定更好”，而是因为它把多智能体放回了正确位置：只在适合并行的研究阶段使用，用 supervisor 控制深度，用 compression 管理上下文，用单一 final writer 统一表达。
真正的产品分水岭不在模型名字，而在系统边界：
- brief 是否足够明确。
- supervisor 是否会按任务复杂度分配预算。
- 子研究员是否隔离上下文而不丢失证据。
- 压缩层是否保留可验证主张。
- 最终报告是否能回到来源。
- 评测是否覆盖事实、来源、成本和过程。
如果这些都没有，deep research 只是“搜索 + 长摘要”。如果这些做扎实，它就会变成一种新的知识工作 runtime：能在开放问题里动态规划搜索路径，能把分散证据压成结构化发现，也能在成本可控的范围内交付可审计报告。
参考资料
- LangChain Blog: Open Deep Research
- GitHub: langchain-ai/open_deep_research
- Anthropic Engineering: How we built our multi-agent research system
- Cognition: Don't Build Multi-Agents
- LangChain Blog: Context Engineering