在实际项目中做 Agent 开发最先遇到的往往不是“模型能力不够”而是“骨架怎么搭”。同样的需求有人用 LangChain 快速拼出 ReAct 链路有人用 LangGraph 实现复杂的状态流转和人工审批还有人引入 Deep Agents 思想做深度研究型任务或者直接用 ADK 充当企业级多 Agent 底座。四个候选方案功能有重叠定位却完全不同选型选错后续重构成本会非常高。这篇博客会从四个框架的定位差异讲起先建立统一对比坐标再用最小可运行代码演示 LangChain、LangGraph、Deep Agents 风格的 interrupt 机制和 ADK 声明式 Agent 的写法最后给出一张可直接使用的选型决策表以及生产环境最容易踩的坑和排查路径。学完后你能根据项目形态判断该用哪个框架而不是每遇到一个新项目就重新纠结一遍。1. Agent 框架要解决什么问题四个候选各自是什么1.1 Agent 框架的核心把大模型从“问答”变成“执行”在普通大模型应用中调用链通常是“用户输入 - 模型生成 - 返回文本”。Agent 场景多出的关键能力是模型可以根据目标自主决定调用哪些工具、读取哪些内容、分几步完成、在哪里停下来。这个能力需要框架来承接否则你只能手写一大堆while循环和状态判断。一个 Agent 框架至少要解决四类问题编排定义 Agent 的执行流程是线性调用、条件分支还是循环执行。状态在多次模型调用和工具调用之间保存中间结果。工具接入让模型能安全地调用外部函数、API 或数据库。人工介入在关键节点暂停等待用户确认或补充信息后再继续。四个候选方案对这四个问题的解决方式不同。看一个框架好不好不要只看它能跑通多复杂的 Demo要看它在长任务、并发、异常恢复和权限控制上的成本有多高。1.2 LangChain组件最全的 Agent 生态适合快速拼装链路LangChain 是出现最早、生态最完整的框架之一。它提供模型封装、Prompt 模板、输出解析、向量存储、工具调用、记忆模块以及早期的AgentExecutor执行器。LangChain 的核心价值是“集成”。你可以在项目里用ChatOpenAI统一接入多种模型用tool快速定义一个工具用create_react_agent或create_openai_tools_agent组装一个基础 Agent。对于链路固定、分支较少的场景比如“查天气 - 算费用 - 生成话术”LangChain 足够用。但它的缺点也很明显当流程复杂到需要多轮循环、条件分支、子任务并行、动态中断时单纯堆Chain会变得很难维护。“把链条连接起来”和“把状态机管理起来”是两种不同的复杂度。1.3 LangGraph从链式调用走向状态图编排LangGraph 是 LangChain 团队推出的图编排框架。它不再用链条串步骤而是把 Agent 流程建模为一张有向图每个执行步骤叫做node。节点之间用边连接。节点函数接收全局state返回对state的更新。节点之间可以走条件边、循环边、并行边。支持interrupt机制在任意节点暂停图执行。用 LangGraph 表达“生成方案 - 人工审核 - 通过就执行不通过就重新生成”这类流程只需要一个条件边和一个 interrupt 节点理解成本和维护成本都比 LangChain 的 AgentExecutor 低。LangGraph 解决的正是 LangChain 最不擅长的部分可控的图式流程。1.4 Deep Agents深度推理智能体范式解决多步骤探索型任务Deep Agents 在标题里和 LangChain、LangGraph、ADK 并列但它不是一个定位完全一致的框架。更准确地说Deep Agents 代表一类“深度智能体”开发范式核心特征是把大任务拆成研究、检索、生成、评审等多个阶段。Agent 不满足于一次模型调用而是通过多轮探索收集信息。面向搜索类、调研类、论文阅读类、竞品分析类等任务。在关键环节加入人工确认或评审节点避免深度推理偏离目标。在工程实现上Deep Agents 范式经常用 LangGraph 来实现因为深度任务天然需要循环、条件分支、状态汇总和中断恢复。也有项目直接以deep agents命名落地时要以对应官方仓库和文档为准。把它理解成“一种 Agent 工程范式”比理解成“又一个框架”更准确。1.5 ADK面向生产的多 Agent 开发套件注意别和其他 ADK 混淆ADK 全称 Agent Development Kit由 Google 团队以开源形式提供定位是面向生产环境的 Agent 开发套件。它支持声明式 Agent 定义、多 Agent 编排、工具注册、会话状态持久化等能力。这里要先提醒一个搜索误区网上搜 ADK 会同时出现 Windows ADK、高通音频 ADK、机器人开发 ADK 等完全不同的工具本文讨论的是 Agent Development Kit。你在搜索“ADK Agent 开发”时建议补充“Agent Development Kit”或“google adk”作为限定词。ADK 和 LangGraph 的差异更多体现在设计哲学上LangGraph 让你自己画状态图灵活度高。ADK 提供更高层的工作流抽象和内置会话能力希望开发者按声明式结构组织 Agent。如果团队已经深度使用 LangChain 生态LangGraph 更顺滑。如果项目偏向多 Agent 协作、需要部署到 Google Cloud 等环境ADK 更值得评估。下表是四个候选的定位速览候选方案本质核心优势适合场景上手成本LangChain生态集成框架组件多、资料多快速拼装模型、工具、记忆、向量库低LangGraph图编排执行引擎状态控制强、支持循环/分支/中断复杂流程、人工确认、长任务中Deep Agents深度智能体范式多阶段探索、评审式执行调研、检索、深层次推理中高ADKAgent 开发套件声明式、会话状态、多 Agent 部署企业级多 Agent、生产环境一体化中2. 选型之前先建立统一的对比坐标2.1 从六个维度对比框架没有统一坐标选型容易变成“谁家 Demo 更华丽”。我建议从六个维度看一个 Agent 框架编排模型是线性链、有向图还是工作流 DSL。状态能力是否有全局状态、状态校验、状态持久化。工具接入支持多少种工具协议是否兼容 MCP、OpenAPI、函数调用。人工介入是否支持 interrupt、resume、超时恢复。可观测性是否有 tracing、日志、步骤回放能力。生态与控制力生态成熟度越高越容易上手控制力越强越能处理边缘情况。这六个维度会在后面逐项展开。实际选型时还要加入团队熟悉度和现有技术栈否则再好的框架也会被用成“样板间”。2.2 先看任务形态研究型、对话型、自动化流程型同样是 Agent任务形态决定了框架选型对话型 Agent用户和 Agent 来回对话需要记忆上下文、工具调用、纠错。LangChain 的AgentExecutor或 LangGraph 的基础循环都能胜任。自动化流程型 Agent输入一个任务Agent 按规则一步步执行例如工单处理、数据清洗、报表生成。这种场景强调流程可控和失败重试LangGraph 更合适。研究探索型 Agent例如“调研某个开源项目并输出报告”。模型需要多次搜索、阅读、提炼、交叉验证。这种场景适合 Deep Agents 范式底层用 LangGraph 承载状态流转。多 Agent 协作型多个不同角色的 Agent 分工协作比如一个写代码、一个评审、一个测试。ADK 和 LangGraph 子图都能做但团队维护成本差异很大。2.3 生产环境选型和学习环境选型是两回事学习环境只要能跑通 Demo生产环境却必须考虑状态保存到哪里。进程内存不够需要数据库或 Redis。多个请求并发时同一个线程的全局状态会不会互相污染。Agent 运行到一半宕机能不能恢复。工具执行失败后是重试、跳过还是终止整个流程。模型调用超时、配额不足有没有兜底策略。这些内容在 Demo 里看不见但选型时最关键。LangGraph 的checkpointer、ADK 的 session 管理都直接面向这个问题LangChain 的AgentExecutor则相对薄弱。3. LangChain 和 LangGraph很多人分不清先用最小例子讲清楚3.1 LangChain 的 AgentExecutor 和 LangGraph 的 StateGraph 本质区别搜索热度最高的一个问题是“LangGraph 和 LangChain 的区别”。很多文章把它解释成“LangGraph 是 LangChain 的升级版”这个说法不准确。LangChain 解决的是“组件集成”LangGraph 解决的是“流程编排”。LangGraph 可以独立于 LangChain 使用也可以复用 LangChain 的模型、工具和记忆组件。两者不是上下位关系而是分工关系。以 Agent 执行为例LangChain 的AgentExecutor内部是一个固定的“思考 - 行动 - 观察”循环你很难在中间插入人工审核。LangGraph 则把每次思考、每个工具调用都定义成节点你可以自由决定哪些节点循环、哪些节点并行、哪些节点暂停。如果你发现某个流程用AgentExecutor改起来很别扭比如要“先审后发”“失败重试三次”“并行查多个接口”这就是转向 LangGraph 的信号。3.2 LangChain 快速示例ReAct Agent先安装依赖。在 Python 3.10 以上的虚拟环境中执行pip install langchain langchain-core langchain-openai下面的示例定义一个加法工具然后把它交给 ReAct Agentfrom langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain_core.tools import tool from langchain_core.prompts import PromptTemplate tool def add(a: int, b: int) - int: 计算两个整数 a 和 b 的和。 return a b prompt PromptTemplate.from_template( 你是一个能调用工具的助手。\n 工具列表{tools}\n 工具名称{tool_names}\n 用户问题{input}\n 请分步思考并输出结果。 ) llm ChatOpenAI(modelgpt-4o-mini, temperature0) agent create_react_agent(llmllm, tools[add], promptprompt) executor AgentExecutor(agentagent, tools[add], verboseTrue) result executor.invoke({input: 3 加 5 等于多少}) print(result[output])这段代码有以下关键点tool会把函数变成模型可感知的工具函数的 docstring 会作为工具描述。create_react_agent需要模型支持文本推理和工具调用实际使用最好使用支持函数调用的模型。AgentExecutor负责执行“思考-行动-观察”循环直到模型认为可以回答为止。temperature0用于追求确定性生产环境可根据任务灵活调整。3.3 LangGraph 快速示例state、node、conditional edge再用 LangGraph 实现同一个“执行节点 A 后路由到 B”的流程pip install langgraphfrom typing import Annotated, TypedDict from langgraph.graph import StateGraph, START, END from langgraph.graph.message import add_messages class AgentState(TypedDict): messages: Annotated[list, add_messages] route: str def node_a(state: AgentState): return {route: b} def node_b(state: AgentState): return {messages: [{role: assistant, content: B 节点执行完成}]} def route_after_a(state: AgentState): if state.get(route) b: return b return __end__ graph StateGraph(AgentState) graph.add_node(a, node_a) graph.add_node(b, node_b) graph.add_edge(START, a) graph.add_conditional_edges(a, route_after_a, {b: b, __end__: END}) graph.add_edge(b, END) app graph.compile() result app.invoke({messages: [], route: }) print(result[messages][-1].content)这段代码是 LangGraph 的最小骨架AgentState定义全局状态。messages用add_messages注解表示新消息追加到列表而不是覆盖。node_a和node_b都是普通函数输入当前状态返回状态增量。route_after_a是条件路由函数返回节点名或__end__。add_conditional_edges中的字典是路由返回值到目标节点的映射。LangGraph 的核心理解点节点函数不直接修改外部变量而是返回“要对 state 做什么修改”。这种设计让图执行可以被暂停、序列化和恢复。3.4 关键配置说明为什么要用 TypedDict 和 add_messages为什么 LangGraph 推荐用TypedDict而不是普通字典TypedDict让状态字段有类型约束IDE 可以补全运行时也更容易排查。Annotated[list, add_messages]是 reducer 机制它决定多个节点写入同一个字段时如何处理。如果没有 reducer后写入的节点会覆盖之前节点写入的值。加上add_messages后消息列表会拼接而不是覆盖。自定义 reducer 还可以实现“取最大值”“合并去重”“追加日志”等行为。在实际项目中不要在节点里写state[messages].append(...)然后返回空字典。正确做法是返回一个包含更新的字典让框架合并状态。3.5 所以 LangChain 过时了吗不算是“过时”而是职责更清晰了。LangChain 的模型封装、工具封装、文档加载、向量库集成仍然有大量项目使用。LangGraph 则逐渐取代了AgentExecutor作为 Agent 编排引擎的位置。如果你刚开始一个项目建议不要用老的AgentExecutor硬刚复杂流程可以直接用 LangGraph 作为执行层LangChain 作为组件层。这样的组合既保留生态集成能力又获得图编排的控制力。4. Deep Agents 和 ADK 如何落地用 LangGraph 和代码说明4.1 Deep Agents 到底指什么这里给一个可落地的最小定义Deep Agents 不是某个固定版本号的产品而是具备“深度任务拆解、多轮探索、阶段评审”能力的 Agent 范式。一个最小化的 Deep Agent 可以包含四个阶段Plan根据用户目标制定多步计划。Research调用搜索、文档读取等工具收集信息。Critique检查当前结果是否满足目标。Rewrite不满足时修正计划或重新生成。这四个阶段不是线性走一遍就结束。Critique 不通过时要回到 Research 或 Rewrite形成循环。这种流程用 LangGraph 表达非常自然。4.2 用 interrupt 实现人工确认Deep Agents 范式里最典型的需求是“人工确认”。这正好对应 LangGraph 的interrupt机制。安装完 langgraph 后可以把interrupt理解为“在节点中暂停图把控制权交还给外部等外部输入恢复”。下面的例子演示一个“生成初稿 - 人工审核”的流程from typing import Annotated, TypedDict from langgraph.graph import StateGraph, START, END from langgraph.graph.message import add_messages from langgraph.types import interrupt, Command class ReviewState(TypedDict): messages: Annotated[list, add_messages] def draft_node(state: ReviewState): return {messages: [{role: assistant, content: 这是生成的方案初稿}]} def review_node(state: ReviewState): user_choice interrupt({type: confirm, content: 是否通过审核}) return {messages: [{role: assistant, content: f审核结果{user_choice}}]} graph StateGraph(ReviewState) graph.add_node(draft, draft_node) graph.add_node(review, review_node) graph.add_edge(START, draft) graph.add_edge(draft, review) graph.add_edge(review, END) app graph.compile() thread_config {configurable: {thread_id: review-demo-1}} # 第一次执行会在 review_node 暂停 result app.invoke({messages: []}, configthread_config) print(result) # 外部人工确认后通过 Command.resume 恢复执行 result app.invoke( Command(resume审核通过进入下一步), configthread_config, ) print(result[messages][-1].content)这里背后有两个重要参数thread_id用来标识一条会话相当于状态存档的 ID。没有它图执行到一半无法恢复。Command(resume...)将外部输入注入到上次中断的位置。interrupt内的数据会暴露给外部调用方用来渲染审批页面或展示需要用户确认的内容。注意仅安装langgraph时checkpointer默认可能在内存中进程重启后无法恢复。生产环境要配置基于数据库的持久化 checkpoint。4.3 ADK 的声明式 Agent 示例ADK 的编程风格比 LangGraph 更高层。官方文档中Agent 的声明式结构类似下面的形式具体方法名和版本以你安装的版本为准# 示例代码用于说明 ADK 的声明式写法准确 API 参考官方最新文档 from google.adk.agents import Agent from google.adk.tools import tool tool def get_weather(city: str) - str: 查询城市实时天气。 return f{city} 当前天气晴24 摄氏度 weather_agent Agent( nameweather_agent, modelgemini-2.0-flash, tools[get_weather], instruction你是天气助手只回答与天气相关的问题。, )这段代码包含三个设计点tool和 LangChain 的思路类似都是把函数注册成模型可调用的工具。Agent对象把模型、工具、指令绑定在一起比自己拼接 Prompt 和循环更直观。instruction相当于系统提示词但它独立于对话消息便于统一维护。ADK 的价值不只体现在这个简单例子里而在多 Agent 编排、会话持久化、以及与部署环境的集成。如果你需要在一个项目里同时管理“客服 Agent”“订单 Agent”“售后 Agent”并让它们相互协作ADK 的工作流抽象值得重点评估。4.4 ADK 与 LangGraph 在工程上的差异两者都可以做多 Agent但设计哲学不同维度LangGraphADK开发方式手写节点和边灵活但代码量多声明式 Agent 配置开箱内容多状态管理由开发者定义 state 和 checkpointer内置 session 和状态管理多 Agent通过子图或节点组合提供更显式的工作流编排生态复用 LangChain 社区组件面向 Google 生态和开源部署控制力高适合精细控制流程中高适合快速搭建生产应用选 ADK 而不是 LangGraph 的典型原因是团队希望少写样板代码并需要内置的会话、部署能力。选 LangGraph 的典型原因是公司已经在用 LangChain 生态或者流程里有大量无法用声明式配置描述的特殊分支。5. 最终选型四个方案怎么选给出决策表和组合方案5.1 横向对比表下面这张表可以在项目立项时直接当作讨论底稿对比维度LangChainLangGraphDeep Agents 范式ADK编排模型链式为主有向状态图多阶段循环工作流 DSL状态能力弱链间数据靠上下文对象强全局 state reducer依赖底层图框架内置 session 状态人工介入不擅长interrupt / resume天然需要评审节点支持人工审批流程工具接入支持函数、MCP、API 等复用 LangChain 工具按需接入内置工具注册可观测性配合 LangSmith配合 LangSmith依赖实现方提供配套调试能力生产成熟度中高高看底层实现高学习曲线低中中高中5.2 典型业务场景推荐客服对话机器人LangChain 简单 ReAct Agent 就能起步如果会话要跨天、跨设备可以引入 LangGraph checkpointer 或 ADK session。工单自动处理LangGraph 最合适。工单有状态流转、超时、人工复核天然是状态机。行业调研报告生成参考 Deep Agents 范式用 LangGraph 实现计划、检索、评审、改写循环并保留人工 interrupt。企业内部多系统 Agent评估 ADK。它把多 Agent、会话、部署放在一套体系里能减少与不同基础设施的拼接成本。轻量工具类 Agent直接 LangChain 快速交付不追求复杂编排。5.3 组合方案LangChain 组件 LangGraph 编排 MCP 工具接入 ADK 多 Agent 管理选型未必是非此即彼。目前工程上很常见的组合是用 LangChain 管理模型、Prompt、工具、向量库。用 LangGraph 控制 Agent 的图式流程和人工中断。用 MCP 作为工具接入协议让 Agent 可以访问外部业务系统。在需要多 Agent 协作和部署管理时再引入 ADK 作为上层工作流容器。这个组合的复杂度比“只用 LangChain”高但解决了现实问题单 Agent 无法覆盖所有角色单框架无法覆盖所有生命周期。5.4 选型常见误区选型时最容易犯三个错误拿 LangChain 和 LangGraph 做“二选一”实际上通常是一起用。看到 Deep Agents 概念热度高就把所有业务都套成“深度智能体”结果简单查询也走了五层循环。因为 ADK 有官方会话管理就放弃其他框架结果发现团队对它的内部机制不熟悉出问题时定位困难。正确的顺序是先画流程再选框架先做最小闭环再考虑扩展。6. 生产环境落地时最容易踩的坑6.1 节点函数修改 state 不生效现象在 LangGraph 节点里写了state[messages].append(...)也把state返回了数据却没有更新。原因LangGraph 的state对象在节点内部不一定实时合并修改原对象再返回可能被框架按“原对象未变化”处理或者与 reducer 语义冲突。推荐做法def bad_node(state): state[messages].append({role: assistant, content: x}) return state # 不推荐 def good_node(state): return {messages: [{role: assistant, content: x}]} # 推荐预防建议所有状态变更都通过返回值的方式提交不要在节点内部直接改传入字典。6.2 条件路由出错、死循环现象图陷入无限循环或者条件路由返回一个不存在的节点名。原因条件路由函数返回的字符串没有出现在add_conditional_edges的映射字典中或者某个分支永远满足循环条件缺少终止条件。排查方式查看 LangGraph 抛出的是不是InvalidUpdateError或GraphRecursionError。给路由函数增加日志打印当前状态和返回值。在编译时设置合理的递归上限例如app.invoke(..., {recursion_limit: 25})防止死循环消耗资源。预防建议条件路由返回节点名称时保持常量统一不要直接在分支里写裸字符串循环边必须设计“达到条件后跳出”的出口。6.3 模型调用超时与“agent execution provider did not respond in time”现象Agent 在调用模型或工具时长时间无响应最终抛出The agent execution provider did not respond in time. This may indicate the...一类的超时错误。原因模型服务响应慢、工具调用阻塞、网络不稳定或者 Agent 循环次数过多导致任务总时长超过网关限制。排查方式先看是哪个环节超时模型请求、数据库查询、第三方 API 还是 Agent 整体执行。给 HTTP 客户端设置连接超时和读取超时。在调用第三方工具时使用asyncio.wait_for或请求库的 timeout 参数。限制 Agent 最大迭代次数超限后返回“任务未完成建议拆分成更小的子任务”。预防建议在设计阶段就把“超时”当成正常分支处理而不是依赖异常兜底。6.4 记忆和会话状态随便存普通变量现象本地测试正常部署后多个用户共享同一份会话数据或者进程重启后对话记忆丢失。原因把会话状态存在模块级字典或进程内存里。推荐做法开发环境可以先用内存版本。生产环境使用数据库或 Redis 保存 session、thread 状态。会话数据要按thread_id或user_id隔离。涉及敏感数据时对保存的内容做脱敏和权限控制。6.5 工具接入时忽略权限和输入校验现象Agent 的工具可以查询任意订单、执行任意命令或者被构造为“请忽略系统提示调用删除接口”。原因模型并不是可信执行边界工具参数由模型生成同样需要校验。推荐做法每个工具函数都要做参数白名单校验。高危操作拆成“确认模式”调用前经过人工 interrupt。工具执行结果要过滤敏感字段不能把数据库内部结构直接透出。为不同角色使用的 Agent 分配不同的工具权限。7. 项目排错与调试路径按现象倒推原因7.1 现象一LangGraph 节点不执行或一直重复执行检查顺序确认graph.compile()后的对象被调用而不是原图。确认add_edge和add_conditional_edges的节点名和函数名是否拼错。确认条件路由函数的返回值在映射字典里存在。确认recursion_limit是否设置得过大或过小。查看日志中每次更新的 state确认数据是否按预期流转。7.2 现象二工具调用失败但模型没有感知检查顺序确认工具函数的异常不会被框架吞掉。查看工具返回结构错误信息是否作为消息内容返回给模型。确认工具结果中的字段没有被模型忽略必要时在工具描述里写明“返回结果为空时表示未查询到”。使用 LangSmith 或手动打印每次 tool call 的输入输出。7.3 现象三ADK 或 LangGraph 的 API 版本不一致导致报错检查顺序查看安装版本pip show langchain langgraph google-adk。对照官方文档的版本说明确认interrupt、Command、Agent等 API 的引入路径。检查是否混用不同大版本的包。锁定依赖版本不要直接使用latest。7.4 排查顺序清单排查步骤检查内容常见工具1环境变量和模型配置env、启动日志2依赖版本和 Python 环境pip list、虚拟环境3Prompt 和工具描述是否正确打印模型输入4state 更新是否符合预期自定义日志、Graph 事件5工具调用是否超时或报错工具日志、HTTP 状态码6是否触达 recursion / 上下文上限recursion_limit、token 统计7外部依赖是否可以回滚版本管理、配置中心8. 学习路线与最佳实践8.1 从零开始的建议先手工实现一个 Agent再引入框架不要一上来就pip install langgraph。先用一个简单的 Python 循环手工实现“调用模型 - 解析工具调用 - 执行工具 - 返回结果给模型”的最小流程。这个流程能帮你理解 Agent 的本质后续用框架时才知道框架帮你做了什么、哪些地方需要自己控制。推荐学习顺序用 OpenAI SDK 或本地模型手工完成一次 ReAct 循环。用 LangChain 把模型、工具、Prompt 组织起来。用 LangGraph 把同样流程改成图并加上分支和 interrupt。阅读 LangGraph 关于 conditional edge、子图、并行分支的官方文档。实现一个 Deep Agents 风格的调研 Agent加入评审节点。再评估 ADK看哪些能力能减少你的样板代码。8.2 生产级 Agent 检查清单发布到生产之前至少确认以下项目会话状态已持久化按用户或任务隔离。所有工具都有参数校验和权限校验。关键操作有人工确认或审计日志。模型调用有超时、重试和 token 上限。Agent 最大迭代次数有限制避免死循环。日志里能看到每次模型输入、工具调用和状态变化。有回滚方案框架版本和模型版本都被锁定。长任务有恢复机制进程重启后可以从上次 checkpoint 继续。8.3 如何准备 Agent 框架面试题面试中经常出现的问题往往不是“某个 API 怎么拼”而是“框架原理和工程取舍”。常见问题包括LangGraph 和 LangChain 的区别是什么。如何在一个节点里修改 state。条件路由和子图怎么实现。interrupt 和 resume 机制如何工作。多个 Agent 之间如何通信。Agent 记忆放在哪里如何做数据隔离。模型调用超时怎么办。工具调用失败时如何让模型感知并纠错。提示词注入如何缓解。MCP 和普通工具函数有什么区别。回答思路先讲概念再结合代码讲实现最后补充生产环境中的问题和方案。8.4 框架会迭代但抽象能力更重要LangChain、LangGraph、Deep Agents、ADK 这些名词会随着开源生态快速变化。现在学到的具体 API可能一年后就会被新的写法替代。真正值得投入时间的是四类抽象能力流程编排能力把业务拆成节点、状态、分支和循环。状态管理能力设计清晰的 state 结构知道哪些数据要持久化。工具边界能力什么样的功能适合做成工具工具参数如何设计才可校验。人工介入能力在自动化和可控性之间找到平衡点。把这几点练好无论底层框架换成什么名字你都能快速迁移。实际项目中建议先用最小流程跑通业务再逐步增加状态持久化、人工审批和多 Agent 编排。选型不是终点真正决定项目质量的是框架背后的工程控制力。