最近 Agent 这个概念又热了一轮，网上框架多到让人头疼：LangChain 是老牌选择，LangGraph 主打图编排，Deep Agents 靠 OpenAI 生态吸了一波关注，ADK 又是 Google 官方推出的开发套件。很多做 RAG、工具调用、多智能体编排的同学都在问：这几个到底什么关系？是不是学一个就够了？如果要接 API、要跑批量任务、要上生产，选哪个更稳？
这篇文章不聊概念堆砌，直接进入选型核心。我会把四个框架的定位、核心抽象、安装上手、状态管理、多 Agent 编排、接口能力和适用场景逐一拆开，最后给出一套可落地的选型建议。读完你至少能判断：自己手头的项目该用 LangChain、LangGraph、Deep Agents 还是 ADK。
1. 核心能力速览
| 对比项 | LangChain | LangGraph | Deep Agents | ADK |
|---|---|---|---|---|
| 项目定位 | 通用 LLM 应用开发框架 | LLM 图编排与状态工作流 | 分层智能体编排框架 | Google 官方 Agent 开发套件 |
| 核心抽象 | Chain、Tool、Retriever、Agent | StateGraph、Node、Edge、State | Agent、Tool、Interrupt、Handoff | Agent、Tool、Flow、Session |
| 状态管理 | 内存态为主，适合轻量 | 内置 Checkpoint，支持持久化 | 通过上下文和持久化记录管理 | Session 状态，支持持久化 |
| 多 Agent 编排 | 支持但较弱，靠链式/ReAct | 支持子图、并行分支、条件路由 | 主 Agent 与子 Agent 分层委派 | 支持子 Agent、Flow、分发编排 |
| 是否支持回调/中断 | 支持回调 | 支持动态中断、断点续跑 | 支持 interrupt 机制 | 支持事件与扩展机制 |
| 生态绑定 | 中立，支持多模型供应商 | 中立，兼容 LangChain 生态 | 偏 OpenAI 生态 | 偏 Google / Vertex AI 生态 |
| 上手成本 | 低，适合快速原型 | 中，需要理解图思维 | 中，需要理解分层委派 | 中，需要理解 Agent + 工具模型 |
| 适合场景 | RAG、搜索问答、简单工具链 | 复杂工作流、生产级 Agent | 研究型 Agent、深度任务编排 | 企业级、可观测性要求高的场景 |
从表里能直接看出：这四个不是单纯的版本演进关系，而是各自侧重点不同。LangChain 覆盖的是“我要快速把大模型和工具串起来”的基础需求；LangGraph 把控制流提升到了图的层级，解决复杂分支和状态；Deep Agents 更强调“主从”和“委派”的设计；ADK 则更像是面向企业环境的全家桶式开发套件。
2. 适用场景与使用边界
选框架之前，先明确自己的场景属于哪一类。把这四个框架放到实际任务里看，结论会比较清楚。
2.1 LangChain 适合谁
如果你要做的任务是“给大模型接一个搜索工具”“把知识库内容召回后送给模型生成”“做一个带记忆的问答机器人”，LangChain 是最快路径。它的组件化设计让 Prompt、LLM、Tool、Retriever 都能独立替换，很适合快速验证想法。
不适合的场景是：流程庞杂、分支多、需要持久化断点续跑、多个 Agent 之间频繁协作。这类需求用 LangChain 原生的 Chain 写会很别扭，逻辑分散在各个 callback 和 agent 内部，排查问题困难。
2.2 LangGraph 适合谁
LangGraph 适合流程可以被描述成“状态机”的场景。比如客服工单系统：先判断用户意图，再路由到相应子流程，需要多轮确认，中途可能人工介入，最后生成结果并落库。这类场景的节点和边是固定的，用 StateGraph 表达非常自然。
LangGraph 的最大价值是状态持久化和条件路由，非常适合生产级 Agent 服务。但它的学习曲线比 LangChain 陡，你需要转变思维：不再是“链式调用”，而是“状态如何流转”。
2.3 Deep Agents 适合谁
Deep Agents 强调的是层次化智能体编排。它适合把一个复杂的研究任务拆给多个子 Agent：一个 Agent 负责搜索，一个 Agent 负责分析，一个 Agent 负责汇总，主 Agent 负责调度和决策。OpenAI 生态的用户用起来更顺手，和 Assistants API、Responses API 的结合比较紧密。
使用时要特别注意：Deep Agents 偏研究型设计和 OpenAI 产品路线，通用性和跨生态能力不如 LangGraph。如果你要接多种模型供应商、部署到非 OpenAI 服务上，需要多做一层适配。
2.4 ADK 适合谁
ADK 更适合对可观测性、企业级治理、服务端部署有要求的团队。Google 在 Agent 开发上的思路是“尽量标准化”：Agent 定义、工具规范、会话管理、评估模块都做成套件的一部分。如果你本身在用 Google Cloud 或 Vertex AI，ADK 和云端生态的集成会很顺畅。
但这里要提醒：ADK 的社区中文资料目前仍然偏少，遇到深坑时排查成本高。如果你的团队已经熟练使用 LangChain，迁移到 ADK 的收益需要认真评估。
2.5 安全、隐私与合规边界
无论选哪个框架，在处理真实数据时都要锁住几条底线：
- 涉及用户个人信息、企业文档、人脸、声音、肖像等内容时，必须先确认授权和合规边界。
- 框架本身只是调度层，数据传到哪个模型服务、是否留存、是否用于训练，取决于你的模型供应商配置，需要在代码里显式处理。
- 本地部署的模型要关注推理服务的安全访问控制，不要裸奔到公网。
- 测试时建议使用脱敏数据和最小样本集，不要在开发环境直接跑全量生产数据。
3. 环境准备与前置条件
这四个框架都以 Python 为主，安装流程相似。推荐 Python 3.10 及以上版本，虚拟环境隔离依赖。以下安装命令是通用方式，具体版本号以 PyPI 实际发布为准。
# 创建虚拟环境 python -m venv venv source venv/bin/activate # 升级 pip pip install --upgrade pip3.1 LangChain 环境准备
LangChain 现在的安装方式和早期不同，核心包和生态包是分开的。一套基础环境需要装这些：
pip install langchain langchain-core langchain-community langchain-openai需要处理文档和向量库时，再按需添加：
pip install langchain-text-splitters langchain-chroma pypdf3.2 LangGraph 环境准备
LangGraph 可以独立安装，也可以和 LangChain 一起用。推荐独立安装，同时搭配官方持久化依赖：
pip install langgraph langgraph-checkpoint如果要用 SQLite 或 Postgres 作为持久化后端，再补充对应驱动。
3.3 Deep Agents 环境准备
Deep Agents 的代码和 OpenAI Agents SDK 关联比较密切。具体包名和版本要按官方文档确认，安装时建议锁定版本，避免 API 变化影响代码：
pip install openai-agents安装完成后检查 SDK 版本，并确保环境变量中配置了可访问的模型 API Key。
3.4 ADK 环境准备
Google ADK 的包名是 google-adk：
pip install google-adk安装后需要确认 Python 版本兼容性和可选依赖，例如在 Jupyter 中可视化 Agent 流程时，可能需要补装对应插件。
3.5 通用检查清单
| 检查项 | 说明 |
|---|---|
| Python 版本 | 建议 3.10 以上，具体看项目文档 |
| 模型 API | 确保 API Key 可用，或本地模型服务已启动 |
| 网络访问 | 部分依赖下载和模型调用需要访问外网，注意合规 |
| 端口占用 | 如果启动 WebUI 或 API 服务，提前检查端口 |
| 磁盘空间 | 依赖包体量不大，但模型文件和向量库可能占用较多空间 |
4. 四个框架的快速上手示例
以下示例用于理解每个框架的写法差异，实际项目中需要替换为你自己的模型、工具和 Prompt。
4.1 LangChain 快速上手：一个带搜索工具的问答链
from langchain_openai import ChatOpenAI from langchain_core.tools import tool from langchain.agents import create_react_agent, AgentExecutor from langchain_core.prompts import PromptTemplate @tool def search_knowledge_base(query: str) -> str: """模拟知识库搜索，返回相关片段。""" return "知识库中与 " + query + " 相关的内容是：xxxx。" llm = ChatOpenAI(model="gpt-4o-mini", temperature=0) prompt = PromptTemplate.from_template( "你是一个助手。请回答用户问题，必要时使用工具。\n" "工具: {tools}\n" "工具名: {tool_names}\n" "用户问题: {input}\n" "历史: {agent_scratchpad}" ) agent = create_react_agent(llm, [search_knowledge_base], prompt) executor = AgentExecutor(agent=agent, tools=[search_knowledge_base]) result = executor.invoke({"input": "帮我查一下项目部署文档里关于显存的要求。"}) print(result["output"])这段代码代表 LangChain 最常见的 Agent 用法：定义 Tool，创建 ReAct Agent，然后用 AgentExecutor 执行。优点是代码短、易理解；缺点是流程一旦复杂，控制和调试都会变得困难。
4.2 LangGraph 快速上手：条件路由与状态流转
LangGraph 的核心是 StateGraph。下面的例子演示如何定义状态、节点和条件边：
from typing import TypedDict, Literal from langgraph.graph import StateGraph, START, END class AgentState(TypedDict): question: str route: str answer: str def analyze_question(state: AgentState): q = state["question"] # 这里用简单的关键词判断代替模型意图识别 if "搜索" in q: route = "search" else: route = "chat" return {"route": route} def search_node(state: AgentState): return {"answer": "这是搜索结果：" + state["question"]} def chat_node(state: AgentState): return {"answer": "这是闲聊回复：" + state["question"]} def decide_route(state: AgentState) -> Literal["search", "chat"]: return state["route"] graph = StateGraph(AgentState) graph.add_node("analyze", analyze_question) graph.add_node("search", search_node) graph.add_node("chat", chat_node) graph.add_edge(START, "analyze") graph.add_conditional_edges( "analyze", decide_route, {"search": "search", "chat": "chat"} ) graph.add_edge("search", END) graph.add_edge("chat", END) app = graph.compile() result = app.invoke({"question": "帮我搜索最新版本的发布说明"}) print(result["answer"])这段代码展示了 LangGraph 和 LangChain 的关键区别：每个节点接收 State，返回 State 更新；条件边根据当前状态决定下一步。这种设计让复杂流程可以被画出、被测试、被持久化。
4.3 Deep Agents 风格示例：分层委派
Deep Agents 的主流写法围绕 Agent 对象展开。下面是一个偏结构化的示例，实际参数需要按 OpenAI Agent SDK 文档调整：
from agents import Agent, Runner researcher = Agent( name="researcher", instructions="负责收集资料，输出结构化摘要。", tools=[], ) writer = Agent( name="writer", instructions="负责根据资料撰写文章。", tools=[], ) main_agent = Agent( name="coordinator", instructions="先让 researcher 收集资料，再由 writer 成文。", agents=[researcher, writer], ) result = Runner.run_sync(main_agent, "写一篇关于 Agent 框架对比的短文") print(result.final_output)这段代码的重点是 agents 参数：主 Agent 可以委派给子 Agent。这个模式适合“把大任务拆成小任务”的类型，但要注意子 Agent 之间如果存在非常复杂的状态共享，写法会比 LangGraph 繁琐。
4.4 ADK 快速上手：定义 Agent 与工具
ADK 的 Agent 定义比较规范，工具注册方式也比较清晰：
from google.adk.agents import Agent from google.adk.tools import tool @tool def get_weather(city: str) -> str: """获取指定城市天气。""" return f"{city} 的天气是晴天，25 度。" agent = Agent( name="weather_agent", model="gemini-2.0-flash", instruction="你是一个天气助手，使用 get_weather 工具回答问题。", tools=[get_weather], ) # 实际运行需要通过 Runner 或 Web 服务启动，不同版本 API 有差异ADK 把 Agent、工具、指令分隔得很明确，适合团队协作开发和测试。它的代码风格更像是“配置化开发”，而 LangGraph 更像是“编程化开发”。
5. 功能测试与效果验证
框架选型不能只看文档，必须亲手验证。建议按这个顺序测试：意图路由、工具调用、多轮对话、状态持久化、批量并发。
5.1 意图路由与条件分支测试
这是一个最常见的验证点。对 LangGraph 和 ADK，重点看条件路由是否按预期触发，分支路径是否会汇聚回主状态。
| 测试场景 | 输入示例 | 预期结果 |
|---|---|---|
| 工具调用型问题 | “帮我查询订单状态” | 路由到查询工具节点 |
| 闲聊型问题 | “今天天气怎么样” | 路由到闲聊节点 |
| 多条件问题 | “先查库存，再算价格” | 按顺序进入两个节点 |
测试时建议记录每一轮的 State 变化，尤其要关注条件边返回的路径值是否和节点名完全匹配。字符串匹配错误容易导致运行时找不到节点。
5.2 多轮对话与记忆测试
这一项决定框架能不能真正落地到产品中。
LangChain 的 Memory 有内置方案，但需要自己管理会话 ID 和检索逻辑。LangGraph 的 Checkpoint 机制更完整，默认支持把每一步的状态保存下来，重启后可以从断点继续。Deep Agents 的记忆管理依赖 SDK 内部的上下文机制，具体要看版本实现。ADK 的 Session 概念设计得比较完整，适合做多轮对话场景。
测试方法：连续发 5 轮相关提问，中间故意改一次指令，比如“把刚才的主题换成另一个方向”，然后看模型能否正确理解当前上下文。
5.3 工具调用稳定性测试
工具调用是 Agent 最容易出错的地方。测试时建议覆盖：
- 工具参数缺失：模型没有提供必填参数，框架是否报错，还是自动跳过？
- 工具返回异常：工具内部抛出异常，Agent 能否捕获并重试？
- 工具返回内容过长：返回的 JSON 超过上下文限制，框架如何截断？
- 多个工具并行：模型是否自主决定并行调用，还是必须串行？
对比测试时，我会先给四个框架分别注册两个工具：一个查询数据库，一个调用外部 HTTP 接口。然后让模型回答一个需要同时使用两个工具的问题，观察调用成功率、耗时和错误处理。
6. 多 Agent 编排与状态管理对比
这是选型差别最大的领域。
6.1 LangGraph 的状态机模型
LangGraph 把 Agent 流程建模为图。每个节点读取共享状态，计算出增量后更新状态。这种模型在处理复杂分支、循环、并行子图时有天然优势。子图机制允许你把一套流程封装成 node，嵌入到更大的流程中，这对后台任务的工程化非常友好。
LangGraph 的 Checkpoint 机制是它的核心卖点之一：每个节点执行前后的状态都可以持久化到存储后端，运行中途崩溃后可以从最近的检查点恢复，而不需要重新跑完整流程。
6.2 Deep Agents 的分层委派模型
Deep Agents 更倾向于“一个主 Agent 调度多个子 Agent”。主 Agent 负责任务分解，子 Agent 负责具体执行，子 Agent 之间不直接通信，而是通过共享记录或工具调用间接协作。
这种模型的优点是简单直观：你不需要设计复杂的边和状态，只需要决定哪些 Agent 可以被委派。缺点也很明显：如果子 Agent 之间需要大量状态共享，主 Agent 的调度压力会变大，prompt 消耗也会更高。
6.3 ADK 的流程与会话模型
ADK 的 Agent 定义比 LangGraph 更模板化。它提供 Flow 编排能力，可以在 Agent 之间建立工作流，同时保留 Session 层做状态管理。对于“一个 Agent 处理用户输入，把结果交给另一个 Agent 做后处理”这种场景，ADK 的代码结构会比较整齐。
从开发体验看，ADK 更偏重“定义清晰、可观测、可测试”。如果团队需要多人协作，ADK 的工程化结构容易统一规范。但它的灵活度不如 LangGraph，遇到非常规控制流时，可能需要引入额外代码绕过框架限制。
7. 接口 API 与批量任务
生产环境里，Agent 框架很少只在脚本里跑一次。你需要关心的三个问题是：能否通过 API 对外服务，能否接入消息队列做批量任务，失败后能否自动重试。
7.1 LangChain 与 LangGraph 的接口方式
LangChain 本身不强制提供 Web 服务，但结合 FastAPI 可以快速暴露接口，很多项目用 LangServe 或者自定义 FastAPI 路由包装。
LangGraph 提供了编译后的图对象，可以直接在 FastAPI 中调用。它的持久化特性让接口层的体验更好：同一个线程 ID 可以继续上一次会话，断点续跑也能通过 API 触发。示例：
from fastapi import FastAPI from your_graph import app as graph_app app = FastAPI() @app.post("/agent/run") async def run_agent(payload: dict): config = {"configurable": {"thread_id": payload.get("thread_id", "default")}} result = graph_app.invoke( {"question": payload["question"]}, config=config ) return {"answer": result["answer"]}7.2 Deep Agents 和 ADK 的接口能力
Deep Agents 依托 OpenAI SDK，天然适合以服务方式运行。通过 SDK 调用 Agent 后，可以直接把结果序列化为 JSON 返回给上游系统。
ADK 提供了完整的服务端运行时能力，官方推荐使用 gRPC 或 HTTP 接口。企业场景中，ADK 的可观测性设计对监控请求链路有帮助，但具体接口路径需要查阅官方文档。
8. 资源占用与性能观察
Agent 框架本身不是重资源应用，真正的资源消耗来自三处：模型 API 调用、本地向量库、并发执行线程。
8.1 显存占用观察
如果你使用本地模型，需要关注的是模型推理服务的显存占用，而不是 Agent 框架本身。用 nvidia-smi 可以实时观察：
watch -n 1 nvidia-smi显存占用主要取决于模型大小、上下文长度和并发数。Agent 框架的上下文越长，每轮推理占用的显存越高。如果你是多 Agent 编排，主 Agent 和子 Agent 都可能积累大量上下文，显存压力会叠加。
8.2 CPU 与内存占用观察
LangGraph 的持久化和图调度会有少量 CPU 和内存开销，批量并发时更明显。建议在批量任务执行时观察进程的内存变化：
ps aux | grep python如果内存持续增长，可能是状态对象没有释放，需要检查你的 Node 函数是否在 State 中累积了大字段。
实用建议：
- 批量任务开始前先跑 10 条测试样本，观察平均耗时和内存斜率。
- 不要把所有中间结果都塞进 State，只保留必要字段。
- 接口服务建议加上超时控制，避免下游模型响应慢导致线程堆积。
- 使用异步调用时，要控制并发数，避免触发模型供应商限流。
9. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| LangChain Agent 不调用工具 | Prompt 格式与 ReAct 模板不匹配 | 打印 agent_scratchpad 内容 | 检查 Prompt 是否包含 tools 和 tool_names 占位符 |
| LangGraph 条件路由报错 | 条件边返回值和节点名不匹配 | 打印运行时返回的 route 值 | 确保 produce 条件边时正好用节点注册名 |
| 多轮对话忘记前文 | 没有配置 Checkpoint 或 Session | 查看 State 中历史字段是否更新 | 启用 LangGraph Checkpoint 或 ADK Session |
| Deep Agents 子 Agent 没有执行 | 主 Agent 的委派条件不满足 | 打印主 Agent 的中间步骤 | 调整 instructions，明确委派触发条件 |
| ADK 工具调用失败 | 工具函数签名与模型预期不一致 | 查看工具输出格式 | 按 JSON Schema 风格补充参数描述 |
| 批量任务卡住 | 并发过高触发限流 | 观察请求日志和状态码 | 增加重试机制，降低并发数 |
| 接口服务超时 | 模型响应慢或链路过长 | 分离日志，按节点统计耗时 | 为每个 Agent 子节点增加耗时埋点 |
9.1 关于“模型供应商限流”的处理
批量任务中最常见的坑是限流。四个框架都提供了重试机制，但默认关闭或不完整。建议在封装层加统一重试：
import time def call_with_retry(func, max_retries=3, backoff=2): for i in range(max_retries): try: return func() except Exception as e: if i == max_retries - 1: raise e time.sleep(backoff ** i)10. 最佳实践与选型建议
最后给出一套比较务实的选型标准。
10.1 按经验阶段推荐
- 第一次接触 Agent 开发：先学 LangChain，把工具调用、RAG、Prompt 模板这几个基础概念吃透。
- 已经能写简单 Agent，但项目流程开始复杂：迁移到 LangGraph，用 StateGraph 重新组织流程。
- 主力模型是 OpenAI，想做研究型 Agent 任务：直接看 Deep Agents，理解主从 Agent 的分层排练。
- 团队规模大，需要标准化、可观测、企业级治理：认真评估 ADK，特别是在既有 Google 云生态下。
10.2 按项目类型推荐
| 项目类型 | 推荐框架 | 理由 |
|---|---|---|
| 知识库问答/文档解析 | LangChain | 检索和文档处理生态最成熟 |
| 工单系统/业务流审批 | LangGraph | 条件路由和持久化能力完整 |
| 研究助手/深度搜索 | Deep Agents | 分层 Agent 适合任务拆解 |
| 企业级平台/多团队协作 | ADK | 标准化程度高，适合统一规范 |
10.3 工程落地建议
- 先写最小可运行版本，不要一上来就搭复杂的多 Agent 图。
- 所有外部工具调用都要加超时、重试和日志。
- 模型 Prompt 和 Agent 逻辑分开管理，方便迭代。
- 保留一份固定的测试用例集，每次升级框架或模型都回归一遍。
- 不要盲目追求多 Agent。能用单 Agent 加工具解决的问题，不要拆成三个 Agent。
- 在接入真实用户数据前，先确认数据权限、隐私声明和合规边界。
11. 总结
LangChain 适合快速原型和轻量工具链，LangGraph 适合有状态、有分支、要上生产的复杂流程，Deep Agents 更适合以 OpenAI 模型为主的分层任务研究，ADK 则更适合企业标准化开发和多团队协作。
如果只能给一个建议：先别管哪个框架最热门，把你的核心流程画成图，哪些节点，哪些跳转，哪些状态需要保存。画完这张图，你再回来看这四个框架，答案会非常清楚。
建议收藏备用，选型的时候拿出来对照一下。下一篇可以考虑拆一个具体场景，比如用 LangGraph 做一个带人工审核的工单 Agent，把条件路由、Checkpoint、接口 API 完整走一遍。
