LangChain 亲手拆解三层 Agent 栈：别纠结了，先用 Deep Agents

8 月 6 日，LangChain 工程师 Sydney Runkle 在官方博客发文，厘清了自家三个开源 agent 项目的定位和选型逻辑。文章的默认推荐只有一个：从 Deep Agents 开始，需要更多控制或确定性时再往下走。

Runkle 在 X 上称，。

Harrison Chase：它们各占生态里不同的位置

LangChain 的 Harrison Chase 在 X 上将三者关系浓缩为一句话：这条推文收获 69 次点赞、70 次书签。

并非所有人都接受这个三层叙事。产品经理 Mykyta Pavlenko 直言不买账：他认为 Deep Agents 不过是 LangGraph 上的一层封装，不值得单独占位。

开发者 Gregor 点出了更实际的痛点：三层抽象叠在一起，调试时很难定位故障根源。

Consensus 公司 AI 总监 Derek Gilbert 给出了务实的拆解——简单 agent 用 LangChain create_agent，长时域自主 agent 用 deepagents，生物、金融等高监管行业才需要 LangGraph 自建 harness。

从一条 chain 到三层栈，用了三年

LangChain 的 agent 栈不是一次设计出来的。2022 年 10 月，它以"让 LLM 应用最快跑起来"的姿态出现，核心是 chain——把 prompt、模型调用和输出固定串联。

2024 年 1 月，agent 越来越复杂，chain 的线性结构不够用了。LangGraph 作为基于图的运行时被推出，内置持久化执行、流式传输和 human-in-the-loop。

2025 年 7 月，模型强到足以让"规划→调工具→看结果→再规划"这个循环标准化。Deep Agents 应运而生，在这个循环之上捆绑了文件系统、子 agent、技能和记忆，做成通用 harness。Runkle 在博客中明确表示受 Claude Code 和 Manus 两个产品启发。

一周前的 7 月 29 日，Deep Agents 刚发布。Stripe 也公开了——一个工程师，一周时间，上线首周达成季度采用目标，如今 83% 的 Stripe 员工每周使用 Kai，跨超过 6 万个会话。

Deep Agents 就是 LangChain agent 加一堆 middleware

Runkle 在博客中写了一句关键事实："Deep Agents is actually just the core LangChain agent plus a bunch of middleware." 三层之间不是平级的，而是上下堆叠。

最底层是 LangGraph——agent 运行时。基于图结构，提供持久化执行、容错、每一步的可观测性和 human-in-the-loop。给开发者最大的控制权，也要求开发者自己定义图的拓扑。

中间层是 LangChain——agent 框架。核心抽象极其精简：一个 LLM 在一个循环里调用工具。真正威力在 middleware：通过钩子在循环前后注入确定性步骤，比如上下文快满时自动摘要、执行完跑验证器。LangChain 的 create_agent 自身就建在 LangGraph 之上。

最上层是 Deep Agents——agent harness。开箱自带的最佳实践：文件系统（把不想塞进上下文窗口的内容读写到外部）、子 agent（做专门任务不撑爆主上下文）、技能（agent 按需加载的指令和脚本）、跨运行记忆。

Runkle 用内部案例证明这层抽象的价值：LangChain 自己的 GTM agent 建在 deepagents 上，每周处理近 1 万次请求，150 多个活跃用户，26% 流量由用户发起，74% 由 agent 自主触发。

越自主越强大，代价是可靠性

Runkle 把三层放在了"自主性 vs 确定性"的光谱上。

Deep Agents 处于最自主端——agent 循环可以跑得更久、子 agent 可以大规模展开。LangGraph 处于最确定端——领域知识直接编码进图的拓扑，不把判断留给模型。LangChain 居中。

敏感工作流和不需要 agentic 的可重复任务，确定性是更好的选择。

这个光谱解释了为什么 LangChain 推荐大多数构建者从 Deep Agents 起步。上下文管理已经复杂到不是每个团队都该自己从头解决的程度，而 Deep Agents 内置的摘要、子 agent 和文件系统，正是处理这个复杂性的成熟方案。

但开源 harness 不等于生产就绪。8 月 3 日，平台公司 TrueFoundry 发布了一篇分析——，列举了 Deep Agents 在凭证治理、跨团队访问控制、按 agent 维度的成本可见性和本地部署选项上的缺口。它们的判断是：Deep Agents 解决的是 agent 的执行问题，不是企业运维问题。

默认推荐的，是最不"底层"的那一个

LangChain 推荐的默认起点，不是最轻量的 LangChain 框架，也不是最可定制的 LangGraph 运行时，而是抽象层级最高、内置意见最多的 Deep Agents。

这背后是一个判断——agent 的上下文管理已经变成了比循环控制更普遍的瓶颈。与其让每个团队自己琢磨怎么在上下文快满时做摘要、怎么分拆子任务，不如把这些做成默认配置，让大多数人根本不用操心。