devgo.cn核心观点
- 三个开源框架分属 Agent 技术栈的不同层级：LangGraph 是运行时（控制最多、抽象最少），LangChain 是框架（抽象与集成层），Deep Agents 是 harness（开箱即用的上下文管理最佳实践）。
- 三者完全可组合：Deep Agents 本质上就是核心 LangChain Agent 加一堆中间件，LangGraph 则为 LangChain 与 Deep Agents 的 Agent 提供底层图引擎。
- 选择原则：大多数构建者从 Deep Agents 起步，需要建模复杂工作流或完全控制每一步时再下探到 LangChain 与 LangGraph。
- 实战背书：团队自建的 GTM Agent 就跑在 deepagents 上，每周约 1 万请求、150+ 活跃用户，74% 流量由环境触发的 Agent 工作产生。
内容精讲
LangChain 把自家的三个开源框架摆在一起，给出了一个清晰的判断框架：这不是三选一，而是三层。三者的共同哲学是「构建者拥有 Agent 的每一部分」——自选模型、自控上下文、自持运行 harness。差别只在于你愿意放弃多少控制、换取多少开箱即用的能力。
**Deep Agents：harness，负责上下文工程。** 一个 agent harness 的工作，是通过上下文工程（context engineering）在正确的时间把正确的上下文喂给模型。Deep Agents 把这类最佳实践直接内置：文件系统（不想占上下文窗口时把上下文读写到文件）、子 Agent（做专项工作而不撑爆主上下文）、技能（按需加载的指令与脚本）、记忆（跨运行学习改进）。这些默认配置由团队持续review并更新——用 Deep Agents 的隐含承诺是「上下文管理的最佳实践交给我们」。用法上一条 `create_deep_agent(model=..., tools=[...], system_prompt=..., skills=[...])` 即可。
**LangChain：框架，抽象与集成层。** LangChain 的核心 Agent 抽象极其简单克制——一个 LLM，在一个循环里反复调用工具。这个循环简单但强大；真正的价值在中间件：一组 hook 可以按各种方式修改循环——上下文快满时做摘要、结束时跑验证器、加确定性步骤。最有说服力的注脚是：Deep Agents 其实就是核心 LangChain Agent 加一堆中间件。`create_agent` 是它的入口。
**LangGraph：运行时，图与持久化。** 当你想把更多确定性编码进 Agent、精确控制每一步时，LangGraph 出场。它是基于图的 Agent 运行时，带持久化引擎、human-in-the-loop、故障容错和逐步可观测性。它也是上面两层的地基：LangChain 和 Deep Agents 的 Agent 抽象，最终都渲染为 LangGraph 图来运行。
**怎么选：先上 Deep Agents，需要时再下探。** 规则很直接——大多数构建者应该从 Deep Agents 开始，它有全套开箱即用的能力；当你需要建模复杂工作流、或想完全控制每一个步骤时，再向下用 LangChain 和 LangGraph。举例：做一个 GTM Agent，需要按销售代表记忆（邮件风格偏好、关系理解）、QBR 准备这类重复工作流的技能、以及跨通话记录/新闻/CRM 历史做深度研究的子 Agent——这是 Deep Agents 的标准画像。作者团队的 GTM Agent 确实就这么建的：跑在 deepagents 上，每周近 1 万请求、150+ 活跃用户，26% 用户主动发起、74% 由环境驱动的 Agent 工作（调度/事件触发）贡献，用 LangSmith deployments 部署以支撑突发流量与定时运行的组合。
**选型的本质是控制权光谱。** 运行时最底层给最多控制、最少抽象；harness 给最少控制、最多便利。三层可组合意味着你可以在它们之间自由移动，而不必「押注一家」。对大多数团队，从最高层（Deep Agents）起步、按需下沉，是避免过早工程化的合理路径。
阅读价值
对正在选型 Agent 框架的团队，这篇文章给出了清晰的决策坐标：按「需要多少控制」定位层级，而非按品牌站队；对已经入坑 LangChain 生态的开发者，理解三层结构能显著减少「换个框架重写」的重复劳动。
内容与图片版权归原作者所有 · 原文: https://www.langchain.com/blog/deep-agents-vs-langchain-vs-langgraph