中文精炼导读

核心观点

  • LangChain 的三个开源框架构成其 agent 技术栈的三层：LangGraph 是 agent 运行时（runtime）、LangChain 是 agent 框架（framework）、Deep Agents 是 agent 外壳（harness）——三者共用一个哲学：构建者应该拥有 agent 的每一部分（模型、上下文、外壳）。
  • 三者的取舍是"控制力 vs 抽象度"的谱系：LangGraph 提供最多控制、最少抽象；Deep Agents 反之。三者完全可组合，可以在层之间移动而不是只能选一个。
  • Deep Agents 是一个开箱即用的外壳，核心工作是"上下文工程"——用文件系统、子代理、技能、记忆等一整套有主见的默认实践，把对的上下文在对的时间交给模型；事实上它只是核心 LangChain agent 加了一堆 middleware。
  • 选择建议很明确：大多数构建者应从 Deep Agents 起步；需要建模复杂工作流或想完全控制每一步时，才下沉到 LangChain 和 LangGraph；RAG 问答这类标准循环用 LangChain，租房申请处理这类"确定性步骤 + LLM 提取"混合流程用 LangGraph。
  • 确定性与自主性需要平衡：越自主价值潜力越大、可靠性代价越高；敏感或预设流程更适合确定性。
LangChain 核心 agent 循环
LangChain 核心 agent 循环

内容精讲

文章开篇用一句话概括三个框架的关系：Deep Agents、LangChain、LangGraph 是开源 agent 技术栈的三个层，构建在同一个理念上——构建者应当能拥有 agent 的每个部分：选择的模型、它看到的上下文、以及运行它的外壳。每一层扮演不同角色、提供不同程度的控制。LangGraph 是运行时，提供最多的控制与最少的抽象；LangChain 是框架，处在中间；Deep Agents 是外壳，提供最多的开箱即用能力与最多的抽象。它们完全可以互相组合，因此选择不是"三选一"，而是"从哪一层开始"。

Deep Agents 是开箱即用的 agent 外壳。外壳的职责是"上下文工程"：在正确的时间把正确的上下文交给模型。Deep Agents 自带一整套最佳实践：文件系统（当你不想把上下文直接塞进 LLM 上下文窗口时，用它读写上下文）、子代理（做专业化工作而不撑大主上下文窗口）、技能（提供指令和脚本，让 agent 按需加载）、记忆（让 agent 跨运行学习改进）。这些是团队持续调研并更新的有主见的上下文管理实践——使用 Deep Agents 的好处之一是你可以相信他们会持续跟踪领域前沿并把最佳实践带进来。上手极简：`create_deep_agent(model=..., tools=[web_search], system_prompt=..., skills=["./skills/"])` 一行就能创建 agent。

LangChain 是 agent 框架，即抽象层与集成层。与 Deep Agents 不同，LangChain 的 agent 抽象极简且没有主见：一个 LLM 在一个循环里反复调用工具——就这么简单。但这个循环虽然简单却极其强大，而真正的价值在于你可以在必要时修改它：比如在上下文接近满时做摘要、或在结尾加一个验证器，通常是为了加入更多确定性步骤。LangChain 的 middleware 提供一组钩子，能以多种方式修改这个循环。文章还揭示了一个有趣的内部事实：Deep Agents 实际上就是核心 LangChain agent 加上一堆 middleware！这使得两层之间的概念距离被拉得很近。LangChain 的使用入口是 `create_agent`，同样只需指定模型、工具和 prompt。

LangGraph 是 agent 运行时：一个基于图的框架，用于自定义 agent 工作流，由耐久的引擎支撑，每一步都有人机协同（human-in-the-loop）、容错和可观测性。把 agent 想成图的收益在于：你可以把更多确定性编码进去，更精确地控制发生的步骤。值得注意的是，LangChain 和 Deep Agents 中看到的 agent 抽象（显示为图）其实都是由 LangGraph 驱动的——它是底层引擎。

选择建议部分给出了三条清晰的指引。第一，Deep Agents：当你想要一个"开箱即用且有能力的 agent"时使用，这是大多数构建者的起点。文章用他们自己构建的 GTM（Go-To-Market）agent 举例：每位销售代表需要记忆（邮件风格偏好、关系理解）、针对 QBR 准备这类重复流程的技能、以及跨通话记录、新闻和 CRM 历史做深度研究的子代理。这不是玩具例子——他们自己就基于 deepagents 构建了 GTM agent，目前每周约 1 万次请求、150 多名活跃用户，其中 26% 流量由用户发起、74% 由"环境型 agent 工作"（定时或事件触发）驱动，用 LangSmith deployments 部署，同时支撑突发流量与计划内运行。

第二，LangChain：当你想要核心构建模块、或打算在其上组装自己的定制外壳时使用。LangChain 的集成和抽象在任意层级都有用——在自定义图里、配合 create_agent、配合 create_deep_agent 都可以。它尤其适合需要细粒度控制"每一步哪些工具和上下文到达模型"的场景，超低延迟应用常有此需求。举例：RAG 文档问答机器人——给定问题，agent 搜索向量库找相关页面，agent 循环判断是否已得到满意答案并驱动直到查询完成。这类 agent 不需要子代理委派或文件系统上下文管理，LangChain 的集成让你插任意向量库当工具、选任意模型，create_agent 提供把它们串起来的循环。

第三，LangGraph：当你的 agent 不适合标准循环、或需要在同一工作流里混搭确定性与 agentic 步骤时使用。举例：租房申请处理流水线——从每份申请提取收入、信用和租赁历史，按房东标准打分，自动批准明显合格者、拒绝明显不合格者、边界情况升级给人工。只有第一步碰 LLM，其余是固定代码；模型只被用来从文档提取信息，不授予它任何能采取行动的工具。这是相对确定性的流水线。文章还给出迁移提示：如果已经在用 LangGraph，且你的流程高度 agentic，迁移到 Deep Agents 可能获益；如果价值在图的形态和确定性步骤上，则留下。最后强调三者可组合：把 create_agent 或 create_deep_agent 塞进更大的 LangGraph 工作流，或把自定义 LangGraph 工作流作为子代理放进 create_agent/create_deep_agent；无论用哪个包构建，都能用 LangSmith deployments 部署、用 LangSmith observability 观察。

文章结尾讨论确定性与自主性的光谱：更多自主权给 agent 带来更大的潜在价值，但以可靠性为代价；对敏感或预设好的工作流，确定性是更优的选择。选择框架本质上是在这条光谱上寻找适合你任务的位置。

阅读价值

适合正在选型 agent 框架、或想理清 LangChain 生态层级的开发者：文章用"运行时/框架/外壳"三层模型和具体用例（GTM agent、RAG 问答、租房申请流水线）把三个框架的定位、取舍与组合方式讲得很清楚；它还给出了一个实用的入门路径——先从 Deep Agents 开始，需要更细控制再下沉。

阅读英文原文 → 返回 AI 技术文档

本文为中文精炼导读,由 AI 基于原文整理,内容与图片版权归原作者所有。原文: https://www.langchain.com/blog/deep-agents-vs-langchain-vs-langgraph