AI Vibe Coding 18《多 Agent 协议与消息总线：让协同可扩展而不串线》

当团队从单 Agent 走向多 Agent 后，最先出现的不是“能力不足”，而是“协作失序”：

A Agent 说的话 B Agent 听不懂；
同一任务被多个 Agent 重复执行；
上下文互相污染，导致错误放大；
出问题时只能看聊天记录，无法定位哪一跳失败。

这章的目标是把多 Agent 协作从“会对话”升级到“可工程化运行”。

学习目标

完成本章后，你将能够：

为多 Agent 定义统一协议（消息格式、状态语义、错误模型）。
通过消息总线实现解耦协作，避免点对点硬编码依赖。
建立上下文隔离、幂等执行与补偿机制，降低级联故障。
用链路追踪和事件审计实现可定位、可回放、可治理。

一、先统一协议，再谈协作

多 Agent 失败的根因通常不是模型，而是协议缺失。

你至少要统一四件事：

消息信封（Envelope）：谁发、发给谁、属于哪个任务链路。
载荷（Payload）：业务数据结构与版本。
生命周期状态：queued/running/succeeded/failed/cancelled。
错误语义：可重试、不可重试、需人工介入。

1.1 统一消息信封

{
  "messageId": "msg_01J...",
  "traceId": "trace_9f...",
  "taskRunId": "task_20250716_001",
  "fromAgent": "router-agent",
  "toAgent": "review-agent",
  "messageType": "task.request",
  "sentAt": "2025-07-16T10:30:00Z",
  "schemaVersion": "v1"
}

关键要求：

traceId 必须全链路透传。
schemaVersion 必须显式化，禁止隐式兼容。
taskRunId 是业务归因主键，不能缺失。

二、消息总线优于点对点调用

如果 Agent 之间互调 HTTP，初期快，后期必崩：

依赖网状扩散；
改一个 Agent 牵一串；
故障隔离困难。

建议采用“消息总线 + 订阅分发”模式：

路由 Agent 发布任务事件。
领域 Agent 订阅自己关心的主题。
审计 Agent 旁路订阅所有关键事件。

2.1 主题划分建议

task.request.*：任务请求
task.result.*：执行结果
task.error.*：异常
policy.alert.*：策略告警

主题命名按“领域.动作.级别”分层，后续扩展不会混乱。

三、上下文隔离：每个 Agent 只看该看的信息

多 Agent 最大风险是上下文串线。

例如：客服域 Agent 读取了财务域的敏感字段，再把它写进公共总结，直接合规事故。

3.1 上下文访问策略

基于 Agent 角色绑定可读字段白名单。
上下文注入时做字段脱敏与最小化裁剪。
各 Agent 记忆空间隔离，禁止默认共享会话缓存。

agent_context_policy:
  review-agent:
    allow_fields: ["ticket_id", "module", "diff_summary", "risk_level"]
    deny_fields: ["salary", "bank_account", "id_card"]

四、幂等与补偿：避免“执行一次像抽奖”

消息系统一定会遇到重复投递、乱序、超时重试。

4.1 幂等键

每个可变更动作必须携带 idempotencyKey，服务端落库去重。

public sealed class AgentCommand
{
    public string CommandId { get; init; } = string.Empty;
    public string IdempotencyKey { get; init; } = string.Empty;
    public string TaskRunId { get; init; } = string.Empty;
    public string Action { get; init; } = string.Empty;
}

4.2 补偿策略

可逆操作：执行反向动作（如撤销标记、回滚状态）。
不可逆操作：进入人工补偿队列。
连续失败超阈值：熔断该工作流并告警。

幂等解决“重复”，补偿解决“半成功”。两个都要有。

五、错误模型必须标准化

不是所有失败都该重试。建议分类：

TransientError：网络抖动、限流，可指数退避重试。
ValidationError：输入不合法，不可重试，应快速失败。
PolicyError：策略冲突，需人工或策略中心介入。
SystemError：未知异常，触发告警与降级。

{
  "errorType": "PolicyError",
  "retryable": false,
  "policyRef": "SEC-DATA-BOUNDARY-12",
  "recommendedAction": "escalate_to_human"
}

统一错误模型后，监控与处置流程才可自动化。

六、多 Agent 编排：Orchestrator 与 Choreography 怎么选

两种主流模式：

Orchestrator（编排式）

一个中心编排 Agent 决定流程。
优点：路径可控、审计清晰。
风险：中心节点压力大。

Choreography（协同式）

各 Agent 根据事件自主响应。
优点：扩展灵活。
风险：全局行为难推断。

工程建议：

高风险核心流程（发布、权限、财务）用 Orchestrator。
扩展型流程（分析、报告、推荐）用 Choreography。
二者混合，避免“一把锤子打全部钉子”。

七、可观测性：把每一跳都变成证据

在第 17 章我们建立了任务级观测；本章要加“Agent-Hop 级观测”。

7.1 必备观测字段

traceId
hopIndex
fromAgent/toAgent
latencyMs
inputDigest/outputDigest
decisionCode

7.2 关键指标

CrossAgentSuccessRate
MeanHopsPerTask
LoopDetectedRate（环路协作比例）
CompensationTriggerRate

若 MeanHopsPerTask 持续升高，通常意味着分工边界不清，流程在“来回踢球”。

八、落地实践：从 2 Agent 到 5 Agent 的演进路径

阶段 1（2 Agent）

Router Agent + Domain Agent
先跑通协议、幂等、观测三件套

阶段 2（3-4 Agent）

加入 Audit Agent 与 Knowledge Agent
建立策略告警与回放复盘

阶段 3（5 Agent+）

引入 Planner Agent 做任务拆解
引入 Executor Agent 做受控执行
所有高风险动作统一走审批网关

不要一开始就 10 个 Agent。先稳定再扩容。

九、给 Foundation 小库补齐接口（供后续章节复用）

public interface IMessageBus
{
    void Publish<T>(string topic, T message);
    void Subscribe<T>(string topic, Action<T> handler);
}

public interface IAgentProtocolValidator
{
    bool ValidateEnvelope(string json);
    bool ValidatePayload(string messageType, string payloadJson);
}

public interface IIdempotencyStore
{
    bool TryAcquire(string key, TimeSpan ttl);
}

这三个接口是多 Agent 系统最常见的稳定边界：通信、协议校验、幂等控制。

常见坑

1) 消息 schema 不版本化

上线三个月后你会发现谁都不敢改字段。

2) 把全部上下文广播给所有 Agent

这会直接造成安全风险和推理噪音。

3) 重试无上限

会在故障期放大流量雪崩。

4) 只监控成功率，不监控跳数

成功率高但跳数暴涨，通常意味着系统在低效空转。

下一章进入《知识与工具注册中心：让 Agent 能力可发现、可治理、可灰度升级》，解决团队规模扩大后的能力管理问题。