Agent Interoperability — 跨框架 Agent 互操作¶

不同厂商、不同框架构建的 AI agent 能够在无需了解对方内部实现的情况下协作完成任务的能力。这是当前 agent 生态从"孤岛"走向"网络"的核心工程挑战。

问题的结构¶

2024 年前后，agent 框架迅速增殖：LangGraph、CrewAI、Semantic Kernel、AutoGen、Google ADK、Anthropic Claude SDK……每个框架有自己的内部通信机制，但框架之间没有标准化接口。

结果： - 每次跨框架集成都需要定制开发（点对点方案） - 将 agent 包装成工具是常见妥协——但这削弱了 agent 的自主性 - 生态无法自然形成复合系统

传统 MCP/函数调用模型将外部能力暴露为工具（tool）：无状态、执行确定函数、单次请求-响应。

但 agent 有本质不同的需求： - 多轮协商：任务可能需要澄清、迭代 - 有状态执行：任务跨越多个请求持续进行 - 异步委派：client 不需要持续等待 - 能力声明：agent 需要描述自己擅长什么

将 agent 包装成工具会强行截断这些能力。

A2A 协议通过三个机制实现互操作：

Agent Card 发布于固定端点 /.well-known/agent-card，让任何 A2A-compliant client 都能在运行时发现 agent 的能力和接口，无需预先配置。

Task Lifecycle 定义了跨框架统一的工作单元表示。无论底层用什么框架实现，A2A Task 的状态机是一致的。

Agent 协作时不暴露内部状态、记忆或工具实现。协作双方只依赖： - 声明的能力（Agent Card skills） - 交换的上下文（Message + Artifact）

这保护了知识产权，也使得跨组织协作成为可能。

Orchestrator-Workers 模式描述的是单系统内的 agent 编排。A2A 将这个模式扩展到跨系统边界：orchestrator 可以是任何框架的 client agent，workers 可以是任何框架的 remote agent，中间通过 A2A 协议通信。

从 Agent OS 视角，A2A 类比于操作系统的网络栈： - 本地进程通信 ↔ 框架内 agent 调用 - TCP/IP 跨机器通信 ↔ A2A 跨框架通信 - DNS 服务发现 ↔ Agent Card 能力发现

AgenticOS Workshop（ASPLOS 2026）中 Cisco agntcy 框架明确将 A2A 作为"Internet of Agents"的通信层。

MCP 和 A2A 在 agent 技术栈中各司其职：

互操作性不只是技术问题，也是生态问题：

互操作性带来新的协调难题（超出 A2A 当前规范）：