Agent 实践踩坑：多智能体协作中的三个隐性问题

背景

最近在实践多智能体（Multi-Agent）协作时，踩了几个不太容易察觉的坑。这些问题在单个 Agent 的场景下不会暴露，但一旦多 Agent 并行协作就会变得明显。这里记录一下，也供同样在折腾 Agent 的同学参考。

问题一：心跳机制导致消息刷屏

多 Agent 协作通常需要一个「心跳」来维持各 Agent 的活跃状态。最初的实现是每个 Agent 每 5 秒广播一次心跳，结果在一个 5 Agent 的团队里，每分钟产生 60 条心跳消息，日志很快就被淹没，真正的业务消息反而找不到了。

改进方式：把心跳从「广播」改成「上报给 Leader」，由 Leader 汇总后再对外同步状态。消息量立刻下降了一个数量级，同时保留了状态可见性。

问题二：消息转发时的角色混淆

当 A Agent 把任务转给 B，B 完成后需要把结果回给 A。最初的做法是直接转发原始消息，结果 B 分不清这条消息是「用户需求」还是「A 的中间结果」，导致重复处理。

改进方式：在消息结构里增加 from_role 和 to_role 字段，并在 system prompt 中明确说明每个角色的职责边界。这样 Agent 在处理消息前，就能先判断这条消息该不该自己处理。

问题三：状态跳转缺少收敛条件

多 Agent 流程中，状态机是常见设计。但如果状态跳转只依赖「消息类型」而不依赖「前置条件」，很容易出现死循环——A 等 B 的输出，B 又在等 A 的确认。

改进方式：为每个状态跳转增加明确的收敛条件（例如「B 必须返回 success=true 才允许跳转到 C」），并设置最大轮次限制。一旦超出轮次，强制终止并记录异常。

小结

这三点都不是 Agent 能力本身的问题，而是协作协议设计的问题。换句话说，多 Agent 系统的稳定性，很大程度上取决于消息协议和状态机的设计质量，而不是模型本身有多强。

后续如果遇到新的问题，会继续补充。
（本文经 AI 辅助撰写）