系列开篇 | 《Deep Agents 实战笔记》 基于 deepagents (Python) 官方文档,参考版本 v0.7+ 原文:https://docs.langchain.com/oss/python/deepagents/overview

一、单循环 Agent 的天花板

如果你用 LangChain 的 create_agent 或者手写过 ReAct 循环,大概率遇到过这三个场景:

场景一:上下文爆炸。 让 Agent 分析 10 份文档,第 3 份的时候上下文窗口就塞满了——工具返回的原始结果全部堆在消息历史里,越跑越慢,越跑越贵,最后直接超限报错。

场景二:多任务串行失控。 让 Agent "调研 A、B、C 三个方向并各写一份摘要",它会笨拙地按顺序执行,中间任何一个环节跑偏,后面的全部被污染。

场景三:经验不复用。 上一次会话里 Agent 踩过的坑、总结出的方法论,下一次对话全部归零,从零开始再踩一遍。

这三个问题的根源是同一个:所有东西都挤在一个上下文窗口里——工具结果、中间推理、历史任务、领域知识,全部。

flowchart LR
    subgraph CTX["唯一的上下文窗口(不断膨胀)"]
        S1["系统提示词"]
        T1["工具结果 1<br/>(原始全文)"]
        T2["工具结果 2<br/>(原始全文)"]
        T3["工具结果 3 ..."]
        H1["历史任务残留"]
    end
    U["用户请求"] --> LLM["LLM 调用"]
    LLM --> CTX
    CTX -.->|"窗口塞满 → 遗忘 / 报错 / 成本飙升"| LLM
    style CTX fill:#fde8e8,color:#8b1a1a,stroke:#e05252
    style LLM fill:#eef4ff,color:#1a3a8b,stroke:#4a72d9

正在渲染图表…

二、Deep Agents 的答案:一个"代理 Harness"

LangChain 给出的答案是 Deep Agents。它不是又一个 Agent 框架,官方的定位叫 Agent Harness(代理挽具)——底层的工具调用循环和普通框架一样,但它在这个循环外围内置了一整套让 Agent 在真实长任务中"活着跑完"的机制:

能力层内置机制解决什么问题
执行环境自定义工具 + MCP、虚拟文件系统(可插拔 Backend)、沙箱、解释器Agent 在哪干活、怎么安全干活
上下文管理技能(Skill)、长期记忆、自动总结压缩、大结果卸载(offload)、提示词缓存上下文装不下怎么办
委派子代理(subagent)、任务规划(todo list)多任务怎么拆、怎么并行
引导人机协同(HITL)审批、文件系统权限出错代价高的操作谁来把关
flowchart TB
    CORE["核心工具调用循环<br/>(与普通 Agent 框架相同)"]
    CORE --- ENV & CTXM & DELE & STEER
    subgraph ENV["执行环境"]
        F1["工具 / MCP"]
        F2["虚拟文件系统<br/>(可插拔 Backend)"]
        F3["沙箱 / 解释器"]
    end
    subgraph CTXM["上下文管理"]
        C1["技能 Skill"]
        C2["长期记忆"]
        C3["总结压缩"]
        C4["结果卸载"]
    end
    subgraph DELE["委派"]
        D1["子代理"]
        D2["任务规划 write_todos"]
    end
    subgraph STEER["引导"]
        S1["HITL 审批"]
        S2["文件系统权限"]
    end
    style CORE fill:#eef4ff,color:#1a3a8b,stroke:#4a72d9
    style ENV fill:#f0f7f0,color:#1d4a1d,stroke:#4a9e4a
    style CTXM fill:#f4effb,color:#4a2170,stroke:#8b52c9
    style DELE fill:#fbf3e6,color:#6b4a12,stroke:#c99a3d
    style STEER fill:#fdeef0,color:#701d2a,stroke:#c94a5e

正在渲染图表…

这里面最"反直觉"、也最值得细品的两个设计,是文件系统和子代理。

三、文件系统:给 Agent 一个"外接大脑"

Deep Agents 给每个 Agent 配了一套文件工具(ls / read_file / write_file / edit_file / glob / grep),背后是一个可插拔的 Backend 抽象——可以是内存里的虚拟文件系统(测试用)、真实磁盘、LangSmith 沙箱,甚至是你自己的对象存储,还能按路径路由:/memories/ 走长期记忆存储,/workspace/ 走真实磁盘。

关键在于 Agent 怎么用它:

  • 大结果落盘:搜索工具返回 2 万字网页?写入文件,上下文里只留摘要,需要时再 read_file 读回。
  • 记忆长在文件里:跨会话的经验、用户偏好,就是几个 Markdown 文件,下次会话加载。
  • 技能也是文件:一个 SKILL.md 描述"做某类事的方法论",启动时 Agent 只看到文件名和摘要,任务相关时才读全文——典型的渐进式披露(progressive disclosure)。

一句话总结:上下文窗口是 CPU 内存,文件系统是硬盘。 有了"硬盘",Agent 才敢接长任务。

四、子代理:用"上下文隔离"换"任务质量"

第二个设计是委派。Deep Agents 内置一个 task 工具,主代理可以用它生成一次性子代理去处理隔离子任务。每个子代理拥有完全独立的上下文窗口,干完活只把结果摘要交回主代理。

flowchart TB
    U["用户:调研 A、B、C 三个方向"] --> M
    subgraph M["主代理(监督者)"]
        P1["拆解任务"]
        P2["汇总结果 → 最终报告"]
    end
    M -->|"task: 调研方向 A"| SA1
    M -->|"task: 调研方向 B"| SA2
    M -->|"task: 调研方向 C"| SA3
    subgraph ISO["互相隔离的独立上下文"]
        SA1["子代理 A<br/>自主搜索、读文件、推理"]
        SA2["子代理 B<br/>自主搜索、读文件、推理"]
        SA3["子代理 C<br/>自主搜索、读文件、推理"]
    end
    SA1 -->|"只回传:结果摘要"| M
    SA2 -->|"只回传:结果摘要"| M
    SA3 -->|"只回传:结果摘要"| M
    P1 --> P2
    style M fill:#eef4ff,color:#1a3a8b,stroke:#4a72d9
    style ISO fill:#f7f7f7,color:#333333,stroke:#999999
    style SA1 fill:#f0f7f0,color:#1d4a1d,stroke:#4a9e4a
    style SA2 fill:#f0f7f0,color:#1d4a1d,stroke:#4a9e4a
    style SA3 fill:#f0f7f0,color:#1d4a1d,stroke:#4a9e4a

正在渲染图表…

注意箭头的方向:进去的是任务描述,回来的是摘要。中间几十轮工具调用的原始输出,全部留在子代理自己的上下文里,用完即弃。主代理的窗口始终保持干净。

这带来三个直接收益:

  1. 上下文可控:不管子任务多复杂,主代理只承担"摘要级别"的信息量;
  2. 任务可并行:多个子代理天然可以并发执行(异步子代理还支持后台运行 + 通知);
  3. 职责可定制:给不同子代理配不同的系统提示词、工具集、甚至不同的模型——研究型的用便宜快模型,写报告的用强模型。

当然,代价是子代理"看不到"主代理的完整上下文,所以任务描述(description)的写法直接决定委派质量——官方文档甚至专门写了一节"排错指南"来对比好描述与坏描述的差异,这个我们第 5 篇细讲。

五、和 Claude Agent SDK 怎么选?

Deep Agents 常被拿来和 Claude Agent SDK 对比——毕竟"deep agent"这个概念最早由 Anthropic 在 Claude Research 的博客中带火。两者都是 Agent Harness、都是 MIT 协议,但取舍不同:

维度Deep AgentsClaude Agent SDK
模型支持任意提供商(100+)仅 Claude 系
执行 Backend可插拔(本地 / 虚拟 / 远程沙箱 / 自定义)所在沙箱的本地文件系统
多租户内置(作用域线程、按用户沙箱、RBAC)自行搭建
部署LangSmith 托管 或 langgraph build 自托管自托管为主
定位模型与基础设施解耦,灵活性优先Anthropic 生态深度整合

我的看法:做产品、要接自己的模型和基础设施,选 Deep Agents;已经 all-in Anthropic 生态、做编码类工具,选 Claude Agent SDK。 本系列当然以前者为主线。

六、这个系列会讲什么

接下来 13 篇,我会按「跑通 → 拆机制 → 上实战 → 进生产」的顺序,把 Deep Agents 完整过一遍,每篇都带可运行代码:

  • 第 2 篇:10 分钟跑通你的第一个深度研究 Agent
  • 第 3-4 篇:五大内置能力架构深拆 / Backend 精读
  • 第 5-6 篇:子代理(上):委派的艺术 /(下):异步与动态编排
  • 第 7-8 篇:上下文工程 / 记忆与技能
  • 第 9-10 篇:沙箱与解释器 / 权限与 HITL
  • 第 11-12 篇:实战:复刻 Deep Research / Agentic RAG
  • 第 13 篇:走向生产

下一篇见。


参考资料:

  • Deep Agents Overview(官方文档,本文主要素材)
  • Deep Agents vs. Claude Agent SDK(官方对比页)
  • The two patterns by which agents connect sandboxes(LangChain Blog)