多 Agent 协作工作流：分工、路由与汇总模式

多 Agent 不是把同一个问题问很多遍

多 Agent 的价值来自职责边界：不同角色拥有不同输入、工具、权限和验收标准，再由确定性流程组合结果。若只是让多个模型自由讨论，不仅成本更高，还会出现重复检索、互相引用幻觉、冲突无人裁决和副作用重复执行。适合拆分的任务通常同时具备多个专业步骤，例如资料检索、数据分析、风险审查与成稿；简单分类或一次工具查询用单个模型加普通节点更稳。

本文以“每周生成产品运营简报”为完整例子。输入是时间范围、产品范围和收件人权限；路由 Agent 判断需要哪些工作包；指标 Agent 查询分析库；反馈 Agent 汇总已脱敏的客服主题；风险 Agent 检查异常和表述边界；汇总器根据结构化结果生成简报草稿；最后经过人工批准才发送。整个链路可在 N8N 中用主工作流加多个子工作流实现。

先画权限图，再设计提示词

为每个角色写一张最小职责卡，至少包含目标、允许输入、允许工具、禁止动作、输出 schema、超时和失败策略。指标 Agent 只读聚合指标，不能读取用户级明细；反馈 Agent 只接触已脱敏文本，不能发消息；风险 Agent 可以标记问题，但不能篡改原始数字；汇总器只读取子任务结果，不直接访问数据库。真正的权限必须在凭证、数据库账户和工具入口落实，不能只写在 System Prompt 里。

推荐把 Agent 分为“判断型”和“执行型”。路由、分类、摘要属于判断型，输出候选决策；数据库查询、文件写入、通知发送属于确定性执行，由普通节点或严格工具完成。涉及发布、删除、转账、群发等高风险动作时，Agent 最多提出动作草案，固定规则校验并获得人工批准后才执行。

每次主任务生成 runId，每个子任务生成稳定 taskId，例如 weekly-2026-W36:metrics。所有日志、调用和结果都携带这两个字段。子工作流重跑时复用 taskId，结果表对它建立唯一约束，从根本上避免一个角色被重复派发后产生两份结果。

路由 Agent 只做有限集合内的选择

路由器的输入应是规范化任务，而不是未经处理的整段聊天历史。先用 Edit Fields 形成明确字段：goal、periodStart、periodEnd、productIds、requestedSections、requesterRole。鉴权得到的 requesterRole 来自受信任上下文，绝不能采用用户文本中“我是管理员”的声明。

路由 Agent 只允许从任务目录中选择，并输出结构化计划：

{
  "route": "weekly_brief",
  "tasks": [
    { "type": "metrics", "priority": 1, "reason": "需要周度核心指标" },
    { "type": "feedback", "priority": 2, "reason": "需要解释指标变化" },
    { "type": "risk_review", "priority": 3, "reason": "对外发送前检查" }
  ],
  "needsClarification": false
}

schema 将 route 和 type 限制为枚举，禁止额外字段，并限制任务数量。Code 或 Switch 节点再次检查请求者是否有权调用对应任务。未知类型、数量超限或字段缺失直接进入澄清/人工分支，不能让模型临时创造一个拥有任意工具的新角色。

并非所有路由都需要模型。若 requestedSections 已明确，使用 Switch 映射更便宜、更可预测；只有自然语言目标确实存在歧义时才调用路由 Agent。还可以让确定性规则先处理高置信请求，模型只接收剩余项，并记录路由原因供后续评估。

子 Agent 的输出必须是可合并的证据包

如果子 Agent 只返回一段散文，汇总器无法判断哪些是事实、哪些是推测，也无法稳定处理失败。给所有子任务定义共同信封，再在 payload 中放角色专属内容：

{
  "runId": "weekly-2026-W36",
  "taskId": "weekly-2026-W36:metrics",
  "agent": "metrics",
  "status": "ok",
  "facts": [
    {
      "claim": "本周激活率较上周上升",
      "value": 0.034,
      "unit": "percentage_point",
      "sourceId": "query:activation_weekly",
      "observedAt": "2026-09-07T01:10:00Z"
    }
  ],
  "warnings": [],
  "confidence": "high"
}

sourceId 应能追溯到内部查询、文档或工单集合，但公开简报只展示允许披露的引用。confidence 使用有限枚举，并说明评定规则；小数分数看起来精确，却不一定经过校准。没有证据的结论放入 hypotheses，不能混进 facts。

指标 Agent 的工具接收预定义查询 ID 和参数，不接受模型生成的任意 SQL。工具入口校验产品范围和日期上限，返回列名、单位、数据更新时间及空值说明。指标变化由 Code 节点计算，模型只负责解释，不让它心算比率。分母为零或数据未完成时输出明确 warning。

反馈 Agent 先由普通节点删除邮箱、电话、地址和内部标识，再对工单去重、抽样或聚类。输出主题、样本数量、代表性脱敏片段与覆盖范围，不能把少量意见写成“所有用户”。风险 Agent 接收其他结果和发布规范，逐条产生 severity、ruleId、targetClaim 与 recommendation，避免只返回“看起来没问题”。

在 N8N 中并行派发与收集

主工作流校验路由结果后，将 tasks 拆成 items，通过 Execute Sub-workflow 调用统一分发器，或按类型用 Switch 进入专属子工作流。可以并行的任务必须没有先后依赖；风险审查依赖指标和反馈结果，就应放在第一批任务汇合之后。不要为了“多 Agent”强行并行，因为错误的依赖关系会让审查拿到不完整上下文。

每个子工作流入口重新校验 runId、taskId、任务类型和权限范围，不能假设主流程永远正确。设置单任务超时、最大输入量和工具调用次数。结果先写入任务结果表，再返回主流程；即使主执行中断，恢复流程也能按 taskId 找回已经完成的结果。

汇合时按预期任务清单收集，而不是“收到几个就算几个”。为每个任务标记 ok、partial、failed 或 timed_out。达到截止时间后根据最低完成条件决定继续：比如指标任务失败就阻止生成，反馈任务超时可以生成明确标注“用户反馈数据暂缺”的内部草稿。这个策略写在配置中，不交给汇总模型临场决定。

并发量由外部接口限流、数据库连接池和预算共同决定。为每个角色分别记录调用次数、输入输出用量、耗时和失败率，才能发现某个角色反复检索或输入膨胀。共享缓存必须同时包含权限范围、数据版本、提示版本和规范化输入哈希，避免把一个产品的数据复用给另一个产品。

先解决冲突，再让模型写文章

冲突处理分三层。第一层是确定性一致性检查：相同指标的名称、时间窗、单位和口径必须一致；数值差异超过容差就标记冲突。第二层是来源优先级，例如分析库的正式聚合高于模型从文字中推断的数字，最新完成的数据高于过期快照。第三层才是人工或专门裁决任务，用于无法靠规则解决的语义分歧。

不要让汇总器悄悄“选一个看起来合理的答案”。给冲突对象保留双方 claim、sourceId 和 observedAt，结果状态设为 conflict。若冲突影响核心结论，停止对外发送；若只影响非关键描述，可在草稿中使用保守措辞并附 warning。风险 Agent 也不能覆盖原值，它只能建议修改，最终变更应留下前后差异。

在进入语言模型前，用 Code 节点生成一个经过排序的 mergePacket：任务完成矩阵、已验证事实、假设、警告、冲突和允许引用的来源。汇总 Agent 的指令明确要求只使用 facts，不补齐缺失数据，不把 hypothesis 写成结论，并按指定章节输出。生成后再次用规则核对关键数字是否原样出现；对于对外材料，再由风险审查或人工复核成稿。

完整例子：每周产品运营简报

每周一 09:00，Schedule Trigger 创建 weekly-2026-W36。主流程用 UTC 记录执行时间，再按业务时区计算上一完整自然周。它检查批次表，确认该 runId 未完成，然后读取订阅配置，得到允许的产品范围和内部收件人。

路由结果要求 metrics、feedback 和 risk_review。主流程先并行启动两个任务：metrics 调用预定义的激活、留存和故障率查询，普通节点计算环比并标注数据完整性；feedback 读取该周已脱敏工单，按产品过滤后提炼主题，并把每个主题的样本数写入证据包。两者分别 upsert 到任务结果表。

收集器发现 metrics 为 ok、feedback 为 partial，因为一个渠道延迟入库。最低完成条件允许生成内部草稿，于是 mergePacket 带上“反馈仅覆盖邮件与站内渠道”的 warning。risk_review 随后检查时间窗、单位、百分比与百分点用词、样本覆盖和敏感信息，发现草稿把“上升 3.4 个百分点”误写为“增长 3.4%”，返回高优先级问题。

确定性节点根据源指标改正单位，再重新生成受影响句子，而不是让整个多 Agent 链路从头运行。最终草稿包含核心指标、变化解释、反馈主题、风险提示和数据覆盖说明。它被写入待审批表，审批页面展示事实来源、冲突和警告。负责人批准后，Send Email 节点使用 runId:audience 作为幂等键发送；拒绝则保存原因并结束，不允许 Agent 自行绕过。

如果 metrics 超时，主流程将任务设为 timed_out，按策略停止简报生成并告警；恢复任务只重新运行 metrics。若发送请求超时，发送节点先查询幂等记录或邮件服务状态，不能直接重发。这些失败路径与正常路径同样是流程设计的一部分。

如何评估多 Agent 是否值得

上线前建立一组固定任务，包含正常请求、信息不足、权限越界、来源冲突、子任务超时、工具返回空值和提示词注入。验收不仅看最终文字，还要逐层检查：路由是否选对任务；无关角色是否没有启动；工具参数是否在授权范围；事实能否追溯；冲突是否被显式保留；失败是否按最低完成条件处理；高风险动作是否确实需要批准。

持续记录路由准确率、任务成功率、需要人工修正的事实数、未解决冲突数、端到端耗时和每角色用量。将单 Agent 基线与多 Agent 方案对比：如果质量没有明显提升，却增加了延迟、成本和故障点，应合并角色或改回确定性节点。角色数量不是成熟度指标，可审计的分工和安全的降级才是。

一条可靠的多 Agent 工作流，本质上是受约束的任务编排系统。路由器只在白名单中选择，子 Agent 只使用最小权限工具，结果通过统一证据契约交换，冲突由规则与来源优先级处理，汇总器只负责表达，外部动作仍由幂等、审批和日志守住边界。做到这些，协作才会比单次生成更可靠，而不是更热闹。