本文将从基础概念出发，逐步解析 Agent（智能体）、Function Calling（函数调用）、MCP（模型上下文协议）及 A2A（智能体协作协议），帮助读者理解 LLM 应用知识体系。

本文是参考官方文档、网上的一些文章后进行总结而成，旨在让不了解的同学阅读后有一个大致的概念。大佬可以直接跳过，或者也可以帮忙看下写错没有哈哈~

如果你在阅读过程中发现文中存在错误，请一定留言指正，感谢~

1. Agent

1.1 Agent 是什么？

Agent（智能体） 是一个能够 感知环境、自主决策、执行动作 的实体。在大模型场景中，Agent 通常基于大语言模型（LLM）作为核心推理引擎，结合外部工具、知识库和多模态能力，完成复杂任务。

其本质是构建具备『思考-行动-观察』循环（ReAct）的智能系统。

核心能力：

  • 推理：通过 LLM 解析用户意图、规划任务步骤。

  • 工具调用：调用外部 API、数据库、代码等工具。

  • 记忆与学习：保留历史交互记录，优化长期行为。

一句话描述：Agent 是一个以 LLM 为基础，结合其他外部工具辅助，最终能够完成复杂任务的实体(工具、助手)。

1.2 为什么需要 Agent？

大模型的两大缺陷：大模型受限于计算资源和训练时间，导致信息滞后，并且其基于统计规律的回答缺乏真正的逻辑推理能力。

  • 1）没有最新信息：大模型的训练需要大量的计算资源和时间，因此它们的知识库通常是在某个时间点之前的数据集上训练的。例如，GPT-3.5 和 GPT-4 的知识截至 2021 年 9 月。这意味着它们无法提供此后的新信息或事件。为保持时效性，需定期重训模型，但成本高昂且耗时，导致大模型难以及时跟上信息更新。

  • 2）没有真逻辑：大模型生成的文本和回答主要基于训练数据的统计规律，而非严格的逻辑推理或形式化证明。因此，在处理复杂或需深入逻辑推理的问题时，它们可能产生看似合理但实际不准确的回答。此外，大模型通过预测给定上下文中的下一个词来生成文本，可能受训练数据中的偏见和错误影响，从而削弱逻辑严谨性。

因此，为了能够完成更加复杂的任务，我们需要将大模型和外部工具相结合，而落到具体实现上体现出来就是 Agent。

1.3 Agent 工作流程

举个例子 🌰：有一个很简单的任务，我要查询重庆的天气。

对于大模型来说，没有最新的知识，自然是不知道今天的天气情况，那么需要借助外部工具来完成这个任务，比如调用天气 API。

整个流程大概就是这样的：

 

agent-workflow.png

  • 1）用户发送任务给 Agent

  • 2）Agent 转发给 LLM，并携带上配置好的 tools 信息

  • 3）LLM 根据问题和 tools 信息，找出需要使用的 tool 以及请求参数返回给 Agent

  • 4）Agent 根据 3 中返回的信息调用具体工具得到结果

  • 5）对应工具将结果返回给 Agent

  • 6） Agent 将结果发送给 LLM

  • 7）LLM 根据上下文，整合信息生成最终结果返回给 Agent

  • 8）Agent 将结果返回给用户

可以看到，对于这个简单的任务，在流程中 Agent 好像就干了两件事：

  • 1）在 User 和 LLM 之间传话

  • 2）配合 LLM 调用外部工具

当然了，真正的 Agent 肯定会更加复杂。

1.4 LLM 是如何调用外部工具的

看完上面的 Demo 之后，大家可能会有一个疑问：大模型是怎么知道这个功能该调用哪个外部工具就可以实现呢，又怎么知道这些工具该如何传参数。

实际上大模型确实不知道，因此我们要将外部工具信息告知大模型，比如在 System Prompt 中增加 tools 描述。

这样大模型就知道有哪些工具可以调用了，同时根据用户的问题能够自行判断是否需要调用外部工具，若需要则从问题中解析参数，然后以固定格式(一般为 JSON)返回。

例如，可以使用以下 System Prompt：

你是一个智能助手，可以根据用户请求选择并调用合适的外部工具。以下是工具库和调用规范：
[  {    "name": "get_weather",    "description": "查询指定城市的实时天气状况",    "invoke_conditions": [      "天气",      "气温",      "降雨",      "风力"    ],    "parameters": [      {        "name": "city",        "type": "string",        "required": true,        "extract_rule": "从问题中提取明确城市名称",        "examples": [          "北京市",          "上海"        ]      },      {        "name": "date",        "type": "date",        "required": false,        "default": "当天",        "format": "YYYY-MM-DD",        "examples": [          "2024-08-15"        ]      }    ]  }]你需要严格按以下 JSON 格式返回工具调用结果，注意不要返回其他额外信息：{"tool": "工具名称",  // 必须与工具库中的name完全一致"params": {    "参数1": "值1",   // 参数名与工具定义一致    "参数2": "值2"  }}

然后我们再问问题：

帮我查询重庆的天气。

以下为大模型的思考过程：

好的，用户让我帮忙查询重庆的天气。首先，我需要检查用户的问题中是否包含需要调用工具的关键词。根据工具库中的定义，get_weather工具的调用条件包括“天气”、“气温”、“降雨”、“风力”等词。用户的问题里明确提到了“天气”，所以符合调用条件。
接下来，我需要提取参数。根据工具的定义，必须的参数是城市名称city，可选参数是日期date，默认当天。用户的问题中明确提到了“重庆”，所以city参数的值应该是“重庆市”。日期没有特别说明，所以使用默认值“当天”。
然后，我需要确认参数提取是否正确。用户的问题中没有提到具体日期，所以date参数保持默认。城市名称是否正确，用户写的是“重庆”，而工具示例中有“北京市”和“上海”，但根据常识，“重庆”作为直辖市，正确的名称应该是“重庆市”，不过工具的参数是否接受简称可能需要确认。但根据工具的定义，示例中用了“上海”作为简写，所以可能允许使用简称。不过为了准确，可能应该使用全称“重庆市”。不过用户原文是“重庆”，可能工具的参数接受这个名称，所以直接提取即可。
最后，按照要求生成JSON格式的响应，确保工具名称正确，参数正确无误，没有多余信息。

最终的返回结果

{
  "tool": "get_weather",
  "params": {
    "city": "重庆"
  }
}

可以看到，模型可以根据问题找到正确的工具，并且从问题中解析出参数，最终以 JSON 形式返回了调用请求，Agent 收到这个 JSON 格式信息后就可以真正的调用天气 API 去查询天气了。

不过需要注意的是：根据模型能力不同，可能存在即使明确要求输出 JSON，仍然出现 语法错误、转义字符错误、多出冗余文本之类的问题。

2. Function Calling

2.1 什么是 Function Calling

https://platform.openai.com/docs/guides/function-calling[1]

FunctionCalling 由 OpenA I 在 2023 年 6 月推出，最初在 GPT-3.5 和 GPT-4 模型上实现，它允许大语言模型与外部工具连接，将自然语言转换为 API 调用。这解决了大模型在训练结束，就知识更新停滞的问题。

OpenAI 文档中的描述：

Function calling provides a powerful and flexible way for OpenAI models to interface with your code or external services.

Function Calling 是特定于大语言模型(LLM)的机制，允许模型调用外部函数或 API，它允许模型生成结构化 JSON 输出，以调用外部系统中预定义的函数或 API。

通过调用外部工具和服务，Function Calling 帮助大模型解决了比如今天温度多少度之类的实时性问题。

一句话描述：Function Calling 是一种允许模型通过生成结构化 JSON 输出，以'调用'外部系统中预定义的函数的机制。

注意：这里的'调用'是带引号的,因为 FunctionCalling 并不是直接赋予了 LLM 调用外部函数的能力，而是让 LLM 能够根据预定义函数列表、用户输入 Prompt 等相关信息知道该调用哪个函数，并以此生成结构化输出，包括该调用的函数名、输入参数等以供外部工具使用。

2.1 为什么需要 Function Calling 

实际上，之前我们通过在 System Prompt 中注入 tools 信息的方式已经可以实现类似 Function Calling 的功能了，不过这种方式不够稳定，模型可能不会每次都正确返回(取决于模型能力)。

  • Function Calling 是厂商（如 OpenAI、Anthropic）通过 微调或架构优化，赋予模型生成结构化指令（如 JSON）的能力，这种能力使模型能精准匹配预定义函数，而非依赖自然语言生成。

  • Function Calling 本身 没有统一协议，不同厂商实现方式不同（如 OpenAI 的 tools 参数、Claude 的 tool_use 字段）。

    • 这也是为什么后面又推出了标准化的 MCP 协议,旨在统一工具调用流程。

Function Calling 和 使用 System Prompt 模拟二者都是让 LLM 调用外部工具的一种实现，或者都可以算是广义上的 Function Calling 。具体区别在于：

  • System Prompt 模拟方式：主要依赖于模型的自然语言生成能力，不够稳定

    • 此时的模型只是根据 Prompt 生成返回

  • Function Calling 则是直接对模型进行微调，从而赋予模型生成结构化指令的能力，更加准确。

    • 此时的模型经过特殊的微调，能够更好的处理这种需求，因此能够更加精准的匹配预定义函数

简单理解就是做数学题：1+2+3....+100。

  • 一个是硬算,如果比较复杂的任务可能就会出错

  • 一个是套公式,n(n+1)/2，很轻松就得到结果了

2.3 FunctionCalling 工作流程

流程如下：

 

funcation-calling-workflow.png

图源：https://platform.openai.com/docs/guides/function-calling?api-mode=chat#overview[2]

也是分为这几个步骤：

  • 1）用户定义 Tools 并告知 LLM

  • 2）用户发送 Prompt 给 LLM，LLM 根据拿到的 Tools 信息判断需要调用哪个工具，并生成对应 JSON 格式调用请求

  • 3）用户根据请求调用具体工具

  • 4）用户将调用结果返回 LLM

  • 5）LLM 整合结果返回最终回复

当然了，一般不会是用户直接和 LLM 交互和调用对应工具，会有一个中间商,比如 Agent。

3. MCP

3.1 什么是 MCP

MCP(Model Context Protocol) 是由 Anthropic 推出的一项开放标准协议，旨在解决不同大模型与不同外部工具集成的标准化问题。官方解释是“其目标是为大型语言模型提供一种开放、标准化的方式，以便与外部数据源、工具和服务进行连接。”

  • 它规定了上下文与请求的结构化传递方式，并要求通信格式符合 JSON-RPC 2.0 标准。

  • 简单理解，MCP 相当于大模型领域的“HTTP 协议”，其并不绑定任何大模型，这意味着用户可以在支持 MCP 的工具中，用任何大模型调用 MCP 服务。

协议具体描述在这个仓库：modelcontextprotocol[3] 感兴趣的童鞋可以自行查阅

英文版描述：

The Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you're building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need.

一句话描述：MCP 是一种开放、标准化的协议，以便大型语言模型能够与外部数据源、工具和服务进行连接。

3.2 为什么需要 MCP

在 MCP 爆火之前，Function Calling 函数调用模式也被众多开发者广泛采纳。

但是由于不同厂商对于 Function Calling 的标准、优化方式和迭代路径均不统一，开发者可根据规则自由定义函数和 API 调用方式，这其中就会出现不通用的问题，导致普及困难且需要重复开发，这再次凸显了 MCP 标准化的重要性。

如 OpenAI 的 tools 参数、Claude 的 tool_use 字段。

即便是不支持 Function Calling 的模型，开发者都能够通过 MCP 协议的方式来调用任何一个服务，而这也让我们进入了工具使用的平权时代。

目前，Anthropic 的 Claude 系列，Open AI 的 GPT 系列、Meta 的 Llama 系列，deepseek、阿里的通义系列，Anysphere 的 Cursor，各种主流模型均已接入 MCP 生态。

3.3 MCP 架构

架构如下：

 

mcp-general-architecture.png

图源：https://modelcontextprotocol.io/introduction#general-architecture[4]

MCP 涉及到 5 个组件或角色：

  • MCP Hosts: 真正使用 MCP 的程序，例如 Claude Desktop, IDEs 或者其他 AI 工具

  • MCP Clients: 实现 MCP 协议的客户端，维持和 MCP Server 之间的 1:1 连接

  • MCP Servers: 实现 MCP 协议的服务端，通过 MCP 协议公开某些功能，MCP 服务器可以提供以下类型的功能：

    1. Resources: 客户端可以读取的类似文件的数据（如 API 响应或文件内容）

    2. Tools: 工具：可以由 LLM 调用的函数（经用户批准）

    3. Prompts: 帮助用户完成特定任务的预先编写的模板

    4. ...

  • Local Data Sources: 本地数据源，MCP 服务可以安全访问的本地文件、数据库和其他服务

  • Remote Services: 远程服务，MCP 服务可以连接的外部系统

需要重点关注的就是 MCP Host、MCP Client 以及 MCP Server 三部分，Local Data Sources、Remote Services 可以看做是 MCP Server 自身实现功能的一部分。

  • MCP Host  就是直接跟用户交互的应用程序，例如 Claude，而 MCP Client 一般是直接集成在 MCP Host 里，这样应用程序既可以和用户交互，也可以调用 MCP Server。

  • MCP Server 就是提供 Resources、Tools、 Prompts 等等功能的服务端,可以简单理解为把 Function Calling 中的函数封装为了服务，满足 MCP 标准从而实现功能复用。

3.4 工作流程

MCP 工作流程和 前面介绍的 Agent、FunctionCalling 类似：

 

mcp-workflow.png

  • 1）MCP client 首先从 MCP server 获取可用的工具列表

  • 2）将用户的 Prompt 连同工具描述一起发送给 LLM

    • 这里是否使用 FunctionCalling 方式传递 tools 信息取决于 client 的实现

    • 如果 Client 使用 System Prompt 模拟方式则不要求模型支持 FunctionCalling

  • 3）LLM 根据 Prompt 决定是否需要使用工具以及使用哪些工具

  • 4）如果需要使用工具，MCP client 会调用 MCP server 以执行相应的工具调用

  • 5）工具调用的结果再次被发送回 LLM

  • 6）LLM 整合所有信息生成最终回答

  • 7）最后将响应展示给用户

MCP Client 一般集成在 MCP Host 中，比如 Claude Desktop，因此就画在一起了。

主要区别在于外部工具信息获取和调用方式上：

  • MCP 协议将外部工具定义为 MCP Server，Client 通过连接 MCP Server 获取支持的 tools 列表，并通过 MCP 协议进行调用

  • 而 FunctionCalling 中，tools 信息是提前配置好的，同时 tools 的调用一般是调用本地 function

因此，可以简单理解为 MCP 就是将 Function Calling 进行了标准化。

3.5 Function Calling 和 MCP 差异

首先 Function Calling 和 MCP 二者都是为了让模型能够调用外部工具，假设将这个过程分为三部分：

  • 1）模型感知 tools 信息

  • 2）模型生成 tool 调用请求

  • 3）调用指定 tool

第一步：模型感知 tools 信息，有多种方法：

  • 可以使用 System Prompt 传递 tools 信息

  • 对于 Function Calling 实现，也是非标准的，例如 OpenAI 的 tools 参数、Claude 的 tool_use 字段

  • MCP 并没有对这一步做特殊限制，主要取决于 MCP Host 的实现， 从 MCP Server 获取到 tools 信息之后，可以使用 Function Calling 告知模型，也可以用别的方式如 System Prompt。

第二步：模型生成 tool 调用请求，这一步其实主要是模型上的差异：

  • 对于不支持 Function Calling 的模型一般是依靠自然语言生成能力在处理这个请求

  • 对于支持 Function Calling 的模型，一般是经过特殊数据集微调的，在处理这种请求上会更加准确

第三步：tool 的调用上也有区别：

  • 对于非 MCP 来说，接收到模型的返回后怎么调用工具就看开发者怎么实现了，可以是直接调用本地 Function，也可以是调用远程 API 都没问题

  • 对于 MCP 来说就是按照 MCP 协议调用 MCP Server

也就是说：

  • MCP 更多的是在定义：MCP Server 怎么对外暴露能力，其他人该怎么调用 MCP Server。

  • Function Calling 更多关注的是：怎么把 tools 信息告知给模型，以及模型如何判断该调用哪个 tool

因此二者其实是互补的关系。

4. A2A

4.1 什么是 A2A

2025 年 4 月 9 日，Google 发布了文章《A2A: A new era of agent interoperability》[5]，提出了一个新的开放协议A2A（Agent-to-Agent），允许 AI Agent 之间在各种企业平台或应用程序上相互通信、安全地交换信息和协调行动。

4 月 10 日，在 Google Cloud Next 2025 大会上，谷歌开源了 Agent2Agent Protocol。

A2A(Agent to Agent) 是一项开放标准，可让不同平台和框架之间的 AI Agent 进行通信和协作，而无需考虑其底层技术。其旨在通过实现真正的多 Agent 场景，最大限度地发挥 A gentic AI 的优势。

A2A 的核心作用是解决 Agent 之间的沟通和协作，以及 Agent 与用户的交互。即 Agent 之间能像人与人交流一样，传递意图、协商任务、共享信息。A2A 使开发人员构建的 Agent，能够连接任何其它的 Agent（基于 A2A 构建），并使用户能够灵活组合来自不同供应商的 Agent。最重要的是，企业可以通过标准化方法管理其跨不同平台和云环境的 Agent。

一句话描述：A2A(Agent to Agent) 是一种开放标准，可让不同平台和框架之间的 AI Agent 进行通信和协作，而无需考虑其底层技术的协议。

英文原文：

An open protocol enabling Agent-to-Agent interoperability, bridging the gap between opaque agentic systems.

4.2 为什么需要 A2A

因为构建一个能解决所有问题的 Agent 很难，或者说基本不可能实现，因此一般选择另一条路：多 Agent 分工协作。

每个 Agent 只需要专注某一方面解决，通过 A2A 让多个不同领域的 Agent 协作解决问题，多个 Agent 构成流水线共同完成某个任务。

怎么有点 MoE 的感觉 😂

Agent 之间通过 A2A 协议通信，Agent 通过 MCP 协议调用外部工具，如下图所示：

 

a2a-arch.png

图源：https://google.github.io/A2A/#a2a-and-mcp-complementary-protocols[6]

4.3 关键原则&核心能力

A2A 在设计时坚持的五个关键原则：

  • Embrace agentic capabilities：拥抱智能体能力，支持自然、非结构化的协作模式。

  • Build on existing standards: 复用现有标准,使用 HTTP、Server-Sent Events (SSE) 和 JSON-RPC，确保与现有系统的兼容性。

  • Secure by default：默认安全，支持企业级认证和授权，启动时与 OpenAPI[7] 保持一致。

  • Support for long-running tasks：支持长期任务，处理从快速任务到深入研究的任务，提供实时反馈、通知和状态更新。

  • Modality agnostic:多模态支持，支持文本、音频、视频流等多模态通信。

协议具体描述在这个仓库：google/A2A[8] 感兴趣的童鞋可以跳转查看

A2A 的核心能力：

 

a2a-core.png

  • Capability discovery：能力发现，Agent 使用 JSON 格式的 'Agent Card' 来暴露自己的能力，其他 Agent 可以根据该信息选择执行任务的最佳 Agent，然后使用 A2A 和目标 Remote Agent 通信。

  • Task management：任务管理，Agent 直接的通信是以完成任务为导向的，任务由协议定义，对于长时间的任务，Agent 之间会通信以保持同步状态。

  • Collaboration：协作，Agent 之间代理可以相互发送消息，以传达 上下文, 回复, 工件或者用户指令。

  • User experience negotiation:用户体验协商，支持不同内容类型（如图像、iframe、视频、网页表单），提供丰富的交互。

4.4 A2A 工作流程

4.4.1 概念

A2A 中比较重要的概念：

  • Agent Card：相当于智能体的"身份证+能力说明书"，用于对外公开自身技能和服务接口。

    • 以 JSON 格式存储在服务器的 /.well-known/agent.json 路径

    • 包含名称、版本、能力描述（如支持的任务类型）、认证方式（API Key/OAuth）、可访问的 HTTP 端点（如任务提交 URL）

  • A2A Client：任务发起方，可以是用户应用或其他智能体。

  • A2A Server：智能体的"任务处理中心"，负责接收请求并协调任务执行。

  • Task：协议中的最小工作单元，代表需要完成的用户需求。

    • 即时任务（如查询天气）：同步返回结果

    • 长期任务（如供应链优化）：通过 SSE 推送实时状态更新

    • 生命周期：包含 6 种状态流转：已提交（Submitted）→ 处理中（Working）→ 需输入（Input-Required）→ 完成/失败/取消

    • 唯一标识：每个 Task 有全局唯一的 ID，支持跨智能体追踪进度

    • 执行模式：

  • Message：智能体间通信的载体，支持多模态交互。

 

a2a-workflow.png

图源：https://google.github.io/A2A/specification/[9]

4.4.2 工作流

流程如下：

 

a2a-workflow2.png

  • 1）发现 Agent：通过 Agent Card，了解智能体的能力。

  • 2）发送任务：客户端发送任务请求：

    • 使用 tasks/send 处理即时任务，返回最终 Task 对象。

    • 使用 tasks/sendSubscribe 处理长期任务，服务器通过 SSE 事件发送更新。

  • 3/4）处理：服务器处理任务，可能涉及流式更新或直接返回结果。

  • 5）交互（可选）：若任务状态为 input-required，客户端可发送更多消息，使用相同 Task ID 提供输入。

  • 6）完成：任务达到终端状态（如 completed、failed 或 canceled）。

4.5 A2A 和 MCP 协作

A2A 社区推荐将 Agent 建模为 MCP 资源(也就是把 Agent Card 存起来)，这样其他 Agent 可以通过 MCP 获取到 Agent Card 从而感知到其他 Agent 的信息。

 

a2a-mcp.png

图源：https://google.github.io/A2A/topics/a2a-and-mcp/#intersection[10]

MCP 解决的是 Agent 与外部工具的标准化连接问题，而 A2A 解决的是 Agent 之间的协作问题，两者共同构成智能体生态的基础协议。

5. 小结

概念：

  • Agent 是一个以 LLM 为基础，结合其他外部工具辅助，最终能够完成复杂任务的实体(工具、助手)。

首先构建一个强大的 Agent 是我们的最终目的，根据 Agent 定义 LLM + 外部工具 = Agent，那么如何让 LLM 调用外部工具呢，FunctionCalling 和 MCP 两条路：

  • FunctionCalling 是一种允许模型通过生成结构化 JSON 输出，以'调用'外部系统中预定义的函数的机制。

  • MCP 是一种开放、标准化的协议，以便大型语言模型能够与外部数据源、工具和服务进行连接。

在构建 Agent 之后，如何让 Agent 更加强大呢，除了构建单个强大的 Agent 之外，我们可以让多个 Agent 进行协作，复用其他 Agent 的能力：

  • A2A(Agent to Agent) 是一种开放标准，可让不同平台和框架之间的 AI Agent 进行通信和协作，而无需考虑其底层技术的协议。

个人理解：

  • LLM 是一切的基础

  • Agent 是我们要实现的目标，一个能够解决复杂任务的助手

  • 为了能够解决复杂问题，Agent 需要在 LLM 基础上结合其他外部工具的辅助

  • FunctionCalling 是 LLM 调用外部工具的一种实现手段

  • MCP 则可以看做是这种手段的标准化

  • LLM + FunctionCalling 或者 MCP 我们实现了一个强大的 Agent

  • 但是想要构建一个六边形战士很难，因此我们让每个 Agent 只需要专注某一方面，通过 A2A 让多个不同领域的 Agent 协作解决问题

 

# 人工智能 # 改行学it # 语言模型 # 机器学习 # 深度学习
Logo
MCP技术社区

欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！

更多推荐

cover

人工智能-基础篇-27-模型上下文协议--MCP到底怎么理解？对比HTTP的区别？

avatar MCP技术社区
cover

MCP新手图文指南：轻松实现AI与您的数据和工具无缝对接

avatar MCP技术社区
cover

让你的 AI 更聪明，这 7 个开源 MCP 项目不要错过

avatar MCP技术社区