LLM与外部世界的交互演进：Function Call, MCP, A2A 技术与理念分析

LLM的局限性与Function Calling的出现

随着训练数据的不断扩展和训练方法的持续优化，LLM 的推理能力越来越强大。但是，这种能力的增强也带来了一个不可忽视的问题：如何让这些预训练的LLM与现实世界进行交互，获取最新的数据和信息？可以说，这成为了限制LLM应用潜力的一个瓶颈。

想象一下，无论模型有多么博学，它也无法得知"今天深圳的天气如何？"或是直接帮你"预定明晚飞往上海的机票"。由于LLM的知识仅限于训练数据的截止日期，它无法感知实时信息，也不能主动触发外部世界的任何变化。

为了突破这一局限，OpenAI在2023年率先推出了Function Calling功能。通过这个功能，开发者可以定义外部工具或API，LLM可以在理解用户意图的基础上，智能地判断何时需要调用这些外部工具，并生成结构化的调用请求，从而间接实现与现实世界数据和服务的连接。

下面是一个简单的示例：

import json

# 1. 定义实际执行任务的函数 (我们的工具)
def get_current_weather(location: str):
    """模拟获取指定地点的当前天气"""
    print(f"--- [执行工具] 正在查询 '{location}' 的天气... ---")
    if "shenzhen" in location.lower():
        return json.dumps({
            "location": location,
            "temperature": "26",
            "condition": "多云",
            "unit": "Celsius"
        })
    else:
        return json.dumps({"location": location, "error": "Location not found"})

# 2. 用户提问
user_query = "深圳今天天气怎么样？"
print(f"用户: {user_query}")

# 3. 模拟 LLM 分析用户意图后，决定需要调用函数
print("\n--- LLM 分析后，决定调用函数 ---")
llm_thinks_call_this = {
    "function_name": "get_current_weather",
    "function_args_str": '{"location": "Shenzhen"}' 
}
print(f"LLM 意图: 调用函数 '{llm_thinks_call_this['function_name']}'")
print(f"LLM 提取的参数: {llm_thinks_call_this['function_args_str']}")

# 4. 应用程序根据 LLM 的意图，执行本地函数
function_to_run = llm_thinks_call_this['function_name']
args_str = llm_thinks_call_this['function_args_str']

if function_to_run == "get_current_weather":
    args_dict = json.loads(args_str)
    try:
        weather_result_str = get_current_weather(**args_dict)
        print(f"--- 函数执行结果: {weather_result_str} ---")

        # 5. LLM 收到函数结果，生成最终回复
        print("\n--- LLM 收到函数结果，生成最终回复 ---")
        weather_data = json.loads(weather_result_str)
        final_response = f"查询到深圳当前天气为 {weather_data['temperature']}°C，天气状况是{weather_data['condition']}。"
        print(f"LLM: {final_response}")

    except Exception as e:
        print(f"[错误] 函数执行失败: {e}")
        print("LLM: 抱歉，我现在无法获取天气信息。")
else:
    print("LLM: 我可以直接回答或无法处理该请求。")

显而易见，Function Calling功能的推出，标志着LLM从一个纯粹的文本生成工具，转变为能够与外部世界进行交互的智能代理，这是LLM发展的一个重要里程碑。但与此同时，这也给开发者带来了新挑战。在开发具体的AI应用时，开发者不仅要从不同的LLM（M） 中选择合适的模型，还需要集成各种外部工具（N） 。这就形成了一个复杂的 "M x N"集成矩阵。更为麻烦的是，不同的LLM可能有不同的工具调用协议和接口标准，因此每种LLM与工具的组合都可能需要单独的适配工作。这大大增加了系统开发的复杂度和成本，也使得开发出的工具很难在不同系统间复用。

Anthropic推出MCP：通过标准化解决M x N的复杂度问题

虽然Function Calling能力让LLM与外部世界的交互成为可能，但它也显著增加了工程实现的复杂度。开发者面临的挑战是如何管理'M'种不同的LLM与'N'种潜在工具的组合问题。如何有效地管理和扩展这种交互能力，避免为每一对(LLM, 工具)组合进行繁琐的定制化适配，成了亟待解决的工程问题。

从工程实践的角度看，要解决这种'M x N'的复杂度，理想的方案应该借鉴成熟的软件生态管理模式。我们可以思考一下，为什么现代软件开发如此高效？以大家熟悉的npm（Node Package Manager）为例，npm能够大大简化开发者集成和复用第三方库（也可以类比成这里的"工具"）的过程，原因就在于它提供了：

• 标准化的包描述 (package.json)： 它定义了包的名字、版本、依赖关系等元数据，确保了每个"工具"有统一的身份标识和使用说明。这类似于我们所需要的统一的工具定义标准。
• 中央仓库与发现机制 (npm install)： 它提供了一个集中式平台，方便发布、查找和获取这些标准化的工具，解决了"去哪里找工具"的问题。这就像是我们所需要的标准工具发现协议。
• 标准化的加载与调用接口 (require/import)： Node.js环境提供了统一的方式来引入和使用包的功能，屏蔽了底层实现的差异。这也对应着我们所需要的标准的工具通信与交互方案。

正是这些标准化的范式、协议和机制，将原本可能是M x N的复杂集成问题有效解耦和简化。而Anthropic推出的MCP（Model Context Protocol）正是沿着类似的思路，通过一套标准化的上下文协议，为AI应用与外部系统的交互提供了通用方式。它是如何实现的呢？我们可以先从MCP的整体设计架构入手。官方的架构图比较复杂，我重新整理了一下，帮助大家更好理解它的设计理念（具体协议细节我们暂时不展开，避免干扰主线理解）：

从图中可以看到，MCP所打造的一致性模型上下文协议，主要体现在三个方面：

1. MCP Client： 负责与MCP服务器进行连接、发现工具、处理工具调用，并将最终结果反馈给用户。任何实现了MCP Protocol（Client）协议的应用，都可以作为MCP客户端程序。
2. MCP Server： 负责工具的集成，并通过MCP Protocol（Server）协议向MCP Client暴露特定功能，提供工具调用能力。MCP Server可以在本地（与MCP Client同一台设备上）运行，也可以通过互联网运行在远程服务器上。
3. Transport Layer： 定义了MCP Client如何与MCP Server进行通信的协议细节。如果是本地MCP Server，MCP Client会启动MCP Server作为子进程，并通过标准输入输出进行跨进程通信（客户端写入服务器的STDIN，服务器通过STDOUT响应，消息格式为JSON-RPC 2.0）。如果是远程MCP Server，则通过HTTP协议远程连接，支持SSE进行流式传输，这部分大家应该很熟悉，就不再详细讲解。

通过以上设计可以看出，任何通过MCP Protocol (Client)实现的标准MCP客户端，都可以通过MCP Protocol（Transport Layer）发现并调用MCP Protocol（Server）实现的工具。我们再来看文章第一部分中提到的问题通过MCP来实现时的方案：

此时，通过标准的模型上下文协议，任意一个MCP Client都可以与任意一个MCP Server进行连接，并调用其上的一系列功能。M x N的问题得到了有效的解决。

了解了MCP的核心设计理念后，我们再深入一下细节。MCP本质上是通过一套标准化的方式，让MCP Client能够发现并使用MCP Server上与外部世界交互的工具。从这个角度来看，MCP Server至少需要提供给MCP Client两个接口：list_tools（列出自己有哪些工具以及它们的用途）和call_tool（调用指定的工具）。

上图是我在Cursor（MCP Client）中配置的Blender MCP Server，这样我就可以通过自然语言与Cursor Agent进行交互，在Blender中创建3D模型。可以看到，当Blender MCP Server配置并成功连接后，MCP Client就能通过Server提供的list_tools接口获取到所有可用工具。接下来，当我在Cursor Agent下请求"帮我创建一个太空飞船的3D模型"时，MCP Client是如何选择调用哪个工具来完成任务的呢？

从源码分析可以看出，MCP Client选择调用哪个工具，实际上还是通过Function Calling的能力。换句话说，MCP的工具调用准确性，归根结底还是依赖于Function Calling的准确性优化。这其中有三个关键因素： 工具细节描述的完整度、提问信息的完善度，以及LLM对Function Calling的支持度。前两个因素是工程层面的优化，而最后一个因素则关系到LLM的能力。随着各大LLM纷纷宣布支持MCP，它们对于标准Prompt模板下的Function Calling指令的遵循能力也不断得到增强。LLM在返回给MCP Client需要调用的工具后，接下来就能通过MCP Server提供的call_tool接口，准确地调用相应的工具。

更进一步：从LLM与工具之间的标准化互动到Agent之间的标准化互动

MCP极大地扩展了单个LLM的能力，让它能够更好地接入现实世界的数据和服务。但这主要解决了 "LLM - 工具" 层面的互动标准化问题，目标是增强单一智能核心的背景知识和可执行能力。

然而，随着技术的进步，尤其是进入被许多人称为 "Agent元年" 的2025年，行业的焦点开始转向更高层次的抽象------智能体（Agent）。开发者们不再满足于构建一个"博学"的LLM或简单的工具调用，而是致力于开发能够自主感知、规划、记忆并执行复杂任务序列的独立或半独立Agent。此时，一个新的挑战浮现出来：这些功能各异、可能由不同团队甚至不同公司开发的Agent，如何能够有效地相互发现、沟通和协作，形成一个协同演化的智能生态？

在这样的背景下，标准化再次成为关键。如果说MCP关注的是如何让LLM标准化地"使用工具"，那么下一步，自然就是如何让Agent之间标准化地"相互调用"。顺应这一趋势，Google推出了促进Agent间互操作性的框架（Agent-to-Agent, A2A）。A2A框架的核心目标是打破Agent孤岛，让它们像现代微服务架构中的服务一样，能够相互发现、理解对方的能力，并以一种可靠、规范的方式进行调用与协作。它的设计哲学借鉴了成熟的分布式系统理念，采用标准的客户端-服务器（Client-Server） 架构模式。

为了实现Agent间的顺畅互动，A2A框架需要解决两个核心的标准化问题，这些问题和我们在讨论LLM-工具交互时的关注点类似，但这次应用到的是Agent层面：

1. 能力发现（Discovery）： 一个Agent如何知道网络中存在哪些其他Agent？它如何了解这些Agent具备哪些能力？
2. 任务调用（Invocation）： 当Agent A发现了具备所需能力的Agent B后，它应该如何规范地向Agent B发出请求，委托其执行任务，并能够有效地跟踪任务状态和获取结果？

A2A之能力发现：Agent的"数字名片"

为了解决发现问题，A2A框架引入了 "Agent名片"（Agent Card） 的概念。这本质上是一种标准化的元数据描述文件，每个Agent都会发布自己的"名片"，让其他Agent能够查询和理解。这张"名片"通常包含以下关键信息：

• 名称与描述： Agent的易懂名称和它能够提供的服务或任务的简要介绍。

• 能力清单： 这是核心部分，结构化列出该Agent提供的服务或能执行的任务类型。每个能力项可能包含：

  • 能力名称（如 image_generation，flight_booking）
  • 输入参数规范（如：图像描述文本、出行日期和目的地）。
  • 输出结果规范（如：返回的结果数据格式）。

• 服务接入点（Endpoint）： Agent监听请求的网络地址和通信协议。

• 认证方式： 如何安全地与此Agent建立连接。

下图是Google Maps Agent提供的一个标准Agent名片示例：

有了名片后，当前Agent如何找到另一个Agent的名片呢？A2A推荐将Agent Card托管在Agent服务的基础URL下的一个 熟知位置（Well-Known URI），比如：https:///.well-known/agent.json。这与许多Web标准的做法类似。Client（Agent A）可以通过DNS找到Agent B的服务器，然后发送HTTP GET请求到这个熟知路径来获取Agent Card。

## 官方Demo中获取Agent名片的方法
def get_agent_card(remote_agent_address: str) -> AgentCard:
  """获取Agent名片"""
  agent_card = requests.get(
      f"http://{remote_agent_address}/.well-known/agent.json"
  )
  return AgentCard(**agent_card.json())

一旦获取到名片后，Agent A就能解析名片内容，判断某个Agent是否拥有自己需要的能力，并找到如何调用它。当A2A生态逐渐扩大时，预计会出现一个成熟的Agent市场，方便各个Agent之间进行交换和合作。

A2A 之任务调用：标准化的 Task 与异步协作

解决了"找谁做"的问题之后，接下来的挑战是如何"让它做"。为了解决这个问题，A2A框架定义了标准化的交互单元------"任务"（Task）。当Agent A（客户端）需要Agent B（服务器）执行某项任务时，它会构建一个符合A2A协议规范的Task请求对象，并将其发送到Agent B的服务接入点。

一个标准的Task结构大致如下：

interface Task {
  id: string; // 任务的唯一标识符，用于后续引用该任务
  sessionId: string; // client生成的会话ID，支持将多个相关任务归属于同一会话
  status: TaskStatus; // 任务状态，由Agent Server维护（已提交、进行中、待用户输入、完成、取消、失败、未知）
  history?: Message[]; // 消息记录，A2A中信息的核心承载结构
  artifacts?: Artifact[]; // 任务执行过程中或完成后生成的结果数据
  metadata?: Record<string, any>; // 扩展数据，允许自定义任务信息
}

Agent A（客户端）获取到Agent B（服务器）的Agent名片后，首先解析出Agent B的能力集合和各个能力的连接方式。接着，Agent A将调用信息（首先生成一个task id，然后将Query填充到Message中）封装成Task结构，最后通过A2A的标准协议发起任务请求。在这个过程中，Client和Server之间可以多次进行通信、交换信息、以及管理任务状态。

上述流程主要聚焦于同步通信。A2A框架的另一个核心优势是它支持异步通信 。Agent A在发送Task请求后，无需阻塞等待Agent B完成任务，它可以继续处理其他事务。Agent B会在后台异步地处理任务。异步非阻塞的模式对于构建能够处理长时间运行任务、松耦合的系统和可扩展的Agent生态系统至关重要。为了高效传递异步结果并同步任务状态，A2A框架支持两种主要的通信机制： 流式传输（SSE）和 推送通知，他们分别有各自的应用场景，比如SSE适合长文本的分块回传或执行一个多步骤任务时的实时状态通知，而推送通知则适合极长时间运行的任务或者Agent Client可能离线的场景。

总的来说，A2A框架通过为Agent的能力发现（"名片"）和任务调用（支持状态和异步处理的"Task"）提供标准化协议，让我们能够构建一个更加灵活、可扩展的Agent生态系统。开发者可以专注于打造各自擅长的Agent，同时还可以轻松调用其他Agent的能力，大家一起合作完成那些单个Agent无法独立完成的复杂任务。这标志着我们从单一智能体的提升，迈向了一个由多个智能体协作组成的新阶段。

LLM 交互演进的思考：从连接、规范到协同

回顾文章之前讨论的内容，LLM乃至Agent与外部世界及彼此之间的交互方式，正沿着一条清晰的技术路快速演进。

• 第一阶段：打破LLM的知识壁垒，实现基础「连接」
• 第二阶段：建立工具集成规范，追求高效「集成」
• 第三阶段：超越个体（Agent），探索群体「协同」

归根结底，LLM 和 Agent 交互方式的持续演进，正是我们不断探索如何让 AI 更好地融入现实世界，更有效地解决复杂问题，并最终构建一个更强大、更智能、更具协作性的未来的体现。每一步的进展，都是我们朝着通用人工智能的目标迈出的坚实一步。