Tool Calling、 MCP、A2A一文透析 – 叶子的技术碎碎念

这两年随着大模型的能力的飞速发展，我们可以依赖大模型做很多更加复杂的任务，为了完成这些任务，我们经常需要依赖于外部环境提供的能力，为了整合这些能力，涌现了多种扩展技术，目前很常用的就是工具/函数调用（Tool/Function Calling）和模型上下文协议（MCP， Model Context Protocol），此外就是最近才发布不久的Agent2Agent协议。它们的功能在某些角度来看十分相近，但又有着各自的特点，本文将会分别就这几种技术进行介绍和分析，帮助大家对它们能有个总体的认知。

工具调用（Tool Calling）

Tool Calling 和 Function Calling 是两个意义相近的技术。有的人认为 Tool 是由多个 Function 组成的，也有人认为 Tool 本身就是 Function 的封装。从应用层来看，两者可以互换使用，LangChain 的文档也将两者视作同义词。因此本文统一使用 Tool Calling 进行描述。

Tool Calling 最早由 OpenAI 于 2023 年引入（当时称为 Function Calling），最初用于支持 ChatGPT 插件系统。这项能力使 LLM 可以通过标准接口请求宿主程序调用外部插件、API 或服务，从而突破模型固有知识边界和算力限制。OpenAI 提供了基于 JSON Schema 的函数定义方式，要求开发者为每个工具（即函数）定义名称、描述、输入参数类型和结构。模型一旦识别出用户的问题属于某个工具所能处理的范围，就会生成符合 JSON 格式的调用请求，而宿主应用接收请求、执行对应操作并返回结果，模型继续生成最终答复。随着该机制的成功，Claude、Gemini 等多个模型也支持了类似机制，同时 LangChain、LlamaIndex 等框架也构建了丰富的 Tool 封装能力，使 Tool Calling 成为 LLM 应用开发的重要基础设施。

Tool Calling 的核心优势有：

✅ 开发门槛低：在支持 Tool Calling 的模型中，开发者只需定义工具接口，不必教会模型如何使用它；
✅ 响应智能化：模型可基于用户输入决定是否调用工具、调用哪个工具、传递哪些参数；
✅ 结构安全性高：参数采用结构化格式（如 JSON），易于验证、防止提示注入；
✅ 插件能力增强：使模型如同拥有一个“可编程指令库”，通过组合调用构建复杂功能。

Tool Calling 调用流程图

典型示例

假设用户问：“杭州明天适合穿什么衣服？”

模型无法判断天气，识别出需调用 get_weather(city) 工具；
模型生成调用请求：{ "tool": "get_weather", "params": { "city": "杭州" } }
工具执行后返回天气情况（如15℃、小雨）；
模型结合天气与常识生成回答：“建议穿防水外套和长裤。”

工具调用的限制

尽管 Tool Calling 功能强大，但也有以下不足：

❌ 缺乏统一标准：各大模型平台的调用机制、参数格式等不同，难以实现完全兼容；
❌ 上下文不统一：每个模型对工具行为的解释可能不同，可能出现调用失败、误判等情况；
❌ 扩展复杂度提升：当工具数量众多或有调用依赖关系时，开发者需要构建中间调度逻辑，增加了代码复杂度和维护成本；

因此，在构建大型、多工具、多数据源的 LLM 系统时，仅依赖 Tool Calling 会显得吃力，这就需要更系统化的协议与架构来支撑，例如 MCP 用于统一工具接入标准、A2A 用于多 Agent 协同通信。

MCP (Model Context Protocol)

模型上下文协议（Model Context Protocol, MCP）是 Anthropic 于 2024 年 11 月正式提出的开放标准，其目标是为大语言模型（LLM）与外部数据源和工具之间的通信，提供一套统一、安全、标准化的接口协议。

背景与诞生动因

在 MCP 出现之前，大模型获取外部数据大致有两种方式：

直接注入数据至上下文（prompt injection）：例如将一整段文件内容或数据库查询结果拷贝进模型的 prompt 中。这种方式存在三个显著问题：
- 上下文长度限制：即便是支持几十K上下文的模型，也难以处理复杂文档、大型表格或完整历史。
- 效率低：模型必须对每次 prompt 中冗余重复的信息重新处理。
- 合规风险高：尤其在企业环境中，将敏感数据直接送入第三方大模型服务会带来隐私泄露与合规问题。
赋予模型执行权限的本地 Agent（如 Open Interpreter）：这种方式由模型驱动程序调用本地系统功能（如读取文件、执行命令），虽然强大，但风险也很高：
- 权限过大：模型拥有类似管理员权限，容易被 prompt injection 利用。
- 难以受控与审计：执行路径不透明，出现错误时难以定位责任点。

MCP 的提出正是为了解决以上问题，提供一个模型与工具之间的中立“桥梁”，兼顾能力、灵活性、安全性和标准化。

MCP 的核心架构与协议设计

架构图（如图所示）

基本组成

MCP Host：运行 MCP Client 的宿主环境，可能是 Claude 桌面端、IDE、企业 Copilot 系统等。
MCP Client：代表模型一侧发起任务请求的客户端 SDK，封装成标准协议消息发送给 MCP Server。
MCP Server：暴露功能或数据接口的服务提供者，可是本地数据库、文件系统，也可以是远程 API。
数据源或远程服务：MCP Server 后端连接的数据或服务。

技术协议

通信协议：基于 JSON-RPC 2.0，使用 WebSocket、本地 socket、HTTP 等方式作为承载层。
会话管理：虽然 JSON-RPC 是无状态协议，MCP 在其基础上增加了有状态会话机制，支持多轮交互。
能力协商：客户端和服务器在建立连接后，会互换所支持的能力与版本，确保兼容性。

核心能力

MCP Server 可以提供三种主要类型的能力：

1. Resources（资源）

表示模型可以读取的数据，如：
- 本地文件（markdown, code, PDF 等）
- 数据库查询结果
- 实时日志流
Server 端根据 query 参数，返回结构化数据或内容片段，模型据此推理。

2. Prompts（提示）

Server 提供特定场景下可复用的提示模版，例如：
- 提交 Bug 的规范格式
- 提醒语句的生成模版
模型根据 prompt 模版动态构建完整 prompt，提升上下文一致性与效果。

3. Tools（工具）

Server 以函数形式暴露一组可调用方法，模型可以查看工具描述、参数定义，并构造调用请求。
输入/输出均为结构化 JSON。
类似 OpenAI 的 function calling，但与模型 API 解耦，工具只暴露于 MCP Server，而非模型服务端。

除了这3个核心能力之外，还有2个核心的概念:

Sampling（反向调用模型）

Sampling_ 是 客户端（Client） 提供给 服务器（Server） 的附加能力；它允许服务器 反向请求 客户端执行一次 LLM 补全，然后把生成结果回传给服务器本身。这使服务器可在自身逻辑里嵌套 LLM 调用（例如让模型为返回的数据做摘要、分类或生成代码），从而形成 递归式、多代理协作。
Sampling 目前尚未在 Claude Desktop 默认客户端中启用，实际落地时需要确认所用 SDK/客户端是否支持。
由于服务器可触发模型生成，规范要求 Sampling 应始终有人类在环（human‑in‑the‑loop），客户端应提供拒绝或中止采样请求的能力。
Roots：限定服务器可操作范围的“根路径”
Roots 是客户端提供给服务器的 URI 列表，用于 声明服务器可操作的资源边界。典型 root 可以是文件系统目录、Git 仓库路径或 REST API 根 URL。
用途
1. 最小暴露面：服务器只应在这些 root 下读取/写入，避免误操作其他文件或泄露数据。
2. 动态更新：客户端可在会话中实时添加、移除或变更 roots，服务器会通过 _roots/listchanged 通知获知。
本质：Roots 只是“指导信息（guidance, not enforcement）”，真正的约束仍需服务器端遵守；但它为多源资源接入提供了清晰的作用域模型，便于权限审核与 UI 呈现。

安全性与可控性设计

MCP 的重要设计目标之一是安全，在企业环境尤为关键。具体策略包括：

最小权限原则：模型无法访问未注册的 Server，也无法执行非暴露接口。
本地数据不出网：Server 与 Client 在本地运行时，数据无需离开用户端。
Server 实施访问控制：开发者可限定哪些请求被允许执行。
连接加密：可使用 WebSocket+TLS 或 Unix Socket 确保传输加密。
审计与日志记录：所有操作可被记录，方便排查与合规监管。

实际应用流程示例

以“模型查询某用户的数据库信息”为例：

注册能力：Server 启动并声明提供 query_user_info 工具，说明其参数为 user_id，返回结构为 JSON。
能力协商：模型所在应用（Client）建立连接，获得工具描述。
模型调用：模型识别到缺少用户信息，于是发起 Tool Call 请求：
```
{
 "method": "query_user_info",
 "params": {"user_id": 12345}
}
```

Server 执行：MCP Server 查询数据库，返回：

{
 "result": {"name": "小明", "level": 3, "org": "杭州分部"}
}

模型继续生成回答：基于新获得的信息，回答“该用户来自哪个部门？”等问题。

MCP 的生态与开源工具支持

目前 MCP 已成为行业重点推进的通用标准，生态扩展迅速：

官方 SDK：提供 Python、TypeScript、Java、C# 等语言支持
预构建服务器：如 Google Drive, Slack, GitHub, Postgres 等接口已提供标准 MCP Server 实现
开源工具链：
- mcp-python-sdk
- mcp-typescript-sdk
- 开源集成如 Dify、LangChain 社区已提供插件

国内也已有初步生态实践：如阿里百炼推出了 MCP 工具市场，支持企业级私有 Server 接入。

MCP总结

MCP 是大模型应用场景中最具潜力的“接口层”标准，它为模型与外部世界之间提供了结构化、安全、模块化的连接方式：

对模型来说：不必再手动拼接提示词或理解复杂 API 文档，只需理解 MCP 协议即可动态发现资源与工具；
对开发者来说：只需实现一次 MCP Server，便可同时服务于各种支持 MCP 的 LLM；
对企业来说：最大化数据安全控制权，最小化模型供应商绑定风险。

在未来，MCP 可能会成为 LLM 工程体系中的标准“适配层，逐步成为让LLM接入外部数据/工具的事实标准。

Agent2Agent协议（A2A）

Agent2Agent（简称A2A）协议是谷歌于今年4月推出的一项全新开放标准。与MCP聚焦于模型对接工具不同，A2A关注的是AI智能体之间的互联互操作。2024年底至2025年，各种由不同平台和厂商构建的AI Agent（智能体）如雨后春笋般出现——从企业的客服Bot、业务流程Agent，到个人的自动化助手。然而，这些Agent各自为营，缺乏统一的通信语言，形成了信息和能力的“孤岛” 。不同部门或公司的AI系统难以直接对话协作，就像一群说着不同语言的人试图一起工作一样，效率大打折扣。Google联合了包括Salesforce、SAP、LangChain等在内的50多家技术伙伴推出A2A协议，旨在为异构AI智能体建立统一通信标准，打破框架和供应商壁垒。

A2A（Agent2Agent）协议的核心在于：为多个自治智能体（Agents）之间的任务协作与消息通信，提供一套统一的、结构化的协议标准。 在 A2A 的框架中，一个“客户端智能体”（Client Agent） 负责发起任务请求，一个“远程智能体”（Remote Agent） 负责接受任务、执行操作、并将结果回传。A2A 协议的交互主要由以下四大核心能力支撑：

Capability discovery： 代理可以使用 JSON 格式的“Agent Card”来宣传其能力，从而允许客户端代理识别能够执行任务的最佳代理并利用 A2A 与远程代理进行通信。
Task management： 客户端与远程代理之间的通信以任务完成为导向，代理负责执行最终用户的请求。此“Task”对象由协议定义，并具有生命周期。它可以立即完成，或者，对于长时间运行的任务，每个代理可以进行通信，以彼此保持同步，了解任务的最新完成状态。任务的输出称为“Artifact”。
Collaboration： 代理可以互相发送消息来传达上下文、回复、Artifact或用户指令。
User experience negotiation： 每条消息包含“部分”，即完整形成的内容片段，例如生成的图像。每个部分都有指定的内容类型，允许客户端和远程代理协商所需的正确格式，并明确包含对用户 UI 功能（例如 iframe、视频、Web 表单等）的协商，这意味着 A2A 不仅关注 Agent 之间的语义协作，还主动考虑最终用户界面呈现方式的兼容性和体验质量，这是前所未有的细节设计。

Agent2Agent 协议并不是一个“让两个模型聊聊天”的玩具协议，而是一个为多智能体系统构建而设计的严肃通信标准。它让智能体之间的协作具备以下特性：

可发现（通过 Agent Card 找到对口 Agent）；
可协作（通过结构化任务和消息交换达成多轮互动）；
可追踪（任务生命周期管理）；
可适配（根据用户设备/界面能力协商展示形式）；
可扩展（设计支持异步、长任务、组合式工作流）；

这也意味着，在未来 AI 代理系统中，A2A 将可能扮演类似“互联网协议TCP/IP”在信息网络中的作用——它不是服务，而是基础通信层标准。

A2A与MCP的功能很相似，但也有着不同。A2A侧重智能体之间的协作沟通，而MCP侧重智能体获取外部工具与数据。两者可以视为互补的层次。Google在发布A2A时也明确提到：“A2A是一个开放协议，与Anthropic的MCP互为补充：MCP为智能体提供有用的工具和上下文，而A2A则让不同智能体能够协同工作” 。例如，在一个汽车维修店的示例中，MCP负责连接单个维修机器人智能体与它使用的传感器、机械臂等“工具”（结构化动作指令），而A2A则让不同机器人和客服代理彼此对话协商，共同完成复杂的维修任务。因此，两协议并非竞争关系，而是针对不同层面的需求提供支持：MCP连接“AI与工具”，A2A连接“AI与AI”。

对比

在了解了上述三种技术的背景和特点后，我们从开发复杂度、生态成熟度、适用场景、安全性、性能五个方面对它们进行对比分析。下表提供了一个快速概览，随后是每个维度的详细说明：

比较维度	工具调用（Tool Calling）	模型上下文协议（MCP）	Agent2Agent 协议（A2A）
开发复杂度	低。在支持函数调用的模型上配置简单，定义函数接口即可使用。模型自动处理格式，无需复杂Prompt。但增加大量工具时需管理调用逻辑。	中等。需部署/集成MCP客户端和服务器，有一定工程开销。好在有官方SDK和众多现成集成可用，减少重复开发工作。	较高。属于分布式多智能体系统开发，需要设计Agent交互逻辑。目前工具链尚不成熟，上手门槛高于前两者，但标准化协议减轻了不同Agent通讯的实现难度。
生态成熟度	高。已广泛支持于主流LLM平台和框架中，概念成熟。然而缺乏统一标准，不同实现之间兼容性有限。	较高。作为开放标准自发布即获众多厂商支持，生态扩张迅速。已有大量开源服务器和大厂应用集成MCP，趋于标准化。	起步阶段。2025年初发布，虽有重量级联盟支持，但生态尚在构建。目前主要在合作伙伴产品和Google云生态中试验，社区接受度有待观察。
适用场景	单Agent扩能。适合给单一大模型助手增添技能，如问答机器人调用计算、查资料等。实现快速、直接，在聊天应用、AI插件等场景广泛应用。	工具/数据整合。适合需要整合多数据源、工具的复杂应用，尤其在企业环境下（如智能客服接入业务数据库、开发助手访问代码库）。当您想在不绑定特定厂商的前提下，让模型安全调用各种内部资源时，MCP是优选。	多Agent协作。适合复杂任务拆解给多个AI智能体的场景，如流程自动化、跨部门AI协同工作。当任务涉及不同专长的Agent需要对话配合（类似多人团队）时，应考虑A2A。也用于将不同平台的AI系统连接起来。
安全性	相对安全。调用的函数由开发者预先限定，输出参数结构固定，降低了被用户提示劫持的可能。但工具本身的权限需严格管理，避免模型滥用强大工具造成危害。	安全为先。MCP强调在开发者基础设施内安全地连接模型和数据。通过限定模型可访问的MCP服务器，敏感数据不直接暴露给模型API，提高了数据保护。协议设计上有鉴权机制，安全审计更可控。	企业级安全。A2A明确要求Agent间安全交换信息。协议通常会结合身份认证、加密通信，防止未授权Agent加入对话。多Agent协作也能设置权限边界，例如限制某些Agent只能执行特定操作，从体系结构上分散风险。
性能	同步调用，开销低（一次工具调用相当于一次函数执行+一次模型响应）。对于简单任务，响应迅速。但若单次请求需多轮工具交互，延迟累积会增加，应合理控制调用次数。	额外开销小。引入MCP主要是一次轻量的网络交互开销，通常可接受。它能让模型按需获取所需数据，避免传入大量无关信息，整体效率提升。在新版本中MCP支持流式传输结果，大数据场景下性能表现更佳。

综上所述，Tool Calling、MCP 和 A2A 各有侧重，互为补充。开发者在选择哪种技术方案时，可以根据项目需求的性质和复杂度来权衡：

如果您的场景以单个LLM助手为主，需要快速赋予它额外能力，例如让聊天机器人能查资料、接第三方API，那么优先考虑使用工具调用**。它实现简单、见效快，能大幅提升模型实用性。对于初创应用或功能原型，工具调用是最低成本的方案。
如果您的场景需要深度整合企业内部的数据和工具，或者希望在不同LLM平台之间保持弹性，那么模型上下文协议（MCP）是更稳健的选择。MCP提供了标准化的接口，让AI系统能够安全获取各类数据源。在需要长期维护、拓展**的项目（如企业数字员工）中，采用MCP能降低后期集成新系统的难度，并满足严苛的安全要求。
如果您的场景涉及复杂任务的自动化和多智能体协作，例如搭建一个AI代理网络去协同完成业务流程，那么可以考虑引入Agent2Agent协议（A2A）。当单个智能体无法高效完成任务，多个专能Agent各展所长又需要互相配合时，A2A将提供未来式的解决方案。不过在2025年这个时间点，A2A生态尚不成熟，除非您有明确的多Agent需求和足够的研发实力，否则一般来说可先通过MCP+单Agent实现核心功能**，观望A2A的发展。一旦A2A工具链和案例逐渐丰富，再逐步演进到多Agent架构。

值得注意的是，这些技术并非相互排斥。在一个大型AI应用中，完全可以综合运用它们：用MCP打通AI与各种工具数据的接口，再通过A2A让多个AI模块协同决策，同时在每个智能体内部依然使用工具调用来完成细节任务。正如前文分析的，Tool Calling解决“单兵作战”能力，MCP解决“武器弹药补给”，A2A解决“团队配合”。根据任务需要组合拳出击，才能打造真正强大的AI系统。

总结一句话：如果只是给模型添把“工具”就能搞定问题，那就用工具调用；如果需要搭建“接口”连接四面八方的数据，那就上MCP；而当您希望组建“团队”让多个AI一起干活时，可以考虑A2A。希望本次对比分析能帮助您在大模型应用开发中选对工具、用好协议，开发出安全高效的AI应用系统。