同样让 AI 订机票为什么你的代码像一团乱麻别人却写得像艺术品先讲个真实对比。同样是“帮用户订机票”这个任务用 LangChain 的 AgentExecutor 写出来大概是这样from langchain.agents import AgentExecutor, create_react_agentagent create_react_agent(llm, tools, prompt)executor AgentExecutor(agentagent, toolstools, verboseTrue)result executor.invoke({input: 帮我订一张明天从北京到上海的机票})代码很简洁但问题是——你完全不知道中间发生了什么。Agent 先调用了哪个工具机票查询失败了怎么重试用户中途改主意了怎么打断这些关键逻辑全部被封装在一个“黑盒循环”里你只能看到最终结果却无法控制过程。而用 LangGraph 写同样功能代码长了不少但每一步都清清楚楚from langgraph.graph import StateGraph, ENDgraph StateGraph(AgentState)graph.add_node(parse_intent, parse_intent)graph.add_node(search_flight, search_flight)graph.add_node(confirm_booking, confirm_booking)graph.add_edge(parse_intent, search_flight)graph.add_conditional_edges(search_flight, route_after_search)graph.add_edge(confirm_booking, END)看到区别了吗前者是“交给黑盒”后者是“自己编排”。这就引出了今天要聊的核心问题为什么 2025 年所有主流 Agent 框架——LangGraph、OpenAI Swarm、CrewAI——都在做同一件事把 Agent 从“循环调用”升级为“图状编排”答案藏在六个字里设计模式。这篇文章会给你三样东西第一一张表看懂 Agent 开发的 6 种核心设计模式第二一张决策树告诉你什么场景该用哪种模式第三一个完整实战项目带你亲手用 LangGraph 落地一个多模式组合的 Agent。读完你就能建立从“模式”到“框架”的完整认知链下次技术选型不再拍脑袋。一、Agent 设计模式全景图——6 种模式一张表看懂先上核心交付物——一张表把 6 种模式讲清楚。建议直接截图保存这是全网少有的系统梳理。模式一句话定义典型场景复杂度适用团队ReAct推理→行动→观察→再推理的循环问答机器人、客服助手、多步工具调用⭐⭐入门团队Plan-and-Execute先制定完整计划再逐步执行周报生成、数据分析、研究任务⭐⭐⭐有架构经验的团队Reflection生成→自我批判→修订多轮迭代代码生成、文案润色、质量敏感场景⭐⭐⭐追求输出质量的团队Tool-Calling模型直接输出结构化工具调用指令天气查询、计算器、数据库查询⭐所有团队Human-in-the-Loop关键节点人工审核/确认金融交易、医疗建议、内容审核⭐⭐⭐⭐合规要求高的团队Multi-Agent多个 Agent 分工协作统一调度复杂业务流程调研→生成→发布⭐⭐⭐⭐⭐成熟架构团队下面逐一精讲每种模式给你“定义 场景 小案例”三段式保证看完就能用。1. ReAct最经典的推理-行动循环核心逻辑ReAct Reason Act。模型先“思考”下一步该做什么然后“行动”调用工具观察结果后再“思考”如此循环直到完成任务。这是目前最主流、最通用的 Agent 模式。你看到的绝大多数“AI 客服”“AI 助手”背后跑的都是 ReAct。真实案例用户问“我的订单到哪了”。Agent 的推理链条是这样的——思考用户想知道物流状态我需要先查订单号 → 行动调用查询订单工具 → 观察拿到订单号 → 思考现在需要查物流信息 → 行动调用物流查询工具 → 观察物流信息已获取 → 思考信息完整可以回答用户了 → 输出最终答案。核心要点ReAct 的精髓在于“边想边做”每一步推理都基于上一步的观察结果不需要预先规划完整路径灵活性极高。2. Plan-and-Execute先规划再行动核心逻辑和 ReAct 的“边走边看”不同Plan-and-Execute 模式要求 Agent 先制定一份完整计划然后按计划逐步执行。计划可以动态调整但整体框架先行。真实案例自动生成数据分析报告。Agent 先规划第一步收集原始数据 → 第二步清洗数据 → 第三步分析趋势 → 第四步生成图表 → 第五步撰写结论。计划确认后按部就班执行每步的输出作为下一步的输入。核心要点这种模式适合“任务步骤明确、执行路径可预测”的场景。优点是可控性强缺点是灵活性不如 ReAct遇到计划外情况需要重新规划。3. Reflection让 AI 自我批判核心逻辑Reflection 模式的核心是“生成 → 批判 → 修订”的循环。Agent 先生成一版输出然后让另一个角色或同一个模型的不同 prompt对输出进行批判性评价再根据反馈修订如此迭代多轮。真实案例代码生成场景。第一轮生成代码后Reflection 节点会检查代码有没有 bug有没有安全隐患性能是否最优然后给出修改建议模型根据建议重写代码。通常迭代 2-3 轮后代码质量会有显著提升。核心要点这种模式特别适合“输出质量敏感”的场景比如代码、法律文书、医疗建议。代价是推理成本翻倍生成 批判各算一次调用但换来的是质量的大幅提升。4. Tool-Calling最轻量的工具调用核心逻辑模型直接输出结构化的工具调用指令JSON 格式系统解析后执行工具将结果返回给模型。和 ReAct 的区别在于Tool-Calling 通常是“单轮决策”不需要复杂的推理循环。真实案例天气查询。用户问“北京今天多少度”模型直接输出{quot;toolquot;: quot;get_weatherquot;, quot;paramsquot;: {quot;cityquot;: quot;北京quot;}}系统调用天气 API返回结果模型组织语言回答。整个过程一次完成不需要循环。核心要点这是最轻量、最高效的模式适合“单步工具调用”场景。如果你的任务不需要多步推理用 Tool-Calling 就够了杀鸡不用牛刀。5. Human-in-the-Loop人在回路核心逻辑在关键节点暂停 Agent 的执行等待人工审核或确认通过后再继续。这是高风险场景的“安全阀”。真实案例金融交易场景。Agent 检测到一笔可疑交易自动触发了风控规则。此时 Agent 不会直接执行处置动作而是暂停生成一份风险报告推送给风控专员审核。专员确认后Agent 才继续执行。整个过程在关键节点插入了人工判断确保高风险操作不会失控。核心要点这种模式不是“技术问题”而是“合规问题”。在金融、医疗、法律等强监管行业Human-in-the-Loop 不是可选项是必选项。6. Multi-Agent多智能体协作核心逻辑多个 Agent 各司其职通过一个 Dispatcher调度器统一协调。每个 Agent 负责一个子任务完成后将结果交给下一个 Agent 或汇总给 Dispatcher。真实案例内容营销全链路。一个“市场调研 Agent”负责收集行业数据产出报告后交给“内容生成 Agent”撰写文章再交给“审核 Agent”检查合规性最后“发布 Agent”负责分发到各平台。每个 Agent 专注一个环节效率和质量都比单 Agent 硬扛高得多。核心要点这是最复杂的模式适合“流程长、角色多、任务可拆分”的业务场景。代价是系统复杂度指数级上升需要处理 Agent 间的通信、数据传递、异常处理等问题。关键洞察模式不是互斥的这 6 种模式不是单选题而是组合题。生产级 Agent 往往是多种模式的组合嵌套。比如一个智能客服系统核心是 ReAct但遇到高风险操作时叠加 Human-in-the-Loop一个内容生成系统主体是 Plan-and-Execute但每轮输出后叠加 Reflection 提升质量。搞清楚了 6 种模式下一步就是——怎么选二、模式选型实战——什么场景该用哪种模式很多开发者踩过的坑是拿到需求就急着写代码写到一半发现模式选错了推倒重来。正确的姿势是先做选型决策再动手编码。下面给你一张决策树照着走就不会错任务需要多步推理吗├── 否 → Tool-Calling 就够了└── 是 → 需要动态规划吗├── 否 → ReAct边想边做└── 是 → Plan-and-Execute先规划再执行需要人工审核吗├── 是 → 叠加 Human-in-the-Loop└── 否 → 需要多角色协作吗├── 是 → Multi-Agent└── 否 → 需要自我改进吗├── 是 → 叠加 Reflection└── 否 → Plan-and-Execute 就够场景 A智能客服ReAct Tool-Calling用户问“我的订单到哪了”。Agent 的完整链路是识别意图Tool-Calling→ 查订单系统Tool-Calling→ 判断需要物流信息ReAct 推理→ 查物流系统Tool-Calling→ 组合回答。选型判断任务需要多步推理查订单 → 查物流 → 组合回答但步骤相对固定不需要动态规划所以用 ReAct 为主Tool-Calling 辅助。场景 B自动周报生成Plan-and-Execute ReflectionAgent 的完整链路是规划收集数据 → 分析趋势 → 生成报告→ 执行每步独立完成→ 反思审查报告质量发现问题则修订。选型判断任务步骤明确、可预测适合 Plan-and-Execute同时报告质量直接影响使用者决策需要叠加 Reflection 做质量把关。场景 C金融风控审核Human-in-the-Loop Multi-AgentAgent 的完整链路是风险检测 Agent 实时监控交易Multi-Agent 中的一个角色→ 发现问题 → 生成风险报告 → 推送给人工审核Human-in-the-Loop 暂停→ 审核通过 → 处置 Agent 执行操作。选型判断涉及多个角色协作检测、审核、处置必须用 Multi-Agent同时金融场景合规要求极高Human-in-the-Loop 是硬性要求。常见选型误区误区一盲目追求复杂模式。“能用 ReAct 解决的非要用 Multi-Agent”这是最常见的错误。记住一个原则能用简单模式解决绝不用复杂模式。模式越复杂系统越难维护出问题的概率越大。误区二忽视 Human-in-the-Loop 的必要性。很多开发者在非高风险场景也硬塞人工审核导致用户体验极差反过来在高风险场景却完全自动化出了事故才后悔。判断标准很简单如果这一步出错会造成严重后果金钱损失、法律风险、人身安全就必须有人工审核。选好了模式接下来就是最核心的问题——为什么偏偏是 LangGraph三、为什么是 LangGraph——从设计模式反推框架需求要回答“为什么是 LangGraph”先反过来想6 种设计模式对框架提出了哪些核心需求需求推导6 种模式 → 5 大框架需求需求一状态管理。所有模式都需要跨步骤传递数据。ReAct 的“推理-行动-观察”循环里每一步的观察结果要传给下一步Multi-Agent 里一个 Agent 的输出要传给另一个 Agent。如果没有统一的状态管理数据传递会变成一场灾难。需求二控制流编排。ReAct 需要循环推理 → 行动 → 观察 → 再推理Plan-and-Execute 需要顺序执行 动态调整Multi-Agent 需要并行 分支。框架必须能表达这些复杂的控制流结构。需求三错误恢复。某一步失败后系统如何回退如何重试如何跳过比如调外部 API 超时是重试三次还是直接放弃这些逻辑需要框架层面的支持。需求四人在回路。Human-in-the-Loop 要求框架能在任意节点“暂停”等待人工输入后再“恢复”。这不是简单的 if-else 能搞定的需要原生的暂停/恢复机制。需求五可观测性。多步骤执行的过程追踪、日志记录、可视化调试——这是生产级 Agent 的刚需。出了问题你得能定位到具体是哪一步、哪一行代码。对照实验为什么 LangChain 不够用LangChain 的 AgentExecutor 是一个“黑盒循环”——它帮你封装了 ReAct 循环但你无法细粒度控制每一步。具体来说四个致命局限第一不支持复杂分支。AgentExecutor 只能线性执行“思考 → 行动 → 观察”的循环无法表达“如果 A 条件成立走这个分支否则走另一个分支”的逻辑。第二状态管理脆弱。所有中间状态都塞在一个 context 里一旦步骤变多上下文爆炸状态就乱了。第三无法插入人工审核。AgentExecutor 一旦启动就会一口气跑完你没法在中间步骤暂停等待人工确认。第四可观测性差。你只能看到最终结果中间过程是一个黑盒。出了问题只能加日志打印调试体验极差。LangGraph 的解法图结构如何天然满足这些需求LangGraph 的核心思想是把 Agent 的执行流程建模成一张图。图有三个基本元素——State状态、Node节点、Edge边它们正好对应前面推导出的五大需求。State状态公共黑板模式。所有节点共享读写同一个 State 对象天然支持跨步骤数据传递。就好比团队协作时大家都在同一块黑板上写字、修改信息自然流通。Node节点独立执行单元。每个节点是一个函数——接收 State 作为输入处理后返回更新后的 State。节点可复用、可组合想加一个新步骤就加一个新节点。Edge边控制流编排。边定义了节点的执行顺序支持条件路由根据当前状态决定走哪条边、循环回到之前的节点、并行同时执行多个节点。ReAct 的循环、Multi-Agent 的并行协作都能用边来表达。Checkpointer自动持久化状态。LangGraph 内置 Checkpointer 机制自动保存每一步的状态快照。如果程序崩溃可以从最近的断点恢复不用从头开始。这解决了错误恢复的需求。interrupt()原生支持人在回路。LangGraph 提供了 interrupt() 函数可以在任意节点暂停执行等待人工输入后恢复。这是 Human-in-the-Loop 模式的原生支持不用自己造轮子。一张图总结模式 → 需求 → LangGraph 能力映射设计模式核心需求LangGraph 对应能力ReAct循环控制条件边conditional edges实现循环Plan-and-Execute顺序执行 动态调整图结构天然支持顺序 条件路由Reflection多轮迭代循环边实现生成-批判-修订Tool-Calling单步工具调用节点内调用工具函数Human-in-the-Loop暂停/恢复interrupt() 原生支持Multi-Agent多角色协作多节点 并行边实现编排看到这个映射表你就明白了——LangGraph 不是“碰巧”适合这些模式而是“专门”为这些模式设计的。它把 Agent 开发从“写循环”升级为“画图”这恰恰是 2025 年所有主流框架的演进方向。四、LangGraph 实战速览——最小骨架 选型建议光说不练假把式。先给你一个最小可运行的 LangGraph 骨架30 行代码感受一下图编排的威力。最小可运行骨架from typing import TypedDict, Listfrom langgraph.graph import StateGraph, END# 1. 定义 State公共黑板class AgentState(TypedDict):messages: List[str]next_step: str# 2. 定义 Node独立执行单元def call_llm(state: AgentState) - AgentState:# 调用 LLM生成回复response llm.invoke(state[messages])return {messages: state[messages] [response]}def call_tool(state: AgentState) - AgentState:# 调用工具获取结果tool_result search_tool.invoke(state[messages][-1])return {messages: state[messages] [tool_result]}# 3. 构建 Graph图编排graph StateGraph(AgentState)# 添加节点graph.add_node(llm, call_llm)graph.add_node(tool, call_tool)# 添加边顺序执行graph.add_edge(llm, tool)# 添加条件边根据状态路由def router(state: AgentState) - str:if 需要调用工具 in state[messages][-1]:return toolreturn endgraph.add_conditional_edges(llm, router, {tool: tool, end: END})# 设置入口graph.set_entry_point(llm)# 编译并运行app graph.compile()result app.invoke({messages: [帮我查一下北京天气], next_step: })这段代码展示了 LangGraph 的核心三要素State状态、Node节点、Edge边。你把业务逻辑拆成一个个节点然后用边把它们连接起来执行流程一目了然。LangChain vs LangGraph 选型对照表场景推荐框架原因简单问答、单次工具调用LangChain轻量、上手快多步骤流程、条件分支LangGraph图结构天然支持需要状态持久化/断点恢复LangGraphCheckpointer 原生支持多 Agent 协作LangGraph原生多 Agent 编排需要人工审核介入LangGraphinterrupt() 原生支持快速原型验证LangChain代码量更少生产级三件套LangGraph 不只是个库它背后是一整套生态LangSmith可观测性追踪工具每一步执行都有日志和可视化追踪调试神器。LangGraph Studio可视化调试工具你把图加载进去能看到节点执行的全过程拖拽式调整流程。LangGraph Platform一键部署平台支持云端部署、版本管理、监控告警。这三件套覆盖了“开发 → 调试 → 部署”的完整链路是生产级 Agent 的标配。搞清楚了概念和选型最后来一个完整的实战项目带你亲手落地一个“组合模式”的 Agent。五、实战实例用 LangGraph 构建一个“研究报告生成器”理论知识讲再多不如动手做一遍。下面这个项目我会带你用 LangGraph 搭建一个“研究报告生成器”——输入一个研究主题自动完成“资料收集 → 内容生成 → 质量审核 → 人工确认”的全流程。这个项目会用到Plan-and-Execute先规划再执行、Reflection质量审核、Human-in-the-Loop人工确认三种模式的组合是一个接近真实业务场景的完整案例。项目概览输入研究主题如“2025 年 AI Agent 行业趋势”输出一份结构化的研究报告Markdown 格式流程规划 → 收集资料 → 生成内容 → 质量审核 → 人工确认 → 输出报告技术栈LangGraph OpenAI API步骤 1定义 Statefrom typing import TypedDict, List, Optionalclass ResearchState(TypedDict):topic: str # 研究主题plan: List[str] # 执行计划research_data: List[str] # 收集到的资料draft: Optional[str] # 生成的草稿review_feedback: Optional[str] # 审核反馈human_confirmation: bool # 人工确认结果final_report: Optional[str] # 最终报告决策点State 的设计是整个项目的基石。每个字段对应一个阶段的核心数据确保信息在节点间顺畅传递。步骤 2定义 Nodedef plan_research(state: ResearchState) - ResearchState:规划研究步骤prompt f为研究主题 {state[topic]} 制定一个研究计划输出步骤列表。plan llm.invoke(prompt).split(\n)return {plan: plan[:5]} # 限制最多 5 步def collect_data(state: ResearchState) - ResearchState:收集研究资料data []for step in state[plan]:# 调用搜索工具收集资料result search_tool.invoke(f{state[topic]} {step})data.append(result)return {research_data: data}def generate_draft(state: ResearchState) - ResearchState:生成报告草稿prompt f基于以下资料撰写一份关于 {state[topic]} 的研究报告资料{state[research_data]}要求结构清晰包含引言、主体、结论。draft llm.invoke(prompt)return {draft: draft}def review_draft(state: ResearchState) - ResearchState:审核报告质量prompt f审核以下报告指出问题和改进建议报告{state[draft]}检查维度准确性、完整性、逻辑性、可读性。feedback llm.invoke(prompt)return {review_feedback: feedback}def revise_draft(state: ResearchState) - ResearchState:根据反馈修订报告prompt f根据以下反馈修订报告原报告{state[draft]}反馈{state[review_feedback]}revised llm.invoke(prompt)return {draft: revised}决策点collect_data 节点是串行执行还是并行执行如果追求速度可以用 LangGraph 的并行边如果追求稳定性串行更保险。这里为了演示先用串行。步骤 3构建图并设置 Human-in-the-Loopfrom langgraph.graph import StateGraph, ENDfrom langgraph.checkpoint import MemorySaver# 创建图graph StateGraph(ResearchState)# 添加节点graph.add_node(plan, plan_research)graph.add_node(collect, collect_data)graph.add_node(generate, generate_draft)graph.add_node(review, review_draft)graph.add_node(revise, revise_draft)# 添加边顺序执行graph.add_edge(plan, collect)graph.add_edge(collect, generate)graph.add_edge(generate, review)# 条件边审核不通过则修订通过则进入人工确认def should_revise(state: ResearchState) - str:if 问题 in state[review_feedback]:return revisereturn confirmgraph.add_conditional_edges(review, should_revise, {revise: revise,confirm: confirm})graph.add_edge(revise, review) # 修订后再次审核# Human-in-the-Loop人工确认节点def human_confirmation(state: ResearchState) - ResearchState:# interrupt() 会暂停执行等待人工输入confirmation interrupt({message: 报告已生成请确认是否发布,draft: state[draft]})return {human_confirmation: confirmation[approved]}graph.add_node(confirm, human_confirmation)# 根据人工确认结果决定是否输出最终报告def route_after_confirmation(state: ResearchState) - str:if state[human_confirmation]:return finalizereturn revise # 人工不通过打回修订graph.add_conditional_edges(confirm, route_after_confirmation, {finalize: finalize,revise: revise})# 最终输出节点def finalize_report(state: ResearchState) - ResearchState:return {final_report: state[draft]}graph.add_node(finalize, finalize_report)graph.add_edge(finalize, END)# 设置入口graph.set_entry_point(plan)# 编译启用 Checkpointer 以支持中断恢复app graph.compile(checkpointerMemorySaver())决策点interrupt()是 LangGraph 实现 Human-in-the-Loop 的关键。当执行到confirm节点时图会自动暂停等待外部输入。你可以把这个逻辑封装成一个 API 接口前端展示报告草稿用户点击“通过”或“打回”再调用接口继续执行。步骤 4运行项目# 初始化状态initial_state {topic: 2025 年 AI Agent 行业趋势,plan: [],research_data: [],draft: None,review_feedback: None,human_confirmation: False,final_report: None}# 运行会执行到 interrupt 处暂停config {configurable: {thread_id: research_001}}result app.invoke(initial_state, config)# 此时执行暂停在 confirm 节点等待人工输入print(等待人工确认...)print(报告草稿, result[draft])# 模拟人工确认通过app.invoke({human_confirmation: True},config)# 获取最终报告final_state app.get_state(config)print(最终报告, final_state[final_report])关键点thread_id是 Checkpointer 的标识符不同 thread_id 对应不同的会话状态。中断后通过同一个 thread_id 恢复执行状态不会丢失。实战总结这个项目虽然简化了真实业务场景但完整展示了 LangGraph 的三个核心能力图编排用节点和边清晰表达了“规划 → 收集 → 生成 → 审核 → 确认 → 输出”的完整流程。条件路由should_revise和route_after_confirmation两个条件函数实现了“审核不通过打回修订”和“人工不通过打回修订”的复杂逻辑。Human-in-the-Loopinterrupt()让图在人工确认节点暂停实现人机协作。你可以把这个项目扩展到真实业务——比如把collect_data节点换成真实的搜索 API把human_confirmation节点封装成 Web 界面就是一个可用的“研究报告自动生成系统”。结语设计模式是“道”框架是“术”写到这里回到开头的问题为什么 2025 年所有主流 Agent 框架都在做“图状编排”答案是因为 Agent 开发正在从“写 Demo”走向“做产品”而图结构是表达复杂业务流程最自然的方式。设计模式是“道”框架是“术”。先想清楚你的业务属于哪种模式再选框架而不是反过来被框架束缚。最后给你三个行动建议第一如果你的 Agent 还停留在“调 API → 拿结果”的层面先用 ReAct 模式跑通。不要一上来就搞 Multi-Agent复杂度会把你淹没。第二当业务复杂度上升逐步引入 Plan-and-Execute、Human-in-the-Loop、Reflection。每引入一个模式都对应解决一个具体问题——计划性不足加 Plan-and-Execute。风险太高加 Human-in-the-Loop。质量不稳定加 Reflection。第三选框架时先看你的模式需求再对照框架能力。如果你需要状态持久化、条件路由、人工审核、多 Agent 协作——LangGraph 是最佳选择如果你只是做简单问答LangChain 足够别杀鸡用牛刀。文末互动你现在在用什么模式开发 Agent遇到了什么坑评论区聊聊我会精选留言送出 LangGraph 官方文档中文导读 PDF。如果你觉得这篇文章有帮助点个「在看」让更多开发者看到。下期预告《LangGraph 状态管理深度实践》聊聊 Checkpointer 的高级用法和性能优化。 AI订机票：你的代码一团乱麻，别人的却是艺术品？
同样让 AI 订机票为什么你的代码像一团乱麻别人却写得像艺术品先讲个真实对比。同样是“帮用户订机票”这个任务用 LangChain 的 AgentExecutor 写出来大概是这样from langchain.agents import AgentExecutor, create_react_agentagent create_react_agent(llm, tools, prompt)executor AgentExecutor(agentagent, toolstools, verboseTrue)result executor.invoke({input: 帮我订一张明天从北京到上海的机票})代码很简洁但问题是——你完全不知道中间发生了什么。Agent 先调用了哪个工具机票查询失败了怎么重试用户中途改主意了怎么打断这些关键逻辑全部被封装在一个“黑盒循环”里你只能看到最终结果却无法控制过程。而用 LangGraph 写同样功能代码长了不少但每一步都清清楚楚from langgraph.graph import StateGraph, ENDgraph StateGraph(AgentState)graph.add_node(parse_intent, parse_intent)graph.add_node(search_flight, search_flight)graph.add_node(confirm_booking, confirm_booking)graph.add_edge(parse_intent, search_flight)graph.add_conditional_edges(search_flight, route_after_search)graph.add_edge(confirm_booking, END)看到区别了吗前者是“交给黑盒”后者是“自己编排”。这就引出了今天要聊的核心问题为什么 2025 年所有主流 Agent 框架——LangGraph、OpenAI Swarm、CrewAI——都在做同一件事把 Agent 从“循环调用”升级为“图状编排”答案藏在六个字里设计模式。这篇文章会给你三样东西第一一张表看懂 Agent 开发的 6 种核心设计模式第二一张决策树告诉你什么场景该用哪种模式第三一个完整实战项目带你亲手用 LangGraph 落地一个多模式组合的 Agent。读完你就能建立从“模式”到“框架”的完整认知链下次技术选型不再拍脑袋。一、Agent 设计模式全景图——6 种模式一张表看懂先上核心交付物——一张表把 6 种模式讲清楚。建议直接截图保存这是全网少有的系统梳理。模式一句话定义典型场景复杂度适用团队ReAct推理→行动→观察→再推理的循环问答机器人、客服助手、多步工具调用⭐⭐入门团队Plan-and-Execute先制定完整计划再逐步执行周报生成、数据分析、研究任务⭐⭐⭐有架构经验的团队Reflection生成→自我批判→修订多轮迭代代码生成、文案润色、质量敏感场景⭐⭐⭐追求输出质量的团队Tool-Calling模型直接输出结构化工具调用指令天气查询、计算器、数据库查询⭐所有团队Human-in-the-Loop关键节点人工审核/确认金融交易、医疗建议、内容审核⭐⭐⭐⭐合规要求高的团队Multi-Agent多个 Agent 分工协作统一调度复杂业务流程调研→生成→发布⭐⭐⭐⭐⭐成熟架构团队下面逐一精讲每种模式给你“定义 场景 小案例”三段式保证看完就能用。1. ReAct最经典的推理-行动循环核心逻辑ReAct Reason Act。模型先“思考”下一步该做什么然后“行动”调用工具观察结果后再“思考”如此循环直到完成任务。这是目前最主流、最通用的 Agent 模式。你看到的绝大多数“AI 客服”“AI 助手”背后跑的都是 ReAct。真实案例用户问“我的订单到哪了”。Agent 的推理链条是这样的——思考用户想知道物流状态我需要先查订单号 → 行动调用查询订单工具 → 观察拿到订单号 → 思考现在需要查物流信息 → 行动调用物流查询工具 → 观察物流信息已获取 → 思考信息完整可以回答用户了 → 输出最终答案。核心要点ReAct 的精髓在于“边想边做”每一步推理都基于上一步的观察结果不需要预先规划完整路径灵活性极高。2. Plan-and-Execute先规划再行动核心逻辑和 ReAct 的“边走边看”不同Plan-and-Execute 模式要求 Agent 先制定一份完整计划然后按计划逐步执行。计划可以动态调整但整体框架先行。真实案例自动生成数据分析报告。Agent 先规划第一步收集原始数据 → 第二步清洗数据 → 第三步分析趋势 → 第四步生成图表 → 第五步撰写结论。计划确认后按部就班执行每步的输出作为下一步的输入。核心要点这种模式适合“任务步骤明确、执行路径可预测”的场景。优点是可控性强缺点是灵活性不如 ReAct遇到计划外情况需要重新规划。3. Reflection让 AI 自我批判核心逻辑Reflection 模式的核心是“生成 → 批判 → 修订”的循环。Agent 先生成一版输出然后让另一个角色或同一个模型的不同 prompt对输出进行批判性评价再根据反馈修订如此迭代多轮。真实案例代码生成场景。第一轮生成代码后Reflection 节点会检查代码有没有 bug有没有安全隐患性能是否最优然后给出修改建议模型根据建议重写代码。通常迭代 2-3 轮后代码质量会有显著提升。核心要点这种模式特别适合“输出质量敏感”的场景比如代码、法律文书、医疗建议。代价是推理成本翻倍生成 批判各算一次调用但换来的是质量的大幅提升。4. Tool-Calling最轻量的工具调用核心逻辑模型直接输出结构化的工具调用指令JSON 格式系统解析后执行工具将结果返回给模型。和 ReAct 的区别在于Tool-Calling 通常是“单轮决策”不需要复杂的推理循环。真实案例天气查询。用户问“北京今天多少度”模型直接输出{quot;toolquot;: quot;get_weatherquot;, quot;paramsquot;: {quot;cityquot;: quot;北京quot;}}系统调用天气 API返回结果模型组织语言回答。整个过程一次完成不需要循环。核心要点这是最轻量、最高效的模式适合“单步工具调用”场景。如果你的任务不需要多步推理用 Tool-Calling 就够了杀鸡不用牛刀。5. Human-in-the-Loop人在回路核心逻辑在关键节点暂停 Agent 的执行等待人工审核或确认通过后再继续。这是高风险场景的“安全阀”。真实案例金融交易场景。Agent 检测到一笔可疑交易自动触发了风控规则。此时 Agent 不会直接执行处置动作而是暂停生成一份风险报告推送给风控专员审核。专员确认后Agent 才继续执行。整个过程在关键节点插入了人工判断确保高风险操作不会失控。核心要点这种模式不是“技术问题”而是“合规问题”。在金融、医疗、法律等强监管行业Human-in-the-Loop 不是可选项是必选项。6. Multi-Agent多智能体协作核心逻辑多个 Agent 各司其职通过一个 Dispatcher调度器统一协调。每个 Agent 负责一个子任务完成后将结果交给下一个 Agent 或汇总给 Dispatcher。真实案例内容营销全链路。一个“市场调研 Agent”负责收集行业数据产出报告后交给“内容生成 Agent”撰写文章再交给“审核 Agent”检查合规性最后“发布 Agent”负责分发到各平台。每个 Agent 专注一个环节效率和质量都比单 Agent 硬扛高得多。核心要点这是最复杂的模式适合“流程长、角色多、任务可拆分”的业务场景。代价是系统复杂度指数级上升需要处理 Agent 间的通信、数据传递、异常处理等问题。关键洞察模式不是互斥的这 6 种模式不是单选题而是组合题。生产级 Agent 往往是多种模式的组合嵌套。比如一个智能客服系统核心是 ReAct但遇到高风险操作时叠加 Human-in-the-Loop一个内容生成系统主体是 Plan-and-Execute但每轮输出后叠加 Reflection 提升质量。搞清楚了 6 种模式下一步就是——怎么选二、模式选型实战——什么场景该用哪种模式很多开发者踩过的坑是拿到需求就急着写代码写到一半发现模式选错了推倒重来。正确的姿势是先做选型决策再动手编码。下面给你一张决策树照着走就不会错任务需要多步推理吗├── 否 → Tool-Calling 就够了└── 是 → 需要动态规划吗├── 否 → ReAct边想边做└── 是 → Plan-and-Execute先规划再执行需要人工审核吗├── 是 → 叠加 Human-in-the-Loop└── 否 → 需要多角色协作吗├── 是 → Multi-Agent└── 否 → 需要自我改进吗├── 是 → 叠加 Reflection└── 否 → Plan-and-Execute 就够场景 A智能客服ReAct Tool-Calling用户问“我的订单到哪了”。Agent 的完整链路是识别意图Tool-Calling→ 查订单系统Tool-Calling→ 判断需要物流信息ReAct 推理→ 查物流系统Tool-Calling→ 组合回答。选型判断任务需要多步推理查订单 → 查物流 → 组合回答但步骤相对固定不需要动态规划所以用 ReAct 为主Tool-Calling 辅助。场景 B自动周报生成Plan-and-Execute ReflectionAgent 的完整链路是规划收集数据 → 分析趋势 → 生成报告→ 执行每步独立完成→ 反思审查报告质量发现问题则修订。选型判断任务步骤明确、可预测适合 Plan-and-Execute同时报告质量直接影响使用者决策需要叠加 Reflection 做质量把关。场景 C金融风控审核Human-in-the-Loop Multi-AgentAgent 的完整链路是风险检测 Agent 实时监控交易Multi-Agent 中的一个角色→ 发现问题 → 生成风险报告 → 推送给人工审核Human-in-the-Loop 暂停→ 审核通过 → 处置 Agent 执行操作。选型判断涉及多个角色协作检测、审核、处置必须用 Multi-Agent同时金融场景合规要求极高Human-in-the-Loop 是硬性要求。常见选型误区误区一盲目追求复杂模式。“能用 ReAct 解决的非要用 Multi-Agent”这是最常见的错误。记住一个原则能用简单模式解决绝不用复杂模式。模式越复杂系统越难维护出问题的概率越大。误区二忽视 Human-in-the-Loop 的必要性。很多开发者在非高风险场景也硬塞人工审核导致用户体验极差反过来在高风险场景却完全自动化出了事故才后悔。判断标准很简单如果这一步出错会造成严重后果金钱损失、法律风险、人身安全就必须有人工审核。选好了模式接下来就是最核心的问题——为什么偏偏是 LangGraph三、为什么是 LangGraph——从设计模式反推框架需求要回答“为什么是 LangGraph”先反过来想6 种设计模式对框架提出了哪些核心需求需求推导6 种模式 → 5 大框架需求需求一状态管理。所有模式都需要跨步骤传递数据。ReAct 的“推理-行动-观察”循环里每一步的观察结果要传给下一步Multi-Agent 里一个 Agent 的输出要传给另一个 Agent。如果没有统一的状态管理数据传递会变成一场灾难。需求二控制流编排。ReAct 需要循环推理 → 行动 → 观察 → 再推理Plan-and-Execute 需要顺序执行 动态调整Multi-Agent 需要并行 分支。框架必须能表达这些复杂的控制流结构。需求三错误恢复。某一步失败后系统如何回退如何重试如何跳过比如调外部 API 超时是重试三次还是直接放弃这些逻辑需要框架层面的支持。需求四人在回路。Human-in-the-Loop 要求框架能在任意节点“暂停”等待人工输入后再“恢复”。这不是简单的 if-else 能搞定的需要原生的暂停/恢复机制。需求五可观测性。多步骤执行的过程追踪、日志记录、可视化调试——这是生产级 Agent 的刚需。出了问题你得能定位到具体是哪一步、哪一行代码。对照实验为什么 LangChain 不够用LangChain 的 AgentExecutor 是一个“黑盒循环”——它帮你封装了 ReAct 循环但你无法细粒度控制每一步。具体来说四个致命局限第一不支持复杂分支。AgentExecutor 只能线性执行“思考 → 行动 → 观察”的循环无法表达“如果 A 条件成立走这个分支否则走另一个分支”的逻辑。第二状态管理脆弱。所有中间状态都塞在一个 context 里一旦步骤变多上下文爆炸状态就乱了。第三无法插入人工审核。AgentExecutor 一旦启动就会一口气跑完你没法在中间步骤暂停等待人工确认。第四可观测性差。你只能看到最终结果中间过程是一个黑盒。出了问题只能加日志打印调试体验极差。LangGraph 的解法图结构如何天然满足这些需求LangGraph 的核心思想是把 Agent 的执行流程建模成一张图。图有三个基本元素——State状态、Node节点、Edge边它们正好对应前面推导出的五大需求。State状态公共黑板模式。所有节点共享读写同一个 State 对象天然支持跨步骤数据传递。就好比团队协作时大家都在同一块黑板上写字、修改信息自然流通。Node节点独立执行单元。每个节点是一个函数——接收 State 作为输入处理后返回更新后的 State。节点可复用、可组合想加一个新步骤就加一个新节点。Edge边控制流编排。边定义了节点的执行顺序支持条件路由根据当前状态决定走哪条边、循环回到之前的节点、并行同时执行多个节点。ReAct 的循环、Multi-Agent 的并行协作都能用边来表达。Checkpointer自动持久化状态。LangGraph 内置 Checkpointer 机制自动保存每一步的状态快照。如果程序崩溃可以从最近的断点恢复不用从头开始。这解决了错误恢复的需求。interrupt()原生支持人在回路。LangGraph 提供了 interrupt() 函数可以在任意节点暂停执行等待人工输入后恢复。这是 Human-in-the-Loop 模式的原生支持不用自己造轮子。一张图总结模式 → 需求 → LangGraph 能力映射设计模式核心需求LangGraph 对应能力ReAct循环控制条件边conditional edges实现循环Plan-and-Execute顺序执行 动态调整图结构天然支持顺序 条件路由Reflection多轮迭代循环边实现生成-批判-修订Tool-Calling单步工具调用节点内调用工具函数Human-in-the-Loop暂停/恢复interrupt() 原生支持Multi-Agent多角色协作多节点 并行边实现编排看到这个映射表你就明白了——LangGraph 不是“碰巧”适合这些模式而是“专门”为这些模式设计的。它把 Agent 开发从“写循环”升级为“画图”这恰恰是 2025 年所有主流框架的演进方向。四、LangGraph 实战速览——最小骨架 选型建议光说不练假把式。先给你一个最小可运行的 LangGraph 骨架30 行代码感受一下图编排的威力。最小可运行骨架from typing import TypedDict, Listfrom langgraph.graph import StateGraph, END# 1. 定义 State公共黑板class AgentState(TypedDict):messages: List[str]next_step: str# 2. 定义 Node独立执行单元def call_llm(state: AgentState) - AgentState:# 调用 LLM生成回复response llm.invoke(state[messages])return {messages: state[messages] [response]}def call_tool(state: AgentState) - AgentState:# 调用工具获取结果tool_result search_tool.invoke(state[messages][-1])return {messages: state[messages] [tool_result]}# 3. 构建 Graph图编排graph StateGraph(AgentState)# 添加节点graph.add_node(llm, call_llm)graph.add_node(tool, call_tool)# 添加边顺序执行graph.add_edge(llm, tool)# 添加条件边根据状态路由def router(state: AgentState) - str:if 需要调用工具 in state[messages][-1]:return toolreturn endgraph.add_conditional_edges(llm, router, {tool: tool, end: END})# 设置入口graph.set_entry_point(llm)# 编译并运行app graph.compile()result app.invoke({messages: [帮我查一下北京天气], next_step: })这段代码展示了 LangGraph 的核心三要素State状态、Node节点、Edge边。你把业务逻辑拆成一个个节点然后用边把它们连接起来执行流程一目了然。LangChain vs LangGraph 选型对照表场景推荐框架原因简单问答、单次工具调用LangChain轻量、上手快多步骤流程、条件分支LangGraph图结构天然支持需要状态持久化/断点恢复LangGraphCheckpointer 原生支持多 Agent 协作LangGraph原生多 Agent 编排需要人工审核介入LangGraphinterrupt() 原生支持快速原型验证LangChain代码量更少生产级三件套LangGraph 不只是个库它背后是一整套生态LangSmith可观测性追踪工具每一步执行都有日志和可视化追踪调试神器。LangGraph Studio可视化调试工具你把图加载进去能看到节点执行的全过程拖拽式调整流程。LangGraph Platform一键部署平台支持云端部署、版本管理、监控告警。这三件套覆盖了“开发 → 调试 → 部署”的完整链路是生产级 Agent 的标配。搞清楚了概念和选型最后来一个完整的实战项目带你亲手落地一个“组合模式”的 Agent。五、实战实例用 LangGraph 构建一个“研究报告生成器”理论知识讲再多不如动手做一遍。下面这个项目我会带你用 LangGraph 搭建一个“研究报告生成器”——输入一个研究主题自动完成“资料收集 → 内容生成 → 质量审核 → 人工确认”的全流程。这个项目会用到Plan-and-Execute先规划再执行、Reflection质量审核、Human-in-the-Loop人工确认三种模式的组合是一个接近真实业务场景的完整案例。项目概览输入研究主题如“2025 年 AI Agent 行业趋势”输出一份结构化的研究报告Markdown 格式流程规划 → 收集资料 → 生成内容 → 质量审核 → 人工确认 → 输出报告技术栈LangGraph OpenAI API步骤 1定义 Statefrom typing import TypedDict, List, Optionalclass ResearchState(TypedDict):topic: str # 研究主题plan: List[str] # 执行计划research_data: List[str] # 收集到的资料draft: Optional[str] # 生成的草稿review_feedback: Optional[str] # 审核反馈human_confirmation: bool # 人工确认结果final_report: Optional[str] # 最终报告决策点State 的设计是整个项目的基石。每个字段对应一个阶段的核心数据确保信息在节点间顺畅传递。步骤 2定义 Nodedef plan_research(state: ResearchState) - ResearchState:规划研究步骤prompt f为研究主题 {state[topic]} 制定一个研究计划输出步骤列表。plan llm.invoke(prompt).split(\n)return {plan: plan[:5]} # 限制最多 5 步def collect_data(state: ResearchState) - ResearchState:收集研究资料data []for step in state[plan]:# 调用搜索工具收集资料result search_tool.invoke(f{state[topic]} {step})data.append(result)return {research_data: data}def generate_draft(state: ResearchState) - ResearchState:生成报告草稿prompt f基于以下资料撰写一份关于 {state[topic]} 的研究报告资料{state[research_data]}要求结构清晰包含引言、主体、结论。draft llm.invoke(prompt)return {draft: draft}def review_draft(state: ResearchState) - ResearchState:审核报告质量prompt f审核以下报告指出问题和改进建议报告{state[draft]}检查维度准确性、完整性、逻辑性、可读性。feedback llm.invoke(prompt)return {review_feedback: feedback}def revise_draft(state: ResearchState) - ResearchState:根据反馈修订报告prompt f根据以下反馈修订报告原报告{state[draft]}反馈{state[review_feedback]}revised llm.invoke(prompt)return {draft: revised}决策点collect_data 节点是串行执行还是并行执行如果追求速度可以用 LangGraph 的并行边如果追求稳定性串行更保险。这里为了演示先用串行。步骤 3构建图并设置 Human-in-the-Loopfrom langgraph.graph import StateGraph, ENDfrom langgraph.checkpoint import MemorySaver# 创建图graph StateGraph(ResearchState)# 添加节点graph.add_node(plan, plan_research)graph.add_node(collect, collect_data)graph.add_node(generate, generate_draft)graph.add_node(review, review_draft)graph.add_node(revise, revise_draft)# 添加边顺序执行graph.add_edge(plan, collect)graph.add_edge(collect, generate)graph.add_edge(generate, review)# 条件边审核不通过则修订通过则进入人工确认def should_revise(state: ResearchState) - str:if 问题 in state[review_feedback]:return revisereturn confirmgraph.add_conditional_edges(review, should_revise, {revise: revise,confirm: confirm})graph.add_edge(revise, review) # 修订后再次审核# Human-in-the-Loop人工确认节点def human_confirmation(state: ResearchState) - ResearchState:# interrupt() 会暂停执行等待人工输入confirmation interrupt({message: 报告已生成请确认是否发布,draft: state[draft]})return {human_confirmation: confirmation[approved]}graph.add_node(confirm, human_confirmation)# 根据人工确认结果决定是否输出最终报告def route_after_confirmation(state: ResearchState) - str:if state[human_confirmation]:return finalizereturn revise # 人工不通过打回修订graph.add_conditional_edges(confirm, route_after_confirmation, {finalize: finalize,revise: revise})# 最终输出节点def finalize_report(state: ResearchState) - ResearchState:return {final_report: state[draft]}graph.add_node(finalize, finalize_report)graph.add_edge(finalize, END)# 设置入口graph.set_entry_point(plan)# 编译启用 Checkpointer 以支持中断恢复app graph.compile(checkpointerMemorySaver())决策点interrupt()是 LangGraph 实现 Human-in-the-Loop 的关键。当执行到confirm节点时图会自动暂停等待外部输入。你可以把这个逻辑封装成一个 API 接口前端展示报告草稿用户点击“通过”或“打回”再调用接口继续执行。步骤 4运行项目# 初始化状态initial_state {topic: 2025 年 AI Agent 行业趋势,plan: [],research_data: [],draft: None,review_feedback: None,human_confirmation: False,final_report: None}# 运行会执行到 interrupt 处暂停config {configurable: {thread_id: research_001}}result app.invoke(initial_state, config)# 此时执行暂停在 confirm 节点等待人工输入print(等待人工确认...)print(报告草稿, result[draft])# 模拟人工确认通过app.invoke({human_confirmation: True},config)# 获取最终报告final_state app.get_state(config)print(最终报告, final_state[final_report])关键点thread_id是 Checkpointer 的标识符不同 thread_id 对应不同的会话状态。中断后通过同一个 thread_id 恢复执行状态不会丢失。实战总结这个项目虽然简化了真实业务场景但完整展示了 LangGraph 的三个核心能力图编排用节点和边清晰表达了“规划 → 收集 → 生成 → 审核 → 确认 → 输出”的完整流程。条件路由should_revise和route_after_confirmation两个条件函数实现了“审核不通过打回修订”和“人工不通过打回修订”的复杂逻辑。Human-in-the-Loopinterrupt()让图在人工确认节点暂停实现人机协作。你可以把这个项目扩展到真实业务——比如把collect_data节点换成真实的搜索 API把human_confirmation节点封装成 Web 界面就是一个可用的“研究报告自动生成系统”。结语设计模式是“道”框架是“术”写到这里回到开头的问题为什么 2025 年所有主流 Agent 框架都在做“图状编排”答案是因为 Agent 开发正在从“写 Demo”走向“做产品”而图结构是表达复杂业务流程最自然的方式。设计模式是“道”框架是“术”。先想清楚你的业务属于哪种模式再选框架而不是反过来被框架束缚。最后给你三个行动建议第一如果你的 Agent 还停留在“调 API → 拿结果”的层面先用 ReAct 模式跑通。不要一上来就搞 Multi-Agent复杂度会把你淹没。第二当业务复杂度上升逐步引入 Plan-and-Execute、Human-in-the-Loop、Reflection。每引入一个模式都对应解决一个具体问题——计划性不足加 Plan-and-Execute。风险太高加 Human-in-the-Loop。质量不稳定加 Reflection。第三选框架时先看你的模式需求再对照框架能力。如果你需要状态持久化、条件路由、人工审核、多 Agent 协作——LangGraph 是最佳选择如果你只是做简单问答LangChain 足够别杀鸡用牛刀。文末互动你现在在用什么模式开发 Agent遇到了什么坑评论区聊聊我会精选留言送出 LangGraph 官方文档中文导读 PDF。如果你觉得这篇文章有帮助点个「在看」让更多开发者看到。下期预告《LangGraph 状态管理深度实践》聊聊 Checkpointer 的高级用法和性能优化。