协议演进：从Function Calling到A2A

可视化演示

动态演示协议演进的核心机制，通过架构/数据/状态/性能四种模式展示关键概念与交互流程。

本地直呼阶段：Function Calling 的动机与能力边界

回到美食家冲进后厨喊话的场景——他为什么非要进后厨？因为菜单上写着“今日推荐”，但他想知道“现在还有没有新鲜的空运三文鱼”。这就是 Function Calling 的设计动机：让大模型在需要实时数据、私有数据或执行动作时，“喊一嗓子”调用一个预设的本地函数。它是大模型从“只能聊天”进化到“能干活”的第一次跃迁。

在技术上，开发者会在系统提示词中声明工具清单（名称、描述、参数 JSON Schema），模型在推理时判断“该调哪个工具”，然后输出一个结构化的函数调用请求。框架层拦截这个请求，执行对应函数，再把结果“回填”给模型继续生成。这套“声明-识别-执行-回填”的闭环，相当于厨师听到喊话后切菜下锅，再把菜端出来。

Function Calling 的核心公式是：模型根据输入和工具描述，决定是否返回一个函数调用请求。

然而，后厨喊话终究是“私人暗号”：每个餐厅（应用）的喊法（工具声明格式）都不一样，换个餐厅就得重新学。Function Calling 的能力边界正在于此——它解决的是“能不能调”，而不是“好不好调”。开发者需要为每个工具手写声明、为每次调用处理异常，且模型偶尔会“喊错菜名”（幻觉参数）。当工具数量从几个增长到几十上百个时，维护成本指数级上升。

标准菜单：MCP 的诞生与设计哲学

后厨喊话的问题在于“没有标准菜单”。2024 年末，Anthropic 发布了 Model Context Protocol（MCP），一举把“喊话点菜”升级为“看菜单点菜”。MCP 的设计动机非常朴素：整个行业都在为“AI 接工具”这件事重复造轮子——OpenAI 有 Function Calling，谷歌有 Function Calling，各云厂商也各有各的插件规范。这种碎片化让“一次接入、处处可用”成为奢望。

MCP 的设计哲学可以概括为“菜单标准化”：它定义了 AI 应用（Host）与工具服务（Server）之间的标准交互方式，包括服务发现（看菜单）、工具调用（点菜）、上下文管理（忌口备注）等。最关键的突破是“双向连接”和“动态发现”——Agent 不需要提前知道有哪些工具，而是运行时去 Server 查询能力清单，就像客人落座后扫桌上的二维码打开菜单一样。

这套哲学隐含了一个重要取舍：用标准化的“慢”换生态化的“快”。虽然单个工具接入比本地调用多了一层协议开销，但工具方只需实现一次 MCP Server，所有支持 MCP 的 AI 应用都能自动使用。先写一次协议，之后处处复用。MCP 对应着“技术标准化是生态繁荣的前提”这条铁律——正如 USB 接口统一了设备连接，MCP 统一了 AI 与工具的连接。

MCP = 标准菜单格式 + 点菜流程 + 后厨联动规范

服务生模式：MCP 核心架构与治理

MCP 的架构像一个训练有素的餐厅服务团队。Host（如 Claude Desktop、IDE 插件）是餐厅经理，负责理解客人需求；Client 是具体跑腿的服务生，负责在 Host 和 Server 之间传话；Server 是后厨，拥有真正的厨艺（工具和数据）。三者各司其职，互不越权。

通信上，MCP 采用 JSON-RPC 2.0 作为“传话暗语”。服务生和后厨之间的每一句对话都遵循统一格式：查菜单（tools/list）、点菜（tools/call）、备注忌口（上下文管理）。其中，服务发现是 MCP 的精髓——Host 启动时会向 Server 发送能力清单请求，Server 返回所有可用工具的描述，全程动态、无需重启。

MCP 的“治理”理念体现在三个层面。会话管理上，Client 为每次对话创建独立会话，像服务生记住每桌的忌口；工具组织上，Server 可以按域分组（如数据库组、文件组），像后厨分热菜、凉菜、甜品各个档口；安全治理上，MCP 允许控制“哪些菜能点”——API key 管理、权限拦截、审计日志，确保服务生不能私自下单最贵的菜。

餐饮联盟：A2A 与 Agent 互联

如果说 MCP 统一了“AI 点菜、工具做菜”，那 A2A（Agent-to-Agent）协议则是让“餐厅之间联网”的餐饮联盟。A2A 是 Google 于 2025 年 4 月开源的开放协议，目标是解决 Agent 之间的互联互通。试想：你是一个旅行规划 Agent，需要订机票、订酒店、安排行程——如果每个环节都有一个独立的 Agent 服务（航司 Agent、酒店 Agent、攻略 Agent），你如何找到它们、如何与它们协作？A2A 给出了答案。

A2A 的核心机制是 Agent Card——每个 Agent 发布一张“电子名片”，上面写着：我的 ID（全局唯一）、我的能力（能干什么）、我的通信端点（去哪找我）、我的认证方式（怎么验明正身）。其他 Agent 可以通过注册中心（Agent Directory）发现这些名片，然后直接对等通信、任务协作。

A2A 与 MCP 不是替代关系，而是互补关系。MCP 解决“Agent 怎么用工具”，A2A 解决“Agent 怎么找 Agent”。一个 Agent 可以同时是 MCP Client（调工具）和 A2A Participant（与别的 Agent 协作），就像一家餐厅既用标准菜单服务客人，也加入美食联盟与同行互通。A2A 的终极愿景是打破“每家 AI 公司一个孤岛”的现状，让跨组织、跨平台的 Agent 协作成为常态——这是通向通用 Agent 生态的必由之路。

选型矩阵：三代协议对比与决策

面对三代协议，技术决策者最常问的问题是“我该用哪个？”答案藏在“场景”二字里。我们用一张对比矩阵厘清它们的核心差异。

| 维度 | Function Calling | MCP | A2A |

|------|-----------------|-----|-----|

| 通信拓扑 | 应用内直连 | Host-Client-Server 星型 | Agent 对等网状 |

| 标准化程度 | 各厂商私有 | 开放协议 | 开放协议 |

| 服务发现 | 静态声明 | 动态 list_tools | Agent Card 注册/发现 |

| 核心抽象 | 函数调用 | 工具服务 | Agent 能力 + 任务协作 |

| 适用规模 | 单应用、少量工具 | 中大型工具集成 | 跨 Agent/跨组织协作 |

选型决策可以概括为三条路径。路径一：单体快跑——如果你在做 PoC 或内部小工具，工具只有三五个，选 Function Calling 准没错，它最快、最直接、零额外依赖。路径二：标准集成——当你的 Agent 需要接入数据库、第三方 SaaS、内部 API，且未来可能有更多工具加入时，果断上 MCP。路径三：生态互联——当你要构建多个 Agent 协同的复杂系统，或需要与外部组织的 Agent 交互时，用 A2A 让 Agent 互相发现、对等协作。

一个重要原则是“以场景驱动选型，而非追逐热点”。MCP 再火，你只有两个工具也未必需要它；A2A 再前瞻，你只有一个 Agent 也无从谈起。决策的本质是匹配：让协议的复杂度匹配系统的复杂度，让生态的广度匹配业务的广度。

平滑升级：迁移路径与兼容策略

从 Function Calling 迁移到 MCP 再到 A2A，看起来是“推倒重来”，但聪明的架构师会优雅过渡。迁移的第一原则是兼容存量，渐进演进，别学那些为了“用新架构”而把系统重写一遍的愣头青。

具体的迁移路径分三步。第一步：存量封装——以 Function Calling 实现的工具，用一个“适配器层”包装成 MCP Server。每个已有函数用一个 @mcp.tool 装饰器暴露，函数签名自动映射为工具 Schema。这样存量代码零改动，就获得了 MCP 标准接入能力。第二步：协议融合——在 Agent 侧同时保留 MCP Client 和 A2A Participant。所有内部工具走 MCP，外部 Agent 协作走 A2A。两者通过统一的能力路由层调度——路由层先查 A2A Agent 目录，再查 MCP 工具清单，决定请求发给谁。第三步：渐进替换——随着 MCP 生态成熟，逐步将适配器层升级为原生 MCP Server，去掉中间层。

避坑指南同样重要。第一大坑是“一次性大爆炸迁移”，正确做法是先用适配器扛住业务，再逐步替换；第二大坑是“忽视协议语义差异”，MCP 的 list_tools 返回的是工具描述而非函数指针，迁移时要改的是调用方式而非业务逻辑；第三大坑是“治理机制缺失”，无论是 MCP 还是 A2A，权限和审计都要在设计期就纳入，否则协议越标准、越容易被滥用。记住：协议演进是加法，不是替换——让每一代协议都成为新一代基础设施的基石。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""演示如何用 MCP 封装一个普通函数，并通过 Client 动态发现和调用工具。""" import asyncioimport jsonfrom mcp.server.fastmcp import FastMCP # 1. 定义 MCP Server，等价于餐厅的"后厨"mcp = FastMCP("InventoryServer")  @mcp.tool()def query_stock(sku: str) -> str:    """查询某个SKU的实时库存（模拟真实库存系统）。"""    stock_map = {"A1001": 150, "B2002": 0, "C3003": 78}    stock = stock_map.get(sku, -1)    if stock < 0:        return json.dumps({"sku": sku, "error": "SKU不存在"})    if stock == 0:        return json.dumps({"sku": sku, "stock": 0, "status": "缺货"})    return json.dumps({"sku": sku, "stock": stock, "status": "有货"})  @mcp.tool()def create_order(sku: str, quantity: int) -> str:    """根据SKU和数量创建补货订单。"""    return json.dumps({"order_id": "PO2025" + sku, "sku": sku,                       "quantity": quantity, "status": "已创建"})  async def main():    # 2. 启动 MCP Server 子进程，等价于"后厨开工"    from mcp import ClientSession, StdioServerParameters    from mcp.client.stdio import stdio_client     server_params = StdioServerParameters(        command="python",        args=["-m", "mcp.server.fastmcp", "实验脚本名"]  # 实际运行时替换为当前文件名    )    async with stdio_client(server_params) as (read, write):        async with ClientSession(read, write) as session:            # 3. 动态发现工具：等价于"查看菜单"            tools = await session.list_tools()            print("菜单(工具清单):")            for t in tools.tools:                print(f"  - {t.name}: {t.description}")             # 4. 调用工具：等价于"点菜下单"            result = await session.call_tool("query_stock", {"sku": "B2002"})            print("查询缺货SKU:", result.content[0].text)            order = await session.call_tool("create_order",                                            {"sku": "B2002", "quantity": 50})            print("创建订单结果:", order.content[0].text)  if __name__ == "__main__":    asyncio.run(main())

1. from mcp.server.fastmcp import FastMCP导入 FastMCP 框架，让普通函数变成标准 MCP 服务
2. @mcp.tool()装饰器把函数暴露为 MCP 工具，参数 Schema 自动生成，等价于“写入菜单”
3. async with stdio_client(server_params) as (read, write)建立与 Server 子进程的标准输入输出通道
4. tools = await session.list_tools()动态查询 Server 的能力清单，等价于“客人扫码看菜单”
5. await session.call_tool("query_stock", {"sku": "B2002"})标准化的工具调用，不再依赖硬编码声明

常见误区

面试题