A2A Agent Marketplace

这是什么#

输入一个本地项目路径，多个专业 Agent 自动协作，产出一份中文架构分析报告和 Mermaid 架构图（可下载 HTML）。核心不在”分析代码”本身，而在验证 A2A 协议的多 Agent 协作模式：Agent 之间通过 A2A 协议互相发现、传递消息、协商结果，不是一个大模型包办所有事。

协作流程#

三个 Agent 各司其职：

• CodeReader：扫描目录结构、按关键词搜索代码——只负责”读”
• Analyst：基于读到的代码写架构分析，并承担审核角色
• Diagrammer：把分析转成 Mermaid 架构图

三者之间通过 A2A 协议互相发现、传递消息、协商结果——不是一个大模型包办所有事，而是多个专业 Agent 真正协作。

为什么不让一个模型包办#

“分析代码库并画架构图”这件事，交给一个模型一次性做完是可行的。做成多 Agent 协作，验证的是另外两件事：

① 角色分离带来的独立性。 Analyst 既写分析、又审核 Diagrammer 画的图。如果读代码、写分析、画图、审核都在同一个上下文里，“审核”就退化成了自我确认——它会倾向于认为自己刚画的图是对的。让审核者与作图者分处不同上下文，那句”这张图和分析不符”才有意义。 这与我在 Agent 工程系列里写的”执行任务的那一个自评不算数”是同一条。

② 协商回路，而不只是流水线。 多数”多 Agent”实际是把任务切成几段顺序执行，中间没有反馈。这里 Diagrammer 画完的图要交回 Analyst 审核，不符就打回重画——有回路才叫协作，否则只是把一个 prompt 拆成了三个。

代价也很清楚：调用次数与延迟都显著高于一次性做完。所以这是个验证协作模式的 demo，不是”这样效率更高”的主张。

技术栈#

Python 3.11 + A2A SDK + Streamlit。每一步 A2A 调用在界面上实时可见，能直观看到 Agent 之间怎么传递消息。