很多团队做多 Agent，会先从“多角色对话”开始：一个做规划、一个写代码、一个做审查。
看起来很高级，但很快会遇到四个现实问题：
- 任务互相踢皮球，没人对最终结果负责。
- 上下文越传越长，成本失控，且信息污染严重。
- 权限边界模糊，评审 Agent 也能执行写库工具。
- 任一步骤失败后，系统不知道该重试、回滚还是降级。
这说明你搭了“角色”，但没搭“系统”。
这篇文章只解决一个目标：把多 Agent 从 Demo 升级为可运行、可管控、可回放的工程系统。
一、先回答：什么时候需要多 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 会从第一天就滑向不可控。
四、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 最小评估集（20-50 条即可起步）
按场景分桶：
- 正常路径
- 冲突结论
- 工具异常
- 权限越界诱导
- 高并发压力
每条样本都要定义成功标准，不要靠“人工感觉”。
九、一个可运行的最小蓝图（MVP）
如果你要在 2-3 周内做出“可讲、可跑、可评估”的多 Agent Demo，推荐这个配置：
9.1 角色划分
Planner Agent：拆任务、定义成功标准Executor Agent：调用工具执行Critic Agent：检查风险与一致性Orchestrator：调度 + 状态机 + 策略
9.2 工程清单
- 协作消息 schema（JSON）
- 状态机与转移日志
- 工具网关（统一 timeout/retry/idempotency）
- 权限策略引擎（最小权限）
- 失败补偿机制（至少 2 个补偿动作）
- 评估脚本（离线回放 + 指标输出）
9.3 面试可复用叙事
你可以用这条链路讲项目：
“先定义协作协议与状态机，再把执行风险关在 Orchestrator 与 Policy 层，最后用可观测与评估闭环证明系统稳定性。”
这比“我们用了某某框架”更有说服力。
十、常见误区（以及更好的替代方案）
误区 1：角色越多越智能
替代：先做 2-3 个角色，把协议与评估做扎实，再扩角色。
误区 2：让 Agent 自由聊天协作
替代：强制结构化消息 + 明确成功标准。
误区 3：只关注准确率，不看系统指标
替代：准确率与时延、成本、失败恢复率一起看。
误区 4：权限只在 API 网关做一次
替代：用户权限 + Agent 权限 + 运行时权限三层叠加。
结语：多 Agent 的核心不是“多”，而是“可治理”
到 2026 年，多 Agent 已经不再是“概念加分项”，而是工程设计能力的放大镜。
真正能拉开差距的不是你有几个 Agent，而是你是否能回答下面这五个问题：
- 协作协议是什么，如何防止信息污染？
- Orchestrator 如何调度、降级、补偿？
- 权限边界如何保证不越权？
- 失败后如何恢复，谁负责最终一致性？
- 如何用指标证明系统在变好？
如果你都能讲清楚，你做的就不是“AI Demo”，而是“可上线系统雏形”。
延伸阅读：
