获课：97it.top/17156/

与多智能体协作“斗智斗勇”：我在A2A协议与角色编排中的崩溃与顿悟

在AI技术圈，多智能体（Multi-Agent）系统被描绘得如同科幻电影般美好：一个总控大脑（Manager）优雅地将任务分发给各个领域的专家（Worker），它们各司其职、默契配合，最终输出完美的成果。然而，当我真正着手将这套A2A（Agent-to-Agent）架构从Demo推向生产环境时，迎来的不是“智能涌现”的惊喜，而是一场关于系统失控、成本爆炸与角色混乱的“崩溃之旅”。

我的崩溃始于一个看似完美的协作闭环。我设计了一个由“执行者”和“评审者”组成的双人小组，原本期待它们能通过多轮对话打磨出高质量的结果。但现实却是，评审者对执行者的产出吹毛求疵，执行者则在反复修改中逐渐迷失，两者陷入了无休止的“礼貌推诿”与死循环。当我看到后台账单在短短几周内从几百美元飙升至数万美元时，我才猛然惊醒：在工程世界里，绝对的自由等于绝对的失控。A2A的本质根本不是单纯的AI思考问题，而是一个充满高度动态与强不确定性的分布式系统工程。

在经历了无数次任务脱轨、中间状态不一致以及调试无门的痛苦后，我逐渐摸索出了一套与多智能体“斗智斗勇”的生存法则，迎来了属于工程落地的顿悟。

首先，我学会了给智能体套上“硬边界”的枷锁。我深刻意识到，Agent之间的调用绝不是人类那样的随意聊天，而是必须严谨的RPC（远程过程调用）。现在，我在每一条A2A的调用链路上都设置了严格的熔断机制：明确最大调用轮数、设定Token消耗的预算上限、规定超时强制退出。一旦超过边界，系统代码会毫不留情地直接中断流程。我不再指望Agent自己“意识到该停了”，因为在概率模型的世界里，只有代码的硬性兜底才能阻止它们烧光预算。

其次，我彻底放弃了将“状态管理”交给智能体的幻想。在早期的编排中，我天真地以为Agent能理解任务处于“进行中”还是“已完成”。结果，网络波动或模型的一次概率性抽风，就会导致任务被重复派发，引发重复扣款或数据写入的灾难。现在的我，严格遵循“Agent负责算，系统负责控”的原则。我引入了全局唯一任务ID和严格的状态机（FSM），所有Agent只负责返回计算结果，而任务状态的流转、非法跳转的拦截，全部由系统代码牢牢掌控。

最后，在角色编排上，我从“自由对话”转向了“结构化契约”。与其让智能体在漫长的对话历史中自己揣摩对方的意图，不如直接为它们制定严格的输入输出Schema（数据模式）。通过强制规定上下游的数据结构，并引入全局共享的“黑板”机制，我确保了信息在传递过程中不会丢失或被私藏。同时，我建立了全链路的可观测性体系，不再依赖零散的对话日志，而是通过TraceID追踪每一次调用的输入输出、延迟与Token消耗，让黑盒般的智能体协作变得透明可查。

与多智能体协作的这场“斗智斗勇”，让我彻底褪去了对AI的盲目狂热。真正的智能体落地，靠的不是更华丽的Prompt或更聪明的模型，而是对分布式系统缺陷的深刻敬畏，以及用确定性的工程逻辑去约束不确定性模型的系统化能力。这，才是A2A架构走向成熟的真正顿悟。