5.2 消息协议与协作拓扑：让智能体把话说清楚

5.2 消息协议与协作拓扑：让智能体把话说清楚

本节摘要：多智能体系统里最多的故障不是"想错"，而是"传错"——任务在转述中失真、结果在回传中丢字段。本节定义一份最小但完整的消息信封，给出总线式派发的参考实现，并把四种拓扑的控制流与风险摊开对比。

智能体之间的每次交互都是一次"模型读到一段文字再决策"。没有协议的队伍，派发任务的文字全靠主管即兴发挥：有时带上下文，有时不带；有时写清验收标准，有时只有一句"处理一下"。结果就是队员各猜各的。协议的价值在于把每次交互必须携带什么定成死格式，让失真没有藏身之处。

图：消息信封结构——每次交互必须携带的字段

信封与总线：参考实现

@dataclass
class Message:
    msg_id: str            # uuid，全系统唯一
    correlation_id: str    # 归属的任务实例，追踪与汇总靠它
    type: str              # task / result / question / control
    sender: str            # "orchestrator" / 队员名
    receiver: str          # 队员名 / "broadcast"
    payload: dict          # 结构化正文
    acceptance: dict | None = None   # 任务书的验收标准
    round_no: int = 0      # 对话轮次，防无限互问

class Bus:
    """极简消息总线：主管派任务、队员交结果，全部走统一信封。"""
    def __init__(self, agents: dict):
        self.agents = agents
        self.threads: dict[str, list[Message]] = {}

    def send(self, msg: Message):
        self.threads.setdefault(msg.correlation_id, []).append(msg)
        if msg.type == "task":
            reply = self.agents[msg.receiver].handle(msg)     # 队员干活
            self.send(Message(                                 # 回传必带原任务号
                msg_id=new_id(), correlation_id=msg.correlation_id,
                type="result", sender=msg.receiver, receiver=msg.sender,
                payload=reply, round_no=msg.round_no + 1))
        elif msg.type == "result":
            self.agents[msg.receiver].on_result(msg)           # 主管验收
​

两处设计立住了协议的纪律。任务书（type 为 task）必带 acceptance——队员干完自检、主管验收都拿它当唯一标准，"做完了吗"从主观争论变成字段比对。回传必带 correlation_id——并行多任务时，结果不会串门；这个字段缺失造成的串单，是多智能体系统里最经典的低级事故。

四种拓扑的控制流对照

主管型是默认起点：控制权集中意味着调试时只有一份派发轨迹可读。辩论型要定死轮次（信封里的 round_no 派上用场），两到三轮是收益拐点，再往上多是重复表态。群聊形态自由度最高也最容易失控，只在队员需要互相看到彼此进展的场景（比如多人协作改一份文档）使用。

案例：一次派发失真的解剖

背景：主管型队伍里，撰稿人交付的调研报告大量使用编造数据。追责时撰稿人的轨迹显示，它收到的任务书写着"写一份市场调研报告"——七个字，没有数据来源要求、没有验收标准。

操作：按协议改造派发格式后，同样的任务书变成结构化 payload：资料来源限定为调研员的返回、引用必须标注出处、acceptance 写明"每个数字可追溯到来源清单里的条目"。

结果：编造率大幅下降——不是因为撰稿人变诚实了，而是验收标准让它无处可藏：来源清单之外的数字在自检环节就会被自己发现缺引用。

解读：多智能体系统里的"信任问题"，八成可以靠协议解决。模型队员对任务书的服从度，远高于对"请认真负责"这类态度的服从度——这一点与 2.1 节的提示契约是同一条原理在队内的延伸。

变式：队员中途缺信息时，允许 type 为 question 的反问消息（"来源清单里没有竞品 B 的数据，是否需要补充调研？"），主管裁决后再派发。禁止反问的队伍会逼着队员用编造填补空白——提问权是多智能体系统的安全阀。

本节要点回顾

• 协议治失真：信封七字段让每次交互可独立读懂、可追踪、可验收——故障定位从猜变成查。
• 两个必带：任务书必带验收标准，回传必带 correlation_id，二者是多智能体系统的最低纪律。
• 拓扑定控制流：主管型做默认，流水线防放大，辩论定轮次，群聊慎用。
• 反问是安全阀：允许队员承认"我不知道"并提问，好过用编造填补信息缺口。

协议与拓扑解决"怎么配合"，下一节把镜头拉远，看智能体架构模式从单体到团队的完整演化脉络——每种模式各治什么病、付出什么代价。

协议演进的三个阶段

团队的消息协议很少一步到位，实践中通常经历三个阶段，每个阶段有明确的升级信号。

阶段一，自由文本：队员之间直接传自然语言。能跑通，但失真率随队伍规模上升，故障排查全靠翻聊天记录。升级信号：同一任务的重试结论不一致，或两个队员对"完成"的理解出现分歧。

阶段二，结构化信封：引入本节的字段规范，任务派发与结果回传可程序校验。这一阶段能解决八成的传递故障。升级信号：跨任务的统计与审计需求出现——管理层想知道每类任务的平均轮次、超时率，自由填写的字段撑不起维度分析。

阶段三，版本化协议：信封带协议版本号，字段变更走兼容规则（新增字段可忽略、语义变更必须升版本）。这一步在队伍规模扩大、多个团队共享总线时变得必要——没有版本号，上游改一个字段的含义，下游的任务书会在无声中全线失真。

升级的节奏建议：别跳级。直接上阶段三的团队常被版本管理的复杂度反噬——协议治理的成本要与队伍规模匹配。