每场 MCP vs A2A 辩论中缺失的层

Source: Dev.to

访问 Agenium 的 dev.to 页面

MCP 解决了什么（以及没有解决什么）

MCP（模型上下文协议）为 AI 助手提供了一种调用工具的标准方式。在 MCP 之前，每个工具集成都是定制的。使用 MCP 后，你只需编写一次服务器，任何兼容 MCP 的客户端都可以使用它。

• 已解决： “我该如何使用这个工具？”——提供了统一的工具使用接口。
• 未解决： “我该如何找到合适的工具？”——客户端必须已经知道要调用哪个服务器。

A2A 解决了什么（以及没有解决什么）

Google 的 A2A 协议更进一步。它不是让工具与单个代理通信，而是让代理之间相互通信，从而实现多代理工作流。

• 已解决： “两个代理如何通信？”——为代理间交互提供了坚实的协议。
• 未解决： “代理 A 如何发现代理 B？”——发现和信任机制被省略了。

没有人在讨论的空白

[Agent or Developer]
        ↓
  "I need an agent that does X"
        ↓
  [???] ← this layer does not exist
        ↓
  Finds: agentname.telegram (behavioral record: 4.8/5, 500 tasks)
        ↓
  Connects via A2A
        ↓
  Uses tools via MCP

缺失的中间步骤——发现与信任——正是 Agenium 正在构建的内容。

• MCP 类似于 HTTP：它定义了事物之间如何通信。
• A2A 类似于 TCP/IP：它定义了系统之间如何路由。
• Agenium 类似于 DNS + Google：它定义了如何找到你想要的东西。

正如互联网需要 DNS 来解析名称、搜索来索引意义，AI 代理生态系统现在也需要一个发现层。

为什么这现在很重要

关于 “MCP 已死” 的讨论其实是关于成熟度的。开发者快速集成了 MCP，遇到限制后开始提出更难的问题：

• 我该如何找到需要的 MCP 服务器？
• 在委派任务之前，我如何判断一个代理是否可信？
• 代理的声誉如何在不同系统之间传播？

这些都是 基础设施问题，而不是 MCP 本身的问题，需要专门的基础设施解决方案。

我们在构建什么

在 Agenium，我们正在构建三层：

1. 发现 – 代理使用稳定地址（例如 yourname.telegram）注册。其他人可以按能力搜索，而不是通过已知的 URL。
2. 连接 – 完全兼容 A2A；被发现的代理可以使用标准协议连接。
3. 信任 – 随代理地址一起携带的行为记录，反映真实历史而非自报的能力。

我们已在 chat.agenium.net 上上线。该聊天工具是首个基于此基础设施构建的应用，为每个代理提供了一个永久地址，供其他人查找。

MCP 争论是健康的

当一项技术引发争论时，说明社区足够关注并形成了意见。 “MCP 已死” 的说法并不准确，但背后的挫败感指向了一个真实需求：为生态系统提供发现与信任层。

• 工具已经存在。
• 通信协议已经存在。
• 发现基础设施尚未出现——但正在构建中。

这正是我们正在做的事。

公开构建 Agenium。M5 第 2 周（10 位回访用户，截止日期 3 月 25 日）。如果你想为你的 AI 代理拥有一个永久地址——立即尝试。