最近不少团队都在评估同一个问题想开始做 Agent 开发LangChain、LangGraph、Deep Agents、ADK 到底该选哪个这个问题之所以难回答是因为这四个名字虽然都被叫做“Agent 框架”但它们解决的问题、代码形态、设计哲学差别非常大。用错框架带来的复杂度往往比不用框架直接调模型还要难受。如果先给一个总判断LangGraph 是最接近“工程化 Agent 大脑”的编排方案Deep Agents 是给单 Agent 任务准备的极简循环范式ADK 是多智能体编排和云生态集成的务实选择而 LangChain 更像一个庞大的工具生态不能简单当成一个框架来理解。下面我会从概念、代码、场景、坑点四个维度展开帮你做一次真正能落地的选型决策。这篇内容会覆盖四个框架的核心模型、环境搭建、最小可运行示例、常见报错和工程化建议。如果你正在给团队做技术选型或者刚接触 Agent 开发想找一条靠谱路径建议收藏后反复对照实践。1. Agent 开发真正难在哪选型解决的是什么问题很多第一次接触 Agent 开发的工程师会有一个错觉Agent 开发就是“给大模型配上工具然后让它多轮调用”。这个理解不完全错但它忽略了 Agent 开发中最核心的复杂度——控制流与状态管理。直接调一个 Chat Completions 接口把工具返回结果塞回上下文看起来很简单。但当你的业务进入真实场景后会出现一系列问题模型输出一个工具调用但工具执行失败下一步怎么办多轮工具调用后上下文越来越长如何管理记忆和窗口一个 Agent 处理不了的任务需要拆成多个子 Agent 协同谁来调度某个环节需要用户确认才能继续Agent 如何“挂起”和“恢复”流程出现死循环如何检测并优雅退出上线之后如何追踪一次完整决策链路排查问题的根源这些问题单独看都容易解决组合在一起就变成了一个典型的工程问题。而 Agent 框架的选型本质上就是选择一套解决“控制流、状态管理、多 Agent 协作、可观测性”的工程范式。所以在选型之前要先明白你要的不是一个“调用大模型的封装库”而是一套能够承载复杂业务逻辑的运行时。不同的框架对这套运行时的理解不同有的把它抽象成“图”有的保留为“循环”有的则选择构建完整的“多智能体运行时”。选型的前提是理解这些设计差异。2. 四个框架的系统定位与设计哲学2.1 LangChain工具生态最全的“百宝箱”LangChain 是 Agent 领域最早火出圈的框架之一它的核心定位是“为大模型应用提供标准化的工具链”。从文档加载、文本切分、向量存储、提示词模板到 Tool 封装、Memory 管理LangChain 几乎涵盖了大模型应用开发的各个层面。LangChain 的底层表达是 LCELLangChain Expression Language这是一种声明式组合语法用来把“模型调用”“工具调用”“输出解析”串成管道。早期版本的 Agent 实现主要依赖 ReAct 思路模型推理一遍决定调用哪个工具拿到结果后再推理直到给出最终答案。这个设计带来的好处是生态庞大网上资料多遇到问题容易找到答案。坏处也很明显抽象层次多、版本迭代频繁、自定义行为时需要浏览大量源码。随着 LangGraph 的成熟LangChain 官方也逐渐把 Agent 的重心转移到 LangGraph 上LangChain 更适合作为“工具库”使用而不是 Agent 运行时的最优选择。2.2 LangGraph用图模型构建可控的 Agent 流程LangGraph 是 LangChain 团队推出的 Agent 编排框架核心思想非常清晰把 Agent 的流程定义成一个状态图StateGraph。节点Node是业务逻辑单元边Edge是状态迁移规则状态State是流动在整个图中的共享数据。这个模型天然支持循环、条件分支、并行节点、子图嵌套正好覆盖了 Agent 开发中最难的控制流问题。和 LangChain 的 Pipeline 式表达不同LangGraph 更接近系统设计里的状态机。你可以把 Agent 的每一步动作显式建模成一个节点把决策规则写成路由函数。正因为这种显式的控制流LangGraph 在复杂业务场景下的可维护性和可观测性明显优于 LangChain。从开源社区的趋势看LangGraph 已经成为 LangChain 生态中做 Agent 开发的首选。如果你需要的是“把一个复杂流程拆解成可控的步骤”LangGraph 是目前社区共识度最高的选择。2.3 Deep Agents把 Agent 回归到极简循环Deep Agents 是 OpenAI Deep Research 团队开源的项目它和 LangChain、LangGraph 是完全不同的风格。Deep Agents 的核心洞察是不管是研究任务、代码分析还是浏览器操作Agent 的本质都可以归纳为一个循环——模型思考、调用工具、观察结果、再思考直到得到最终答案。因此Deep Agents 的设计极度克制。它没有引入复杂的状态机概念也没有庞大的工具链生态只保留了 Agent 循环、内置断言system asserts、挂起interrupt、交接handoff等少数核心抽象。这种“少即是多”的风格带来两个好处一是上手门槛极低代码量少适合快速验证 Agent 想法二是逻辑透明出问题时容易定位。但代价是当你的业务确实需要复杂流程编排时Deep Agents 的表达能力会显得不足你需要自己在循环外面做大量工作。从社区反馈看Deep Agents 最适合的场景是“我们有一个明确的任务目标需要 Agent 自主完成一个相对独立的工作”而不是“我们需要多个 Agent 在复杂规则下协同运转”。补充一点Deep Agents 的官方实现一直在迭代如果你决定使用务必以官方仓库的最新文档为准不要照搬网上过时的示例代码。2.4 ADKGoogle 生态下的多智能体开发套件ADKAgent Development Kit是 Google 推出的 Agent 开发框架。它的定位和前面三个有明显区别ADK 更强调“多智能体编排”和“云生态集成”。ADK 的核心抽象是 Agent 基类你可以组合多个子 Agent 构成树状结构父 Agent 负责判断该把任务交给哪个子 Agent。同时ADK 对 Code Execution代码执行沙箱、MCPModel Context Protocol、Google 搜索、Gemini 模型等做了深度集成。如果你已经在 Google Cloud 上构建应用或者准备基于 Gemini 模型做 Agent 开发ADK 是最顺滑的选择。它降低了调用云服务的成本也天然适配 Google 生态的运维方式。不过ADK 在国内开发者的实际使用中相关中文资料相对较少社区规模和 LangChain 生态还有差距。如果你的团队对多智能体架构要求高且不介意参考英文文档ADK 值得认真评估。3. 核心维度对比四个框架如何选先看一张总表后面再逐步展开说明。维度LangChainLangGraphDeep AgentsADK开发团队LangChain 社区LangChain 团队OpenAI Deep ResearchGoogle核心模型Pipeline / LCEL状态图StateGraphAgent Loop 循环多智能体树状编排编程范式声明式组合图 状态机过程式循环面向对象 回调循环支持较弱强原生支持强核心就是循环中等依赖子 Agent 设计条件分支一般强route 函数通过工具调用实现Agent 间路由多 Agent 协作一般强子图 Supervising支持 Handoff树状多 Agent 强记忆管理内置多种 Memory通过 State 管理上下文累积会话级 Session 管理生态集成极广文档/向量/工具多继承 LangChain 生态轻量偏单 AgentGoogle 云生态、MCP、Code Execution学习成本中高中高低中典型场景文档问答、知识库 RAG复杂业务工作流自主任务型 Agent多智能体 云集成3.1 从“控制流”角度看Agent 开发中最关键的是控制流。如果你看官方文档会发现LangGraph 把控制流建模成图的边和路由函数这种设计在复杂场景下是压倒性的优势。比如你需要“根据用户输入判断走 A 分支还是 B 分支”“执行完后如果结果不满足要求再回到上一步”“并行调用两个子 Agent 后再合并结论”用 LangGraph 实现几乎是直观转换。Deep Agents 的控制流隐藏在循环里。它更接近“给 Agent 一个目标让它自己走完”的思路。对于不需要复杂分支的单 Agent 任务这种设计足够但一旦业务需要人工介入编排节点你会发现自己需要在循环外面做额外的判断逻辑。ADK 的控制流体现在 Agent 之间的路由上父 Agent 决定任务分配子 Agent 返回结果。这种树状结构和 LangGraph 的图模型相比表达复杂流程时稍显受限但理解成本更低。3.2 从“状态管理”角度看状态是 Agent 框架绕不开的问题。LangGraph 的 State 是显式定义的你在写图之前要先定义 State 的数据结构每个节点接收一个 State、返回更新后的部分 State。这种设计让数据流非常透明但也意味着你要付出设计 State 的心智成本。Deep Agents 的状态管理更轻主要通过上下文累积完成。好处是写起来简单坏处是状态一旦变得复杂比如需要区分短期记忆和长期记忆、需要跨会话保留状态你需要自己设计持久化方案。ADK 提供 Session 级别的会话管理在构建多轮对话型 Agent 时会方便很多。LangChain 则内置多种 Memory 实现但它的记忆和 LangGraph 的 State 是不同层面的抽象混用时容易让新手困惑。3.3 从“学习曲线”角度看如果你只看学习曲线Deep Agents 是最友好的概念少、代码短半天就能跑通一个能用的 Agent。LangGraph 和 LangChain 都需要你理解它的核心抽象还要跟上版本迭代速度。ADK 需要同时理解 Agent 基类、Runner、Session 等概念还要适应 Google 生态的思维方式。我的建议是不要因为某一个框架“简单”就直接选它。学习成本应该放在项目维护周期的维度来评估。一个需要长期演进、多人协作的复杂 Agent 系统用 LangGraph 前期的设计投入会回报在后期维护上。4. 环境准备与最小依赖安装在动手写代码之前先把环境准备好。无论你用哪个框架第一步都是创建独立的 Python 环境避免依赖冲突。# 创建并激活虚拟环境 python3 -m venv agent_env source agent_env/bin/activate # 确认 Python 版本建议 3.10 及以上 python --version # 升级 pip pip install --upgrade pip接下来按需安装框架。如果你打算一次评估多个框架建议分开建不同的虚拟环境不要混装在同一个环境里。# 仅评估 LangChain 生态 pip install langchain langchain-openai langchain-community # 仅评估 LangGraph通常需要配合 LangChain 工具 pip install langgraph langchain-openaiDeep Agents 和 ADK 的安装方式同样参考官方仓库说明执行它们对 Python 版本和依赖库有自己的要求直接按照官方文档安装即可。# 仅供参考具体包名以官方仓库 README 为准 # 评估 Deep Agents 时安装对应项目依赖 # 评估 ADK 时安装 Google 官方 ADK 包配置模型 API 时把密钥写入环境变量是比较安全的做法不要硬编码在代码里。# 以 OpenAI 为例写入环境变量 export OPENAI_API_KEYsk-你的密钥 # 以 Gemini 为例 export GOOGLE_API_KEY你的密钥注意不同框架对同一个模型厂商的调用方式略有差异。LangChain 生态统一用langchain-openai这种封装ADK 则默认对接 Gemini 系列Deep Agents 通常直接基于模型 SDK。5. 四个框架的最小可运行示例下面用四个最小示例分别演示“一个能查询天气的 Agent”。为了控制篇幅每个示例只展开核心逻辑完整可运行代码需要你在本地补齐 API Key 和工具函数。5.1 LangChain基于 ReAct 的最简 AgentLangChain 的 Agent 有多种实现方式这里用create_react_agent加AgentExecutor组合一个最简 ReAct Agent。# 文件langchain_agent_demo.py from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain_core.tools import tool # 1. 定义一个工具模拟查询天气 tool def get_weather(city: str) - str: 查询指定城市的天气情况。 # 实际项目中这里会调用天气 API return f{city} 今天晴气温 25 摄氏度。 # 2. 初始化模型和提示词 llm ChatOpenAI(modelgpt-4o-mini, temperature0) tools [get_weather] # 3. 直接使用最简单的 prompt 模板 from langchain_core.prompts import PromptTemplate prompt PromptTemplate.from_template( 你是智能助手。你可以使用工具回答问题。\n 可用工具{tools}\n 工具名{tool_names}\n 用户问题{input}\n 思考过程{agent_scratchpad} ) # 4. 构建并执行 Agent agent create_react_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools) result executor.invoke({input: 北京今天天气怎么样}) print(result[output])这段代码反映了 LangChain 的典型风格你需要组装 Tool、Prompt、Agent 和 Executor。工具函数用tool装饰后即可被模型发现。如果你换用 LangChain 其他 Agent 类型比如 OpenAI Functions Agent写法会不一样。运行方式python langchain_agent_demo.py如果输出中包含天气查询结果说明链路通了。常见的失败原因有两个一是 API Key 没配上二是模型名称与当前账号权限不匹配。5.2 LangGraph用状态图实现 Agent 流程LangGraph 的核心是定义 State、节点和边的迁移。下面用一个“判断是否调用工具”的最小图来演示。# 文件langgraph_agent_demo.py from typing import TypedDict, Literal from langgraph.graph import StateGraph, END # 1. 定义状态结构 class AgentState(TypedDict): question: str need_tool: bool answer: str # 2. 节点判断是否需要调用工具 def decide_need_tool(state: AgentState) - dict: # 真实项目中可以让模型来决定这里用简单规则示意 if 天气 in state[question]: return {need_tool: True} return {need_tool: False} # 3. 节点调用工具并生成回答 def use_tool(state: AgentState) - dict: # 模拟工具返回结果 city state[question].replace(天气怎么样, ).replace(今天, ) return {answer: f{city} 今天晴气温 25 摄氏度。} # 4. 节点不调用工具直接回答 def direct_answer(state: AgentState) - dict: return {answer: f你问的是{state[question]}这个问题不需要工具。} # 5. 路由函数根据状态决定走哪个节点 def route_node(state: AgentState) - Literal[use_tool, direct_answer]: return use_tool if state[need_tool] else direct_answer # 6. 构建状态图 graph StateGraph(AgentState) graph.add_node(decide_need_tool, decide_need_tool) graph.add_node(use_tool, use_tool) graph.add_node(direct_answer, direct_answer) graph.set_entry_point(decide_need_tool) graph.add_conditional_edges(decide_need_tool, route_node) graph.add_edge(use_tool, END) graph.add_edge(direct_answer, END) app graph.compile() # 7. 执行 result app.invoke({question: 北京今天天气怎么样}) print(result[answer])这里的核心是 State 的显式定义decide_need_tool返回的部分状态会被合并进整体 Stateroute_node根据 State 中的need_tool字段路由到不同节点。运行方式python langgraph_agent_demo.py当你的 Agent 流程越来越复杂比如需要循环执行、人工确认、子图嵌套时只需要在这个图模型上不断添加节点和边不需要推倒重来。这也是 LangGraph 在工程维护上的核心价值。5.3 Deep Agents极简 Agent Loop 范式Deep Agents 的核心理念是把 Agent 表达为循环而不是图。官方实现的具体 API 一直在迭代这里我用一个贴近其设计思路的概念性示例来说明。# 文件deep_agents_demo.py # 注意该示例为概念演示实际 API 以官方仓库最新文档为准 class SimpleAgentLoop: def __init__(self, model, tools): self.model model self.tools {tool.__name__: tool for tool in tools} self.messages [] self.max_iterations 5 def run(self, task: str) - str: self.messages.append({role: user, content: task}) for _ in range(self.max_iterations): # 1. 调用模型 response self.model.call(self.messages) # 2. 如果模型给出了最终答案退出循环 if response.is_final_answer: return response.content # 3. 如果模型请求调用工具 if response.requires_tool: tool_name response.tool_name tool_args response.tool_args # 执行工具 result self.tools[tool_name](**tool_args) # 把工具结果放回上下文 self.messages.append({ role: tool, tool_name: tool_name, content: result, }) # 4. 超过最大轮数强制退出 return 超出最大迭代次数任务中止。这种循环结构非常容易理解也很容易改造成异步版本或加入更复杂的退出条件。Deep Agents 团队真正花心思的地方在于 prompt 设计、工具调用时的错误恢复、多 Agent 的 handoff 机制而不是提供一个庞大的抽象层。如果你使用官方实现很快会发现它的代码量和维护成本明显小于 LangGraph。这是刻意的设计取舍不是功能缺失。5.4 ADKAgent Runner 的组合式开发ADK 的核心设计是“定义 Agent然后通过 Runner 运行”。下面是一个最小示例展示 ADK 的基本用法。API 名称可能随版本调整使用前务必查阅官方文档。# 文件adk_demo.py # 注意具体类名和导入路径以 Google ADK 官方文档为准 from google.adk.agents import Agent from google.adk.runner import Runner # 1. 创建一个最简 Agent agent Agent( nameweather_assistant, modelgemini-2.0-flash, # 模型名以你的实际可用模型为准 instruction你是一个天气助手。用户问天气时你可以调用工具查询。, ) # 2. 创建 Runner负责执行 Agent runner Runner( agentagent, app_nameweather_agent_app, ) # 3. 运行一次对话 response runner.run( user_iduser_123, session_idsession_456, message北京现在热吗, ) # 4. 获取结果 print(response.output_text)ADK 的亮点在于当你有多个 Agent 时可以定义父 Agent 和子 Agent通过sub_agents参数组合让父 Agent 根据用户意图把任务交给对应的子 Agent。这种树状结构在多领域助手场景下非常合适。如果你的业务已经用了 Google CloudADK 的部署、日志、监控和云服务集成是很大的加分项。如果你主要用国内云厂商或 OpenAI 系列模型ADK 的集成优势会弱一些。6. 不同业务场景下的选型建议框架对比之后关键要落到“你的业务到底属于哪种场景”。我从实际项目类型出发给出四类常见场景的选型建议。6.1 复杂业务工作流必须控制每一步典型特征流程固定分支多需要审计某个环节可能需要人工审批。例如工单自动处理、金融业务审核、运维故障自愈。这类场景最匹配的是 LangGraph。它的 StateGraph 模型让你把业务规则显式建模成节点和边每一步的输入输出都有明确的数据结构出问题时可以从日志里还原完整执行链路。条件分支、循环回溯、人工确认这些需求在 LangGraph 里都有对应的原生方案。6.2 独立任务型 Agent希望快速上线典型特征任务目标单一明确比如“从 50 个网页里提取产品价格表”“把一份 PDF 转换成结构化 JSON”“自动生成竞品分析报告”。这种任务不需要反复编排流程更看重 Agent 自主决策能力。这类场景选 Deep Agents 更合适。它的极简设计让你能快速跑到可演示状态而且后续换模型、加工具都不需要改框架层面的东西。如果你的团队还处于 Agent 能力验证阶段Deep Agents 能帮你用最小成本判断方向是否正确。6.3 多智能体协作需要任务分配和上下文隔离典型特征系统包含多个专业子助手比如一个智能客服里既有订单助手、售后助手又有商品推荐助手。父级 Agent 需要先理解用户意图再决定交给哪个子 Agent 处理。多智能体协作方面ADK 和 LangGraph 都是强项。选择的关键在于你的周边生态如果模型已经锁定 Gemini并且后续要上 Google Cloud 的运维体系选 ADK如果团队更熟悉 LangChain 生态或者模型用的是 OpenAI 系选 LangGraph。6.4 知识库问答和 RAG 型 Agent典型特征核心能力是文档处理、向量检索、重排、引用溯源Agent 的“决策”复杂程度较低但资料处理和检索链路很重。这类场景依然是 LangChain 生态的优势区。文档加载器、文本切分器、向量库对接、检索融合等组件丰富社区案例多遇到问题容易找到答案在此基础上如果还需要一定的 Agent 控制流可以再用 LangGraph 做上层编排。7. 常见问题与排查思路7.1 框架版本频繁升级导致示例跑不通这是 Agent 框架开发中最常遇到的问题。LangChain、LangGraph、Deep Agents、ADK 都处于快速迭代阶段你搜到的教程很可能是半年甚至两个月前写的API 名称和包结构已经变了。问题现象可能原因排查方式解决方案ImportError 找不到模块版本变化导致包名变更查看官方 changelog 和迁移文档锁定版本以官方最新示例为准模型响应格式解析失败底层模型 SDK 升级查看模型响应原始 JSON升级框架版本或固定模型 SDK 版本Agent 不调用工具prompt 模板不够明确或工具描述不清晰打印模型完整输出观察思考过程优化工具描述和 prompt加入 few-shot 示例7.2 Agent 陷入死循环LangGraph 和 Deep Agents 这种支持循环的框架死循环是很容易出现的问题。原因通常是模型反复调用同一个工具工具返回的结果没有让状态发生本质变化模型无法判断该停止。问题现象可能原因排查方式解决方案日志显示工具被反复调用模型没有从结果中提取到关键信息把工具返回结构化 JSON设置最大迭代次数增加终止条件判断子图返回后父图又进入相同分支路由条件缺少状态标记检查 State 中是否有区分阶段的字段在 State 中加入 round 或 stage 字段多 Agent 相互交接停不下来handoff 目标选择错误检查子 Agent 返回的意图限制交接层级设置全局最大轮数7.3 上下文过长导致模型效果下降Agent 循环中每轮工具调用都会往上下文里追加内容。十几轮之后输入长度可能超过模型窗口或者模型被无关信息干扰。问题现象可能原因排查方式解决方案模型回答越来越差上下文被工具返回结果污染统计每轮 token 消耗精简工具返回内容只保留关键字段API 报上下文超限累计输入超过模型窗口查看错误码和 token 计数增加上下文截断或摘要节点7.4 ADK Runner 调用失败ADK 的使用方式和 LangChain 系列差异较大Runner 的初始化参数、Session 管理方式如果不按当前版本文档来很容易报错。遇到问题先看官方仓库的 issue 区这是最快路径。8. Agent 框架上线的工程化建议8.1 先把流程画出来再写图代码不管选 LangGraph 还是 ADK动手写代码之前建议先把你心中理想的 Agent 流程用文字或图形梳理清楚用户输入进来第一步做什么判断条件是什么失败怎么处理哪些环节需要人工介入。这个步骤和数据库建模的道理一样——前期梳理得越清楚后期改图的成本越低。8.2 状态设计要克制只放真正需要共享的数据LangGraph 的 State 是所有节点共享的如果你把大段的工具返回结果全部塞进 State很快会面临上下文膨胀和字段冲突的问题。更好的做法是工具返回后先做信息提取只把结构化摘要放到 State 里原始结果写入外部存储。8.3 给工具命名的标准要统一Agent 模型靠工具名和描述来决定是否调用。工具名称要直观描述要写清楚“什么场景下使用、输入什么参数、输出什么格式”。如果多个工具的功能边界模糊模型很容易选错。建议团队内部建立工具描述模板。8.4 日志和追踪是 Agent 项目的第一基础设施Agent 的不确定性意味着你必须能回答“这次请求为什么走了 A 分支而不是 B 分支”。LangGraph 的日志能展示节点流转但是不够精细。建议在上线前接入一套完整的追踪系统记录模型输入输出、工具调用参数与结果、节点切换原因。这部分的投资回报率非常高。8.5 不要过度设计先跑通最小闭环很多团队一上来就设计复杂的多 Agent 架构结果连一个 Agent 都还不稳定。更稳妥的推进路径是先用一个最简 Agent 把核心链路跑通再逐步拆分节点、添加分支、引入多 Agent。每一次拆分都要有明确收益不要为了架构而架构。8.6 锁定依赖版本构建可复现环境Agent 框架迭代速度极快项目配置文件里务必锁定核心依赖的精确版本并保留安装时间记录。否则两周后再跑同一套代码结果可能完全不同。生产环境中还需要把依赖锁文件纳入版本管理。9. 总结与下一步实践建议现在回到最初的选型问题LangChain、LangGraph、Deep Agents、ADK 到底怎么选如果你需要做知识库问答、RAG 或快速原型LangChain 生态仍然是资源最丰富的起点如果你的业务有明确的流程分支、状态流转和审计需求LangGraph 是当前最值得投入的工程化方案如果你是在验证一个“目标明确、靠模型自主跑完”的单 Agent 任务Deep Agents 的低门槛能帮你更快得到答案如果你更看好 Google 生态或者需要天然的多智能体树状协作和云集成ADK 值得认真研究。没有最好的框架只有最匹配业务的框架。选型时不要被框架的噱头带偏重点评估三点团队的技术基础、业务的流程复杂度、后期的维护成本。下一步建议非常直接不要停留在对比文档的阶段直接用真实业务场景里的一个小任务做 PoC。一个任务用四个框架各实现一遍你会比看任何对比文章都更清楚差异。跑通 PoC 之后再思考如何把日志、追踪、状态管理这些工程能力补上去。Agent 开发的竞争力终究来自工程化的深度而不是某个框架的新鲜感。 Agent开发框架选型指南：LangChain、LangGraph、Deep Agents与ADK对比
最近不少团队都在评估同一个问题想开始做 Agent 开发LangChain、LangGraph、Deep Agents、ADK 到底该选哪个这个问题之所以难回答是因为这四个名字虽然都被叫做“Agent 框架”但它们解决的问题、代码形态、设计哲学差别非常大。用错框架带来的复杂度往往比不用框架直接调模型还要难受。如果先给一个总判断LangGraph 是最接近“工程化 Agent 大脑”的编排方案Deep Agents 是给单 Agent 任务准备的极简循环范式ADK 是多智能体编排和云生态集成的务实选择而 LangChain 更像一个庞大的工具生态不能简单当成一个框架来理解。下面我会从概念、代码、场景、坑点四个维度展开帮你做一次真正能落地的选型决策。这篇内容会覆盖四个框架的核心模型、环境搭建、最小可运行示例、常见报错和工程化建议。如果你正在给团队做技术选型或者刚接触 Agent 开发想找一条靠谱路径建议收藏后反复对照实践。1. Agent 开发真正难在哪选型解决的是什么问题很多第一次接触 Agent 开发的工程师会有一个错觉Agent 开发就是“给大模型配上工具然后让它多轮调用”。这个理解不完全错但它忽略了 Agent 开发中最核心的复杂度——控制流与状态管理。直接调一个 Chat Completions 接口把工具返回结果塞回上下文看起来很简单。但当你的业务进入真实场景后会出现一系列问题模型输出一个工具调用但工具执行失败下一步怎么办多轮工具调用后上下文越来越长如何管理记忆和窗口一个 Agent 处理不了的任务需要拆成多个子 Agent 协同谁来调度某个环节需要用户确认才能继续Agent 如何“挂起”和“恢复”流程出现死循环如何检测并优雅退出上线之后如何追踪一次完整决策链路排查问题的根源这些问题单独看都容易解决组合在一起就变成了一个典型的工程问题。而 Agent 框架的选型本质上就是选择一套解决“控制流、状态管理、多 Agent 协作、可观测性”的工程范式。所以在选型之前要先明白你要的不是一个“调用大模型的封装库”而是一套能够承载复杂业务逻辑的运行时。不同的框架对这套运行时的理解不同有的把它抽象成“图”有的保留为“循环”有的则选择构建完整的“多智能体运行时”。选型的前提是理解这些设计差异。2. 四个框架的系统定位与设计哲学2.1 LangChain工具生态最全的“百宝箱”LangChain 是 Agent 领域最早火出圈的框架之一它的核心定位是“为大模型应用提供标准化的工具链”。从文档加载、文本切分、向量存储、提示词模板到 Tool 封装、Memory 管理LangChain 几乎涵盖了大模型应用开发的各个层面。LangChain 的底层表达是 LCELLangChain Expression Language这是一种声明式组合语法用来把“模型调用”“工具调用”“输出解析”串成管道。早期版本的 Agent 实现主要依赖 ReAct 思路模型推理一遍决定调用哪个工具拿到结果后再推理直到给出最终答案。这个设计带来的好处是生态庞大网上资料多遇到问题容易找到答案。坏处也很明显抽象层次多、版本迭代频繁、自定义行为时需要浏览大量源码。随着 LangGraph 的成熟LangChain 官方也逐渐把 Agent 的重心转移到 LangGraph 上LangChain 更适合作为“工具库”使用而不是 Agent 运行时的最优选择。2.2 LangGraph用图模型构建可控的 Agent 流程LangGraph 是 LangChain 团队推出的 Agent 编排框架核心思想非常清晰把 Agent 的流程定义成一个状态图StateGraph。节点Node是业务逻辑单元边Edge是状态迁移规则状态State是流动在整个图中的共享数据。这个模型天然支持循环、条件分支、并行节点、子图嵌套正好覆盖了 Agent 开发中最难的控制流问题。和 LangChain 的 Pipeline 式表达不同LangGraph 更接近系统设计里的状态机。你可以把 Agent 的每一步动作显式建模成一个节点把决策规则写成路由函数。正因为这种显式的控制流LangGraph 在复杂业务场景下的可维护性和可观测性明显优于 LangChain。从开源社区的趋势看LangGraph 已经成为 LangChain 生态中做 Agent 开发的首选。如果你需要的是“把一个复杂流程拆解成可控的步骤”LangGraph 是目前社区共识度最高的选择。2.3 Deep Agents把 Agent 回归到极简循环Deep Agents 是 OpenAI Deep Research 团队开源的项目它和 LangChain、LangGraph 是完全不同的风格。Deep Agents 的核心洞察是不管是研究任务、代码分析还是浏览器操作Agent 的本质都可以归纳为一个循环——模型思考、调用工具、观察结果、再思考直到得到最终答案。因此Deep Agents 的设计极度克制。它没有引入复杂的状态机概念也没有庞大的工具链生态只保留了 Agent 循环、内置断言system asserts、挂起interrupt、交接handoff等少数核心抽象。这种“少即是多”的风格带来两个好处一是上手门槛极低代码量少适合快速验证 Agent 想法二是逻辑透明出问题时容易定位。但代价是当你的业务确实需要复杂流程编排时Deep Agents 的表达能力会显得不足你需要自己在循环外面做大量工作。从社区反馈看Deep Agents 最适合的场景是“我们有一个明确的任务目标需要 Agent 自主完成一个相对独立的工作”而不是“我们需要多个 Agent 在复杂规则下协同运转”。补充一点Deep Agents 的官方实现一直在迭代如果你决定使用务必以官方仓库的最新文档为准不要照搬网上过时的示例代码。2.4 ADKGoogle 生态下的多智能体开发套件ADKAgent Development Kit是 Google 推出的 Agent 开发框架。它的定位和前面三个有明显区别ADK 更强调“多智能体编排”和“云生态集成”。ADK 的核心抽象是 Agent 基类你可以组合多个子 Agent 构成树状结构父 Agent 负责判断该把任务交给哪个子 Agent。同时ADK 对 Code Execution代码执行沙箱、MCPModel Context Protocol、Google 搜索、Gemini 模型等做了深度集成。如果你已经在 Google Cloud 上构建应用或者准备基于 Gemini 模型做 Agent 开发ADK 是最顺滑的选择。它降低了调用云服务的成本也天然适配 Google 生态的运维方式。不过ADK 在国内开发者的实际使用中相关中文资料相对较少社区规模和 LangChain 生态还有差距。如果你的团队对多智能体架构要求高且不介意参考英文文档ADK 值得认真评估。3. 核心维度对比四个框架如何选先看一张总表后面再逐步展开说明。维度LangChainLangGraphDeep AgentsADK开发团队LangChain 社区LangChain 团队OpenAI Deep ResearchGoogle核心模型Pipeline / LCEL状态图StateGraphAgent Loop 循环多智能体树状编排编程范式声明式组合图 状态机过程式循环面向对象 回调循环支持较弱强原生支持强核心就是循环中等依赖子 Agent 设计条件分支一般强route 函数通过工具调用实现Agent 间路由多 Agent 协作一般强子图 Supervising支持 Handoff树状多 Agent 强记忆管理内置多种 Memory通过 State 管理上下文累积会话级 Session 管理生态集成极广文档/向量/工具多继承 LangChain 生态轻量偏单 AgentGoogle 云生态、MCP、Code Execution学习成本中高中高低中典型场景文档问答、知识库 RAG复杂业务工作流自主任务型 Agent多智能体 云集成3.1 从“控制流”角度看Agent 开发中最关键的是控制流。如果你看官方文档会发现LangGraph 把控制流建模成图的边和路由函数这种设计在复杂场景下是压倒性的优势。比如你需要“根据用户输入判断走 A 分支还是 B 分支”“执行完后如果结果不满足要求再回到上一步”“并行调用两个子 Agent 后再合并结论”用 LangGraph 实现几乎是直观转换。Deep Agents 的控制流隐藏在循环里。它更接近“给 Agent 一个目标让它自己走完”的思路。对于不需要复杂分支的单 Agent 任务这种设计足够但一旦业务需要人工介入编排节点你会发现自己需要在循环外面做额外的判断逻辑。ADK 的控制流体现在 Agent 之间的路由上父 Agent 决定任务分配子 Agent 返回结果。这种树状结构和 LangGraph 的图模型相比表达复杂流程时稍显受限但理解成本更低。3.2 从“状态管理”角度看状态是 Agent 框架绕不开的问题。LangGraph 的 State 是显式定义的你在写图之前要先定义 State 的数据结构每个节点接收一个 State、返回更新后的部分 State。这种设计让数据流非常透明但也意味着你要付出设计 State 的心智成本。Deep Agents 的状态管理更轻主要通过上下文累积完成。好处是写起来简单坏处是状态一旦变得复杂比如需要区分短期记忆和长期记忆、需要跨会话保留状态你需要自己设计持久化方案。ADK 提供 Session 级别的会话管理在构建多轮对话型 Agent 时会方便很多。LangChain 则内置多种 Memory 实现但它的记忆和 LangGraph 的 State 是不同层面的抽象混用时容易让新手困惑。3.3 从“学习曲线”角度看如果你只看学习曲线Deep Agents 是最友好的概念少、代码短半天就能跑通一个能用的 Agent。LangGraph 和 LangChain 都需要你理解它的核心抽象还要跟上版本迭代速度。ADK 需要同时理解 Agent 基类、Runner、Session 等概念还要适应 Google 生态的思维方式。我的建议是不要因为某一个框架“简单”就直接选它。学习成本应该放在项目维护周期的维度来评估。一个需要长期演进、多人协作的复杂 Agent 系统用 LangGraph 前期的设计投入会回报在后期维护上。4. 环境准备与最小依赖安装在动手写代码之前先把环境准备好。无论你用哪个框架第一步都是创建独立的 Python 环境避免依赖冲突。# 创建并激活虚拟环境 python3 -m venv agent_env source agent_env/bin/activate # 确认 Python 版本建议 3.10 及以上 python --version # 升级 pip pip install --upgrade pip接下来按需安装框架。如果你打算一次评估多个框架建议分开建不同的虚拟环境不要混装在同一个环境里。# 仅评估 LangChain 生态 pip install langchain langchain-openai langchain-community # 仅评估 LangGraph通常需要配合 LangChain 工具 pip install langgraph langchain-openaiDeep Agents 和 ADK 的安装方式同样参考官方仓库说明执行它们对 Python 版本和依赖库有自己的要求直接按照官方文档安装即可。# 仅供参考具体包名以官方仓库 README 为准 # 评估 Deep Agents 时安装对应项目依赖 # 评估 ADK 时安装 Google 官方 ADK 包配置模型 API 时把密钥写入环境变量是比较安全的做法不要硬编码在代码里。# 以 OpenAI 为例写入环境变量 export OPENAI_API_KEYsk-你的密钥 # 以 Gemini 为例 export GOOGLE_API_KEY你的密钥注意不同框架对同一个模型厂商的调用方式略有差异。LangChain 生态统一用langchain-openai这种封装ADK 则默认对接 Gemini 系列Deep Agents 通常直接基于模型 SDK。5. 四个框架的最小可运行示例下面用四个最小示例分别演示“一个能查询天气的 Agent”。为了控制篇幅每个示例只展开核心逻辑完整可运行代码需要你在本地补齐 API Key 和工具函数。5.1 LangChain基于 ReAct 的最简 AgentLangChain 的 Agent 有多种实现方式这里用create_react_agent加AgentExecutor组合一个最简 ReAct Agent。# 文件langchain_agent_demo.py from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain_core.tools import tool # 1. 定义一个工具模拟查询天气 tool def get_weather(city: str) - str: 查询指定城市的天气情况。 # 实际项目中这里会调用天气 API return f{city} 今天晴气温 25 摄氏度。 # 2. 初始化模型和提示词 llm ChatOpenAI(modelgpt-4o-mini, temperature0) tools [get_weather] # 3. 直接使用最简单的 prompt 模板 from langchain_core.prompts import PromptTemplate prompt PromptTemplate.from_template( 你是智能助手。你可以使用工具回答问题。\n 可用工具{tools}\n 工具名{tool_names}\n 用户问题{input}\n 思考过程{agent_scratchpad} ) # 4. 构建并执行 Agent agent create_react_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools) result executor.invoke({input: 北京今天天气怎么样}) print(result[output])这段代码反映了 LangChain 的典型风格你需要组装 Tool、Prompt、Agent 和 Executor。工具函数用tool装饰后即可被模型发现。如果你换用 LangChain 其他 Agent 类型比如 OpenAI Functions Agent写法会不一样。运行方式python langchain_agent_demo.py如果输出中包含天气查询结果说明链路通了。常见的失败原因有两个一是 API Key 没配上二是模型名称与当前账号权限不匹配。5.2 LangGraph用状态图实现 Agent 流程LangGraph 的核心是定义 State、节点和边的迁移。下面用一个“判断是否调用工具”的最小图来演示。# 文件langgraph_agent_demo.py from typing import TypedDict, Literal from langgraph.graph import StateGraph, END # 1. 定义状态结构 class AgentState(TypedDict): question: str need_tool: bool answer: str # 2. 节点判断是否需要调用工具 def decide_need_tool(state: AgentState) - dict: # 真实项目中可以让模型来决定这里用简单规则示意 if 天气 in state[question]: return {need_tool: True} return {need_tool: False} # 3. 节点调用工具并生成回答 def use_tool(state: AgentState) - dict: # 模拟工具返回结果 city state[question].replace(天气怎么样, ).replace(今天, ) return {answer: f{city} 今天晴气温 25 摄氏度。} # 4. 节点不调用工具直接回答 def direct_answer(state: AgentState) - dict: return {answer: f你问的是{state[question]}这个问题不需要工具。} # 5. 路由函数根据状态决定走哪个节点 def route_node(state: AgentState) - Literal[use_tool, direct_answer]: return use_tool if state[need_tool] else direct_answer # 6. 构建状态图 graph StateGraph(AgentState) graph.add_node(decide_need_tool, decide_need_tool) graph.add_node(use_tool, use_tool) graph.add_node(direct_answer, direct_answer) graph.set_entry_point(decide_need_tool) graph.add_conditional_edges(decide_need_tool, route_node) graph.add_edge(use_tool, END) graph.add_edge(direct_answer, END) app graph.compile() # 7. 执行 result app.invoke({question: 北京今天天气怎么样}) print(result[answer])这里的核心是 State 的显式定义decide_need_tool返回的部分状态会被合并进整体 Stateroute_node根据 State 中的need_tool字段路由到不同节点。运行方式python langgraph_agent_demo.py当你的 Agent 流程越来越复杂比如需要循环执行、人工确认、子图嵌套时只需要在这个图模型上不断添加节点和边不需要推倒重来。这也是 LangGraph 在工程维护上的核心价值。5.3 Deep Agents极简 Agent Loop 范式Deep Agents 的核心理念是把 Agent 表达为循环而不是图。官方实现的具体 API 一直在迭代这里我用一个贴近其设计思路的概念性示例来说明。# 文件deep_agents_demo.py # 注意该示例为概念演示实际 API 以官方仓库最新文档为准 class SimpleAgentLoop: def __init__(self, model, tools): self.model model self.tools {tool.__name__: tool for tool in tools} self.messages [] self.max_iterations 5 def run(self, task: str) - str: self.messages.append({role: user, content: task}) for _ in range(self.max_iterations): # 1. 调用模型 response self.model.call(self.messages) # 2. 如果模型给出了最终答案退出循环 if response.is_final_answer: return response.content # 3. 如果模型请求调用工具 if response.requires_tool: tool_name response.tool_name tool_args response.tool_args # 执行工具 result self.tools[tool_name](**tool_args) # 把工具结果放回上下文 self.messages.append({ role: tool, tool_name: tool_name, content: result, }) # 4. 超过最大轮数强制退出 return 超出最大迭代次数任务中止。这种循环结构非常容易理解也很容易改造成异步版本或加入更复杂的退出条件。Deep Agents 团队真正花心思的地方在于 prompt 设计、工具调用时的错误恢复、多 Agent 的 handoff 机制而不是提供一个庞大的抽象层。如果你使用官方实现很快会发现它的代码量和维护成本明显小于 LangGraph。这是刻意的设计取舍不是功能缺失。5.4 ADKAgent Runner 的组合式开发ADK 的核心设计是“定义 Agent然后通过 Runner 运行”。下面是一个最小示例展示 ADK 的基本用法。API 名称可能随版本调整使用前务必查阅官方文档。# 文件adk_demo.py # 注意具体类名和导入路径以 Google ADK 官方文档为准 from google.adk.agents import Agent from google.adk.runner import Runner # 1. 创建一个最简 Agent agent Agent( nameweather_assistant, modelgemini-2.0-flash, # 模型名以你的实际可用模型为准 instruction你是一个天气助手。用户问天气时你可以调用工具查询。, ) # 2. 创建 Runner负责执行 Agent runner Runner( agentagent, app_nameweather_agent_app, ) # 3. 运行一次对话 response runner.run( user_iduser_123, session_idsession_456, message北京现在热吗, ) # 4. 获取结果 print(response.output_text)ADK 的亮点在于当你有多个 Agent 时可以定义父 Agent 和子 Agent通过sub_agents参数组合让父 Agent 根据用户意图把任务交给对应的子 Agent。这种树状结构在多领域助手场景下非常合适。如果你的业务已经用了 Google CloudADK 的部署、日志、监控和云服务集成是很大的加分项。如果你主要用国内云厂商或 OpenAI 系列模型ADK 的集成优势会弱一些。6. 不同业务场景下的选型建议框架对比之后关键要落到“你的业务到底属于哪种场景”。我从实际项目类型出发给出四类常见场景的选型建议。6.1 复杂业务工作流必须控制每一步典型特征流程固定分支多需要审计某个环节可能需要人工审批。例如工单自动处理、金融业务审核、运维故障自愈。这类场景最匹配的是 LangGraph。它的 StateGraph 模型让你把业务规则显式建模成节点和边每一步的输入输出都有明确的数据结构出问题时可以从日志里还原完整执行链路。条件分支、循环回溯、人工确认这些需求在 LangGraph 里都有对应的原生方案。6.2 独立任务型 Agent希望快速上线典型特征任务目标单一明确比如“从 50 个网页里提取产品价格表”“把一份 PDF 转换成结构化 JSON”“自动生成竞品分析报告”。这种任务不需要反复编排流程更看重 Agent 自主决策能力。这类场景选 Deep Agents 更合适。它的极简设计让你能快速跑到可演示状态而且后续换模型、加工具都不需要改框架层面的东西。如果你的团队还处于 Agent 能力验证阶段Deep Agents 能帮你用最小成本判断方向是否正确。6.3 多智能体协作需要任务分配和上下文隔离典型特征系统包含多个专业子助手比如一个智能客服里既有订单助手、售后助手又有商品推荐助手。父级 Agent 需要先理解用户意图再决定交给哪个子 Agent 处理。多智能体协作方面ADK 和 LangGraph 都是强项。选择的关键在于你的周边生态如果模型已经锁定 Gemini并且后续要上 Google Cloud 的运维体系选 ADK如果团队更熟悉 LangChain 生态或者模型用的是 OpenAI 系选 LangGraph。6.4 知识库问答和 RAG 型 Agent典型特征核心能力是文档处理、向量检索、重排、引用溯源Agent 的“决策”复杂程度较低但资料处理和检索链路很重。这类场景依然是 LangChain 生态的优势区。文档加载器、文本切分器、向量库对接、检索融合等组件丰富社区案例多遇到问题容易找到答案在此基础上如果还需要一定的 Agent 控制流可以再用 LangGraph 做上层编排。7. 常见问题与排查思路7.1 框架版本频繁升级导致示例跑不通这是 Agent 框架开发中最常遇到的问题。LangChain、LangGraph、Deep Agents、ADK 都处于快速迭代阶段你搜到的教程很可能是半年甚至两个月前写的API 名称和包结构已经变了。问题现象可能原因排查方式解决方案ImportError 找不到模块版本变化导致包名变更查看官方 changelog 和迁移文档锁定版本以官方最新示例为准模型响应格式解析失败底层模型 SDK 升级查看模型响应原始 JSON升级框架版本或固定模型 SDK 版本Agent 不调用工具prompt 模板不够明确或工具描述不清晰打印模型完整输出观察思考过程优化工具描述和 prompt加入 few-shot 示例7.2 Agent 陷入死循环LangGraph 和 Deep Agents 这种支持循环的框架死循环是很容易出现的问题。原因通常是模型反复调用同一个工具工具返回的结果没有让状态发生本质变化模型无法判断该停止。问题现象可能原因排查方式解决方案日志显示工具被反复调用模型没有从结果中提取到关键信息把工具返回结构化 JSON设置最大迭代次数增加终止条件判断子图返回后父图又进入相同分支路由条件缺少状态标记检查 State 中是否有区分阶段的字段在 State 中加入 round 或 stage 字段多 Agent 相互交接停不下来handoff 目标选择错误检查子 Agent 返回的意图限制交接层级设置全局最大轮数7.3 上下文过长导致模型效果下降Agent 循环中每轮工具调用都会往上下文里追加内容。十几轮之后输入长度可能超过模型窗口或者模型被无关信息干扰。问题现象可能原因排查方式解决方案模型回答越来越差上下文被工具返回结果污染统计每轮 token 消耗精简工具返回内容只保留关键字段API 报上下文超限累计输入超过模型窗口查看错误码和 token 计数增加上下文截断或摘要节点7.4 ADK Runner 调用失败ADK 的使用方式和 LangChain 系列差异较大Runner 的初始化参数、Session 管理方式如果不按当前版本文档来很容易报错。遇到问题先看官方仓库的 issue 区这是最快路径。8. Agent 框架上线的工程化建议8.1 先把流程画出来再写图代码不管选 LangGraph 还是 ADK动手写代码之前建议先把你心中理想的 Agent 流程用文字或图形梳理清楚用户输入进来第一步做什么判断条件是什么失败怎么处理哪些环节需要人工介入。这个步骤和数据库建模的道理一样——前期梳理得越清楚后期改图的成本越低。8.2 状态设计要克制只放真正需要共享的数据LangGraph 的 State 是所有节点共享的如果你把大段的工具返回结果全部塞进 State很快会面临上下文膨胀和字段冲突的问题。更好的做法是工具返回后先做信息提取只把结构化摘要放到 State 里原始结果写入外部存储。8.3 给工具命名的标准要统一Agent 模型靠工具名和描述来决定是否调用。工具名称要直观描述要写清楚“什么场景下使用、输入什么参数、输出什么格式”。如果多个工具的功能边界模糊模型很容易选错。建议团队内部建立工具描述模板。8.4 日志和追踪是 Agent 项目的第一基础设施Agent 的不确定性意味着你必须能回答“这次请求为什么走了 A 分支而不是 B 分支”。LangGraph 的日志能展示节点流转但是不够精细。建议在上线前接入一套完整的追踪系统记录模型输入输出、工具调用参数与结果、节点切换原因。这部分的投资回报率非常高。8.5 不要过度设计先跑通最小闭环很多团队一上来就设计复杂的多 Agent 架构结果连一个 Agent 都还不稳定。更稳妥的推进路径是先用一个最简 Agent 把核心链路跑通再逐步拆分节点、添加分支、引入多 Agent。每一次拆分都要有明确收益不要为了架构而架构。8.6 锁定依赖版本构建可复现环境Agent 框架迭代速度极快项目配置文件里务必锁定核心依赖的精确版本并保留安装时间记录。否则两周后再跑同一套代码结果可能完全不同。生产环境中还需要把依赖锁文件纳入版本管理。9. 总结与下一步实践建议现在回到最初的选型问题LangChain、LangGraph、Deep Agents、ADK 到底怎么选如果你需要做知识库问答、RAG 或快速原型LangChain 生态仍然是资源最丰富的起点如果你的业务有明确的流程分支、状态流转和审计需求LangGraph 是当前最值得投入的工程化方案如果你是在验证一个“目标明确、靠模型自主跑完”的单 Agent 任务Deep Agents 的低门槛能帮你更快得到答案如果你更看好 Google 生态或者需要天然的多智能体树状协作和云集成ADK 值得认真研究。没有最好的框架只有最匹配业务的框架。选型时不要被框架的噱头带偏重点评估三点团队的技术基础、业务的流程复杂度、后期的维护成本。下一步建议非常直接不要停留在对比文档的阶段直接用真实业务场景里的一个小任务做 PoC。一个任务用四个框架各实现一遍你会比看任何对比文章都更清楚差异。跑通 PoC 之后再思考如何把日志、追踪、状态管理这些工程能力补上去。Agent 开发的竞争力终究来自工程化的深度而不是某个框架的新鲜感。