面向上下文协议主要解决 Agent 如何从外部世界（数据、工具、服务）获取完成任务所需信息（上下文）的问题。以前主要靠针对特定模型微调函数调用能力，但缺乏标准导致接口五花八门，开发维护成本高。

MCP协议：

MCP（Model Context Protocol）协议作为AI届的USB-C，他的目标是建立一个连接LLM与外部资源的通用、开放标准。他采用Client-Server架构，将工具调用、资源访问与LLM解耦，并对开发、调用的协议基于JSON-RPC进行标准化，解决了不同模型和工具提供商带来的碎片化问题。

MCP主要采用 Client - Server 架构，其核心架构主要包括以下内容：

• 主机（Host）：通常是发起连接的 LLM 应用程序，如 Claude Desktop、IDE 插件等。它负责管理客户端实例和安全策略，是用户与 AI 模型进行交互的平台，同时也承担着集成外部工具、访问多样化数据资源的任务。
• 客户端（Client）：是主机内的连接器，与服务器建立 1:1 会话。它负责处理协议协商和消息路由，充当主机与外部资源之间的桥梁，通过标准化的协议接口协调数据传输和指令交互，确保信息的实时性与一致性。
• 服务器（Server）：是独立运行的轻量级服务，通过标准化接口提供特定功能，如文件系统访问、数据库查询等。服务器连接外部资源与 AI 模型，向 LLMs 暴露来自不同数据源的内容和信息，还支持创建可复用的提示模板和工作流，帮助开发者设计标准化的交互模式。

基于MCP协议，Agent可以不局限于语言、框架的限制，集成社区里优秀的MCP Server，让Agent能方便调用外部API、访问和修改各类资源，实现如自动化办公、数据抓取、信息检索、流程编排、跨系统集成等多种能力。MCP协议的标准化设计，使得工具的开发与接入变得高度便捷，极大提升了Agent的可扩展性和生态兼容性。开发者可以快速复用社区已有的工具组件，降低开发和维护成本，同时也让Agent具备了灵活适配不同业务场景的能力，推动了AI Agent在实际生产环境中的落地和普及。

Function Call

Function Calling 具体指的是 LLM 根据用户的自然语言输入，自主决定调用哪些函数，并进行格式化的函数调用的能力。

Function Call（函数调用）是编程中的核心概念，简单说就是“让代码执行指定任务的操作”。想象一下，您在玩遥控车：按下按钮（调用函数），车子就运行预设动作（执行函数）。这背后的原理是基于输入参数触发特定代码块，就像OpenAI官网描述的那样：“Function Calling allows models to call functions with JSON-structured arguments, enabling seamless integration with external tools.”（参考OpenAI官网最新文档，2025年更新）。

在技术层面，它由三部分组成：

• 调用语句：如Python中的 function_name(参数)，告诉系统“开始干活”。

• 参数传递：输入数据驱动函数逻辑，例如传递用户查询。

• 返回值：函数执行后输出结果，比如计算数据或调用API。
  最新数据（来自Python官网和OpenAI）显示，Function Call支持多种语言，2025年AI框架中调用成功率超98%，让开发更可靠。

外部系统通常会以函数（function）的形式进行封装，LLM 通过函数调用（function calling）可以实现与外部系统的交互。

Function Calling 一般的过程如下：

1. 将用户的自然语言输入与已有函数的描述作为输入参数传给 LLM；
2. LLM 结合输入参数，决定调用哪些函数，并指明必要参数（如函数的入参），进行格式化（如 JSON、XML 格式）的输出；
3. 用户端接收到 LLM 格式化的函数调用后，对本地的函数进行调用，得到结果；
4. 将得到的函数结果传给 LLM，使得 LLM 有了所需的上下文信息。

Function Calling 实际上强调的是 LLM 本身的能力，一些经过特殊训练或调优的 LLM 能够根据用户的自然语言输入决定使用哪些函数，并按约定的格式表达出函数的调用。

面向Agent间协议：A2A

随着任务越来越复杂，单个 Agent 能力有限，多 Agent 协作成为趋势。面向Agent间的协议主要是为了规范 Agent 之间的沟通、发现和协作。

早在2024年10月，由国人发起的ANP（Agent Network Protocol）社区已经在开始孵化，旨在打造智能体互联网时代的HTTP协议，使用 W3C DID 进行身份认证，并有元协议层让 Agent 能自主协商沟通方式，使智能体能够在互联网上相互发现、连接和交互，建立一个开放、安全的智能体协作网络，不过目前Github仓库779个Star，社区关注度和热度都不太高。

2025年4月，Google联合50多家技术和服务合作伙伴，共同发布了全新的开放协议——A2A协议旨在为AI智能体之间的互操作性和协作提供标准化的通信方式，无论底层框架或供应商如何，智能体都能安全、灵活地发现彼此、交换信息、协同完成复杂任务。协议发布后，得到了社区的大量关注，至今获得了16.1k Star。A2A协议的核心功能包括：

• 能力发现：智能体通过JSON格式的"Agent Card"宣传自身能力，便于其他Agent发现和调用最合适的智能体。
• 任务和状态管理：以任务为导向，协议定义了任务对象及其生命周期，支持任务的分发、进度同步和结果（工件）输出，适配长短任务场景。
• 协作与消息交换：智能体之间可发送消息，交流上下文、回复、工件或用户指令，实现多智能体间的高效协作。
• 用户体验协商：每条消息可包含不同类型的内容片段（如图片、表单、视频等），支持客户端和远程Agent协商所需的内容格式和UI能力。

基于A2A协议，开发者可以构建能够与其他A2A智能体互联互通的系统，实现跨平台、跨厂商的多Agent协作。例如在企业招聘场景中，一个Agent可以负责筛选候选人，另一个Agent负责安排面试，第三个Agent负责背景调查，所有流程通过A2A协议无缝衔接，大幅提升自动化和协作效率。A2A协议的开放性和标准化为未来智能体生态的互操作性和创新能力奠定了坚实基础。

Function Call vs MCP vs A2A

Function Call和MCP的核心区别是什么？

一句话总结：Function Call不是协议，是大模型提供的一种能力，MCP里的工具调用，是基于Function Call能力实现的，对于工具来说，MCP和Function Call是依赖关系。但MCP除了工具外，还有Prompts、Resources等其他上下文的定义。

Function Call 是大模型提供的基础能力，允许模型根据自然语言指令自动调用预定义函数，实现与外部工具的连接，但它并非统一标准 —— 不同厂商（如 OpenAI、百度文心）对其接口格式、参数定义等有独立实现，导致工具需针对不同模型重复适配，类似各品牌手机自有充电接口的碎片化问题。

MCP（模型上下文协议）则是跨模型、跨工具的统一交互标准，不仅规范了工具调用（如函数描述、参数格式），还整合了 Prompts、资源管理等上下文体系，目标是成为 AI 生态的 "USB-C"，让工具只需按统一协议封装一次，即可在多模型中通用，大幅降低跨平台适配成本。​

尽管 MCP 试图通过标准化解决碎片化问题，但其落地面临多重障碍：​

• 生态成熟度不足：MCP 应用市场虽有超 1.3 万个工具（MCP Server），但多数存在配置复杂、实现不规范、同质化严重等问题，真正能直接用于生产环境的少之又少，开发者常因适配成本高而选择直接调用 API；​
• 企业基建冲突：若团队已有统一的工具调用体系（如自研 Agent 框架、API 网关），MCP 的协议层可能被视为冗余，现有基建已实现工具管理、监控等功能，引入 MCP 反而增加运维负担，类似服务网格在成熟基建中难以落地的困境；​
• 通用协议的场景局限：MCP 的标准化设计难以满足金融、工业等垂直领域的定制需求（如安全审计、数据隔离），此时直接开发专用工具链反而更高效。

总的来说，Function Call 是大模型连接外部世界的 "能力基石"，

MCP 是推动跨生态协同的 "协议桥梁"。MCP 的价值在于跨模型通用工具的快速构建（如无代码配置场景），但其局限性也表明，它并非万能 —— 企业需根据自身基建成熟度和场景需求选择方案：已有完善工具链的团队可优先复用现有体系，而致力于构建开放 AI 生态的开发者，则可借助 MCP 实现 "一次开发、多端运行" 的规模化效应。

未来 MCP 需通过分层设计（基础规范 + 行业扩展）、质量认证体系等提升实用性，才能在碎片化与标准化的平衡中找到更广阔的应用空间。​

MCP 和 A2A 是什么关系？

从协议分层来说，MCP、A2A并非互斥，而是分层协同。MCP主要解决"Agent如何用好工具"，通过标准化工具接口，极大提升了工具复用和生态兼容性。而A2A则解决"多个Agent如何协作"，通过标准化Agent间通信，推动了多Agent系统的互操作和协作创新。在实际系统中，常见的模式是：

• 单个Agent通过MCP协议调用各类工具，获得外部能力。
• 多个Agent通过A2A协议互相发现、分工协作，协同完成复杂任务。

但其实换个思路，我们可以将"工具"视为一种低自主性 Agent。这类"工具型Agent"专注于执行高度特化的任务，其行为模式更接近于传统的API调用，输入输出明确，决策空间有限。反过来，一个复杂的"Agent"也可以被看作是一种**高自主性"工具"**。特别是当这个Agent能够理解和生成自然语言，处理复杂上下文，并自主规划和执行多步骤任务时，它就成了一个可以被其他系统或Agent调用的强大"能力单元"。这么看来，MCP 和 A2A 也可能是竞争的关系。

从这个角度看，MCP协议（面向上下文，强调Agent如何使用工具）和A2A协议（面向Agent间协作）的界限正在变得模糊。如果工具的输入输出本身就是自然语言，或者工具本身具备了一定的"智能"和"状态"，那么调用一个"工具"和与一个"Agent"协作在交互模式上可能非常相似。这意味着，未来这两类协议可能会进一步融合，形成一个更统一的框架，既能规范Agent如何利用外部能力（无论是简单的API还是复杂的"工具型Agent"），也能协调多个高自主性Agent之间的协作，最终实现一个更加无缝和高效的智能体生态系统。

举个实际的例子，假如 AI Agent 需要完成一个"规划 5 天深圳到厦门旅行"，使用 MCP 和使用 A2A 的都可以实现：

• MCP：像个大总管。一个中央 Agent (MCP Travel Client) 负责调用所有外部服务（机票、酒店、天气），然后汇总信息生成计划。优点是简单可控，缺点是中心化依赖高，不易扩展。
• A2A：像个部门协作。任务被分配给专门的 Agent（交通、住宿、活动），这些 Agent 可以直接相互沟通（比如机票 Agent 直接问天气 Agent 获取信息），也可以和用户进行沟通（比如机票Agent完成初筛之后询问用户是否满足需求，对用户给出的建议进行迭代修改），这种方式更灵活，适合企业内复杂协作。

那么，在实际项目中，我们应该如何在这两者之间做出选择呢？MCP会更适合那些交互模式类似于传统API调用的场景。当你需要Agent作为工具执行者，关注明确的输入和输出，且交互流程相对固定时，MCP的结构化和工具导向特性会更具优势。它强调的是Agent如何高效、规范地使用外部工具，补充模型上下文。而A2A更适用于需要多个Agent进行复杂协作、对话式交互和任务共同完成的场景。A2A关注的是Agent之间的消息传递（Messages）、状态同步以及最终的输出制品（Artifacts）。如果系统需要Agent之间进行动态协商、分工合作，并且结果的达成比固定的交互流程更重要，那么A2A会是更合适的选择。

总而言之，协议本身没有绝对的好坏之分，选择MCP还是A2A，亦或是未来可能出现的其他协议，都需要根据项目的具体需求、团队的技术栈、以及期望实现的Agent交互模式进行综合考量。这与我们在微服务架构设计中面临的选择类似：是选择基于TCP二进制流的tRPC，还是基于HTTP/2的gRPC，亦或是更为通用的HTTP RESTful API？每种协议都有其特定的优势和适用场景，关键在于找到最契合当前业务和技术目标的那个。

写在最后

AI Agent 的发展正处于爆发前夜，从最初的 LLM 聊天机器人，到具备规划、记忆、工具调用能力的智能体，再到多 Agent 协作的复杂生态，整个行业正在经历一场范式转变协议标准化是 Agent 生态繁荣的基石：MCP、A2A 等协议的出现，极大降低了工具和 Agent 的集成门槛，让"能力复用"成为可能。未来，协议的进一步融合和演进，将推动智能体生态走向真正的互联互通。