从MCP到A2A再到Proxy：Agent-工具协议的三种代理模式

从MCP到A2A再到Proxy：Agent-工具协议的三种代理模式

当AI Agent从单机推理走向分布式协作，协议层正在经历一场静默的架构革命。MCP负责向下连接工具，A2A负责横向连接Agent，而Proxy模式正在成为连接这两种协议栈的工程桥梁。本文基于IETF最新互联网草案和主流框架实践，系统拆解Agent-工具协议的三种代理模式及其选型逻辑。

引言：当Agent需要"手"也需要"同事"

2025年初，两个协议几乎同时闯入AI工程化视野。Anthropic发布了MCP（Model Context Protocol），Google联合50多家合作伙伴发布了A2A（Agent-to-Agent Protocol）。外界一度将它们视为竞争对手，但深入理解后会发现：它们解决的是不同层面的问题。

一个简单的区分方式是：MCP让Agent拥有"手"------能够调用工具、访问数据、操作外部系统；A2A让Agent拥有"同事"------能够与其他Agent协作、委派任务、共享工作成果。两者不是替代关系，而是同一协议栈的不同层级。

但随着Agent系统从实验室走向生产环境，一个新的工程问题浮现了：如何让MCP和A2A在同一套基础设施中共存、互操作？ 答案指向了第三种形态------Proxy（代理）模式。

一、MCP：代理到工具的垂直集成

1.1 设计目标与核心抽象

MCP的全称是Model Context Protocol，由Anthropic于2024年底推出。它的核心目标是标准化AI模型与外部工具、数据源和系统的连接方式。

在MCP之前，每个工具接入都需要单独开发适配代码------数据库一套写法、API一套写法、文件系统又是一套。MCP通过统一的客户端-服务器架构，将"M×N"的集成问题转化为"M+N"。

核心抽象：

• Tools：Agent可调用的函数，带名称、描述和JSON Schema参数
• Resources：Agent可读取的结构化数据
• Prompts：可复用的提示词模板

MCP采用JSON-RPC 2.0作为通信协议，支持stdio（本地进程通信）和HTTP+SSE（远程通信）两种传输方式。

1.2 MCP的代理模式：客户端-服务器

在MCP架构中，代理模式表现为一个Agent（MCP客户端）向一个或多个MCP服务器发起工具调用请求 。Agent通过tools/list发现可用工具，通过tools/call执行工具调用。

# MCP客户端调用工具的模式
# 来源：基于Microsoft Agent Framework MCP实现

import asyncio
from mcp import ClientSession, StdioServerParameters

async def call_mcp_tool():
    # 1. 建立MCP会话
    server_params = StdioServerParameters(
        command="python",
        args=["-m", "my_mcp_server"]
    )
    
    async with ClientSession(server_params) as session:
        # 2. 发现工具
        tools = await session.list_tools()
        print(f"可用工具: {[t.name for t in tools]}")
        
        # 3. 调用工具
        result = await session.call_tool(
            "query_database",
            arguments={"sql": "SELECT * FROM orders"}
        )
        return result.content

1.3 安全边界：工具描述的投毒风险

MCP的安全模型依赖于开发者对工具描述的控制。但实证数据揭示了严重漏洞：492个面向互联网的MCP服务器完全关闭了认证；约37%的服务器存在SSRF（服务端请求伪造）暴露风险。

更隐蔽的攻击是工具描述投毒------恶意或不当的工具描述被模型读取后，可以诱导Agent执行非预期操作。Microsoft的红队评测显示：仅靠Prompt级别的安全指令，对抗性场景下的策略违反率高达26.67%。

二、A2A：代理到代理的水平集成

2.1 设计目标与核心抽象

A2A（Agent2Agent）由Google于2025年4月发布，核心目标是让不同供应商、不同框架构建的Agent能够相互发现、通信和协作。

A2A的通信模型定义了两个角色：

• 客户端Agent：发起任务请求的Agent
• 远程Agent：接收并执行任务的Agent

核心抽象：

• Agent Card ：JSON格式的"身份名片"，描述Agent的能力、技能、端点URL和认证要求，通常托管在/.well-known/agent.json
• Task：工作单元，有完整生命周期（submitted→working→input-required→completed/failed）
• Artifact：任务完成后的产出物（文档、代码、图片等）
• Message：客户端和Agent之间的通信轮次，包含Parts（文本、文件或结构化数据）

2.2 A2A的代理模式：对等协商

A2A的代理模式是对等的、协商式的。客户端Agent通过Agent Card发现远程Agent的能力，然后组建Task对象发送给远程Agent执行。

# A2A任务委派模式
# 来源：基于阿里云开发者社区A2A实践

import httpx
import json

class A2AClient:
    def __init__(self, agent_endpoint: str):
        self.endpoint = agent_endpoint
        
    def discover_agent_card(self) -> dict:
        # 获取Agent Card
        response = httpx.get(f"{self.endpoint}/.well-known/agent.json")
        return response.json()
    
    def delegate_task(self, task_input: dict) -> dict:
        # 委派任务
        task = {
            "id": "task-001",
            "type": "工单处理",
            "input": task_input,
            "context_id": "session-123"
        }
        
        response = httpx.post(
            f"{self.endpoint}/tasks/send",
            json=task,
            headers={"Content-Type": "application/json"}
        )
        return response.json()

A2A最适合的场景是：不同团队拥有的Agent需要互相委派工作。例如：HR Agent需要向IT Agent请求开通员工账号，两个Agent属于不同部门、不同代码库。

2.3 安全边界：Agent Card的签名验证

A2A的安全基础是Agent Card。在v1.0之前，任何人都可以发布声称任意能力的卡片，可能被用于伪造身份或注入恶意内容。

核心实践：生产环境中必须验证Agent Card的签名，拒绝未签名的卡片。这是一个信任模型问题，不是可选项。

三、Proxy模式：连接MCP与A2A的工程桥梁

3.1 三种代理模式的定义

IETF最新互联网草案定义了Agent-工具协议的三种代理模式：

模式	作用	典型场景
拦截器（Interceptor）	在MCP客户端和服务器之间插入治理层	审计日志、权限校验、格式转换
网关（Gateway）	统一前端暴露多个MCP服务器，支持认证和路由	企业级MCP聚合、ID-JAG令牌交换
命名空间代理（Namespace Proxy）	将A2A Agent封装为MCP工具，或将MCP工具暴露为A2A服务	MCP-A2A协议桥接

3.2 拦截器模式：MCP Guard实现

拦截器模式是最轻量的代理形态------它不改变协议语义，只在消息路径上插入检查和转换逻辑。

# MCP Guard拦截器实现（简化版）
# 来源：permission-protocol/mcp-guard

class MCPInterceptor:
    def __init__(self, policy: dict):
        self.policy = policy  # YAML策略配置
    
    async def intercept_call_tool(self, tool_name: str, arguments: dict):
        # 1. 检查工具是否在拦截列表中
        if tool_name in self.policy.get("blocked_tools", []):
            return {"error": f"工具 {tool_name} 已被策略禁止"}
        
        # 2. 检查是否需要审批
        if tool_name in self.policy.get("approval_required", []):
            approval = await self.request_approval(tool_name, arguments)
            if not approval:
                return {"error": "操作被用户拒绝"}
        
        # 3. 放行
        return await self.forward_to_tool(tool_name, arguments)

拦截器的价值在于非侵入性------MCP Server不需要修改任何代码，治理逻辑全部在代理层完成。

3.3 网关模式：统一的认证与路由入口

网关模式是MCP企业级部署的核心形态。一个网关汇聚所有下游MCP服务器，对开发者呈现为单一MCP端点，内部路由到N个后端。

# Kong AI Gateway MCP配置
# 来源：Kong MCP Gateway文档

plugins:
  - name: mcp-gateway
    config:
      upstreams:
        - name: db-server
          url: http://db-mcp:8080/mcp
          auth:
            type: bearer
            token: ${env:DB_MCP_TOKEN}
        - name: search-server
          url: http://search-mcp:8080/mcp
          auth:
            type: oauth2
            client_id: ${env:OAUTH_CLIENT_ID}
      rate_limit:
        per_user: 100/minute
      audit_log:
        enabled: true
        endpoint: http://audit:9090/ingest

网关模式解决的核心问题是：认证标准化、审计集中化、限流统一化。企业部署多个MCP Server后，网关是唯一能统一治理这些服务的方式。

3.4 命名空间代理模式：MCP↔A2A协议桥接

最复杂的代理模式是将MCP和A2A两个协议栈打通。

MCP→A2A方向 ：将A2A Agent封装为MCP工具。Agent Framework提供了AgentMCPTool实现------从Agent派生原生MCP工具定义，使Agent调用看起来就像普通工具调用。

A2A→MCP方向：将MCP Server作为A2A Agent的工具后端。Agent通过A2A协议委派任务，执行代理内部通过MCP调用具体工具。

# Agent Framework: 将Agent封装为MCP工具
# 来源：Microsoft Agent Framework MCP托管

from agent_framework import AgentMCPTool

# 将一个Agent包装为MCP工具
agent_tool = AgentMCPTool(
    agent=my_agent,
    name="delegate_to_agent",
    argument_description="委派给远程Agent的任务描述",
    chat_option_parameters={
        "reasoning_effort": {
            "type": "string",
            "enum": ["low", "medium", "high"]
        }
    }
)

# 注册到MCP Server
server.register_tool(agent_tool)

3.5 架构决策：选哪种模式？

Microsoft Learn的架构指南提供了清晰的判断标准：

• 用MCP：一个Agent需要调用多个外部工具
• 用A2A：多个Agent需要互相委派任务
• 用拦截器：已有MCP Server，需要添加治理层
• 用网关：企业级部署，需要统一认证、审计、限流
• 用命名空间代理：需要让MCP Agent调用A2A Agent，或反之

KodeKloud的评估更直接："大多数团队应从MCP开始。一个带良好范围MCP工具的Agent就能解决大部分实际用例。只有当不同团队、不同框架或不同供应商的Agent需要互相委派工作时，才添加A2A。"

四、生产落地：选型与实施路径

4.1 两种协议的职责边界

维度	MCP	A2A
连接方向	垂直（Agent→工具）	水平（Agent→Agent）
通信模式	客户端-服务器	对等协商
核心抽象	Tool, Resource, Prompt	Agent Card, Task, Artifact
状态管理	服务器自行实现	三级状态（会话/代理/任务）
服务发现	依赖宿主配置	Agent Card标准化发现
典型场景	查询数据库、调用API	跨部门任务委派、多Agent协作

4.2 混合架构的参考实现

一个完整的生产级Agent系统可能同时使用三种代理模式：

┌─────────────────────────────────────────────────────────────┐
│                      编排器（Orchestrator）                  │
│                    协调多个A2A Agent                         │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                   A2A Agent（远程代理）                      │
│                      通过Agent Card发现                      │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                  MCP Gateway（网关模式）                     │
│           统一认证、路由、审计、限流                          │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│        MCP Server 1    │    MCP Server 2    │    拦截器     │
│        （数据库工具）    │    （API工具）      │  (权限校验)   │
└─────────────────────────────────────────────────────────────┘

五、总结

MCP和A2A不是竞争关系，而是Agent协议栈的不同层级。MCP负责"手"，A2A负责"同事"，Proxy模式负责"连接"这两层。

选型建议：

• 单个Agent需要调用工具 → MCP
• 多个Agent需要互相协作 → A2A
• 企业级MCP治理 → 网关模式
• 已有MCP需要审计/审批 → 拦截器模式
• 需要在MCP和A2A之间桥接 → 命名空间代理模式

---

参考文献：

1. A2A vs MCP：為新興代理生態系統而設的兩個互補協議，Logto部落格，2025年4月
2. 多代理模式，Microsoft Learn，2026年7月
3. 自承载代理作为MCP工具，Microsoft Agent Framework文档，2026年7月
4. A2A vs MCP, Agent Communication Protocols for DevOps，KodeKloud，2026年7月
5. 动作与工具使用模式，Microsoft Learn，2026年1月
6. Google A2A协议：MCP的替代还是配合？，安全内参，2025年4月
7. 企业多智能体协作的工程边界：MCP工具接入与A2A任务编排实践，阿里云开发者社区，2026年8月
8. MCP与A2A协议比较：人工智能系统互联与协作的技术基础架构，阿里云开发者社区，2025年4月
9. 人工智能通信协议的对比：MCP、ACP与A2A，航天云网，2025年6月