最近刷知乎和B站，做Agent开发的朋友应该都感觉到了一件事：DeepAgents这个词，出现频率有点高得反常。
8月25日，知乎刚有人发了一篇《一张图讲明白Deep Agents，LangChain，LangGraph》；同一天还有源码级的拆解文章，把文件系统中间件这套设计从源码层面翻出来讲。知乎B站那边，Datawhale开源课程《DeepAgents实战》系列8月26日已经更到第19集，最新一集讲PTC（编程式工具调用），单集播放800多，保持着周更节奏。哔哩哔哩再往前数，知乎上的《LangChain DeepAgents速通指南》已经写到第十二篇，从源码一路拆到命令体系。
真正给这波讨论定调的，其实是官方自己。8月6日，LangChain官方博客发了一篇题为《Deep Agents vs LangChain vs LangGraph》的文章，开门见山地把三者的分工说透了；8月12日，联合创始人Harrison Chase又发了一篇《Why managed agents are the next big thing in agent building》。官方连发两篇文解释"我们这三层东西分别是什么"，这在LangChain的历史上并不多见——也说明社区被绕晕的程度，已经惊动了官方。
与此同时，圈子里还有一场没吵完的架。7月底那篇《用Claude Agent SDK干掉LangGraph之后，我的金融研报Agent终于不崩了》，34个赞、153个收藏，标题直接把LangGraph架在火上烤。作者的核心吐槽是：光是载入三年的资产负债表、利润表、现金流量表，再聊几轮分析对话，上下文就直接炸了。知乎但点开评论区更有意思：高赞反驳说的是"上下文爆掉本来就是你设计Agent时该考虑到的边界"，还有人说"这不是哪个SDK的问题，是工程经验和架构经验不足的问题"。
一边是新框架刷屏，一边是老牌编排层被唱衰，很多一直跟着LangChain生态走的朋友就懵了：我好不容易把LangChain和LangGraph的关系捋顺，怎么又冒出来一个DeepAgents？这三者到底是竞争关系，还是各管一摊？我现在做的东西，到底该用哪一层？
我的结论先放在前面：这三个不是三个互相竞争的框架，而是同一个技术栈里的三层楼。搞错楼层，才会用错工具。今天这篇，就把三件套的分工、DeepAgents火起来的原因、以及你什么时候该迁什么时候不该迁，一次说清楚。
先认清：这不是三选一，是三层楼
很多人被绕晕，根源在于把LangChain、LangGraph、DeepAgents当成了"三个框架选一个"。实际上它们是叠在一起的三层，解决的问题完全不同。
官方8月6日那篇文章里的原话是这样的：“LangGraph is an agent runtime, LangChain is an agent framework, and Deep Agents is an agent harness.”——LangGraph是运行时，LangChain是框架，DeepAgents是harness（可以理解成"全套托管的驾驶舱"）。LangChain官方博客三层完全可组合，你可以在层与层之间移动，而不是三选一。
翻译成大白话：
LangChain是"开发抽象层"。它管的是模型调用、提示词模板、工具定义、结构化输出这些基础件。官方给它的核心抽象画了张图，简单到只有一个循环：一个LLM，循环跑，不断调工具。你现在看到的LangChain 1.0系列教程讲的结构化输出、记忆、RAG基础，都是这一层的事。它回答的问题是"怎么和大模型打交道"。
LangGraph是"运行与流程编排层"。当你的Agent不再是"问一句答一句"，而是要走一个多步骤、有分支、能暂停、能恢复、能人工介入的流程时，就轮到LangGraph了。它用状态机把你的流程固化下来，配套检查点、持久化、人在环路。它回答的问题是"怎么让Agent按我画的流程可靠地跑"。
DeepAgents是"自主智能体层"。它直接架在LangGraph之上，把一套接近Claude Code形态的自主Agent能力打包好了给你：内置文件系统工具（ls、read、write、edit、glob、grep、shell七件套）、子代理（你不指定就默认给你一个general-purpose子代理）、AGENTS.md长期记忆、Skills技能、沙箱执行环境、中间件体系。它回答的问题是"怎么让Agent自己规划、自己拆解任务、长时间自主干活"。
官方还有个很妙的说法：DeepAgents本质上就是LangChain的核心Agent循环，外加一大堆中间件。LangChain官方博客理解了这句话，三层的关系就彻底通了。
LangChain官方在8月6日的文章里，还给三层画了一张"确定性—自主性"光谱图：LangGraph在最左（最大确定性），DeepAgents在最右（最大自主性），LangChain居中。用官方的话说，运行时给你的控制权最大、抽象最少，harness正好相反。LangChain官方博客落到选择上其实就一句话：你需要的确定性越高，越往左走；任务越开放、越难预先画流程，越往右走。
DeepAgents凭什么在这个8月刷屏
DeepAgents火起来，不是营销，是三个信号叠在一起。
第一，社区内容密度突然上来了。判断一个技术方向是不是真热，别看发布会，看有没有人愿意持续写实操。B站《DeepAgents实战》系列从上下文、中间件、文件系统后端，一路讲到子智能体、记忆、沙箱，再到最新一集的PTC，更到第19集还在稳定更新；知乎上有人把DeepAgents Code的28个斜杠命令体系整个拆了一遍。知乎这种密度的UGC，通常意味着真的有人在拿它做东西，而不只是转发官宣。
第二，官方迭代踩在了生产痛点上。DeepAgents在2025年7月底首发，官方给它的初始定位就是一个可定制的通用深度智能体。LangChain官方博客从首发到现在刚一年，它在PyPI上已经发了121个版本，今年明显在加速：5月12日发0.6.0，7月29日发0.7.0，8月6日、8月25日又接连发出0.7.5和0.7.9——最新版0.7.9，就是8月25日晚上刚发的。0.6那个大版本的几个新功能，几乎全是冲着"跑生产环境"去的：
内嵌代码解释器，支持PTC（编程式工具调用）。传统模式下，Agent每调一次工具都要跟模型往返一次，中间结果哪怕只用来算下一步输入，也得走一趟。PTC让Agent直接写代码来调工具，中间结果留在运行时里，不用反复回模型，token消耗和推理步数一起降。知乎安装也简单，PyPI上装`deepagents[quickjs]`，npm上装`@langchain/quickjs`。
开源模型有了Harness配置，成本直接往下打。官方明确说，Kimi K2.6、GLM 5.1、DeepSeek V4这类开放权重模型已经能用于生产级Agent，成本通常比闭源模型低20倍以上。知乎0.6把模型配置提升成了一等公民，可以版本化、可diff。官方还给了组测试数据：仅仅更换Harness层，gpt-5.2-codex在Terminal-Bench 2.0上的得分就从52.8%涨到66.5%，gpt-5.3-codex在tau2-bench上涨20%。模型没换，只是把"怎么驱动模型"这层调对了——这其实是在说，框架层对模型能力的释放，比很多人想象的更重要。
长任务的检查点存储优化（DeltaChannel）。Agent跑得越久，检查点攒得越大。0.6引入增量存储，不再给每个检查点做全量快照，只存差异部分，官方说按对话长度和上下文大小，检查点存储能合理降低10到100倍；对比实验里模拟一个编码智能体连干200轮，不开增量通道要攒下5.27GB的检查点存储，开了之后只需要129MB。知乎跑长任务的人，这条是真金白银。
流式v3。`stream_events(…, version=“v3”)`提供统一事件流，对齐了Agent流式协议，LangGraph SDK也支持通过`client.threads.stream(…)`拉远程事件流。做前端实时渲染的，不用再猜一个chunk到底是文本、推理还是工具调用了。
第三，这套设计正在变成行业共识，不是一家在玩。8月25日那篇文件系统工具链的拆解文章，分析的其实是国内另一个框架的实现，但你会看到一模一样的设计：ls、read、write、edit、glob、grep、shell七件套，工具结果超过上下文限制就转存到文件、给模型留个预览、让它按需读取。知乎连不相关的框架都在收敛到同一套模式，说明"自主Agent该长什么样"这件事，业内已经有了相当稳定的答案。DeepAgents恰好是这个答案里封装得最完整的一个。
选型决策：你的场景该用哪一层
好，回到最实际的问题。对着下面这个路径走一遍，基本就能定位自己：
情况一：你做的是单模型调用加简单工具链。典型场景：问答机器人、结构化信息抽取、单步的RAG检索问答。这种用LangChain就够了，别引图（graph），引了纯属给自己找麻烦。状态机对一个一问一答的场景没有任何价值，只有维护成本。
情况二：你做的是固定流程的多步任务。典型场景：审批链、客服工单流转、需要明确步骤和分支的业务Agent、需要断点续跑的场景。这时候上LangGraph，把流程固化成状态机，检查点和人工介入都给你备好了。官方自己举的例子就很典型：一个租房申请审批流水线，只有第一步用LLM做信息提取，后面的评分、批准、拒绝、转人工全是固定代码。LangChain官方博客关键是——流程是你预先知道的。
情况三：你做的是需要自主规划的长任务。典型场景：研究报告自动生成、代码项目、多智能体协作、过程中会产生大量中间文件、你无法预先画出完整流程。这才是DeepAgents的主场。知乎文件系统工具、子代理、记忆、沙箱，全是为"任务跑很久、中间产物很多、路径不确定"准备的。它的记忆也是双通道的：短期记忆走Checkpointer，跨会话的长期记忆走Store，长任务的状态不会跑着跑着就丢了。
情况四：你重度绑定Claude模型，且不想自己维护编排基建。那可以直接考虑Claude Agent SDK——这正是那篇刷屏文章的选择，它继承的上下文压缩机制确实省事。但往下看一段，先别急着下结论。
先泼两盆冷水：别急着迁
那篇《干掉LangGraph》的文章很火，但评论区比正文更值钱。
文章作者的场景是金融研报自动生成：9份报表×5家公司=45份数据文件，光原始数据就是90万Token起步，而qwen3-max的上下文窗口是256K——连原始数据都装不下，更别提还要留空间给Agent推理和工具调用。知乎于是他迁到了自带五级上下文压缩的Claude Agent SDK。
但评论区两条高赞反驳，值得每一个想迁移的人先读一遍：一条说，数据上限超过context上限，这本来就是设计Agent时应该考虑到的边界；另一条说得更直接，大数据应该通过子代理或者特定工具独立调用、按场景有限汇报，而不是一股脑塞出全部结果——这不是哪个SDK的问题，而是工程经验和架构经验不足的问题。知乎这两条评论点破了一个容易被忽略的事实：上下文管理、子代理隔离、大结果转存，这些模式不依赖任何一个框架。DeepAgents的价值，是把业界验证过的最佳实践打包给你，省掉你自己搭脚手架的时间——比如子代理隔离，DeepAgents Code里已经做成了标配能力，一个任务可以拆出几十个子代理并行干；但如果你不理解这些模式背后的道理，换个框架，该崩还是会崩。那篇文章里作者手搓的文件传递机制，和DeepAgents、Claude Agent SDK内置的机制，思路是同一个——只是人家封装得更完整。
第二盆冷水：DeepAgents不是银弹。引入自主智能体层，意味着Agent的行为不再完全在你的状态机里，调试复杂度会上升，出了问题你得去看它的中间文件、子代理记录、执行轨迹。如果你的场景本来就小、流程本来就清楚，上DeepAgents就是典型的过度工程——用一个自动驾驶系统去开家门口五百米的路。
所以更准确的说法是：不是DeepAgents比LangGraph强，而是它们根本不在一个楼层。拿"自主性"去换"可控性"之前，先确认你的任务真的需要那么多自主性。
接下来值得盯什么
如果你决定跟进这个方向，有几个信号值得放进你的观察清单：
v0.x的迭代速度。一年121个版本，8月刚过半就发了0.7.9，API还在快速演化。现在适合做技术预研和小场景试点，核心生产链路建议等一等。
开源模型Harness配置库的成熟度。如果你用的是Kimi、GLM、DeepSeek，这是最直接的成本变量。官方那个"成本低20倍"的说法值得在你的实际任务上亲手验证一遍，别直接照单全收。
可观测性配套。自主Agent调试难不难，最后拼的是能不能看清它每一步在干嘛。DeepAgents现在跑在LangSmith上做全链路追踪，每一次模型调用、中间件钩子、工具调用的span树都摊开给你看——这条线的集成体验，会直接影响它在生产里到底好不好用。
一句话收尾：LangChain三件套里，LangChain管抽象，LangGraph管流程，DeepAgents管自主。先搞清楚你的任务在哪一层，再决定上不上车——这比追着任何一个新名词跑，都省事得多。
