多 Agent 协作架构设计：从概念到可运行的系统

很多团队做多 Agent，会先从“多角色对话”开始：一个做规划、一个写代码、一个做审查。

看起来很高级，但很快会遇到四个现实问题：

任务互相踢皮球，没人对最终结果负责。
上下文越传越长，成本失控，且信息污染严重。
权限边界模糊，评审 Agent 也能执行写库工具。
任一步骤失败后，系统不知道该重试、回滚还是降级。

这说明你搭了“角色”，但没搭“系统”。

这篇文章只解决一个目标：把多 Agent 从 Demo 升级为可运行、可管控、可回放的工程系统。

零、先看一个典型失败案例：并行 Agent 结论冲突导致输出摇摆

很多人第一次做多 Agent，会自然想到“让多个 Agent 各自给答案，再挑一个最好的”。

问题是，如果你没有定义冲突处理规则，系统最后很可能不是“更稳”，而是“更摇摆”。

0.1 失败现象

一个企业采购 Agent 把任务拆成三个并行子任务：

Research Agent：收集候选供应商
Risk Agent：标记合规与交付风险
Pricing Agent：做价格区间估算

在一次真实运行里，三个 Agent 给出了互相打架的结论：

Research 认为供应商 A 信息最完整，建议优先推进
Risk 认为供应商 A 有跨境合规风险，不建议继续
Pricing 认为供应商 B 成本更高，但交付窗口更稳定

如果 Orchestrator 只是“拼接三段自然语言”再让模型总结，最终输出很容易在不同轮次里来回摇摆：一轮推荐 A，下一轮又改口说 B 更稳。

0.2 根因定位

这种问题通常有四个根因：

协议层：各 Agent 没有统一输出 schema，结论与证据粒度不同
仲裁层：没有显式评分维度和阈值，只靠模型临场判断
状态层：上一次仲裁理由没有写回 run state，下一轮无法保持一致
观测层：没有记录 disagreement 原因，事后无法复盘为什么改判

0.3 修复策略

真正能止住“输出摇摆”的不是换模型，而是把仲裁过程做成制度：

统一候选输出结构：每个 Agent 都必须输出 proposal + evidence + confidence + riskFlags
显式仲裁规则：先按硬约束过滤，再按权重评分，不允许自由发挥
写回仲裁结果：把最终选择和拒绝理由写入 run state，后续轮次直接引用
冲突可追溯：把 disagreement 原因作为日志字段落盘，支持 replay

0.4 回归测试怎么做

至少准备 20 条“多结论冲突”样本，覆盖这几类情形：

价格最优但合规不满足
风险最低但时延超预算
两个候选结论接近，需要按阈值选择或升级人工确认

对每条样本做三个断言：

仲裁输出必须给出明确理由
同输入重复运行，最终结论不能随机漂移
被拒绝的候选项必须能追溯到具体规则或证据

0.5 一组最值得看的指标

指标	说明	异常信号	目标方向
`arbitration_agreement_rate`	多 Agent 候选与最终结论的一致程度	一致率持续走低	保持稳定
`avg_compensation_per_run`	每次运行平均触发的补偿次数	子任务失败后不断补偿	越低越好
`avg_cost_per_run`	单次多 Agent 运行总成本	并行太多、重算太多	可控在预算内

这类失败案例能很好区分“会搭多角色 Demo”和“能治理多 Agent 系统”的差别。

一、先回答：什么时候需要多 Agent，什么时候不需要？

多 Agent 不是默认更强，它只是把复杂问题拆成多个自治单元。你先看三个判断条件：

1) 单 Agent 是否已触达“职责冲突”

典型冲突：

既要“创意生成”又要“严格合规审核”。
既要“快速探索”又要“稳定执行”。

这两类目标天然拉扯，放在一个 Agent 里，提示词和策略会彼此抵消。

2) 是否存在并行价值

如果任务可拆成独立子任务（如：信息检索、风险评估、方案比选），并行执行能明显降低端到端时延，才值得多 Agent。

3) 是否需要可审计责任边界

线上系统里，你必须回答“谁做了什么决策”。多 Agent 在审计和责任归因上更清晰：

Planner 只负责任务拆解
Executor 只负责工具执行
Critic 只负责风险审查

如果你的场景不满足以上任意一点，优先做好单 Agent + 状态机，通常更稳。

二、三种协作模式：串行、并行、仲裁（选错会拖垮系统）

2.1 串行协作（Pipeline）

流程：Agent A -> Agent B -> Agent C

适合：

输出有明显前后依赖
需要强约束的步骤控制

优点：

可解释性好
回放简单

风险：

任一节点慢，全链路慢
前一步错误会被后续放大

工程建议：

每一步输出必须结构化（schema）
步间做校验，失败即回退，不要“带病流转”

2.2 并行协作（Parallel Fan-out / Fan-in）

流程：Orchestrator -> {Agent A, B, C} -> Merger

适合：

子任务相互独立
对时延敏感

优点：

吞吐更高
能做多路径探索

风险：

结果冲突（A 与 B 结论矛盾）
成本上涨（并发调用更多模型/工具）

工程建议：

明确聚合策略：投票、加权评分、规则优先级
设置并发上限与预算上限，避免“并行爆单”

2.3 仲裁协作（Debate / Election）

流程：多个候选 Agent 输出方案，仲裁 Agent 或规则引擎做最终选择。

适合：

高风险决策（财务、合规、写操作）
需要“解释为什么选这个”

优点：

稳健性高，能降低单路径幻觉
更适合高价值操作前的把关

风险：

设计复杂度高
仲裁自身也可能偏置

工程建议：

仲裁标准必须外显（评分维度、阈值）
把“仲裁理由”作为日志字段落盘，支持审计

三、真正的命门：协作协议（而不是“谁更聪明”）

多 Agent 最容易失败的地方，是 Agent 间传递“自然语言长文本”，导致信息丢失、歧义和污染。

正确做法：定义协作协议（Contract）。

3.1 最小协作消息模型

建议每次 Agent 交互都遵守统一结构：

{
  "runId": "r_20260302_001",
  "taskId": "t_plan_01",
  "from": "planner",
  "to": "executor",
  "goal": "查询用户近30天订单并生成异常摘要",
  "input": {
    "constraints": ["只读权限", "超时8秒"],
    "contextRef": ["ctx_12", "ctx_20"]
  },
  "expect": {
    "schema": "OrderSummaryV2",
    "successCriteria": ["异常订单>=0", "字段完整率=100%"]
  },
  "budget": {
    "maxTokens": 3000,
    "maxLatencyMs": 8000
  }
}

你会发现，这已经不是聊天消息，而是“可执行任务信封”。

3.2 协议必须具备的五个字段

目标（goal）：一句话可判定成功与否
约束（constraints）：权限、成本、时延、格式
成功标准（successCriteria）：可测，不要抽象
预算（budget）：token 与时间上限
引用（contextRef）：传引用 ID，不直接传长文本

没有这五项，多 Agent 会从第一天就滑向不可控。

3.3 协作协议的校验规则：字段齐了还不够，必须能验

很多团队做到这一步会停下来，觉得“有 JSON 协议就行了”。实际还差一半工作：你必须定义协议校验规则。

至少建议做下面这组校验：

goal 不能为空，且必须可判定成功与否
successCriteria 至少一条，并且不能是纯形容词，比如“更好”“更智能”
budget.maxTokens 与 budget.maxLatencyMs 必须在系统允许范围内
constraints 里的权限声明不能超过当前 Agent role scope
contextRef 只能引用当前 run 可见的上下文，不允许跨租户或跨任务引用
schema 必须存在对应版本，避免上下游字段不兼容

这组规则最好放在 Orchestrator 或 Contract Validator 里统一执行，而不是让每个 Agent 自己决定是否遵守。

如果你的系统已经进入工具执行和权限治理阶段，这里要配合安全控制一起落地：

AI Agent 安全与权限控制：一个容易被忽视的落地命门

四、Orchestrator 设计：多 Agent 系统的“操作系统内核”

4.1 Orchestrator 的职责边界

Orchestrator 不做业务推理，它只做四件事：

任务编排：分配、调度、回收
状态推进：维护 run state machine
资源治理：并发、预算、超时
策略执行：权限、重试、降级、补偿

如果 Orchestrator 也参与“内容生成”，系统很容易职责混乱。

4.2 推荐状态机（最小可运行）

INIT
  -> DISPATCH
  -> RUNNING
  -> AGGREGATING
  -> VALIDATING
  -> COMMIT
  -> DONE
  (on error) -> RETRY | COMPENSATE | DEGRADE

每个状态都要绑定：

进入条件
退出条件
最大停留时长
异常转移规则

4.3 调度策略（先简单再复杂）

先用优先队列 + 权重，足以覆盖 80% 场景：

优先级：用户前台请求 > 离线批任务
权重：高价值租户可提升并发配额
退避：失败任务指数退避 + 抖动

不要一上来做复杂强化学习调度，维护成本极高。

五、权限控制：多 Agent 成败分水岭

在多 Agent 场景，权限不是“账号权限”这么简单，而是三层权限叠加：

用户权限：这个用户能看/改什么
Agent 角色权限：这个 Agent 能调用什么工具
运行时上下文权限：当前 run 是否允许该操作

5.1 最小权限模型（可直接落地）

给每个 Agent 定义能力声明：

agent: executor
allowedTools:
  - order.query
  - invoice.preview
deniedTools:
  - payment.refund
maxWriteOpsPerRun: 0
maxExternalCalls: 5

再叠加用户 token scope 与租户策略，最终得到“本次 run 的有效权限集”。

5.2 高风险写操作的“双闸门”

涉及写库/下单/退款时建议强制：

闸门 1：Policy Engine 规则校验
闸门 2：Reviewer Agent 或人工确认

这会增加一步时延，但能显著降低灾难性误操作。

六、失败回滚与补偿：不做这层，系统上线必踩坑

多 Agent 不是所有步骤都可回滚。你需要先区分：

可逆操作：临时文件、缓存写入（可删）
不可逆操作：外部支付、发信、消息推送（不可撤销）

6.1 Saga 思路在 Agent 系统中的落地

把长流程拆成事务片段，每段配一个补偿动作：

创建草稿 -> 补偿：删除草稿
锁库存 -> 补偿：释放库存
发送通知 -> 补偿：发送更正消息

关键点：补偿并不等于回滚，它是“业务语义修正”。

6.2 失败处理优先级

建议顺序：

参数修复重试（同工具）
路径降级（替代工具或只读结果）
执行补偿（若有副作用）
人工接管（输出可审计上下文）

不要在失败后“静默吞掉”，否则你连问题在哪都不知道。

七、上下文治理：避免多 Agent 的“信息雪球”

多 Agent 成本失控，常见根因是把全部历史对话广播给所有 Agent。

7.1 三层上下文分离

Global Context：任务级目标、硬约束（只读）
Role Context：角色特定知识（如审查规则）
Local Working Set：当前步骤需要的最小片段

7.2 传引用，不传全文

用 contextRef 指向上下文存储，Agent 只按需拉取。这样能同时解决：

token 成本
信息污染
隐私最小暴露

7.3 定期摘要与遗忘策略

每 N 步做一次结构化摘要，保留：

决策结论
关键证据 ID
未解决风险

丢弃无关思考链，避免上下文无限膨胀。

八、可观测与评估：没有这层就无法迭代

8.1 你至少要打这些日志字段

runId, taskId, agent, state
输入输出 token、时延、成本
tool 调用参数摘要与结果状态
权限判定结果（allow/deny + rule id）
降级/补偿触发原因

8.2 核心指标（建议按日看趋势）

任务完成率（task_success_rate）
仲裁一致率（arbitration_agreement_rate）
工具失败率（tool_failure_rate）
平均补偿次数（avg_compensation_per_run）
P95 端到端时延（p95_e2e_latency）
单任务平均成本（avg_cost_per_run）

8.3 指标怎么采：先把口径固定，再谈优化

多 Agent 的指标如果没有统一采集口径，很容易出现“每个 Agent 都说自己没问题，但整体系统就是不稳”的情况。

下面这组口径足够做第一版仪表盘：

指标	如何采集	建议样本范围	目标方向
`task_success_rate`	在 run 结束态统计 DONE/FAIL	全量线上 run	稳定提升
`arbitration_agreement_rate`	记录候选结论与最终仲裁的差异	冲突样本重点看	异常时可解释
`avg_compensation_per_run`	每次 run 触发补偿动作次数	有副作用任务单独看	控制在低位
`avg_cost_per_run`	汇总模型 token、工具成本、重试成本	按场景分桶	不因并行失控
`p95_e2e_latency`	从 run 开始到最终输出结束打点	高峰时段重点看	不随峰值塌陷