多Agent最怕的不是答错，而是崩溃后不知道做到哪一步
内容提要
阿里云推出RocketMQ-A2A方案，将多Agent协作建模为可回放会话事件流，用普通Topic分发任务、LiteTopic按会话隔离状态，支持崩溃后从消费位置恢复。但可回放不等于不重复执行，外部副作用仍需幂等键与补偿；事件版本、监控积压与恢复演练同样关键。
延伸解读
可回放不等于不重复：外部副作用才是恢复难点
文章强调，消息系统保存事件只解决“事实没丢”和“状态可重建”，无法自动撤销已发生的外部动作。例如采购Agent调用供应商API下单后、写入成功事件前崩溃，恢复重放可能再次下单。因此业务API仍需幂等键，或采用发件箱、事务消息与人工补偿。这提醒读者：引入可回放事件流后，幂等设计仍是必须补上的一环。
顺序边界：单会话有序，跨会话并发仍需冲突处理
LiteTopic保证单个会话内有序，但不自动保证跨会话全局顺序。若两个Agent同时修改同一客户账户，仍要用版本号、条件更新或锁处理冲突。文章指出，消息“至少到达一次”和业务“恰好生效一次”不是同一件事。落地时需明确单会话有序与跨会话并发的边界，避免误以为消息有序就能解决所有并发问题。
事件版本化与监控：恢复链不断的关键配套
文章提醒，事件模式本身需要版本化。今天Worker写入TEST_FINISHED携带布尔值，明天可能改成包含失败类型的结构；旧会话重放时，新Supervisor若无法理解旧字段，恢复链仍会断。生产系统应为事件定义版本、兼容策略和迁移测试，并避免在消息里直接塞入密钥或完整敏感上下文。监控重点也应转向积压年龄、重复投递、死信数量和会话长期无终态。
是否引入消息集群：先看任务长度与重试安全性
文章给出判断：当Agent数量增加，最先需要扩展的通常不是模型，而是会话状态和失败恢复。但如果系统只有单Agent、短任务和可安全重试的只读工具，引入消息集群可能过度设计；一张数据库任务表和明确状态机更容易运维。读者可据此评估自身场景，避免为不需要的复杂度买单。
Q&A
RocketMQ-A2A 方案是如何解决多 Agent 协作中的状态恢复问题的？
RocketMQ-A2A 将每次协作建模为持久、可回放的会话事件流。普通 Topic 负责 Supervisor 向 Worker 高吞吐分发任务，LiteTopic 作为按会话隔离的返回通道，Worker 把结果和状态事件按顺序写回。Supervisor 与 Worker 分别拥有状态机，由消息推动转换。若 Supervisor 崩溃，可从会话上次消费位置重放结果流，而不是从头运行所有 Agent。
RocketMQ-A2A 在过载和故障场景下的性能表现如何？
官方文章称，在 25 倍过载下，RocketMQ-A2A 把积压外置到持久队列，老年代内存峰值增长 8.2%；HTTP 异步 RPC 增长 456.6%，纯 A2A 实现增长 1366.1%。在 12 组故障注入配置中，端到端任务完成率为 100%。10 个 Broker 的集群支持 1500 万个并发 LiteTopic 和每秒 5 万次处理；20 万个通道下延迟约 15 毫秒，而传统按会话建 Topic 的模型在 2 万个通道时失败。这些数字应按厂商自测理解，不能直接外推。
为什么可回放的消息流不能保证外部操作不会重复执行？
消息系统保存事件，解决的是“事实没有丢”和“状态可重建”，但不能自动撤销已经发生的外部动作。例如采购 Agent 调用供应商 API 下单后，在写入“下单成功”事件前崩溃；恢复后重放到旧状态，可能再次下单。要避免重复，业务 API 仍需接受幂等键，或采用发件箱、事务消息与人工补偿。
在代码修复系统中，如何利用 RocketMQ-A2A 实现崩溃恢复和审计？
代码修复系统可以把“读取 Issue、定位文件、生成补丁、运行测试、请求评审”写成事件。测试 Worker 崩溃后，新 Worker 从任务消息继续；Supervisor 通过会话流知道哪些测试已经返回。补丁写入仓库时带提交基线和任务幂等键，避免恢复后重复创建分支或 PR。审计时保存每次状态转换、工具输入、输出摘要和事件偏移，可以重建“模型为什么看到这条结果”。
使用 RocketMQ-A2A 时，事件模式版本化和监控需要注意什么？
事件模式需要版本化。今天的 Worker 写入 TEST_FINISHED 并携带布尔值，明天可能改成包含失败类型的结构；旧会话重放时，新 Supervisor 若无法理解旧字段，恢复链仍会断。生产系统应为事件定义版本、兼容策略和迁移测试，并避免在消息里直接塞入密钥或完整敏感上下文。监控重点应从单次请求超时转向积压年龄、重复投递、死信数量和某个会话长期没有终态，并接入告警。
什么情况下不适合引入 RocketMQ-A2A 这类消息集群？
如果你的系统只有单 Agent、短任务和可安全重试的只读工具，引入消息集群可能过度设计；一张数据库任务表和明确状态机更容易运维。
采用 RocketMQ-A2A 时，有哪些关键检查项需要落实？
为每个会话定义唯一标识、生命周期和事件保留时间；记录消费位置，并测试 Supervisor 在任意状态崩溃后的恢复；所有有副作用的工具调用使用幂等键或补偿流程；明确单会话有序与跨会话并发的边界；压测时同时观察队列积压、老年代内存、尾延迟和恢复时间；定期演练 Broker、Worker、Supervisor 和外部 API 分别故障。
