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 的底层表达是 LCEL（LangChain 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 ADK：Google 生态下的多智能体开发套件

ADK（Agent Development Kit）是 Google 推出的 Agent 开发框架。它的定位和前面三个有明显区别：ADK 更强调“多智能体编排”和“云生态集成”。

ADK 的核心抽象是 Agent 基类，你可以组合多个子 Agent 构成树状结构，父 Agent 负责判断该把任务交给哪个子 Agent。同时，ADK 对 Code Execution（代码执行沙箱）、MCP（Model Context Protocol）、Google 搜索、Gemini 模型等做了深度集成。

如果你已经在 Google Cloud 上构建应用，或者准备基于 Gemini 模型做 Agent 开发，ADK 是最顺滑的选择。它降低了调用云服务的成本，也天然适配 Google 生态的运维方式。

不过，ADK 在国内开发者的实际使用中，相关中文资料相对较少，社区规模和 LangChain 生态还有差距。如果你的团队对多智能体架构要求高，且不介意参考英文文档，ADK 值得认真评估。

3. 核心维度对比：四个框架如何选

先看一张总表，后面再逐步展开说明。

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-openai

Deep Agents 和 ADK 的安装方式同样参考官方仓库说明执行，它们对 Python 版本和依赖库有自己的要求，直接按照官方文档安装即可。

# 仅供参考，具体包名以官方仓库 README 为准 # 评估 Deep Agents 时安装对应项目依赖 # 评估 ADK 时安装 Google 官方 ADK 包

配置模型 API 时，把密钥写入环境变量是比较安全的做法，不要硬编码在代码里。

# 以 OpenAI 为例，写入环境变量 export OPENAI_API_KEY="sk-你的密钥" # 以 Gemini 为例 export GOOGLE_API_KEY="你的密钥"

注意：不同框架对同一个模型厂商的调用方式略有差异。LangChain 生态统一用langchain-openai这种封装，ADK 则默认对接 Gemini 系列，Deep Agents 通常直接基于模型 SDK。

5. 四个框架的最小可运行示例

下面用四个最小示例，分别演示“一个能查询天气的 Agent”。为了控制篇幅，每个示例只展开核心逻辑；完整可运行代码需要你在本地补齐 API Key 和工具函数。

5.1 LangChain：基于 ReAct 的最简 Agent

LangChain 的 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(model="gpt-4o-mini", temperature=0) 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(agent=agent, tools=tools) 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返回的部分状态会被合并进整体 State，route_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 ADK：Agent + 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( name="weather_assistant", model="gemini-2.0-flash", # 模型名以你的实际可用模型为准 instruction="你是一个天气助手。用户问天气时，你可以调用工具查询。", ) # 2. 创建 Runner，负责执行 Agent runner = Runner( agent=agent, app_name="weather_agent_app", ) # 3. 运行一次对话 response = runner.run( user_id="user_123", session_id="session_456", message="北京现在热吗？", ) # 4. 获取结果 print(response.output_text)

ADK 的亮点在于：当你有多个 Agent 时，可以定义父 Agent 和子 Agent，通过sub_agents参数组合，让父 Agent 根据用户意图把任务交给对应的子 Agent。这种树状结构在多领域助手场景下非常合适。

如果你的业务已经用了 Google Cloud，ADK 的部署、日志、监控和云服务集成是很大的加分项。如果你主要用国内云厂商或 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 名称和包结构已经变了。

7.2 Agent 陷入死循环

LangGraph 和 Deep Agents 这种支持循环的框架，死循环是很容易出现的问题。原因通常是：模型反复调用同一个工具，工具返回的结果没有让状态发生本质变化，模型无法判断该停止。

7.3 上下文过长导致模型效果下降

Agent 循环中，每轮工具调用都会往上下文里追加内容。十几轮之后，输入长度可能超过模型窗口，或者模型被无关信息干扰。

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 开发的竞争力，终究来自工程化的深度，而不是某个框架的新鲜感。