LLM Agent 概念地图：ReAct、Tool Use、Function Calling 与 MCP

这些概念经常出现在同一张 Agent 架构图里，却不属于同一个层次。最容易记住的区分是：

这不是严格的行业分层标准，而是一张实用的工程地图。不同厂商和论文对 Agent 的边界并不完全一致，因此比背定义更重要的是看清：模型输出了什么、谁执行了操作、结果如何返回，以及哪一层负责授权。

Agent：围绕目标运行的闭环

在 LLM 应用语境中，可以把 Agent 理解为一个允许模型根据当前状态选择下一步行动，并根据结果继续工作的闭环系统。典型组成包括：

• 模型：理解任务并提出下一步；
• 运行时：维护消息、状态、预算和循环；
• 工具：搜索、读文件、调用 API 或执行代码；
• 环境反馈：工具结果、错误和用户输入；
• 控制边界：权限、确认、超时、重试和停止条件。

最小循环可以写成：

读取目标与当前状态
        ↓
模型返回回答，或提出工具调用
        ↓
运行时校验权限并执行允许的操作
        ↓
把结果或错误加入上下文
        ↓
继续循环，直到完成、失败或达到停止条件

模型是关键决策组件，但模型本身不会自动获得文件系统、网络或数据库权限。那些能力由运行时提供。反过来，只有固定分支的自动化流程也不一定需要称为 Agent；是否使用这个名称，通常取决于模型在选择行动和适应反馈时拥有多大自主性。

ReAct：一种推理与行动交替的范式

ReAct 来自 2022 年提出、后发表于 ICLR 2023 的论文《ReAct: Synergizing Reasoning and Acting in Language Models》。原论文让模型交替生成语言推理轨迹、任务行动和环境观察：

Thought → Action → Observation → Thought → … → Answer

它与只在已有上下文中推导答案的 Chain-of-Thought（CoT）相比，多了与外部环境交互并根据观察修正路径的能力。例如，模型可以先搜索一个事实，读取结果，再决定下一次检索，而不是一次性凭参数中的记忆作答。

不过需要区分论文范式与现代实现：

• ReAct 描述的是“推理指导行动、观察反过来更新决策”的循环；
• Agent 可以采用 ReAct，也可以使用规划器、状态机、策略模型或其他控制方式；
• 现代推理模型不一定向应用暴露完整内部思维链；
• 应用真正需要记录的是行动、参数、结果、来源、权限决策和简洁理由，而不是依赖不可验证的长篇“思考过程”。

因此，今天说一个系统是“ReAct 风格”，通常意味着它具备可观察的行动—反馈循环，不应推导为“必须打印完整 Thought”。

Tool Use：借助外部能力完成任务

Tool Use 是最宽泛的概念：模型或应用在生成最终结果的过程中使用了模型参数之外的能力，例如：

• 搜索网页或私有知识库；
• 查询数据库和业务 API；
• 读取、修改文件；
• 运行计算器或代码解释器；
• 操作浏览器、设备或其他应用。

是否由模型选择工具需要单独说明：

• 模型主导：模型根据工具描述决定调用哪个工具和参数；
• 程序主导：业务代码先按固定规则查询数据，再把结果交给模型；
• 混合模式：程序限制候选工具、调用次数和权限，模型在边界内选择。

后两种也利用了外部工具，但只有模型参与选择时，才适合说模型具备 Tool Use 能力。这个区分有助于判断系统的可控性和测试边界。

Function Calling：一次结构化调用请求

Function Calling 是模型 API 提供的一类结构化工具接口。应用先向模型提供工具名称、说明和输入 Schema；模型需要工具时返回类似这样的调用请求：

{
  "name": "get_weather",
  "arguments": {
    "city": "Shanghai"
  }
}

对于应用自定义函数，常见生命周期是：

1. 应用把可用函数定义提供给模型；
2. 模型返回函数名和参数，而不是函数的真实执行结果；
3. 应用校验 Schema、权限和业务约束；
4. 应用代码执行函数；
5. 应用把结果与对应调用 ID 返回给模型；
6. 模型生成答案，或提出下一次调用。

所以，自定义 Function Calling 通常不等于“模型生成并执行代码”。模型提出结构化意图，宿主应用决定是否执行。某些平台还提供网页搜索、文件搜索和代码解释器等内置工具，这类工具可以由平台托管执行，不能一概说都由业务应用进程执行。

结构化参数也不等于安全。运行时仍需处理：

• 参数 Schema 和业务语义校验；
• 用户身份、数据范围和最小权限；
• 写入、删除、付费等副作用确认；
• 超时、重试、幂等和调用预算；
• 工具结果中的提示注入与不可信内容。

Function Calling 解决“如何表达调用”，不负责证明这次调用应当获准。

MCP：应用与能力提供方之间的协议

MCP（Model Context Protocol）是连接 AI 应用与外部能力提供方的开放协议。工程上常见的角色是：

• Host：面向用户的 AI 应用，负责模型集成、安全策略和用户授权；
• Client：由 Host 管理，与特定 MCP Server 通信；
• Server：通过协议暴露工具、资源、提示模板等能力。

MCP 不只是“工具调用格式”。它定义了应用如何发现、描述和调用能力，以及双方如何交换协议消息。其核心能力可以包括：

MCP 仍在演进，实施时必须标明目标协议版本。以 2026-07-28 版本为例，协议核心转向无会话设计，请求携带版本和客户端能力信息；旧版本中常见的初始化握手和协议级 Session 已被移除。不要把某一版 SDK 示例当成永远不变的协议定义。

MCP 与 Function Calling 如何配合

二者经常协作，但不存在“MCP 必须通过 Function Calling 才能工作”的协议要求。

一种常见实现是：

MCP Server 暴露工具
        ↓
Host / MCP Client 获取工具定义
        ↓
Host 转换成模型 API 支持的工具 Schema
        ↓
模型返回 function/tool call
        ↓
Host 做授权与参数校验
        ↓
MCP Client 发送 tools/call
        ↓
MCP Server 执行并返回结果
        ↓
Host 把结果交还模型

这里有两套相邻但不同的接口：

• 模型 API 的 Function Calling，连接“模型”和“Host”；
• MCP，连接“Host / Client”和“MCP Server”。

Host 负责在两者之间适配。它也可以不用厂商的 Function Calling，而通过受约束文本、框架自定义调用对象或确定性程序触发 MCP 请求。反过来，Function Calling 也可以直接调用本地函数或普通 HTTP API，完全不经过 MCP。

MCP 出现前，工具是怎样接入的

MCP 没有发明 Tool Use。此前常见方案包括：

• 解析 Action: Search[...] 一类约定文本；
• 使用模型厂商提供的函数或工具调用接口；
• 为每个 REST API 编写专用适配器；
• 使用 OpenAPI、插件 Manifest 或框架自己的 Tool 抽象；
• 由业务代码按固定规则调用工具。

这些方案可以正常工作，主要问题是不同应用、模型平台和框架之间的描述、发现、传输和授权集成往往不能直接复用。MCP 的价值在于建立可互操作的接入边界，而不是让工具调用第一次成为可能。

一次调用中每层分别负责什么

假设用户问：“查我的项目文档，再告诉我当前最重要的风险。”

1. Agent 运行时维护目标、上下文、预算和停止条件。
2. 决策循环判断先检索项目资料；它可能是 ReAct 风格，但不必展示完整思维链。
3. 模型工具接口返回结构化的 search_docs 调用请求。
4. Host确认当前用户可以访问目标项目，并限制查询范围。
5. MCP Client向文档 Server 发起协议调用。
6. MCP Server检索文档并返回带来源的结果。
7. Host把结果标记为不可信资料后交给模型。
8. 模型基于证据回答；若证据不足，继续检索或明确保留不确定性。

这条链路说明，可靠性来自多层共同约束。模型会选工具，不代表它拥有执行权限；协议能连接工具，也不代表工具值得信任。

最容易混淆的五句话

• “使用 ReAct 就必须展示完整思维链”——不对。现代系统可以保留行动和简洁理由，而不暴露原始内部推理。
• “Function Calling 会执行函数”——不完整。自定义函数通常由应用执行，平台内置工具可能由平台执行。
• “MCP 是 Function Calling 的新名字”——不对。一个是接入协议，一个是模型调用接口。
• “有 MCP 就自动安全”——不对。Host 仍需负责授权、确认、数据边界和结果验证。
• “没有 MCP 就不能做 Agent”——不对。MCP 提升互操作性，不是 Agent 或 Tool Use 的前置条件。

一句话总结：Agent 是完成目标的闭环系统，ReAct 是可选的决策—行动范式，Tool Use 描述外部能力的使用，Function Calling 表达模型侧的一次结构化调用，而 MCP 标准化 Host 与能力提供方之间的连接。

参考资料：ReAct 论文、OpenAI Function Calling、OpenAI Reasoning Models、MCP 2026-07-28 版本说明