MCP与A2A统一到Linux Foundation——AI Agent互操作标准化的里程碑

MCP与A2A统一到Linux Foundation——AI Agent互操作标准化的里程碑

一句话总结：2026年8月17日，Google的Agent2Agent（A2A）协议正式加入Linux Foundation旗下的Agentic AI Foundation（AAIF），与Anthropic的Model Context Protocol（MCP）共享同一开放治理框架。250+成员机构、三大云巨头、所有主要AI模型厂商，在同一个屋檐下制定Agent互操作标准。这不是又一个"标准宣言"——这是智能体互联网的TCP/IP时刻。

一、引言：为什么两条协议需要统一治理？

如果你在2025年问一个AI架构师：“MCP和A2A是什么关系？“你大概率会得到一段绕口令式的回答——“MCP是Agent连工具的，A2A是Agent连Agent的，它们不打架，但我不确定该先押注哪个。”

这种不确定性背后有一个真实的企业风险：协议被单一供应商战略绑架。

MCP起源于Anthropic，A2A起源于Google。虽然两者从技术层面天然互补——MCP做垂直集成（Agent到工具），A2A做水平协作（Agent到Agent）——但在治理层面，任何企业投入大量资源适配一个由竞争对手控制的协议，都需要承担一个隐形成本：“如果明天Anthropic或Google改变方向怎么办？“在AI行业，这一点不是空穴来风。2024到2025年间，我们见过太多冠以"开放标准"之名的项目，在供应商战略转向后被降级、废弃或闭源。企业架构师对此心知肚明：没有中立治理的标准，本质上只是供应商API的另一个名字。

更深层的问题在于，一个分裂的标准层会拖慢整个行业的进展。当企业需要在两个协议之间做"赌注式选择"时，它们往往会选择观望——等待一个明确的赢家出现。这种观望让多Agent系统停留在实验阶段，无法进入生产。而2024到2025年，我们恰恰处于Agent从演示走向生产的关键窗口期：每个季度都有新的Agent框架发布，每个SaaS都在塞入自己的Agent，但互操作性几乎为零。我们造了一堆"聪明孤岛”——CRM有一个Agent，邮箱有一个，日历有一个，IDE里还蹲着一个，但它们互不说话。

2026年8月17日，这个风险被正式消除。 当A2A加入AAIF，与MCP、AGENTS.md、goose、agentgateway并列于Linux Foundation的治理框架下，整个Agent生态迎来了一次根本性的制度变化。不是技术变化——是信任结构的变化。从这一刻起，企业不再需要猜测"哪个协议会赢”，因为两者已经并肩站在了同一个中立的屋檐下。

二、AAIF成立背景：从40到250+的爆发式增长

2.1 起源：2025年12月9日

2025年12月9日，Linux Foundation宣布成立Agentic AI Foundation（AAIF），初始贡献包括三个核心项目（来源：Linux Foundation官方新闻稿，2025年12月9日）：

初始白金会员包括AWS、Anthropic、Block、Bloomberg、Cloudflare、Google、Microsoft和OpenAI——这几乎是AI行业所有重要玩家的名单。黄金会员包括Cisco、Datadog、IBM、Oracle、Salesforce、SAP、Shopify、Snowflake等18家企业，白银会员则覆盖Hugging Face、Uber、Zapier等24家创新力量。

2.2 爆发式增长

到2026年8月，AAIF的成员从成立时的不到40个增长到250+（来源：AAIF官网新闻，2026年5月/8月）。这是一个惊人的速度——相当于平均每个月新增20+成员。增长动力来自：

• 企业刚需：任何正在构建多Agent系统的企业，都需要一个"不会因为供应商争斗而作废"的标准
• 合规压力：2026年8月EU AI Act高风险系统要求正式生效，AAIF的中立治理和文档化工作组提供了审计友好的框架
• 实际部署验证：MCP和A2A都在加入AAIF前已有生产级使用，而非"先找标准再找用例”

2.3 治理结构

AAIF采用Linux Foundation成熟的"Directed Fund"模式，核心设计原则是无单一供应商控制：

• Governing Board（理事会）：由AWS的David Nalley担任主席，负责战略、预算和会员政策
• Technical Committee（技术委员会）：8位白金会员各派一名代表，负责项目审批和技术评审
• 7个工作组：覆盖身份认证、安全、可观测性、商业、工作流、准确性和法规对齐

关键设计：理事会负责"钱和方向”，技术委员会负责"代码和标准"，单个项目（如MCP）保留技术方向上的完全自治权。

三、MCP深度解析：Agent-to-Tool标准

3.1 什么是MCP？

MCP（Model Context Protocol）是Anthropic于2024年11月发布的开源协议，其核心目标是解决AI模型与外部工具、数据源、应用程序之间的"n×m集成问题"——即每个AI客户端需要为每个工具编写独立适配器。

一句话比喻：MCP给Agent一双手，让它能操作工具。

MCP被广泛称为"AI的USB-C接口"——一个统一的连接器，让任何AI模型能与任何工具通信。

3.2 生态数据

截至2026年中，MCP的生态数据令人瞩目（来源：Anthropic官方博客，2025年12月9日）：

• 10,000+ 已发布的MCP服务器
• 97M+ 月均SDK下载量（Python + TypeScript）
• 37,000+ GitHub Stars
• 被ChatGPT、Claude、Cursor、Gemini、Microsoft Copilot、VS Code等主流平台全量采用
• AWS、Google Cloud、Azure、Cloudflare等提供企业级MCP基础设施

3.3 MCP 2026-07-28版本重大更新

2026年7月28日，MCP发布了重大架构升级——从有状态（session-based）转向无状态设计（stateless）。这一变更由AAIF技术委员会批准，标志着MCP从"开发者工具"进化为"生产级基础设施协议"（来源：MCP官方Spec Release，2026年7月）。

核心变化包括：

• 异步操作：支持长任务的非阻塞执行
• 无状态设计：去掉了session层，每个请求自包含所有上下文
• Server Identity：服务器身份认证，支持加密验证
• 官方Extensions机制：允许社区扩展协议功能，无需修改核心规范

3.4 MCP代码实现：Go语言示例

下面是一个完整的MCP客户端实现，演示如何连接MCP服务器、调用工具：

package main

import (
    "context"
    "fmt"
    "log"
    "os"
    "github.com/mark3labs/mcp-go/client"
    "github.com/mark3labs/mcp-go/mcp"
)

func main() {
    // 创建MCP客户端，连接到stdio服务器
    c, err := client.NewStdioMCPClient(
        "python3", 
        []string{}, 
        []string{"-m", "mcp_server_fetch"},
    )
    if err != nil {
        log.Fatalf("Failed to create MCP client: %v", err)
    }
    defer c.Close()

    // 初始化连接
    initRequest := mcp.InitializeRequest{}
    initRequest.Params.ProtocolVersion = mcp.LatestProtocolVersion
    initRequest.Params.ClientInfo = mcp.Implementation{
        Name:    "mcp-blog-demo",
        Version: "1.0.0",
    }
    
    initResult, err := c.Initialize(context.Background(), initRequest)
    if err != nil {
        log.Fatalf("Initialize failed: %v", err)
    }
    fmt.Printf("Connected to server: %s v%s\n",
        initResult.ServerInfo.Name,
        initResult.ServerInfo.Version)

    // 列出可用工具
    toolsRequest := mcp.ListToolsRequest{}
    toolsResult, err := c.ListTools(context.Background(), toolsRequest)
    if err != nil {
        log.Fatalf("ListTools failed: %v", err)
    }

    fmt.Println("Available tools:")
    for _, tool := range toolsResult.Tools {
        fmt.Printf("  - %s: %s\n", tool.Name, tool.Description)
    }

    // 调用工具：获取网页内容
    callRequest := mcp.CallToolRequest{}
    callRequest.Params.Name = "fetch"
    callRequest.Params.Arguments = map[string]interface{}{
        "url": "https://aaif.io",
    }

    result, err := c.CallTool(context.Background(), callRequest)
    if err != nil {
        log.Fatalf("CallTool failed: %v", err)
    }

    // 处理返回结果
    for _, content := range result.Content {
        switch v := content.(type) {
        case mcp.TextContent:
            fmt.Printf("Response (%d chars):\n%s\n", 
                len(v.Text), 
                v.Text[:min(200, len(v.Text))])
        }
    }
}

func min(a, b int) int {
    if a < b {
        return a
    }
    return b
}

3.5 MCP架构示意

┌──────────────────────────────────────────────────┐
│                   AI Client                       │
│  (Claude / ChatGPT / Gemini / Copilot / Cursor)   │
└──────────────────────┬───────────────────────────┘
                       │
              MCP Protocol (JSON-RPC)
                       │
                       ▼
┌──────────────────────────────────────────────────┐
│              MCP Server (Agent Runtime)           │
│                                                   │
│  ┌─────────────┐  ┌─────────────┐  ┌───────────┐ │
│  │  Tool 1     │  │  Tool 2     │  │  Tool N   │ │
│  │ (Database)  │  │ (API)       │  │ (File)    │ │
│  └─────────────┘  └─────────────┘  └───────────┘ │
│                                                   │
│  ┌──────────────────────────────────────────────┐ │
│  │  Resource:  file://, database://, api://     │ │
│  └──────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘

四、A2A深度解析：Agent-to-Agent标准

4.1 什么是A2A？

A2A（Agent2Agent Protocol）是Google于2025年4月9日在Google Cloud Next上发布的开放协议，旨在解决"不同框架、不同供应商、不同组织构建的Agent之间如何互相通信"的问题。

一句话比喻：A2A给Agent一群同事，让它们能互相派活。

4.2 核心设计

A2A的设计刻意保持"极小的表面积"，只定义三个核心原语（来源：A2A官方Spec，aaif.io）：

1. Agent Card（Agent名片）

每个Agent在 /.well-known/agent-card.json 发布一个标准化的JSON文件，相当于Agent的"领英主页"：

{
  "schemaVersion": "v1.0",
  "metadata": {
    "displayName": "Reservation Agent",
    "description": "Handles restaurant table reservations",
    "owner": "restaurant.example.com"
  },
  "skills": [
    {
      "id": "create_reservation",
      "name": "Create Reservation",
      "description": "Book a table at a restaurant",
      "input": {
        "type": "object",
        "properties": {
          "restaurant_id": {"type": "string"},
          "date": {"type": "string", "format": "date-time"},
          "party_size": {"type": "integer"},
          "special_requests": {"type": "string"}
        }
      },
      "output": {
        "type": "object",
        "properties": {
          "reservation_id": {"type": "string"},
          "confirmation": {"type": "string"},
          "status": {"type": "string"}
        }
      }
    }
  ],
  "authentication": {
    "schemes": ["oauth2", "mtls"]
  }
}

2. Task（任务）

工作基本单元，拥有完整的生命周期状态机：

submitted → working → input-required → completed / failed / canceled

3. Artifact（产物）

Task完成后交付的内容（报告、代码、图片等），通过SSE流式回传。

4.3 A2A v1.0关键特性

2026年3月12日冻结的A2A v1.0带来了四个企业级能力（来源：A2A v1.0公告，Google Dev Discussion，2026年7月）：

4.4 A2A代码实现：Python双端示例

A2A Server端（接收任务的Agent）：

from a2a import A2AServer, AgentCard, Skill, Task, Artifact
from a2a.helpers import new_text_message, new_task, new_text_artifact
import asyncio
from datetime import datetime

# 定义Agent技能
class ReservationSkill(Skill):
    """餐厅预订技能"""
    
    async def execute(self, task: Task) -> Artifact:
        params = task.message.parts[0].data
        restaurant_id = params.get("restaurant_id")
        date = params.get("date")
        party_size = params.get("party_size", 2)
        
        # 模拟预订逻辑
        await asyncio.sleep(1)
        reservation_id = f"RES-{datetime.now().strftime('%Y%m%d%H%M%S')}"
        
        return new_text_artifact(
            f"Reservation confirmed!\n"
            f"ID: {reservation_id}\n"
            f"Restaurant: {restaurant_id}\n"
            f"Date: {date}\n"
            f"Party Size: {party_size}\n"
            f"Status: confirmed"
        )

# 创建Agent Card
agent_card = AgentCard(
    display_name="Restaurant Reservation Agent",
    description="Book tables at partner restaurants",
    skills=[ReservationSkill()],
    authentication={"schemes": ["oauth2"]}
)

# 启动A2A Server
server = A2AServer(
    card=agent_card,
    host="0.0.0.0",
    port=8080,
    skills=[ReservationSkill()]
)

if __name__ == "__main__":
    print("A2A Reservation Agent running on http://0.0.0.0:8080")
    server.run()

A2A Client端（发起任务的Agent）：

from a2a import A2AClient
from a2a.helpers import new_text_message, new_task
import asyncio

async def main():
    # 发现远程Agent
    client = A2AClient()
    
    # 获取Agent Card（Agent名片）
    card = await client.fetch_agent_card(
        "https://reservation.example.com/.well-known/agent-card.json"
    )
    print(f"Discovered agent: {card.display_name}")
    print(f"Available skills: {[s.name for s in card.skills]}")
    
    # 创建并发送任务
    message = new_text_message(
        "Book a table",
        data={
            "restaurant_id": "rest_001",
            "date": "2026-09-15T19:00:00+08:00",
            "party_size": 4
        }
    )
    
    task = new_task(message=message)
    result = await client.send_task(
        endpoint="https://reservation.example.com/a2a",
        task=task
    )
    
    # 处理流式结果
    async for event in result.stream():
        if event.artifact:
            print(f"Artifact received: {event.artifact.text}")
        if event.status:
            print(f"Status: {event.status.state}")
    
    print(f"Task completed: {result.artifact.text}")

asyncio.run(main())

4.5 A2A架构示意

┌─────────────────┐        ┌─────────────────┐
│   Agent A       │        │   Agent B       │
│  (Planner)      │        │  (Specialist)   │
│                 │        │                 │
│  ┌───────────┐  │        │  ┌───────────┐  │
│  │Agent Card │  │        │  │Agent Card │  │
│  │Discovery  │──┼────────┼─>│Published  │  │
│  └───────────┘  │        │  └───────────┘  │
│                 │  A2A    │                 │
│  ┌───────────┐  │ Protocol│  ┌───────────┐  │
│  │Task Send  │──┼────────┼─>│Task Recv  │  │
│  └───────────┘  │  JSON   │  └───────────┘  │
│                 │  -RPC   │                 │
│  ┌───────────┐  │  over   │  ┌───────────┐  │
│  │Artifact   │<─┼────────┼──│Artifact   │  │
│  │Receive    │  │  HTTPS  │  │Produce    │  │
│  └───────────┘  │        │  └───────────┘  │
└─────────────────┘        └─────────────────┘

五、两者的互补关系：MCP管"工具连接"，A2A管"Agent对话"

5.1 核心区别

5.2 真实协作场景

一个完整的"智能旅行规划"场景展示了MCP和A2A如何协同工作。这个场景并不复杂，但它揭示了协议组合后的真实价值——不再需要人工在Agent之间传话，Agent自己就能完成完整的端到端业务流程：

用户请求: "帮我规划一次去东京的旅行，预算5000元，住3晚"

                         ┌──────────────────────┐
                         │    Plan Agent         │
                         │  (Orchestrator)       │
                         │                       │
                         │  A2A: 分解任务并派发  │
                         └──┬───────┬───────┬───┘
                            │       │       │
                    A2A     │ A2A   │ A2A   │ A2A
                            │       │       │
              ┌─────────────┘       │       └─────────────┐
              ▼                     ▼                     ▼
    ┌──────────────────┐  ┌──────────────────┐  ┌──────────────────┐
    │  Flight Agent    │  │  Hotel Agent     │  │  Itinerary Agent │
    │                  │  │                  │  │                  │
    │  MCP: 连航司API  │  │  MCP: 连酒店DB  │  │  MCP: 连地图API │
    │  MCP: 连支付工具 │  │  MCP: 连地图服务 │  │  MCP: 连推荐引擎 │
    └──────────────────┘  └──────────────────┘  └──────────────────┘

流程分解：

1. Plan Agent 收到用户请求，通过A2A将"订机票"任务委派给 Flight Agent
2. Flight Agent 使用MCP连接航司API查询航班，使用MCP连接支付工具处理付款
3. Plan Agent 通过A2A将"订酒店"任务委派给 Hotel Agent
4. Hotel Agent 使用MCP查询酒店数据库和地图服务
5. Hotel Agent 通过A2A将结果（Artifact）返回给 Plan Agent
6. Plan Agent 汇总所有结果，生成最终行程

抽掉MCP，Agent没手；抽掉A2A，Agent是孤魂野鬼。

5.3 完整协议栈架构

AAIF下完整的Agent协议栈分为五层（来源：AAIF官方博客，A2A Joins AAIF’s Open Agentic Stack，2026年8月17日）：

┌─────────────────────────────────────────────────┐
│  AGENTS.md (OpenAI)                             │
│  指令与上下文层：告诉Agent如何行为               │
│  已获60,000+开源项目采用                        │
├─────────────────────────────────────────────────┤
│  goose (Block)                                  │
│  Agent运行时层：推理、规划、调用能力              │
│  本地优先、开源、MCP原生集成                    │
├─────────────────────────────────────────────────┤
│  MCP (Anthropic)                                │
│  Agent-to-Tool层：连接工具、数据、应用           │
│  10,000+服务器，97M+月下载                      │
├─────────────────────────────────────────────────┤
│  agentgateway                                   │
│  流量中介与控制层：路由、策略、可观测性          │
│  Agent系统与基础设施之间的边界                  │
├─────────────────────────────────────────────────┤
│  A2A (Google)                                   │
│  Agent-to-Agent层：跨组织/框架的Agent互操作      │
│  150+支持组织，三大云原生集成                   │
└─────────────────────────────────────────────────┘

六、统一治理的意义：从"供应商特性"到"行业基础设施"

6.1 消除单点风险

在A2A加入AAIF之前，企业面临一个尴尬的抉择：

• 选择MCP → 依赖Anthropic的路线图
• 选择A2A → 依赖Google的路线图
• 两个都选 → 维护两套供应商依赖

统一治理后，这个三角困境被打破。 当协议由250+成员通过开放治理机制共同维护时，任何单一供应商都无法单方面改变协议方向。正如AAIF CTO Manik Surtani所说：“A2A加入AAIF，意味着整个协议栈——从上下文到通信到操作——都在同一个地方以同样的方式治理”（来源：AAIF官方博客，2026年8月17日）。

6.2 Linux Foundation的治理信誉

Linux Foundation不是新手。它已经成功托管了：

• Linux Kernel：全球最重要的开源项目
• Kubernetes：容器编排的事实标准
• Node.js：最流行的JavaScript运行时
• PyTorch：AI研究的主流框架
• OpenTelemetry：可观测性标准
• GraphQL：API查询语言标准

这个治理模型的核心优势在于：项目可以被fork、协议可以被信任、路线图不由单一公司决定。

6.3 对企业的实际意义

七、企业落地指南：如何评估供应商的MCP/A2A支持

7.1 评估框架

对于正在构建多Agent系统的企业，以下是评估供应商MCP/A2A支持的实用框架：

第一层：基础支持（必备）

供应商是否提供MCP Server实现？
├── 是 → 继续评估
└── 否 → 需要要求供应商提供MCP适配层

供应商是否支持A2A Agent Card发布？
├── 是 → 继续评估
└── 否 → 需要手动编写A2A适配器

第二层：生产级能力（建议）

MCP支持级别：
├── Level 1: 仅客户端（消费MCP工具）
├── Level 2: 客户端+服务器（提供与消费）
├── Level 3: Level 2 + 官方SDK + 企业级部署指南
└── Level 4: Level 3 + AAIF治理参与

A2A支持级别：
├── Level 1: 发表兼容声明（Logo on page）
├── Level 2: 提供Agent Card端点
├── Level 3: Level 2 + 跨供应商A2A互操作已验证
└── Level 4: Level 3 + 生产级部署 + AAIF TSC参与

第三层：高级场景（差异化）

• 是否支持跨云A2A互操作？（AWS Bedrock ↔ Google Cloud ↔ Azure）
• 是否支持A2A链的可观测性？（分布式追踪跨Agent边界）
• 是否提供MCP Server的SLA和安全性审计？
• 是否参与AAIF的工作组并影响标准方向？

7.2 主流平台支持现状

八、质疑与挑战：ARD的前车之鉴

8.1 ARD的教训

任何关于"Agent标准"的讨论都绕不开ARD（Agentic Resource Discovery）的前车之鉴。ARD在2024年也曾获得大量关注和行业背书，但最终实际采用几乎为零。

为什么ARD失败了？

1. 没有实际生产使用：ARD先发布了标准，然后"寻找用例"——这在标准领域是致命的
2. 缺乏生态支撑：没有主要AI平台或模型原生集成
3. 单一供应商主导：没有类似Linux Foundation的中立治理
4. 解决的是"伪问题"：Agent资源发现本身不是企业最痛的瓶颈

8.2 MCP和A2A为什么不同？

MCP和A2A在加入AAIF前已经有大规模实际生产使用：

• MCP：10,000+服务器、97M+月下载、被所有主流AI平台采用——这不是"寻找用例的标准"
• A2A：华为HarmonyOS全量采用、三大云原生集成、150+支持组织——这也不是

两者的区别在于：它们是先有生态，后有治理；而不是先有治理，再找生态。

8.3 仍然存在的挑战

尽管进展显著，MCP和A2A的统一治理仍面临真实挑战。这些挑战不是理论上的，而是来自社区和实践者的真实反馈：

1. A2A链的安全风险

一个被广泛讨论的问题是A2A链中的"级联幻觉"风险（来源：ByteIota，2026年8月23日）：

Agent A (源) → Agent B (中继) → Agent C (目标)

问题：Agent B将Agent A的输出视为"可信输入"而非"待验证声明"
小型幻觉在每一步被放大，到末端时变成"自信的垃圾"

AAIF安全工作组的跨Agent信任链标准预计在2026年Q3-Q4完成RFC，但在那之前，生产环境中应把每个上游Agent的输出视为未验证输入。

2. A2A的实际采用率难以量化

MCP有明确的采用指标（10,000+服务器、97M+下载），而A2A的"150+支持组织"涵盖了从"放Logo在官网"到"生产级运行"的各种层次。A2A的实际生产部署规模仍然远小于MCP（来源：Devlery，2026年8月19日分析）。

3. 开发者学习成本

采用A2A意味着维护两个协议（MCP + A2A）以及它们之间的兼容性层。对于中小团队，这增加了架构复杂度。社区中反复出现的抱怨是：“我们需要一个协议，而不是两个。”

4. 技术委员会的实际控制权

截至2026年8月，A2A仓库中的GOVERNANCE.md仍然描述了一个8席TSC（AWS、Cisco、Google、IBM、Microsoft、Salesforce、SAP、ServiceNow各一席），文件中并未提及AAIF（来源：A2A GitHub仓库，2026年8月）。改变基金会名称和改变谁编辑规范是两回事。 真正的治理整合需要时间。

九、开放标准与商业竞争：标准层握手，应用层竞争

9.1 一个关键的理解

AAIF的成立和A2A的加入，并不意味着AI巨头们突然"和解"了。它们只是在协议层达成共识，在应用层仍然激烈竞争。

这就像互联网的早期：所有公司都同意使用TCP/IP和HTTP，但它们在浏览器、搜索引擎、电商平台上打得头破血流。

9.2 竞争格局

标准层（合作）：

• MCP和A2A在AAIF下统一治理
• Anthropic、Google、OpenAI、Microsoft、AWS共享技术委员会
• IBM主动合并ACP到A2A，承认"一个标准比多个好"

应用层（竞争）：

• 每个模型厂商都在构建自己的Agent平台
• Claude vs ChatGPT vs Gemini vs Copilot的竞争仍在白热化
• 云厂商在Agent编排、部署、可观测性上差异化

9.3 这对企业意味着什么

企业可以：

1. 在标准层做"无差别投资"：MCP和A2A是中立基础设施，可以放心投入
2. 在应用层保持"策略性选择"：根据场景选择最适合的Agent平台
3. 降低供应商锁定风险：底层协议不被任何单一供应商控制

十、结论：Agent互操作标准化的未来展望

10.1 我们已经走了多远

从2024年11月MCP发布，到2025年4月A2A发布，到2025年12月AAIF成立，再到2026年8月A2A加入AAIF——这条路径清晰且快速：

2024.11  MCP发布 (Anthropic)
   ↓
2025.04  A2A发布 (Google)
   ↓
2025.06  A2A捐赠给Linux Foundation
   ↓
2025.08  IBM ACP合并到A2A
   ↓
2025.12  AAIF成立，MCP/goose/AGENTS.md加入
   ↓
2026.03  A2A v1.0稳定版冻结
   ↓
2026.08  A2A正式加入AAIF，与MCP并列

10.2 未来趋势

1. Agent互联网正在形成

就像HTTP和TCP/IP让Web成为可能，MCP和A2A正在构建"Agent互联网"的基础设施。未来，Agent之间发现、通信、协作将像Web浏览器访问网站一样自然。A2A的Agent Card本质上就是Agent世界的DNS——每个Agent通过标准URL发布自己的"名片"，其他Agent通过发现机制找到它。这种去中心化的发现模型意味着不需要一个中央注册表，任何Agent都可以加入这个网络。

2. 从"全栈Agent"到"分层Agent栈"

企业在Agent上的投资将从"构建全能Agent"转向"构建分层的Agent生态系统"——一个规划层、多个专业Agent层、统一的工具连接层。这类似于微服务架构取代单体应用的演进路径：全能Agent是单体应用，分层Agent栈是微服务架构。MCP和A2A的组合，为这个分层架构提供了标准化的"接线"方式。

3. 安全与信任成为核心议题

随着A2A链在产业中普及，跨Agent的身份验证、信任链、审计追踪将成为新的基础设施需求。AAIF的安全工作组和跨Agent信任链标准将是关键。目前，每个A2A交互中的"信任传递"缺乏标准机制——Agent A信任Agent B，Agent B信任Agent C，但Agent A如何验证Agent C的输出？这不仅是技术问题，也是治理问题。AAIF预计在2026年Q3-Q4完成跨Agent信任链标准的RFC，这将是2026年下半年最重要的Agent基础设施进展之一。

4. 标准竞争从"协议vs协议"转向"实现vs实现"

协议层统一后，竞争将转向：

• 谁提供更好的Agent运行时？（goose vs 其他实现）
• 谁提供更丰富的MCP Server生态？
• 谁提供更易用的A2A编排工具？
• 谁的平台在成本、延迟、可靠性上更优？

10.3 一个更广阔的视角

回看整个事件，我们可以发现一个有趣的规律：互联网基础设施的标准化总是遵循类似的路径。先是创新者推出专有方案，然后是行业认识到需要互操作，接着是竞争者在中立治理下达成共识，最后是生态爆发。

Linux本身走过了这条路。Kubernetes也走过了这条路。现在，AI Agent的互操作标准正在走这条路。MCP和A2A在AAIF下的统一，不是终点——它只是起点。真正的考验在于：这些标准能否在未来的生产环境中证明自己，能否像HTTP和TCP/IP那样成为"看不见的但不可或缺的"基础设施层。

从目前的数据来看，答案是乐观的。MCP已经有10,000+服务器和97M+月下载，这不是"纸上标准"。A2A有150+支持组织和三大云的生产级部署，这也不是"纸上标准"。它们都有实际生态，现在又有了共同的中立治理。

10.4 给开发者的建议

1. 同时学习MCP和A2A：它们不是竞争对手，而是你工具箱里的两个不同工具。MCP让你的Agent能操作世界，A2A让你的Agent能协作。在实际生产中，绝大多数多Agent系统需要同时使用两者。建议先从MCP入手（生态更成熟、学习曲线更平缓），再逐步引入A2A。
2. 将你的Agent设计为既是MCP客户端又是A2A服务器：既能消费工具，也能被其他Agent发现和调用。这种"双重身份"的设计模式将成为未来Agent架构的默认姿势。
3. 关注AAIF的标准进展：特别是安全工作组和跨Agent信任链标准。AAIF的7个工作组（身份、安全、可观测性、商业、工作流、准确性、法规对齐）是公开的，任何成员都可以参与。即使你不参与标准制定，跟踪这些工作组的最新输出也能帮助你提前规划技术路线。
4. 在生产环境中建立A2A链的验证机制：在AAIF的安全标准落地前，不信任上游Agent的输出。每个A2A链节点都应该对上游结果进行独立验证，而不是简单地"接力"传递。这可能会增加一些延迟，但在信任链标准成熟之前，这是必要的安全措施。
5. 参与社区：AAIF的工作组对所有成员开放，参与标准制定比被动接受更有优势。此外，MCP和A2A的GitHub仓库和Discord社区非常活跃，是获取一手信息的最佳渠道。

参考资料

1. [Linux Foundation Announces Formation of AAIF] (https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation) — 2025年12月9日
2. [A2A Joins AAIF’s Open Agentic Stack] (https://aaif.io/blog/a2a-joins-aaif) — 2026年8月17日
3. [Anthropic: Donating MCP to AAIF] (https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) — 2025年12月9日
4. [AAIF 2026 Events Program] (https://www.linuxfoundation.org/press/agentic-ai-foundation-announces-global-2026-events-program-anchored-by-agntcon-mcpcon-north-america-and-europe) — 2026年4月2日
5. [A2A Protocol Joins AAIF: What MCP Devs Need to Know] (https://byteiota.com/a2a-protocol-joins-aaif-what-mcp-devs-need-to-know/) — 2026年8月23日
6. [A2A Joins the Foundation That Hosts MCP, but Real Usage Has Not Moved] (https://devlery.com/en/blog/a2a-joins-aaif-mcp-governance) — 2026年8月19日
7. [A2A 1.0 Joins AAIF: The Internet of Agents] (https://dailyaiworld.com/blogs/a2a-10-joins-agentic-ai-foundation-internet-agents) — 2026年8月18日
8. [What’s New in A2A v1.0] (https://discuss.google.dev/t/what-s-new-in-a2a-v1-0-a-python-dx-glow-up-and-a-fresh-new-look/381896) — 2026年7月16日
9. [A2A Project Proposal to AAIF] (https://github.com/aaif/project-proposals/issues/37) — 2026年6月18日
10. [MCP 给了AI手，A2A给了AI同事] (https://blog.csdn.net/weixin_52326703/article/details/163326436) — CSDN博客，2026年8月30日
11. [A2A Protocol Wiki] (https://aiwiki.ai/wiki/a2a_protocol) — 2026年6月24日
12. [Google’s A2A Protocol Joins AAIF] (https://theroboticsmedia.com/article/google-a2a-protocol-agentic-ai-foundation-linux-foundation-mcp-anthropic-august-20-2026) — 2026年8月30日

• ←上一页
• 下一页→