Google A2A协议调试3个月，团队被逼出这个骚操作

调试两个AI agent对话时，工程师平均要翻47分钟日志才能定位一次状态异常。AgentDM团队用Google A2A协议做了三个月，终于受够了。

他们的痛点很具体：A2A官方Inspector工具只能当"客户端"发消息，没法模拟对方agent回话。当两个agent陷入"输入-追问-再输入"的死循环时，开发者像在看一场只有单边字幕的电影。

于是他们造了个A2A Simulator——一个能同时扮演甲乙双方的调试沙盒。

协议里的"状态机"比聊天复杂得多

A2A不是简单的"你一句我一句"。Google设计的协议把每次对话封装成一个task（任务），带着明确的状态流转：submitted（已提交）→ working（处理中）→ 可能分叉到input-required（需输入）→ 最终收束到completed（完成）或failed（失败）。

AgentDM团队发现，最烧脑的是input-required状态。这相当于agent说："等等，这事我得问你"。发送方收到后要回传补充信息，任务继续推进。但日志里看，你很难判断：追问消息是挂在了原任务上，还是系统脑抽新建了个任务？

官方Inspector让你连上agent发消息，但没法扮演那个"反问"的角色。团队想要的是个分屏界面：左边是Agent Alpha，右边是Agent Beta，中间能看原始JSON-RPC（远程过程调用协议）到底传了什么。

Simulator的核心设计是"双角色沙盒"——同一界面里，你可以手动控制对话任意一方，实时观察状态跳转。

他们给每个simulator实例配置了独立的agent身份，包括技能清单、端点地址、认证信息。启动后，你可以选择让系统auto-run（自动运行）按预设脚本推进，或随时pause（暂停）接管手动输入。

那个让团队崩溃的"working状态"陷阱

A2A允许agent在working状态时发送多次进度更新，类似微信的"对方正在输入…"但带内容。AgentDM早期踩过一个坑：某agent连发4条working消息，最后一条被网络延迟搞丢了，接收方一直等completed通知，两边僵住。

传统调试方式是ssh上服务器grep日志，筛出task ID再人工对齐时间戳。Simulator把这个问题变成了可视化：working消息的payload（载荷）直接展开在侧边栏，哪条丢了、哪条重复发送，一眼能看出来。

更隐蔽的bug是artifact（附件）处理。A2A协议允许agent随消息附带命名文件或结构化数据，但不同agent对mime-type的解析逻辑参差不齐。Simulator内置了artifact inspector，能对比发送端声明的类型和接收端实际解析的结果。

团队负责人提到一个典型场景：某次调试中，Agent Beta声称发送了CSV格式的报表，但Agent Alpha收到的mime-type被识别为plain/text，导致下游解析失败。这个问题在原始JSON里藏了7层嵌套，Simulator的协议视图让它暴露在第3层。

从"看日志"到"演话剧"：调试范式的切换

AgentDM把Simulator的定位比作"排练厅"而非"监控室"。传统调试是事后验尸，Simulator让你能暂停、倒带、改写台词。

具体实现上，他们做了几个关键设计：

会话录制（session recording）——完整捕获一次多轮对话的原始流量，存为可复现的测试用例。团队内部叫它"剧本"，新人 onboarding 时可以直接加载历史故障场景，不用重新搭建环境。

状态断点（state breakpoints）——在task状态跳转处设 hook，满足条件自动暂停。比如"当任何agent进入input-required时停住"，方便检查上下文是否携带了必要的session信息。

协议注入（protocol injection）——手动构造边缘case的JSON-RPC消息，测试agent的容错能力。AgentDM用这功能模拟过"working消息里progress字段为负数"这种奇葩输入，验证自家agent不会崩溃。

Simulator目前开源在GitHub，但文档里埋了个彩蛋：README最底部有一行被注释掉的配置，开启后会显示Google A2A协议文档里没公开的experimental状态码。

团队没解释这些状态码从哪来，只说"我们和Google的人聊过"。

一个被低估的设计细节

AgentDM在Simulator里加了个人类容易忽略、但agent很在意的功能：streaming（流式传输）的可视化。

A2A协议要求所有通信走streaming，意味着消息是碎片到达的。人类开发者习惯看"整段回复"，但agent的世界是"先收到20字节头部，再收到payload长度，再收到正文分片"。Simulator把TCP层面的流重组过程画成了时间轴，哪里卡顿、哪里重传，用颜色标出来。

这个功能源自一次深夜调试：某agent在弱网环境下表现异常，日志显示消息完整送达，但业务逻辑就是不对。最后发现是streaming实现里，某分片的boundary（边界标记）被中间代理吃掉了，导致agent提前认为消息结束。这个问题在Wireshark里要filter 12层才能看到，Simulator把它降到了表层。

团队现在把Simulator集成进了CI流程——每次代码提交后，自动跑一遍"经典故障剧本"，确保没回归。

Google A2A协议今年4月才正式发布1.0版本，生态工具链还在早期。AgentDM的Simulator是社区里首个支持完整双端模拟的调试器，但作者很克制地没喊"首创"，只在release note里写："我们 needed this，所以 built it"。

文章结尾处，团队贴了一张内部截图：Simulator界面里，Agent Alpha和Agent Beta正在讨论"如何优化A2A调试工具"。对话是自动生成的，但人类开发者可以随时插入一条消息，把话题带偏——比如问一句："你们觉得自己被调试了吗？"

两个agent的task状态，会怎么跳转？