LangChain、LangGraph、Deep Agents、ADK：Agent开发框架选型指南

做 Agent 开发最近很难绕开 LangChain、LangGraph、Deep Agents 和 ADK 这四个词。我在实际项目里来回切换过也帮团队做过选型评估最直观的感受是这四个词看起来像同一类东西定位其实完全不一样。选错起点后面改起来会很痛苦。这篇文章不打算把官方文档重新抄一遍而是按照实际开发顺序把每个框架解决什么问题、适合什么人、怎么跑通第一个 Demo、遇到报错先查哪里一次讲清楚。文章适合三类人刚接触 Agent 开发想从零弄清楚该学哪个框架的人。已经用 LangChain 写过简单 Agent但遇到状态管理、多分支、人工确认等复杂场景不知道怎么继续的开发者。准备给团队定技术选型需要快速对比权衡的工程师。如果你只是想写一个能调用工具的聊天机器人LangChain 基本够用如果你的流程里有条件路由、循环、人工审批、并行分支建议直接看 LangGraph如果团队想要一个更完整的工程化套件ADK 值得评估而 Deep Agents 更多是一种架构思路适合在项目规模变大之后借鉴。1. 先别急着装库分清楚四个概念的角色1.1 Agent 框架到底在管什么先明确一个基本问题Agent 框架管的事情并不是“大模型本身”而是大模型外围的那些工程杂活。一个能稳定工作的 Agent 至少需要处理下面几件事让模型知道有哪些工具可以用以及工具的参数格式。维护多轮对话的记忆和历史上下文。执行“模型出意图、框架调工具、工具回结果、模型再总结”的循环直到任务完成。在复杂的流程里保留状态支持分步回退、分支判断和人工干预。记录日志、处理超时和重试保证批量任务不会因为一次失败就全部中断。这些能力如果全部自己写不是不行但重复工作很多。Agent 框架的价值就是把这一层公共逻辑抽象好让开发者把精力放在业务上。1.2 四个关键词的定位表先看一张对比表把四个词的核心定位摆出来名称类型主要作用适合场景LangChain组件生态提供模型封装、工具接入、Prompt 管理、文档加载、向量库集成等基础设施快速原型、RAG、简单工具调用LangGraph编排框架用图结构管理 Agent 的状态流、条件分支、循环、子图、并行节点复杂多步流程、需要人工确认或断点恢复的 AgentDeep Agents架构方法强调多层子 Agent 协作和 interrupt 暂停机制更像一套设计模式任务层级复杂、需要不断拆分和复核的场景ADK开发套件提供 Agent 构建、会话状态、工具注册、评估等工程化能力的框架团队希望开箱即用、减少自行组装成本的场景注意LangChain 和 LangGraph 属于同一个生态前者是组件库后者是编排框架。Deep Agents 严格说不是独立安装包而是一套架构思路。ADK 是独立的一套开发套件和 LangChain 生态没有直接关系。1.3 同样叫 ADK可能是三种完全不同的东西这里一定要提醒一下我见过不少人在搜索时被 ADK 这个缩写绕晕。如果你关注的是 AI Agent 开发ADK 通常指 Google 推出的 Agent Development Kit它是一套面向 Python 的 Agent 开发框架。但如果你搜到“Windows ADK”那是微软的评估和部署工具包通常用来制作 Windows 预安装环境也就是 PE和 Agent 开发没有任何关系。如果你搜到类似“qcc514x_qcc304x ADK 20.3 earbud application”这样的内容那是高通蓝牙音频芯片的嵌入式软件开发套件用于耳机固件开发也跟 Agent 框架无关。所以看到 ADK 这三个字母先看上下文。如果材料里出现了“earbud”或“PE”那就是另一个领域的东西不要混进 Agent 技术选型里。这个区分很基础但确实能避免浪费大量时间。2. LangChain 和 LangGraph同生态里的两条技术路线2.1 LangChain 的价值和边界LangChain 发展比较早生态很丰富工具链也很全。大多数入门教程里提到的 Agent、Prompt Template、Document Loader、Vector Store、Output Parser都是 LangChain 生态里的能力。它最适合的场景是快速把大模型接入业务做简单的问答、RAG 检索、单轮工具调用。用现成组件对接 OpenAI、Ollama、各种向量数据库和 API 服务。学习和理解 Agent 的基本循环逻辑。但 LangChain 的短板也很明显。当你需要处理真正的复杂流程时比如某个节点要判断“用户是否还需要追问”或者流程要进入循环等待人工确认或者多个子任务要并行执行后汇总用 LangChain 那种线性的 Chain 写起来会很别扭甚至会因为缺少状态管理而维护困难。我个人的经验是LangChain 适合做“能跑的 Demo”但不太适合做“长期演进的复杂 App”。2.2 LangGraph 为什么更适合复杂 AgentLangGraph 的核心设计是图。一个 Agent 流程被拆成若干个节点节点之间通过边连接边的走向可以由条件函数决定。它天然支持循环模型调用工具之后回到模型节点继续推理。条件分支根据某一步的结果决定走哪条边。子图把一部分流程封装成子图在父图里复用。并行分支多个节点同时执行最后合并结果。状态持久化通过 Checkpointer 保存每一步的状态支持中断后恢复。这种设计最大的好处是整个流程是显式的。流程复杂时你能清楚地看到每一步发生了什么而不是在一个大循环里靠日志猜状态。对于需要人工审批的关键步骤也可以在图里加一个 interrupt 节点等外部确认后再继续往下走。2.3 LangChain 会不会过时社区里经常有人问“LangChain 是不是过时了”。我的判断是LangChain 作为组件生态仍然有价值直接复用它的模型封装、工具扩展和集成能力能省不少事。但如果你还在用老式的 Chain 对象去编排复杂流程那确实应该考虑迁移到 LangGraph。更合理的做法不是二选一而是组合使用用 LangChain 的模型封装和工具装饰器写单个能力。用 LangGraph 把流程编排成图。把 LangChain 的组件作为节点内部的实现细节。这也是很多项目实际采用的路线。别把两个概念对立起来它们本来就是配套的。3. Deep Agents 和 ADK补足 LangChain 生态之外的两个视角3.1 Deep Agents 的 Interrupt 机制到底解决什么Deep Agents 是近两年讨论度很高的 Agent 架构思路。它和普通 Agent 最大的区别在于任务层级不是让一个 Agent 从头跑到尾而是把一个复杂任务分层由高层 Agent 拆解任务交给多个子 Agent 分别执行每一层都能获取上下文和结果关键节点可以暂停等待人类确认。这套思路里最值得关注的是 interrupt 机制。普通 Agent 一旦启动就会一直跑到结束中间出错了很难干预。而 interrupt 让 Agent 在执行到某个关键步骤时停下来把待确认内容交给人工确认之后从断点继续。实际落地中的典型场景财务流程里的支付操作。发送邮件、发布公告等不可撤销动作。调用成本较高的外部服务前的确认。多步骤任务中需要人工补充信息的情况。如果你之前用 LangGraph它本身就支持 interrupt 这种能力。Deep Agents 更像是在这个基础上把“父 Agent 派发任务、子 Agent 执行复核”的组织方式沉淀成一套可复制的架构模式。3.2 ADK 的工程化思路如果你评估的 ADK 是 Agent 开发套件这一类框架它的特点是工程化粒度更重。从公开文档和社区反馈来看它在会话状态管理、工具注册、Agent 之间的协作、输出产物管理和评估模块上都做了封装适合团队直接拿来做产品而不是自己做各种拼装。它和 LangGraph 的关系有点像“一套完整脚手架”和“一块可编程积木”的区别。LangGraph 给你的是底层编排能力你想怎么拼都行但要自己处理很多周围设施ADK 类框架会给你更多现成约定代价是自定义能力可能不如 LangGraph 那么自由。选型时建议评估这几个点团队是否有 Python 工程基础。是否需要和现有模型平台深度集成。你更看重自由度还是更看重开箱即用。团队能否接受框架背后的一些默认约定。3.3 四个方案不是只能选一个我见过不少团队最后用到的组合是LangChain 提供工具和模型接入。LangGraph 做主流程编排。Deep Agents 的思路用于设计多 Agent 层级。在某些标准化模块上评估 ADK 类的套件是否能直接替换。所以别把这个问题理解成“考选择题”。更重要的是理解每个方案擅长什么然后再根据项目阶段选择。前期追求速度就少用框架中期流程复杂就上编排后期要考虑工程化就补检查、评估和可观测性。4. 按场景选型先看任务再看框架4.1 场景一学习入门和快速原型如果是第一次学 Agent 开发不建议直接上太重的方案。先用 LangChain 写一个能调用工具的最小 Agent搞清楚模型工具调用的基本过程再去看 LangGraph 的官方文档。入门阶段建议按这个顺序先理解 ReAct 或类似 Agent 循环的逻辑模型生成意图系统执行工具结果返回模型。用 LangChain 写一个单工具 Agent。跑通之后再用 LangGraph 把同一个流程改写成图。加入条件分支、循环和状态保存。这样学的好处是你会对“框架到底帮你做了什么”有清晰的认知而不是只学会调用一个现成方法。4.2 场景二复杂状态流和多分支如果需求里出现了以下特征直接考虑 LangGraph用户输入不同流程走向不同。同一个 Agent 要反复调用工具再回到模型继续判断。流程需要中途暂停等待人工确认或审批。多个子任务并行执行最后汇总结果。需要支持断点续跑任务执行一半崩溃了还能恢复。LangGraph 在表达这类流程时会比 LangChain 的 Chain 结构干净得多。尤其是团队需要维护半年以上的项目图结构本身就是一份可演进的流程文档。4.3 场景三生产部署和多 Agent 协作生产环境要考虑的不只是能不能跑还要看日志是否完整能不能定位到具体节点。状态是否持久化重启之后能否恢复。并发任务多了之后资源占用和队列情况。工具调用失败时的重试策略。人工确认环节是否有独立的回调接口。LangGraph 配合 Checkpointer 可以解决状态持久化配合外部队列可以解决并发。如果需要更完整的评估和会话管理能力ADK 这类框架也值得做一次对比验证。4.4 一张选型判断清单判断维度建议方向只是快速接一个模型做个问答LangChain 或直接调用模型 SDK有工具调用但流程单一LangChain有循环、分支、人工确认、状态恢复LangGraph任务层级很深需要父子 Agent 协作Deep Agents 思路 LangGraph 实现团队想要开箱即用的工程化套件评估 ADK需要和 LangChain 生态兼容优先 LangGraph这里有个原则框架选择不要超前于需求。一个简单的线性流程没必要为它引入一套复杂的图编排。5. 最小可运行示例从 LangChain 到 LangGraph5.1 环境准备先准备好 Python 环境和依赖。以当前常见的公开 API 风格为例可以安装以下核心包pip install langchain langchain-openai langgraph如果你使用本地模型也可以把 ChatOpenAI 替换为兼容 OpenAI 接口的本地模型服务。实际版本更新速度比较快落地时先确认你本地安装的版本再对照官方文档调整。还需要确认一个可用的模型访问通道并配置好 API Key。我这里只演示最基本的工具调用和流程编排不涉及生产运行所需的复杂配置。5.2 LangChain 的单 Agent 示例这是一个最简单的 React Agent让模型使用一个加法工具from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain.tools import tool tool def add(a: int, b: int) - int: 两个整数相加。 return a b model ChatOpenAI(modelgpt-4o-mini, temperature0) agent create_react_agent(model, [add]) executor AgentExecutor(agentagent, tools[add]) result executor.invoke({input: 请计算 12 加 33 等于多少}) print(result[output])这个示例的重点不是代码本身而是理解运行过程先由模型判断需要调用 add 工具系统执行工具返回 45模型再把结果组织成可读文本。如果你的模型不支持工具调用或者提示词格式不一致这里就会报错或者返回空结果。5.3 LangGraph 的图流程示例同一个流程用 LangGraph 改写先定义一个状态结构再建立节点和边from typing import TypedDict from langgraph.graph import StateGraph, END from langgraph.graph.message import add_messages class AgentState(TypedDict): messages: list def model_node(state: AgentState): response model.invoke(state[messages]) return {messages: [response]} builder StateGraph(AgentState) builder.add_node(model, model_node) builder.add_edge(model, END) builder.set_entry_point(model) app builder.compile() result app.invoke({messages: [{role: user, content: 你好}]}) print(result[messages])这里还没有加入工具节点和条件路由但已经能看出 LangGraph 的基本结构状态对象、节点函数、边连接、编译。真实项目里会在 model 节点之后加一个条件边判断模型是否想调用工具如果调用则进入工具节点否则直接结束。5.4 跑通之后怎么验证结果成功跑通的判断标准不是“没报错”而是下面几项都符合预期模型正确识别了工具调用需求。工具实际执行参数没有解析错误。模型基于工具结果给出了最终回答。多轮调用时历史消息没有丢失。状态里的字段在每一步之后都符合预期。建议先跑单条样例确认输入输出正常再考虑批量任务。一上来就跑大批量如果某个工具参数出错日志会非常难排查。6. 容易搞混的几个概念Skill、MCP、记忆与任务规划6.1 Agent Skill 和 MCP 有何不同社区里经常有人问 Agent Skill 和 MCP 有什么区别。MCP 的完整名称是 Model Context Protocol它解决的是“模型如何标准化地访问外部工具和数据源”这个问题是一套通信协议。Agent Skill 则通常指 Agent 框架内部封装好的一组可复用能力可能包含提示词、工具调用逻辑和参数校验规则。可以这么理解MCP 是“工具怎么接入”的协议层。Skill 是“把一组能力打包成可复用的技能模块”的应用层。实际项目里两者可以共存。一个 Agent 可以通过 MCP 服务器连接外部系统也可以把内部多步操作封装成 Skill 供业务复用。选型时不要把他们看成竞争关系更多是不同层级的抽象。6.2 记忆到底放在哪里Agent 的“记忆”经常被误解。普通聊天记忆只是把历史消息塞进上下文真正的记忆设计要考虑短期记忆会话内消息直接传递给模型。长期记忆从向量库或数据库检索历史事实。状态记忆流程执行到哪一步哪些子任务已完成。在 LangGraph 里状态对象负责保存当前流程信息Checkpointer 负责持久化向量库负责长期知识检索。在设计时不要把三者混在一起记忆策略应该按数据生命周期拆分。6.3 任务规划能力怎么选LangChain 生态里任务规划能力通常通过不同 Agent 模式实现。常见的有单轮工具调用模型直接决定调用哪个工具。ReAct 循环模型边推理边行动。Plan-and-Execute先规划步骤再逐步执行。多 Agent 协作由编排者拆任务分发给子 Agent。选择依据很简单任务越复杂越需要显式的规划和子任务拆分。如果是固定流程用 LangGraph 的节点和条件边就能表达清楚如果流程本身要根据用户需求动态变化就要考虑规划器结合多 Agent 的架构。7. 高频报错与排查链路7.1 Execution Provider 超时很多人在跑 LangChain 时遇到过类似“agent execution provider did not respond in time”的报错。这个报错表面上很吓人实际排查顺序并不复杂先看是不是模型接口超时。检查模型服务的可用性、API Key 是否有效、网络是否稳定。再看工具调用是否耗时过长。如果工具本身要处理大量数据单步执行超过模型服务的超时阈值就会出现超时。检查重试和超时参数。模型客户端可以配置 timeout、max_retries先调大超时时间再试。最后看 AgentExecutor 的迭代次数限制。如果模型反复调用工具停不下来也会触发异常。这类问题通常不是框架的 bug而是环境或参数边界导致的。7.2 图节点改了状态却不生效用 LangGraph 时如果发现节点函数返回了字段但后续节点读取到的值没变一般先检查这几点返回的字典 key 是否和状态定义的字段名完全一致。字段是否配置了 reducer。如果状态里的列表字段没有绑定 add_messages 之类的 reducer默认是覆盖而不是追加。节点是否真的被这条边执行到了。可以在节点里加 print 或日志确认。是否在编译后使用旧对象。重新编译后要用 app.invoke 拿到最新的状态。状态不生效的问题八成不是框架问题而是数据结构定义和 reducer 规则没有对齐。7.3 工具无限循环或输出不符合预期如果 Agent 一直调用同一个工具停不下来优先检查工具的描述是否足够明确。模型是根据描述决定是否调用的描述含糊会导致误判。工具的返回结果是否包含模型需要的最终信息。如果结果里没有直接答案模型会反复尝试。是否设置了最大迭代次数。生产环境一定要设置上限避免模型陷入死循环。输出不符合预期时先看模型原始输出再看框架解析后的结构化结果。很多问题出在输出格式解析失败而不是模型能力不行。7.4 新框架、第三方安装包的来源风险社区里新框架更新很快比如各种名为 Hermes、Agent Scope、Pi Agent 的项目。我的建议是新增依赖前先确认来源优先看官方文档、官方 GitHub 仓库和 PyPI 发布页。不要从第三方下载站点拿所谓“中文官网”的安装包。安装前检查包的维护活跃度、Issue 反馈和许可证。这不是不信任社区而是生产环境依赖安全本来就应该纳入工程规范。越是热门的概念越容易出现山寨站点或仿冒包。8. 我的选择建议先跑通一条完整链路8.1 最小验证清单不管选哪个框架正式定下来之前先拿一个真实业务场景跑通这套链路单任务一个用户请求能够完整处理并返回结果。多轮对话上下文能正确保留模型不会遗忘关键信息。工具调用至少一个工具能被正确触发并返回有效结果。异常输入输入错误或工具失败时程序不会崩溃能给出可理解的错误信息。批量任务连续跑 10 到 20 条任务观察成功率、耗时和资源占用。状态持久化进程重启后Flow 能否从断点恢复。如果这些都能通过再考虑框架之间的横向对比。如果连单条链路都跑不通问题大概率不在框架选型上而是环境、模型接入或输入格式没弄对。8.2 三条推荐落地路线根据项目阶段我通常会给出三条路线快速原型LangChain 一个模型 SDK最小成本验证 Agent 能力是否能满足业务。标准产品LangChain 提供组件LangGraph 做流程编排用 Checkpointer 保存状态加入人工确认节点。工程化平台在 LangGraph 基础上增加队列、日志、监控、评估模块如果团队倾向少封装评估 ADK 类开发套件能否整体替代。没有一条路线适合所有团队。重点是你先要把自己的业务拆清楚流程是否固定、是否需要人工介入、并发量多大、失败重试怎么处理然后才能判断框架是否匹配。8.3 落地时最该盯住的几件事真正把 Agent 放到生产环境后最容易出问题的其实不是框架功能而是这些容易被忽略的工程问题。日志每个节点运行完都要有明确日志否则批量任务出错时根本定位不了。输出命名批量任务每个结果要有独立、可追踪的命名避免覆盖。队列和并发不要一上来就开最大并发先小批量跑观察模型服务和工具服务的极限。失败重试区分可重试错误和不可重试错误不可重试的错误直接进人工队列。资源监控显存、内存、磁盘、网络都要有指标Agent 框架本身不会替你处理这些问题。踩过几次之后你会发现很多项目最后不是被框架限制住的而是前置环境和工程规范没有跟上。框架只是工具真正决定项目上限的是你对流程的理解和对异常处理的设计。我个人更建议先把单任务跑稳再把流程画成图最后才考虑大批量、多 Agent 和工程化封装。这个顺序能让你少走很多弯路。