上一篇我们把 Checkpointer、thread_id、interrupt这套「能上线」的基建啃完了。图能转、能存、能等人审批——地基齐了。但你马上会撞上另一个问题到底该上哪种架构查个天气用 ReAct写长报告要不要先 Plan企业 Wiki 要不要 RAG工具一多是不是立刻拆成 Supervisor网上文章喜欢甩一堆名词听起来都像「必须上的高级玩法」。结果就是简单问答也硬套多 Agenttoken 烧完了还没搞清楚自己在解决什么。这一篇站高一点把常见模式摆上台面帮你按场景选架构而不是每件事都硬套同一个循环。老规矩本文以官网最新文档核对过Workflows and agents、Agents、Multi-agent、LangGraph v1。网上大量教程仍在教createReactAgent——那是Deprecated本篇主路径用 LangChain 的createAgent。手写环继续用博客 7 那套StateSchemaToolNode。一、先分清Workflow ≠ Agent官网把这两类掰得很开先立住这个心智模型后面所有「类型」才不会糊成一锅WorkflowAgent路径谁说了算你写死的节点顺序、条件边模型动态决定要不要调工具、调哪个典型形态Prompt chaining、路由、并行、编排工人模型 工具的反馈环可预期性高步骤清晰、好测好审低步骤随任务变化何时用流程已知、要可控问题开放、解法事先说不清一句话Workflow 是预定剧本Agent 是边演边写剧本。官网还列了一批常见 Workflow 骨架本篇只点名不逐个开课Prompt chaining上一步输出喂下一步翻译 → 校验 → 润色Routing先分类再进不同专用流Parallelization互不依赖的子任务并行再汇总Orchestrator-worker编排者拆任务工人各自干活Plan-and-Execute 常落在这一带Evaluator-optimizer生成 → 评估 → 不过就再改跟后面「反思类」进阶模式一家亲Agent有 tool_calls?无 tool_calls模型执行工具最终答案Workflow固定节点预定边可预期输出搞混这两者的典型症状明明步骤写死就行却硬上「让模型自己转」或者反过来——任务完全开放却用一串死链式pipe假装自己能搞定。二、ReAct / Tool-calling Agent默认首选ReAct Reasoning Acting想一步 → 要不要动手 → 动手看结果 → 再想……直到给出最终答案。这是绝大多数「会调工具的 Agent」的心跳博客 7 已经手写过完整环。循环结构agent / model → (有 tool_calls?) → tools → 绕回 model → … → END适用场景需要实时查外部数据天气、DB、HTTP API步骤事先说不清得让模型自己决定调哪些工具对话助手、代码助手、轻量数据分析快捷写法createAgent别再用createReactAgentLangGraph v1 起prebuilt 的createReactAgent已弃用。官方推荐 LangChain 的createAgent——底层仍跑在 LangGraph 上接口更干净还能挂 middleware。import{createAgent}fromlangchain;import{ChatOllama}fromlangchain/ollama;import{tool}fromlangchain/core/tools;import*aszfromzod;constcalculatortool(async({a,b}:{a:number;b:number})String(ab),{name:calculator,description:两数相加,schema:z.object({a:z.number(),b:z.number()}),});constllmnewChatOllama({model:qwen2.5:7b,temperature:0});// createAgent 内部就是「模型 ↔ 工具」循环ReAct 心智constagentcreateAgent({model:llm,tools:[calculator],systemPrompt:你是简洁的算术助手。需要计算时调用工具。,});constresultawaitagent.invoke({messages:[{role:user,content:3 加 5 等于多少}],});console.log(result.messages.at(-1)?.content);想深度定制图拓扑改节点名、塞额外 State、特殊路由别跟createAgent死磕——回到博客 7StateGraphbindToolsToolNodeaddConditionalEdges。快捷入口解决 80% 场景剩下 20% 下沉到 Graph API。别忘了安全带recursionLimit模型抽风一直要工具环会空转。调用时带上上限按 super-step 计超限会抛GraphRecursionErrorimport{GraphRecursionError}fromlangchain/langgraph;try{awaitagent.invoke({messages:[{role:user,content:……}]},{recursionLimit:25});}catch(e){if(einstanceofGraphRecursionError){console.error(环转爆了检查工具描述 / Prompt / 终止条件);}else{throwe;}}三、Plan-and-Execute先画地图再走路跟 ReAct「边想边做」不同这一派把任务拆成两段常再加 replanPlan模型先吐出结构化步骤列表「1. 查资料 2. 写大纲 3. 成文」Execute按步执行——每步可以是 tool、子 Chain甚至另一个小 Agent可选Replan看执行结果改后面的计划再继续官网 Workflows 里的Orchestrator-worker跟它同一家族编排者拆活工人干活子任务数量事先可能不定时还会用到Send这类动态派工 API。本篇先抓心智不展开Send。适用场景多步骤长任务写报告、分析流水线需要给用户看「计划进度条」某几步可并行或部分重试优缺点对照 ReActReActPlan-and-Execute决策节奏每步现想先全局计划再执行可解释性看 tool 轨迹计划本身可审查、可改简单任务刚好容易过度设计实现成本低createAgent/ ToolNode 环更高plan / execute / replan 节点伪拓扑长这样是需改计划完成STARTplanexecute_step还有步骤?END原则步骤本来就清晰、还要展示进度 → 考虑 Plan-and-Execute步骤完全说不清 → 先用 ReAct。别为了「看起来高级」给「查个天气」也先生成五步计划。四、RAG能力不是第三种「循环拓扑」很多文章把RAG Agent跟 ReAct 并列成「Agent 类型」。更准确的说法是RAGRetrieval-Augmented Generation是检索增强能力回答前先从知识库捞相关片段塞进 Prompt再让模型基于材料说话。流程就一句用户问题 → 向量检索 Top-K → Prompt context → LLM → 答案最好带 citations它可以挂在纯 Workflow / Chain检索 → 生成博客 4 那套Agent 的某个工具search_docstool由 ReAct 环按需调用更大图里的一个节点多 Agent 系统里的「知识库专家」适用场景企业知识库、产品手册、内部 Wiki训练数据之外的私有 / 最新文档需要引用来源、压幻觉你该记住的硬道理优点坑能答私有知识检索质量 回答质量上限可展示引用要维护向量索引不必为每份文档微调模型chunk、k、embedding 都要调Agent 模式救不了烂索引。chunk 切飘了、embedding 不对路上再花哨的 Supervisor 也是在一本正经地胡说。五、Multi-Agent何时拆、怎么派单单 Agent一个 ReAct 一堆工具在工具不多、领域清晰时往往就够用。官网也反复提醒不是每个复杂任务都需要多 Agent——有时动态工具 好 Prompt 就行。什么时候才值得拆症状拆分动机System prompt 越写越长每 Agent 只留本领域指令工具互相打架计算器跟写库工具同时可见缩小 tool 可见集多团队要独立演进能力边界清晰的子 Agent多领域要并行调研子任务并行再汇总官网把多 Agent 模式谱系写得很清楚Multi-agent本篇先认脸模式一句话Subagents主 Agent 把子 Agent 当工具调度路由都经主 AgentHandoffs对等交接控制权Command({ goto })那一挂后文再啃Skills仍是单 Agent按需加载专业 Prompt / 知识Router先分类再派到专用 Agent / 流最后可汇总业界常说的Supervisor心智上接近「中心调度」读用户意图 → 派给 research / coding 等 specialist → 汇总。实现上可以是 Router 图也可以是langchain/langgraph-supervisor的createSupervisor内部用 tool-based handoff。本篇用最小 Router 图建立直觉不绑死某个封装包。最小 Supervisor / Router 骨架import{StateGraph,StateSchema,GraphNode,ConditionalEdgeRouter,START,END,}fromlangchain/langgraph;import{ChatOllama}fromlangchain/ollama;import*aszfromzod;constStatenewStateSchema({input:z.string(),route:z.string().default(),output:z.string().default(),});constllmnewChatOllama({model:qwen2.5:7b,temperature:0});// 生产里应用 LLM 结构化输出做路由这里用关键词示意拓扑constsupervisorNode:GraphNodetypeofStateasync(state){constisResearch/研究|分析|报告|调研/.test(state.input);return{route:isResearch?research:coding};};constresearchNode:GraphNodetypeofStateasync(state){constmsgawaitllm.invoke(用三句话做调研摘要${state.input});return{output:String(msg.content)};};constcodingNode:GraphNodetypeofStateasync(state){constmsgawaitllm.invoke(给出简洁的实现思路要点列表${state.input});return{output:String(msg.content)};};constrouteFn:ConditionalEdgeRoutertypeofState,research|coding(state)(state.routeresearch?research:coding);constgraphnewStateGraph(State).addNode(supervisor,supervisorNode).addNode(research,researchNode).addNode(coding,codingNode).addEdge(START,supervisor).addConditionalEdges(supervisor,routeFn,[research,coding]).addEdge(research,END).addEdge(coding,END).compile();constresultawaitgraph.invoke({input:调研一下本地 RAG 的常见坑,});console.log(result.output);researchcoding用户输入SupervisorresearchcodingEND原则单 ReAct 能搞定的不要上 Supervisor。每多一个 Agent就多一轮路由延迟、多一段调试链路、多一笔 token。拆分是为了隔离与专业化不是为了 PPT 好看。六、HITL横切能力不是又一种 AgentHuman-in-the-Loop不单独占一张「Agent 类型」工位——它是横切能力图跑到敏感点调用interrupt()暂停人点完再用Command({ resume })恢复。典型场景发邮件前审批、扣款前二次确认、人工改一版再继续。上一篇已经讲透前置条件这里只钉三句话必须compile({ checkpointer })且 invoke 带稳定的thread_id看返回值里的__interrupt__别默认当异常去try/catchresume 时节点会从头再跑——副作用放 interrupt 之后或做成幂等没有 CheckpointerHITL 就是空中楼阁。细节回看博客 8。七、选型对照表 决策口诀模式 / 能力本质是否循环需要 GraphCheckpointer复杂度Prompt chaining 等 Workflow预定路径否 / 有限可选可选低中ReAct /createAgent模型动态调工具是是封装内多轮时建议中Plan-and-Execute先计划后执行是是可选高RAG检索增强否单次检索或挂工具可选可选中Multi-Agent / Supervisor分工 派单常是是可选高HITL人工闸门—是必须中决策口诀从简单往上加别反过来单次问答 / 固定几步 →Chain / Workflow需要工具、步骤说不清 →ReActcreateAgent或手写 ToolNode 环长任务、步骤清晰、要展示计划 →Plan-and-Execute要答私有文档 →挂上 RAG先把检索做好Prompt / 工具集膨胀到互相踩脚 →再考虑 Multi-Agent高风险副作用 →横切 HITLReflection、ReWOO、Tree-of-Thoughts 这类「进阶玩法」后文再单独啃——本篇目标是先选对主架构别一上来就上多路径搜索。常见坑简单任务硬上 Multi-Agent单 ReAct 能转就别上 Supervisor延迟和钱一起涨。把 RAG / HITL 当成「第 N 种 Agent 循环」一个是检索能力一个是人工闸门别跟 ReAct 拓扑混着背。RAG 检索烂还指望换 Agent 模式救命先优化 chunk、embedding、k再谈编排。ReAct 不设recursionLimit死循环把 token 烧光LangGraph 有上限就用上。HITL 没配 Checkpointer /thread_idinterrupt停得住也 resume 不回来。还在抄createReactAgent教程主路径换成createAgent要定制图就下沉StateGraphToolNode。Plan-and-Execute 用于一句话任务计划本身比答案还贵过度设计。