最近 Agent 这个概念又热了一轮网上框架多到让人头疼LangChain 是老牌选择LangGraph 主打图编排Deep Agents 靠 OpenAI 生态吸了一波关注ADK 又是 Google 官方推出的开发套件。很多做 RAG、工具调用、多智能体编排的同学都在问这几个到底什么关系是不是学一个就够了如果要接 API、要跑批量任务、要上生产选哪个更稳这篇文章不聊概念堆砌直接进入选型核心。我会把四个框架的定位、核心抽象、安装上手、状态管理、多 Agent 编排、接口能力和适用场景逐一拆开最后给出一套可落地的选型建议。读完你至少能判断自己手头的项目该用 LangChain、LangGraph、Deep Agents 还是 ADK。1. 核心能力速览对比项LangChainLangGraphDeep AgentsADK项目定位通用 LLM 应用开发框架LLM 图编排与状态工作流分层智能体编排框架Google 官方 Agent 开发套件核心抽象Chain、Tool、Retriever、AgentStateGraph、Node、Edge、StateAgent、Tool、Interrupt、HandoffAgent、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 AIADK 和云端生态的集成会很顺畅。但这里要提醒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-adkpip 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(modelgpt-4o-mini, temperature0) 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(agentagent, 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( nameresearcher, instructions负责收集资料输出结构化摘要。, tools[], ) writer Agent( namewriter, instructions负责根据资料撰写文章。, tools[], ) main_agent Agent( namecoordinator, 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( nameweather_agent, modelgemini-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]}, configconfig ) 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 SessionDeep Agents 子 Agent 没有执行主 Agent 的委派条件不满足打印主 Agent 的中间步骤调整 instructions明确委派触发条件ADK 工具调用失败工具函数签名与模型预期不一致查看工具输出格式按 JSON Schema 风格补充参数描述批量任务卡住并发过高触发限流观察请求日志和状态码增加重试机制降低并发数接口服务超时模型响应慢或链路过长分离日志按节点统计耗时为每个 Agent 子节点增加耗时埋点9.1 关于“模型供应商限流”的处理批量任务中最常见的坑是限流。四个框架都提供了重试机制但默认关闭或不完整。建议在封装层加统一重试import time def call_with_retry(func, max_retries3, backoff2): 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 完整走一遍。