谷歌A2A协议调试3个月，团队发现80%问题藏在对话回合里

AgentDM团队花了3个月搭建多智能体对话平台，最后发现调试工具比协议本身更难做。他们对着JSON日志盯了72小时，才定位到一个input-required状态丢失的bug——这个状态决定了智能体何时需要追问用户。

这不是个例。谷歌A2A协议发布半年后，开发者社区里最热的讨论不是"怎么写agent"，而是"怎么看见两个agent在聊什么"。协议定义了完整的任务生命周期，但生产环境的黑箱让调试变成考古。

协议画了地图，但没给手电筒

A2A把智能体对话抽象成任务状态机。Agent Alpha发消息给Agent Beta，任务从submitted开始，可能经过working、input-required，最终到达completed或failed。听起来清晰，直到你在凌晨三点追踪一个卡在working状态的任务。

谷歌官方有个Inspector工具，能连上agent发消息。问题是它只能当客户端——你能说话，但没法模拟对方怎么回。对于input-required这种需要来回确认的模式，Inspector相当于单边电话。

AgentDM团队遇到的典型场景：Beta agent问了澄清问题，Alpha收到input-required通知了吗？跟进消息挂到原任务还是新建了任务？原始JSON-RPC长什么样？看服务器日志能回答，但日志是碎片，对话是流，两者对不上。

他们想要的是一个聊天界面，两边消息同时可见，能手动控制任意一侧的回复，还能在异常时扒开协议看底层。没有现成工具，只能自己造。

造一个能"演对手戏"的模拟器

A2A Simulator的核心设计很直接：让每个实例扮演对话中的一方。你可以启动两个窗口，一个当Alpha，一个当Beta，实时观察状态流转。或者只启动一个，连到正在开发的agent上，手动模拟各种边界情况。

关键突破是可视化了input-required的完整回路。当Beta进入input-required状态，Alpha界面会弹出输入框，你填完回复，能看到任务ID是否保持一致、状态码如何变化、artifact附件有没有带过去。之前需要翻三份日志确认的事，现在一眼可见。

团队还加了协议检查层。消息格式不对、必填字段缺失、状态跳转非法——这些在模拟器里直接标红，而不是等到agent报错再反推。对于streaming传输的实时更新，他们用时间轴展示每个chunk到达的顺序，方便排查时序bug。

一个意外收获是测试效率。原来验证多轮对话需要写脚本、跑端到端、看日志，现在两个工程师对着模拟器点几分钟就能覆盖主要路径。他们把常见故障模式做成了快捷按钮：模拟网络延迟、注入畸形JSON、强制状态超时。

从调试工具到协议理解的镜子

Simulator上线两周后，团队发现开发者对它的使用方式出乎意料。很多人不是来调自己的agent，而是来理解A2A协议本身——通过手动操作状态机，看每个动作触发什么响应。

这暴露了一个深层问题：A2A的文档描述的是"应该发生什么"，但开发者需要知道"实际发生了什么"。协议规范有40页，真实交互的corner case可能多一个数量级。模拟器成了两者之间的翻译器。

AgentDM把使用数据开放了出来。最频繁的调试场景前三名：input-required循环中断（31%）、artifact传输失败（27%）、任务状态不同步（22%）。这些数字反向推动了他们的agent设计，比如给input-required加超时重试、artifact做分片校验。

谷歌A2A团队注意到了这个项目。双方在邮件里讨论过把Simulator的部分功能合并到官方Inspector，但时间表未定。目前AgentDM选择保持独立迭代，每两周发版，GitHub issue响应速度维持在48小时内。

如果你正在基于A2A开发多智能体系统，现在有三个选择：用官方Inspector做单侧测试，自己搭日志系统做离线分析，或者试试这个能扮演对话双方的模拟器。最后一个选项的star数上周刚破千。

AgentDM的工程师在文档里留了一句话，没有放在首页："我们花了两个月才意识到，调试工具的设计应该先于agent开发——除非你享受在JSON里潜水。"

现在他们想知道：当你的两个agent第一次对话失败时，你会先检查协议实现，还是先怀疑对方agent有bug？