LangGraph 预构建 Agent 实战:create_agent、Supervisor、Swarm 到底封装了什么 LangGraph 企业级 Agent 教程 · 第 6 集。create_agent三行起一个标准 ReAct 循环get_graph()拆开它的真实结构只有两个业务节点middleware怎么把限流/审批变成真节点以及 Supervisor 和 Swarm 的套娃本质。前五集我们全程自己写StateGraph——定义 state、加 node、连 edge、画条件边和循环边。但很快会发现,有几张图你会反复搭一个能调工具、看结果、再判断的 Agent;给这个 Agent 加上最多调 3 次“危险动作先问人”;让多个专家 Agent 分工协作。这些图结构高度标准化。人类团队遇到标准化的活会直接用现成模板,不会每次都从零画流程图。LangGraph 也把这几张反复出现的图封装成了预构建件——create_agent、middleware、create_supervisor、create_swarm。这一集不是要背这几个 API 名,而是要判断哪些需求已经被标准件覆盖,可以直接拿来用;哪些超出了标准件,必须回到自定义 StateGraph。为什么 AI 显得蠢因为它被剥夺了工具和负反馈很多人觉得 AI 蠢,其实是拿一个被剥夺了工具和反馈的它,去比一个工具和反馈都齐全的人。人解决问题显得聪明,不是一次就想对,而是因为人是一个带工具 负反馈的个体手里有很多工具(查资料、算一遍、问同事),每做一步都有负反馈(算错会发现、对方说不对会改)。于是能不断试错、纠偏。纯 LLM 正好被剥夺这两样没工具(只凭记忆)、没负反馈(说完即止,错了不知道、不能回头)。它不是笨,是一锤子买卖 没有手。ReActReason Act就是把这套逻辑还给模型Reason想下一步→ Act用工具动手→ Observe看结果这就是负反馈→ 再 Reason ↑___________________ 循环到模型认为做完 ___________________|create_agent封装的就是这条标准循环,三行代码就能搭出来opsbot_agent create_agent( chat_model, ops_tools, system_promptopsbot_prompt,)用一个客服场景验证“查一下订单 A100 的状态,如果这笔订单金额是 299 元,帮我估算可退多少钱。” 真实 LLM 决定调用哪些工具,预构建 Agent 负责把 tool call、tool execution、再思考循环串起来消息总数: 6是否产生 tool_calls: 是工具消息数量: 2拆开黑盒create_agent 内部只有两个业务节点不要把create_agent当黑盒相信。它返回的就是一个CompiledStateGraph——和你自己写StateGraph().compile()是同一种东西。不靠我说的图,直接用内省方法让 agent 自己说出节点和边graph opsbot_agent.get_graph()for node in graph.nodes.values(): print( -, node.id)for edge in graph.edges: arrow 条件边 if edge.conditional else 硬边 print(f - {edge.source:10} → {edge.target:10} ({arrow}))打印出来只有 4 个框__start__、model、tools、__end__。去掉 middleware 相关分支后,create_agent的核心组装其实就这几行(源码精简版)graph.add_node(model, RunnableCallable(model_node, amodel_node, traceFalse))graph.add_node(tools, tool_node)graph.add_edge(START, model)graph.add_conditional_edges(model, _make_model_to_tools_edge(...), [tools, END])graph.add_conditional_edges(tools, _make_tools_to_model_edge(...), [model, END])三件事值得记住只有model和tools两个真正的业务节点。你自己手写 ReAct 也会写这两个节点,预构建只是替你写好了。循环终止不看模型嘴上说我结束了,而是看最后一条AIMessage还有没有tool_calls。这个判断函数叫_make_model_to_tools_edge,模型并不能直接喊停,是这个函数决定的。tools → model也是条件边,不是硬边。如果某个工具声明了return_directTrue,tools也可能直接跳到END,不会再回model。体检口诀遇到不熟悉的预构建 Agent,先print(agent.get_graph().draw_mermaid()),让它自己说出结构,再去读源码。middleware把横切关注点从 prompt 里搬出来学生最常见的反直觉点是Agent 出了问题,第一反应是再加一句 prompt。但这些动作根本不属于业务对话“最多调 3 次模型,再多就停”——这是预算控制,不是业务规则“用户消息里如果有信用卡号要打码”——这是合规,不是业务规则“issue_refund 调用前必须先问人”——这是审批,不是业务规则。把这些塞进 prompt,模型只是被告知应该这样做,并不一定会真的做。middleware的设计是把这些横切动作拆出来,变成图里真实的节点,不依赖模型的自觉。关键判断middleware 不是装饰器,是真节点。源码会扫描每个 middleware 是否实现了before_agent/before_model/after_model/after_agent四个钩子之一,然后为每个钩子add_node一个新节点,并把入口、循环入口、循环出口、退出节点一一替换掉。这就是为什么有时候你打印get_graph()会看到比model、tools更多的节点——那是 middleware 注入进去的钩子节点,骨架还是同一条 ReAct 循环。预构建的代价快但控制力少——一个真实反例预构建 Agent 并不是不能审批、不能中断。它自带这些开关工具执行前要人工确认用interrupt_before[tools]checkpointer,或者用HumanInTheLoopMiddleware整段挂起恢复靠checkpointer,和第 3 集讲的完全一样。但默认状态下,create_agent会直接执行有副作用的危险工具。用一个退款场景验证unsafe_agent create_agent( chat_model, [query_order_status, issue_refund], # issue_refund 是有副作用的危险工具 system_prompt你是退款助手。用户要求退款时先查订单再调用 issue_refund。,)unsafe_result unsafe_agent.invoke({ messages: [HumanMessage(content给订单 A100 直接退款 100 元。)]}) plaintext 危险工具是否被调用: 是为什么这是问题: 默认 agent 直接执行了退款中间没有任何审批关卡这里的判断分两层修复它不一定要迁移——预构建自带interrupt_before[tools]和HumanInTheLoopMiddleware,就能在工具执行前加上审批关卡,这条路径完全在第 3 集讲过的机制里。真正需要迁移到自定义StateGraph的,是超出标准循环的需求自定义业务状态(比如risk_level、pending_approval)、复杂路由、把审批 / 权限 / 审计做成图里的一等显式结构。唯一不能做的,是把请谨慎塞进 prompt 当安全边界——模型不保证照做。Supervisor 和 Swarm本质是套娃不是魔法第 5 集讲过 Tools 和 Subgraph 的能力原子化;这一集继续往上一层把一个专家 Agent 原子化。create_supervisor让一个主管调度多个专家,适合任务分发create_swarm让多个专家平级交接,适合客服转接。但别把它们当魔法——和create_agent一样,create_supervisor/create_swarm编译出来同样是CompiledStateGraph每个专家就是图里的一个节点,而专家内部又是前面那张 model / tools 循环。所谓多 Agent,本质就是把一张 ReAct 图当成一个节点,再用一张更大的图把它们连起来。order_agent create_agent(chat_model, [query_order_status], nameorder_expert)refund_agent create_agent(chat_model, [query_refund_policy, calculate_refund_amount], namerefund_expert)supervisor_app create_supervisor( [order_agent, refund_agent], modelchat_model, prompt你是客服主管。根据用户问题把任务交给订单专员或退款专员。,).compile()验证套娃结构print(supervisor 实际类型:, type(supervisor_app).__name__)for node in supervisor_app.get_graph().nodes.values(): print( -, node.id)打印出来能看到supervisor、order_expert、refund_expert真就是图里的节点。Supervisor 的本质是——主管 Agent 把专家当成可调用的能力,而不是把所有工具塞进一个大 Agent。另一种拓扑是 Swarm去掉中心主管,让专家用handoff工具直接把对话交接给对方,并用active_agent记住当前由谁负责order_member create_agent( chat_model, [query_order_status, create_handoff_tool(agent_namerefund_member)], nameorder_member,)swarm_app create_swarm([order_member, refund_member], default_active_agentorder_member).compile()区别很直观Supervisor 里有一个中心节点分发任务;Swarm 里没有中心节点,而是order_member通过一个transfer_to_refund_member的 handoff 工具,把对话直接交接给refund_member。选型口诀任务分发、结果汇总用 supervisor;连续转接、平级协作用 swarm。什么时候从预构建迁移到自定义需求推荐选择原因3 天内做一个能查工具的 democreate_agent标准循环速度优先多个专家角色由主管分配create_supervisor角色能力原子化中心调度客服在多个专家间平级转接create_swarm用active_agent保持当前负责角色退款、重启、发布等副作用动作自定义 StateGraph需要审批、权限、审计需要user_role、risk_level等字段自定义 StateGraph预构建核心 state 以 messages 为主学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】