多代理协作：Planner/Executor 在 n8n 中的编排套路

不少团队把 LLM 能力塞进自动化流程后才发现：模型会，但流程不稳——长链任务一旦跨系统、跨时序，很容易在状态丢失、异常回滚与人机协同上“掉链子”。要想既聪明又可靠，关键在于把智能与流程解耦：由可观测的编排系统兜底，让各类智能体按约定接口协作，既能分工，又能合一。

是什么

本文讨论的是一种面向工程落地的多智能体协作方式：把复杂目标拆成若干“规划单元”“执行单元”“评审单元”等角色，通过 n8n 的工作流把它们拼装成可复用的流水线。协作骨架依托 n8n 的节点体系与子流程能力：在主流程中按需调用子流程统一复用；出现异常时由错误工作流接管；需要 LLM 时通过内置的 OpenAI/Chat 模型节点接入。这样做的核心收益是将“智能决策”与“流程控制”分层，让每一步都可审计、可替换、可回放。:contentReference[oaicite:0]{index=0}

为什么

长程任务的真实难点不是“会不会推理”，而是“能不能稳定跑完”。学界与社区近年的经验显示：将推理与行动交替（如 ReAct），或先计划后执行（计划-执行范式），能显著降低幻觉与级联错误；而在工程侧，需要一个能持久化状态、支持人机回环与可中断恢复的编排底座。n8n 的 Wait 节点可在中途挂起并持久化，外部事件再唤醒继续；这与 LangGraph 等“有状态代理编排”理念相呼应；同时 AutoGen 等框架提供多智能体会话范式，可直接作为外部 Agent 服务接入 n8n。:contentReference[oaicite:1]{index=1}

怎么做

最小可用架构（PoC）可以按下列步骤搭建。

1. 定义接口与责任：为各智能单元规定输入/输出 schema 与可用工具清单（如检索、HTTP API、数据库写入）。把“规划产物”做成结构化对象，避免游离文本。相关方法可参考计划-执行示例。:contentReference[oaicite:2]{index=2}
2. 主流程编排（n8n）：以 Webhook/定时触发 → 校验 → 规划 → 分发执行 → 汇总评审的骨架组织节点。执行阶段尽量以“子流程”承载，便于复用与灰度。:contentReference[oaicite:3]{index=3}
3. 状态与人机回环：在关键人工评审处放置 Wait 节点（等待表单/回调/时间），将执行上下文持久化到数据库，待事件达到再恢复。:contentReference[oaicite:4]{index=4}
4. 异常与补偿：为主流程绑定错误工作流（Error Trigger），在失败时收集入参与堆栈，按错误类型进行告警、重试或补偿写入。:contentReference[oaicite:5]{index=5}
5. 工具接入：HTTP Request 节点统一出网；需要自定义逻辑用 Code 节点（JS）实现轻量转换与校验。:contentReference[oaicite:6]{index=6}
6. 扩展并发与弹性：高并发时启用 Queue Mode，将 UI/API、Webhook 与 Worker 解耦；结合并发上限与队列配置实现背压与弹性伸缩。:contentReference[oaicite:7]{index=7}

一个可落地的数据契约（用于“规划→执行”传递）：

{ "objective": "在客服知识库中定位退款政策并生成回复草稿", "steps": [ {"id":"s1","type":"search","tool":"kb.search","input":{"query":"退款时限"},"policy":{"retry":2,"timeout":20}}, {"id":"s2","type":"compose","tool":"llm.write","input":{"template":"基于检索结果生成三段式回复"}}, {"id":"s3","type":"review","tool":"human.approval","input":{"form":"approval_v1"}} ], "context": {"customer_id":"...", "ticket_id":"..."}, "telemetry": {"trace_id":"${$json.traceId}"} }

规划对象在 n8n 中作为消息体在节点间流转：检索由 HTTP Request/外部 RAG 服务完成，写作调用 OpenAI Chat 模型节点，人工审核通过 Wait 节点“On Form Submitted/On Webhook Call”恢复后续步骤。:contentReference[oaicite:8]{index=8}

关键节点拼装清单（可直接按表搭建）：

上述能力均有官方文档与示例支撑，可逐项对照实现与验证。:contentReference[oaicite:9]{index=9}

扩展思考

与新一代 Agent 框架对齐：LangGraph 强调可控性、持久化与人机在环，非常适合作为外部有状态代理服务，通过 HTTP/子流程与 n8n 解耦集成；AutoGen 提供多智能体会话范式；微软在 2025 年推出的 Agent Framework 则整合了 AutoGen 与 Semantic Kernel 的思路，指向统一的企业级代理栈。工程上可将这些框架作为“外部智能层”，n8n 负责编排、审计与守护。:contentReference[oaicite:10]{index=10}

方法论对比：在需要强工具使用与在线检索的任务中，交替推理-行动（ReAct）更易纠错与溯源；而跨多步骤、长跨度的业务流程，计划-执行更利于把控里程碑与补偿逻辑。n8n 作为流程底座，可以同时容纳两种范式，甚至在不同子流程中混用。:contentReference[oaicite:11]{index=11}

可运维与可观测：为每次执行写入 trace_id，将 LLM 调用入参与响应保存到审计表；在 Queue Mode 下设置并发与重试窗口，避免“雪崩”；用错误工作流统一告警与回放入口。这些都是把“能跑”升级为“能长期跑”的要件。:contentReference[oaicite:12]{index=12}

结语：可复用框架与下一步

总结：把智能体当“角色”，把 n8n 当“舞台”。以结构化计划为契约，以子流程复用为抓手，以 Wait/错误工作流与队列并发为护栏，就能把智能从“演示级”推进到“生产级”。上层代理框架负责“想与学”，n8n 负责“跑与管”。:contentReference[oaicite:13]{index=13}

开放问题：在你的业务里，哪一段流程最需要“中途挂起再恢复”（例如等待用户确认或外部系统对账）？如果把这一步改为结构化计划 + Wait 的方式，会减少多少人工对齐成本？欢迎把你的场景拆一拆，再回来对表实现。

更多工程笔记与实践案例，可在 Dr.n8n（drn8n.com）持续关注。