多 Agent 编排系统¶

📊 Level ⭐⭐⭐⭐ | 15.7KB

摘要¶

把多个专门 Agent 接入网络并不会自动带来可靠协作：缺少编排层的 Agent 网络会在可预测的方式下失败——步骤之间状态丢失、关键决策无人签核、单个 Agent 宕机引发静默级联故障，根因都是缺少管理执行、状态与审批门（approval gates）的控制面。AWS 的 Agent Orchestration Workshop 展示了用 Step Functions、Bedrock Agents、MWAA 与人工审批工作流构建这一控制面的技术路径。

核心要点¶

控制面缺失是故障根源：无编排层的 Agent 网络失败模式可预测——状态丢失、无人工签核机制、单点故障静默级联。
编排层三要素：执行管理、状态管理、审批门。
确定性工作流：AWS Step Functions 提供状态管理、重试逻辑、分支与跨 Agent 网络的并行执行。
推理驱动协调：Amazon Bedrock Agents 提供内置工具调用、记忆与动态路由。
人工介入：Human-in-the-loop 审批步骤让执行暂停，直到人类对关键决策签核。
DAG 编排：Amazon MWAA（及 Temporal、Airflow、Orkes、Prefect 等 Marketplace 工具）处理复杂多步流水线。
四种编排模式：Orchestrator-Worker 层级编排、Peer-to-Peer 对等协作、Auction-based 市场竞争、投票共识。
四大设计问题：任务分解、角色分配、通信协议、冲突消解构成编排设计的核心维度。

深度分析¶

四种编排模式的设计哲学与取舍¶

层级编排（Orchestrator-Worker）以「分治」为哲学：中央协调者负责任务分解、结果合并与全局状态跟踪，所有 Worker 的信息流都经由协调者路由。优势是控制集中、决策路径可审计、故障定位容易；代价是协调者成为单点瓶颈——既可能成为调用链上的等待热点，也决定了整个系统的决策上限。

对等协作（Peer-to-Peer）以「自主」为哲学：没有中心节点，Agent 通过消息传递自行协商任务归属与数据流。优势是弹性好、无单点依赖、能适应动态变化的协作关系；代价是全局可见性缺失、协调开销随规模上升，且容易引入循环依赖与死锁——两个 Agent 互相认为对方该处理当前请求时可能无限循环，需要递归上限等熔断机制兜底。

市场竞争（Auction-based）以「择优」为哲学：多个 Agent 根据各自能力、报价与上下文适配度竞标任务，由拍卖机制选出中标者。优势是能按能力与成本动态分配异构任务、天然支持负载均衡；代价是竞标协议的设计复杂度与评估偏差——报价高低未必等价于输出质量。

投票共识（voting-consensus）以「民主」为哲学：多个 Agent 独立完成任务后各自给出判断，通过（加权）投票确定最终输出。优势是能稀释单 Agent 的随机偏差、对高风险决策提供冗余保障；代价是推理成本成倍放大，且可能产生「群体平庸」——多数票未必是最优解。

任务分解与角色分配¶

任务分解粒度是多 Agent 系统最核心的权衡。过粗的分解让子任务仍然超过单 Agent 的能力边界，多 Agent 的优势被消解；过细的分解则引入过多的通信与协调开销，编排层本身的成本反超并行收益。经验粒度是：子任务恰好填满单 Agent 上下文窗口的大部分容量、单次执行时长在 1-5 分钟之间，保证 Agent 有足够上下文独立决策且无需二次分解。

角色分配紧随分解而来：谁做哪个子任务，取决于角色定义、能力声明与上下文适配。层级编排下由协调者集中指派，市场竞争下由竞价机制自然选择，对等协作下靠 Agent 自行协商——分配机制与编排模式绑定，而角色边界必须预先划清：职责重叠的灰色地带正是循环依赖与重复劳动的高发区。

通信协议的核心设计选择¶

通信协议有三个正交的选择轴。同步 vs 异步：同步简单直接但引入阻塞依赖，一个慢 Agent 会拖住整条链；异步灵活但把状态管理复杂度推给了调用方。点对点 vs 发布订阅：点对点直接可控、适合已知且稳定的协作关系；发布订阅解耦可扩展、适合动态变化的 Agent 集群。消息格式：结构化格式（JSON Schema）保证互操作性与可校验性，自然语言灵活但引入解析不确定性。实际系统几乎总是采用混合策略——控制流用同步点对点保证确定性，事件流用异步发布订阅换取弹性。

冲突消解与故障处理¶

多 Agent 的冲突不止来自任务竞争，还来自状态分歧：各 Agent 对「当前世界状态」认知不一致时，合并结果互相覆盖。消解手段从轻到重：结构化消息携带版本与来源信息、协调者做结果合并仲裁、投票共识稀释分歧，最终兜底的是人工审批门——把高冲突、高影响的决策显式挂起等待人类签核。

故障处理同样依赖编排层而非 Agent 自律：确定性工作流（Step Functions / MWAA 等）以状态机或 DAG 的形式为每一步提供重试、分支与并行执行语义，状态持久化在编排层而非 Agent 内存中，从而把「单个 Agent 宕机」从级联灾难降级为可重试的普通故障。

一致性协议四问框架（若飞 2026-09）¶

若飞《面试官：讲一讲多 Agent 协作如何保持一致性》提出以四个追问贯穿一致性边界的原创框架，与上述编排模式/冲突消解互补——编排层回答"怎么组织协作"，四问框架回答"协作中什么算数"：

第一问·为什么拆：任务可并行 ≠ 编排可静态——前者看任务依赖，后者看编排方式；执行中产生新线索时调度器要能收回/合并/补派。认领去重不靠调度器里加 if，靠稳定任务身份 + 带条件认领、租约和唯一约束，把"不重复"变成数据库可检查的事实。
第二问·交什么：Agent 间传的不是更长聊天记录而是可继续执行的工作状态（基于哪一版 snapshot/commit、已确认 evidence refs、仍在猜 assumptions、允许做什么 constraints、产物在哪 artifact refs、怎样算完成 acceptance）；任务状态落 agent_task 执行记录（global_task_id/sub_task_id/agent_id/input_snapshot/status/version/attempt/lease_until/result_ref），attempt+version 让系统识别过期消息，跨服务用 Outbox 把事件与本地状态写进同一事务后异步投递。
第三问·谁拍板：分歧不是问题，"基于不同现实却被当同一份现实汇总"才是——汇总不能只做文本拼接，结论要能回到输入快照/来源/证据；结果标"候选/已验证/冲突/已否决"四态；异构输出靠版本化结果契约或接入层适配器对齐；审查只有改变后续动作才算进入系统（"没有后果的批评只是另一段文本"）。
第四问·凭什么算完成：完成由验收条件定义、由运行时留下证据——是状态机里的状态，不是 Agent 回复里的句号；写操作带幂等键，超时按"未执行/已执行/状态未知"分支处理（状态未知 ≠ 失败）；失败落在子任务层做局部重试而非整任务重跑（避免副作用重复落库）；调度器重启靠租约+心跳防双执行者。

核心命题：多 Agent 并没有绕开分布式系统的老问题，只是把执行者从服务和线程换成了会自主判断的 Agent——模型负责判断下一步，运行时负责证明这一步确实发生过；这正是 Harness 需要承担的部分（给正确工作集/限制动作/记录真实结果/失败后带回可继续状态）。该框架与 Anthropic 多 Agent 研究系统的宽度优先拆分、Google Antigravity Teamwork 的审查闭环互为印证。

实践启示¶

从层级编排开始：Orchestrator-Worker 是最容易理解和调试的模式，适合约 80% 的多 Agent 场景；仅在中心协调者成为性能瓶颈或协作关系动态不可预测时，再考虑对等协作或市场竞标。
粒度规则：1 Agent = 1 上下文窗口：子任务的大小以「填满但不溢出单 Agent 上下文窗口」为准，执行时间控制在分钟级——这是任务分解最可操作的检验标准。
通信标准化先行：在实现任何编排逻辑之前，先定义 Agent 之间的消息格式与协议——结构化消息保证互操作性，控制流用同步点对点、事件流用异步发布订阅。
关键决策挂审批门：把需要人类签核的步骤显式建模为 approval gate，执行在此暂停直到人工确认，避免「无人负责的自动化」与高风险决策的静默放行。
为故障建重试与 DAG：用确定性工作流承载跨 Agent 的流水线，让重试、分支与并行执行成为编排层的内建语义，防止单 Agent 故障静默级联成整体失败。

Workflow 架构详解：控制权归属与可回放系统（若飞 2026-09-20 SUPP）¶

若飞四大多 Agent 架构系列首篇，回答系列总纲问题「谁来决定下一步」的 Workflow 答案：路径本来就稳定时，代码掌握路由权，Agent 负责节点内工作。三层职责切分：Agent 节点（检索/分析/生成/调工具，不决定全局路由不跳过检查点）、Workflow 控制流（顺序/条件/重试/超时/终止，不替代节点内推理）、运行时状态（当前节点/结果版本/证据/恢复点，不等于聊天历史）。四架构控制权对照：Workflow=代码和规则（规则变化需改流程）、Supervisor=中央 Agent（中央上下文与决策成瓶颈）、Hierarchical=多层 Supervisor（跨层调试与权限边界复杂）、Swarm/Handoff=当前 Agent（路由依据难统一审计）——可组合但控制权归属不能含糊。

节点结果契约与事件链（全库零覆盖）：节点间传带版本与证据的结果而非「测试完成」一句话，节点字段契约 input_ref/node/attempt/output_ref/quality_status(passed|failed|pending)/next_action 六字段——next_action 不由 Agent 随口写「建议继续」，节点结果先落库、运行时按检查点/重试预算/权限规则计算，以区分「Agent 没完成」与「运行时没放行」。事件链 node_started→tool_called→artifact_written→quality_checked→node_succeeded/node_failed→retry_scheduled→workflow_paused：排查与恢复的抓手，重放从最近稳定节点继续而非全量重跑。

检查点放节点边界：每节点带最低完成条件（资料收集=来源可访问版本已记录；基准测试=环境/数据切片/结果可复现；安全审查=风险项有证据阻断已处理；方案成稿=只引用通过检查点的结果，不生成发布结论），错误停在靠近源头处——上游错误进入下游后 Agent 只会写得更完整未必能重新核实。失败分支都可检查：重试从哪版输入开始/暂停留下什么证据/人工处理后从哪个稳定节点恢复，「没有这些记录，所谓恢复通常只是重新跑一遍」。框架表达差异：LangGraph=StateGraph+条件边+显式状态、CrewAI=角色任务+Flow、MS Agent Framework=应用代码组合步骤、OpenAI Agents SDK=应用代码控序+agents-as-tools（控制权留外层，与 handoff 交控制权不可混写）、Claude Agent SDK=执行节点但固定顺序需外部调度层（框架提供 Agent Loop ≠ 自动提供业务 Workflow）。「代码模拟 Supervisor」信号：运行时反复问模型「调哪个 Agent/是否跳这步/失败回哪里」=已在模拟 Supervisor，继续塞条件不如承认需要动态调度。Google Research scaling 研究结论：任务依赖结构应先于 Agent 数量进入架构选择。

Supervisor 架构详解：动态派工与瓶颈（若飞 2026-09-23 SUPP）¶

系列第二篇，回答「谁来决定下一步」的 Supervisor 答案：下一步跟着当前证据走，由中央 Agent 动态路由——价值与风险在同一个地方：主管同时承担派工、上下文管理和最终收口。核心框架维度：①派活两种控制权形态——agents-as-tools（中央持控制权，受控函数调用，守输入输出契约）vs handoff（交接后谁拥有下一步决定权；handoff 回交 Supervisor 仍是中心调度，子 Agent 自选同级即滑向 Swarm，判断标准不在工具名）；②派工日志四字段（subtask/reason/input_ref/stop_condition）——reason 记当时看见的证据、input_ref 记子 Agent 实际读取的版本，两者缺一回放只能靠猜，与首篇节点结果契约互补；③可回放中心状态八字段（task_id/goal/dispatch_history[]/subtask_results[]/evidence_refs[]/budget_remaining/quality_status/termination_reason）——termination_reason 区分证据满足/预算耗尽/风险阻断/超时/人工接管，「没有这个字段，成功和放弃在最终文本里长得一样」；④收口三核对（证据齐全/阻断条件处理/预算边界）——主管生成的文字只是交付物不是系统状态，不能靠总结语气把风险覆盖掉；⑤Meta Agents Rule of Two 引入编排语境——单次会话不同时拥有不可信输入处理+敏感系统访问+状态改变/对外通信三能力，Supervisor 汇总风险但不能替代权限隔离；⑥瓶颈的量化注解——Google Research 180 配置：Finance-Agent centralized +80.9% vs PlanCraft 顺序任务 -39%~-70%；独立并行错误放大 17.2 倍 vs 中心协调 4.4 倍（中心须真检查而非拼接）。适用判据：子任务边界可写清+下一步取决于中间发现+需统一收口+子 Agent 间不需持续直接交换中间状态。