框架与编排 / LangChain 生态 / 生产闭环 / Deep Research 实现逻辑
本文转载自 Awesome AI Roadmap，原作者 Polo Li，依 CC BY 4.0 协议共享。

第十二章：Deep Research 的实现逻辑

12.1 Deep Research 是什么

普通问答通常一次检索就能得到答案；研究任务往往一开始就没有固定路径。

例如比较三家云厂商的 Agent 托管能力，需要分别查产品定位、价格、限制和区域差异，还要处理产品改名、资料过期和来源矛盾。

Deep Research 关注的是一套研究流程：系统要围绕研究目标决定下一步搜什么、哪些问题可以并行、证据是否充分，以及何时停止。

12.1.1 生态里几个名字的区别

名字 定位
LangChain 提供模型、工具和 Agent 等高层积木
LangGraph 负责有状态流程如何编排和运行
open_deep_research 展示一套具体研究流程
Deep Agents 构建在 LangGraph 上的 Python agent harness：提供规划、子 Agent、上下文管理和文件系统工具；不是一个保证研究正确性的托管研究产品

边界需要明确：Deep Agents 是单独安装的 deepagents SDK/harness，不是 LangChain 核心包的开关，也不替你提供模型、身份系统、业务授权、数据治理或安全隔离。task 子 Agent 默认是一次性、隔离上下文后只回传最终报告；任务清单从 v0.7 起是 opt-in，不应假设每个 Deep Agent 都会规划或长期记忆。

12.2 核心流程

flowchart TB
    S1["① 澄清问题并确定范围"] --> S2["② 生成 Research Brief"]
    S2 --> S3["③ Supervisor 拆分子课题"]
    S3 --> S4["④ Researcher 并行检索与核验"]
    S4 --> S5["⑤ 压缩证据并检查研究缺口"]
    S5 -->|发现缺口或冲突| S3
    S5 -->|覆盖充分| S6["⑥ 统一生成最终报告"]

    style S2 fill:#e8f0fe
    style S6 fill:#e6f4ea
步骤 关键点
① 范围澄清 用户只说「研究某家公司」时，要确认是关注投资价值、技术路线还是就业风险，否则后续搜索很容易跑偏
② Research Brief 把用户目标、研究维度、时间范围、来源要求和交付形式整理成稳定的成功标准
③ 拆分子课题 只有相对独立的问题才适合并行（如分别研究三家公司的定价）；后一个问题依赖前一个结论就应该串行
④ 多轮检索 每个研究员只处理一个主题，并保留来源信息
⑤ 压缩与查缺 不是把所有网页原文塞回 Supervisor，而是压缩成带出处的关键证据；再检查 Brief 是否被覆盖
⑥ 统一写作 组织论证、处理重复内容，将事实、推断和不确定性分开表达

12.3 为什么需要子 Agent

如果一个 Agent 同时研究多个主题，搜索结果会不断占用同一个上下文——A 公司的价格、B 公司的安全文档和 C 公司的失败请求混在一起，模型反而更难关注当前证据。

12.3.1 第一目的是隔离上下文

每个 Researcher 只处理一个子课题，最终只返回压缩后的结论和来源，主 Agent 不必背着全部搜索过程继续思考。

12.3.2 并行是隔离之后的自然结果

  • 相互独立的研究任务可以同时执行，整体等待时间下降；
  • 彼此依赖的任务却仍要按顺序完成。

Agent 数量越多，模型调用、搜索费用、限流和协调成本也越高。不能为了并行而并行，关键仍是子课题能否独立推进。

12.3.3 为什么不让子 Agent 分别写报告章节

因为各章节可能重复背景、使用不同口径，甚至得出相互冲突的结论。

并行搜证据、统一写报告，更容易保持全文一致性。

12.4 如何保证研究质量

研究报告很长、链接很多，并不代表质量高。

判断质量时，可以沿着「来源 → 证据 → 结论」反向追查：

flowchart TB
    A["① 来源是否值得信
官方文档、论文、监管文件、一手资料更接近原始事实
多篇转载可能都来自同一篇文章
不能因为链接数量多就当成交叉验证"]
    A --> B["② 来源是否真的支持当前结论
报告应把事实、推断和不确定性分开
遇到冲突时追查发布时间、统计口径和原始出处
而不是挑一个最符合预期的答案"]
    B --> C["③ 结论仍不稳就回到研究过程
搜索词是否漏掉关键限定
子课题是否重复
停止条件是否过早
工具失败后有没有换用有效来源"]

    style A fill:#e8f0fe
    style C fill:#fff3cd

12.4.1 评测既看答案也看轨迹

维度 检查
最终答案 是否覆盖 Brief
研究轨迹 搜索路径是否合理
来源覆盖率 关键维度是否都有证据
引用正确性 引用是否真的支持结论
耗时与成本 是否在预算内

通用 Benchmark 可以用于版本比较，但不能代替企业自己的业务数据集。

12.5 如何控制成本和安全

12.5.1 成本受「宽度」和「深度」双重影响

维度 含义 控制手段
宽度 并行研究单元数量 限制同时运行的研究单元
深度 每个 Researcher 和 Supervisor 最多迭代多少轮 限制工具调用次数和补搜轮数

单个分支有上限还不够——整项任务还要设置总 Token、搜索费用和超时预算，再补上失败重试、缓存、限流和取消策略。

这样才能明确继续、降级或停止的条件。

12.5.2 网页和外部文档都是不可信输入

它们可能包含诱导 Agent 泄露密钥或执行危险操作的提示词注入。

措施
研究工具优先只读
内部数据遵循最小权限
密钥不要暴露给搜索或沙箱环境
高风险操作必须人工审批并保留 Trace

对于金融、医疗、法律和安全决策，Deep Research 只能辅助资料整理，不能因为报告带有引用就取消专家复核。

12.5.3 Deep Agents 的文件系统与沙箱边界

Deep Agents 向模型提供的是可插拔 backend 后面的文件系统工具面：ls、read_file、write_file、edit_file、delete、glob、grep。这不是抽象概念——给错 backend 就可能让模型读写真实文件。

Backend / 场景 数据与能力 安全边界
默认 State backend 文件随 LangGraph state/checkpointer 在同一 thread内保存 适合临时工作区；不跨 thread 共享
StoreBackend 文件跨 thread 持久化 namespace、租户隔离、保留与删除策略由应用负责
FilesystemBackend 访问指定根目录的本地文件 只授予专用、最小目录；不要把主机目录、密钥目录或用户主目录作为 root
LocalShellBackend 本机文件系统，另有 execute 没有隔离；仅限受控开发环境
Sandbox backend 隔离的文件系统和 execute 适合不可信代码与自主 Agent；仍须限制网络、凭证、挂载目录、资源和生命周期

只有 Sandbox 和 LocalShell backend 会提供 shell execute。Sandbox 是隔离边界，不是「默认安全」的同义词：把最小权限凭证按需注入，使用只读/受限网络与 CPU、内存、时间配额，并在删除、外发、付费调用等动作前启用 interrupt_on 审批。不要把宿主机的环境变量或云凭证直接暴露给 Agent。

推荐组合：临时中间产物放 thread-scoped State backend；经审核、需要跨会话保留的资料放带租户 namespace 的 Store backend；代码执行放一次性 sandbox。需要同时使用时用 Composite backend 按路径路由，而不是把所有数据和权限放进一个可写本地目录。

12.6 哪些场景适合

同时满足下列三项时，Deep Research 才值得引入：

flowchart TB
    Q1{"问题是否开放到
需要多轮搜索和动态调整方向?"}
    Q1 -->|一次权威检索就能回答| N1["不用
复杂研究流程只会增加成本"]
    Q1 -->|是| Q2{"能否拆出相对独立的子课题?"}
    Q2 -->|不能| N2["不用
并行 Researcher 会频繁等待和交换状态"]
    Q2 -->|能| Q3{"报告价值能否覆盖
多轮模型与搜索成本?"}
    Q3 -->|不能| N3["不用"]
    Q3 -->|能| Y["适合 Deep Research"]

    style Y fill:#e6f4ea

典型场景：竞品分析、技术路线调研、文献综述、供应商尽调、政策影响研究，以及企业内部资料与公开信息的联合分析。

不适合的情形：

情形 原因
只查一个容易核验的实时事实 一次权威搜索更快、更便宜
多个子任务必须严格共享中间状态 强行并行只会增加冲突
数据源本身不可靠或没有访问权限 研究 Agent 也无法凭空得到正确答案

12.7 常见错误

12.7.1 把 Deep Research 理解成「搜索很多次」

重点在于动态决定搜什么、能否并行、证据够不够、何时停止。

12.7.2 把它当成 LangChain 核心包里的一个开关

它是一类研究型 Agent 架构，参考实现和通用框架定位不同。

12.7.3 跳过范围澄清直接开搜

Brief 不明确，后续所有搜索都可能跑偏。

12.7.4 把有依赖关系的子课题也并行

后一个依赖前一个结论时必须串行。

12.7.5 把网页原文全部塞回 Supervisor

应该压缩成带出处的关键证据，否则上下文很快被占满。

12.7.6 让子 Agent 分别写报告章节

会重复背景、口径不一、结论冲突，应并行搜证据、统一写报告。

12.7.7 用链接数量当交叉验证

多篇转载可能都来自同一篇文章。

12.7.8 遇到冲突挑一个最符合预期的答案

要追查发布时间、统计口径和原始出处。

12.7.9 只控制单分支迭代不设总预算

整项任务还要有总 Token、搜索费用和超时上限。

12.7.10 把网页内容当可信输入

提示词注入可能诱导泄露密钥或执行危险操作，研究工具应优先只读。

12.7.11 因为报告有引用就取消专家复核

金融、医疗、法律和安全决策它只能辅助。

12.7.12 只用通用 Benchmark 评测

不能代替企业自己的业务数据集。

12.7.13 把 Deep Agents 当成默认隔离环境

文件工具和 execute 的权限由 backend 决定；LocalShellBackend 直接操作宿主机。对不可信输入或自主代码执行，应选 sandbox，并单独约束凭证、网络、挂载和资源。

12.8 本章总结

  1. Deep Research 是一类研究型 Agent 架构，不是核心包中的一个开关；
  2. 它建立在 LangChain 的模型/工具/Agent 与 LangGraph 的状态与编排能力之上；
  3. 六步流程：明确范围 → 生成 Brief → 拆分子课题 → 并行检索核验 → 压缩证据查缺 → 统一写作；
  4. Research Brief 是稳定的成功标准，缺了它搜索必然跑偏；
  5. 只有独立子课题适合并行，有依赖就串行；
  6. 子 Agent 的第一目的是隔离上下文，并行是隔离之后的自然结果；
  7. 并行搜证据、统一写报告，避免章节重复与结论冲突；
  8. 质量沿「来源 → 证据 → 结论」反向追查，链接多不等于交叉验证；
  9. 评测既看答案也看轨迹、覆盖率、引用正确性、耗时和成本；
  10. 成本受宽度和深度双重影响，单分支上限之外还要有总预算和取消策略；
  11. 外部文档是不可信输入：工具只读、最小权限、密钥隔离、高风险人工审批；
  12. 三项条件都成立才值得用：问题足够开放、子课题可独立、报告价值覆盖成本。
  13. Deep Agents 是 SDK/harness 而非安全或正确性承诺：文件、持久化和 shell 权限取决于 backend；不可信代码要在受限 sandbox 中执行。

可以把它理解为：把一个没有固定路径的研究任务，拆成「Supervisor 规划补缺 + Researcher 隔离上下文并行搜证 + 统一写作」的有状态流程；能否上线，还取决于宽度、深度、预算、来源可信度和提示词注入风险是否被一起控制。

参考资料