agent-interop

Agent 互操作——Agent 在自身进程之外使用的协议

agent-orchestrator 构建循环。agent-evals 验证其行为。本技能涵盖循环接触到的进程之外的一切：工具服务、对等 Agent、注册表，以及连接它们的网关。

---

触发词

“MCP 客户端”“Agent 互操作性”“server.json”“agentgateway”“工具联邦”“интероперабельность агентов”“реестр MCP”“delegation token”“токен делегирования”。

此处内容从 0.31.3 的描述“карточка агента”移至此处。

规则零——不注明日期的协议声明只是猜测

在 2026-08-13 之前的 12 个月里，这些规范无一例外都发生了变化——以下每条参考资料都是在这一天读取的——而且每次变化都会悄然破坏基于上一版编写的代码。具体来说，以下内容均是在这一天对照实时规范核实的，而非凭记忆得出：

• MCP 用 server/discover 取代了 initialize 握手，并改为无状态；以 initialize 开始连接的客户端，使用的是即将淘汰的版本。
• MCP 已弃用 sampling、roots 和 logging——较旧的模型会优先使用这三项功能，因为在过去一年里，它们是客户端侧最受关注的部分。
• A2A 在 v0.x 与 v1.0 之间更改了线路层接口，而截至 2026-08-13，SDK 和博客文章仍在介绍 v0.3。
• agentgateway 已弃用 binds，转而使用 gateways——但截至 2026-08-13，其概览页面仍将 binds 介绍为核心概念。

因此：本技能中的每条参考资料都以 **Spec pinned:** 行开头，此资源包的仓库验证器会在缺少该行时导致构建失败。这是机械检查，而不是愿景——它防范的是这样一类错误：由于页面上没有任何说明，文字便会让人误以为内容仍然有效。

**编写线路层代码之前，请先获取规范。**这些参考资料会告诉你需要查找什么内容，以及有哪些变化；但它们不能替代规范文档。请阅读固定版本，然后检查是否存在更新的版本。下方链接映射中的每个条目都可获取。

哪种协议回答哪类问题

你实际遇到的问题	答案	位置
我想让模型具备针对实时系统的能力	MCP 服务	references/mcp.md
服务已经编写完成，但客户端无法连接	挂载和传输方式	references/mcp-ship.md
我想让应用使用他人提供的工具服务	MCP 客户端	references/mcp.md，然后是 references/mcp-scale.md
服务数量超出上下文窗口的容纳范围	客户端扩展模式	references/mcp-scale.md
我想让另一团队的自主 Agent为我完成某个目标	A2A	references/a2a.md
我想让其他 Agent 能发现并调用我的 Agent	A2A Agent Card	references/a2a.md
我想让人们找到并安装我的 MCP 服务	MCP Registry	references/registry.md
我有很多服务、很多客户端，还有安全团队	网关	references/gateway.md

区分这两大协议的一句话规则。 MCP 将模型连接到一个由你控制其形态的能力；A2A 将你连接到一个你有意不去了解其内部的对等方。官方的表述准确且值得牢记：“A2A 关注的是 Agent 之间协作完成任务，而 MCP 更侧重于 Agent 使用能力。” 实际系统会同时使用两者——A2A 服务的内部通过 MCP 通信——这是推荐的架构，而非折中方案。

选择依据是对方是什么，而不是它会运行多久。 MCP = 由你控制其形态的能力／工具；A2A = 你委托其完成目标、且无法了解其内部的自主对等方。运行时长是第二个问题，它针对的是 Tasks 能力，而非协议。 你负责的长时间运行固定作业——例如十分钟的导出、批量转换——应使用带 Tasks 扩展的 MCP（一个持久句柄：轮询、执行期间提供输入、之后检索；参见 references/mcp.md），而不是 A2A。因此，应根据路由集合做决定，绝不能根据“长时间运行”一词做决定：

• 长时间运行的固定导出 → MCP Tasks，前提是客户端／SDK 协商启用了该扩展；
• 自主委托的谈判 → A2A（你委托的是目标，而非步骤）；
• 到达的客户端／SDK 不支持 Tasks → 明确采用备用方案（拆分作业、让调用方通过普通的 tools/call 轮询作业 ID，或使用 webhook）——因为 Tasks 不可用就改用 A2A，是在用选择协议来绕过缺失的扩展。

在基于 Tasks 构建之前，先检查客户端实际协商启用的扩展；若 Tasks 可用，却在 tools/call 之上另行设计任务生命周期，就是在重新实现该扩展；若 Tasks 只是不受支持，却选择 A2A，则正是本次审查要纠正的路由错误。对于只需通过一次 HTTP 调用和 JSON schema 即可完成的事情，发布 Agent Card 仍属于 MCP 的方向。

---

参考资料

每个文件开头都有自己的 在何时加载 行和修订标记。此表仅作索引；触发条件位于文件中，因此两者不会脱节。

文件	何时阅读
references/mcp.md	你要构建或调用 MCP 服务时——各层、每个请求的 _meta、server/discover、三个服务端原语和唯一保留下来的客户端原语、通知、缓存、传输方式，以及完整的弃用登记表
references/mcp-ship.md	服务已编写完成，但无法访问时——在现有 Web 应用中挂载、传输层身份验证、客户端配置，以及实际上是重复路径导致的 404
references/mcp-scale.md	宿主的服务和工具数量超过上下文容量时——渐进式发现、程序化工具调用、缓存交互，以及每种方式带来的安全风险面
references/a2a.md	对方是另一个 Agent，而不是工具时——Agent 卡片和发现、任务生命周期及其终止状态、三种协议绑定、流式传输与推送
references/registry.md	你要发布服务或构建使用注册表的内容时——server.json、反向 DNS 命名空间及所有权证明方式、发布流程，以及注册表的三种拒绝情形
references/gateway.md	Agent 流量需要一个受控接口时——网关必须做到而 API 网关不必做到的事、联邦与名称冲突、授权实际应位于何处，以及委派——令牌说明哪个 Agent 代表哪个人行事，以及调用是否需要令牌（基于机器的信任：T0/T1/T2）

---

边界——本技能不涉及什么

与 make-skill 的边界。 make-skill 负责从 技能作者 的角度考虑问题：某项工作是否需要技能或服务、如何在 compatibility 中声明服务依赖，以及不同宿主上的工具名称并不相同（Claude Code 中为 mcp__<server>__<tool>，插件自带服务中为 mcp__plugin_<plugin>_<server>__<tool>）。**本技能负责协议传输层。**如果问题是“协议怎么说”，答案在这里；如果问题是“我的技能如何声明需要某项服务”，答案在 make-skill 中。协议只在两处中的一处完整说明，那就是这里。

**与 Fabric 适配器和 Observatory 技能的边界。**Agent 或服务必须加入 Fabric 环境时，具体 HOW 由它们负责：fabric-agent-adapter:creating-fabric-agents、fabric-agent-adapter:adapting-projects-to-fabric 和 fabric-agent-adapter:building-fabric-services（描述符、中心节点、fabric-service/0.1）；Agent 使用的凭据则通过 observatory-log:handling-secrets 处理（命名保险库槽位，不存放实际值）。本技能负责它们使用的协议——MCP、A2A、网关、委派——并指向相关内容，而不重复说明。

**与 agent-orchestrator 的边界。**该技能负责在 模型提供方 之间路由，并管理循环自身的上下文。本技能负责在 进程 之间路由。两者仅在一点交汇：联邦连接多个 MCP 服务的编排器受 references/mcp-scale.md 约束；通过代理为这些服务提供前端的编排器受 references/gateway.md 约束。

**与 agent-orchestrator/references/governance.md 的边界。**该文件决定是否可以跨越某个边界，以及审计记录必须包含哪些内容才能证明控制已应用。本技能说明跨越边界时如何通信。权限在前者，协议在本技能。

**完全不涵盖：**设计单个服务的工具集（有哪些工具、采用什么架构、如何描述——这是设计问题，Anthropic 的 mcp-server-dev 插件专为此而构建）；提示词措辞；脚本中的单次大模型调用。

邻近领域——逐项给出结论

命名清晰，让 Agent 不再靠猜；结论也直接说明，而非含蓄暗示。 结论截至 2026-08-13，即本技能的参考资料固定之日——这个领域变化很快，因此在据此开展工作前，请重新核实所有标记为 关注 的内容。

事项	实际情况	结论
Agent Skills（agentskills.io）	本文件正是用它所定义的开放 SKILL.md 格式编写的——最初由 Anthropic 创建，如今已成为广泛应用于各类客户端的开放标准	采用，但不是在这里。 这个系列由 make-skill 负责。它与互操作性有一种关联：MCP 有一个 Skills over MCP 扩展，因此服务端可以提供技能——参见 references/mcp.md
ACP（IBM 的 Agent Communication Protocol）	曾经是 A2A 的竞争协议	不再是可选方案。 它于 2025-08-29 在 LF AI & Data 旗下合并至 A2A；其团队也已停止开发。如果你在文档中遇到 ACP，如今的答案就是 A2A
AGNTCY（Cisco/Outshift → Linux Foundation，2025 年 7 月）	不是 A2A 的竞争对手——它是围绕多 Agent 系统构建的基础设施栈：包括 OASF 发现、Agent 身份、SLIM 消息传递和可观测性。它已归档了自己的竞争协议	彼此正交。 如果你运行许多 Agent，可评估其身份和可观测性功能；它不能取代 A2A 或 MCP
AP2（Agent Payments Protocol）	Google 面向 A2A 的支付扩展，正通过 FIDO Alliance 工作组推进标准化。它以可验证数字凭证的形式签署意图——包括 Checkout Mandates 和 Payment Mandates，各自都有 Open 和 Closed 两个阶段	关注，但暂时不要基于它构建。 它明确仍在开发中，尚未达到可用于生产的状态。它适用于这个问题——证明此用户已授权此次购买——因此，如果 Agent 未来可能会花钱，就应持续关注
“ChatGPT apps” / OpenAI 的插件接口	经核实，它不是一种独立协议：而是一个 MCP 服务，加上用于工作流的 Agent Skills，以及可选的 UI	无需学习新东西。 构建 MCP 服务；宿主打包方式由宿主决定
MCP 扩展——Tasks、MCP Apps、Skills over MCP	可选择启用的核心协议扩展，按连接协商	先阅读，再考虑自创。 长时间运行的工作已有持久句柄方案；参见 references/mcp.md

链接地图 — 去哪里阅读

这里的内容都不足以概括到可以据此进行开发。以下是相关文档。

阅读内容	用途	URL
MCP 规范（当前版本）	规范性要求；务必检查其对应的修订版本	https://modelcontextprotocol.io/specification/latest
MCP 架构	两个层、无状态性，以及包含真实 JSON 的发现交互	https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture
MCP 服务概念	工具、资源、资源模板、提示词——分别由谁控制	https://modelcontextprotocol.io/docs/2026-07-28/learn/server-concepts
MCP 客户端概念	elicitation 的两种模式与 MRTR 模式；已弃用的客户端功能	https://modelcontextprotocol.io/docs/2026-07-28/learn/client-concepts
MCP 弃用登记表	哪些内容即将淘汰及其最早移除时间的权威列表	https://modelcontextprotocol.io/specification/2026-07-28/deprecated
MCP 客户端最佳实践	渐进式发现和代码模式，以及相关数据	https://modelcontextprotocol.io/docs/2026-07-28/develop/clients/client-best-practices
构建服务 / 构建客户端	SDK 级别的分步指南	https://modelcontextprotocol.io/docs/2026-07-28/develop/build-server、…/build-client
MCP + Agent Skills	Skills 与服务如何组合，以及 mcp-server-dev 插件	https://modelcontextprotocol.io/docs/2026-07-28/develop/build-with-agent-skills
MCP 注册表 — 关于、快速入门	它是什么，以及确切的发布流程	https://modelcontextprotocol.io/registry/about、https://modelcontextprotocol.io/registry/quickstart
面向机器的 MCP 文档索引	如果你是正在探索的 Agent，请先获取此文件	https://modelcontextprotocol.io/llms.txt
A2A 首页与规范	v1.0、三种绑定、规范性内容	https://a2a-protocol.org/latest/、https://a2a-protocol.org/latest/specification/
A2A 核心概念 / 任务生命周期 / 发现	对象模型、生命周期、众所周知的 URI	https://a2a-protocol.org/latest/topics/key-concepts/、…/life-of-a-task/、…/agent-discovery/
A2A 与 MCP	关于二者如何分工的官方说明	https://a2a-protocol.org/latest/topics/a2a-and-mcp/
agentgateway — 独立部署、Kubernetes	配置模型，以及 Gateway API 相关内容	https://agentgateway.dev/docs/standalone/latest/、https://agentgateway.dev/docs/kubernetes/latest/
源代码仓库	文档落后于代码时查看	https://github.com/a2aproject/A2A、https://github.com/modelcontextprotocol/modelcontextprotocol、https://github.com/modelcontextprotocol/registry、https://github.com/agentgateway/agentgateway

如果你是 Agent，请先获取 llms.txt。 modelcontextprotocol.io 和 agentgateway.dev 都发布了该文件，并且都会随文档发布版本进行版本管理——这样你就能找到实际存在的页面，而不是你记忆中的页面。

---

检查清单 — 发布任何使用这些协议的内容

• 将开发所依据的修订版本记录下来——写在 compatibility、常量或 README 行中
• 使用客户端功能前，先阅读弃用登记表
• 为版本不匹配的情况提供处理路径，而不是直接崩溃
• 将工具输出视为不可信输入，包括来自自有服务的输出
• 不要通过 elicitation 表单请求任何秘密信息——这应由 URL 模式处理
• 长时间运行的工作应使用持久句柄，而不是保持连接不释放
• 如果进行联邦：应有意解决名称冲突，而不是依赖加载顺序
• 如果发布：使用你能证明拥有所有权的命名空间
• 每一跳都要执行授权，而不只是入口处