本文是 T 系列的第 00 篇，主要介绍下一代 Chatbot：MCP 扩展对话。

T 系列为技术文章翻译系列，加以本人的一些拙见，如有雷同，实属正常，如有不同，欢迎交流。

现代对话式人工智能的格局正朝着能够执行复杂、多轮任务的应用方向发展。这要求系统不仅限于简单的对话管理，而是需要能够与外部数据源和专业工具实现无缝交互。传统方法往往依赖脆弱的提示工程，难以扩展和维护。本文介绍“模型上下文协议”（MCP），作为构建下一代聊天机器人的基础框架。通过支持与外部工具进行结构化、多轮的交互，MCP 取代了传统的基于提示的临时性解决方案，采用了一种稳健且明确的智能体-工具逻辑。本系列将深入探讨 MCP 的架构设计、实现方式及实际应用场景，为开发者和研究人员提供技术层面的深度解析。

MCP 为 LLM 提供了获取外部数据和执行外部工具的能力，使 LLM 不再局限于简单的提示词，而是基于工具上下文进行复杂的对话交互。

传统 Chatbot 架构的局限性

常见的 Chatbot 架构，尤其是基于大语言模型（LLMs）构建的系统，通常采用临时提示增强或函数调用等技术与工具进行交互。尽管这些方法具备一定的功能，但受到若干关键缺陷的制约。

临时提示增强：系统通过预定义的提示词扩展 LLM 的理解能力，或改写/扩展用户的输入和模型的输出，通常收敛于特定问题、时效性和通用性相对较弱。

1. 依赖脆弱的提示工程，使得这些系统容易受到用户输入或模型输出微小变化的影响。设计能够可靠地指导模型使用特定工具并提供正确参数的提示是一项具有挑战性且易出问题的工作。这可能导致意外故障，并使系统难以泛化。
2. 缺乏对工具交互的明确状态管理，难以在涉及工具使用的多轮对话中保持上下文的一致性。如果聊天机器人需要先使用一个工具获取数据，再利用这些数据通过另一个工具执行操作，那么在基于提示的系统中管理这种依赖关系和数据流动就会变得复杂且容易出错。
3. 有限的可观测性和调试能力会阻碍开发和维护，Agent 推理与工具交互逻辑之间缺乏明确的分离，使得难以判断问题是由模型误解还是工具调用错误引起的。
4. 可扩展性和可重用性常常受到牺牲，嵌入提示中的工具逻辑通常与特定使用场景紧密耦合。在不同 Agent 或应用程序之间重用这些集成需要进行大量重构，从而阻碍了模块化和平台开发。

上述 4 点的根因在于 LLMs 过度依赖有限的提示词工程，对状态管理、可观测性、调试能力、可扩展性和复用性造成影响。

这些局限性凸显了需要采取更加系统化和原则性的工具集成方法，而 MCP 通过为管理代理与工具之间的交互提供清晰的框架，实现了这一目标。

引入 MCP 只能部分消除传统 Chatbot 架构的局限性，如局限性 1（外部数据源扩展了提示词语）、局限性 3（通过工具结果理解 LLMs 的推理行为）。对于局限性 2，状态管理不应该由 MCP 来解决，而是应该由专门的状态管理机制来处理；对于局限性 4，MCP 仍无法解决可扩展性的问题，需要在系统层面进行处理（明确系统的几个特定意图，而非大而全，为了普适而普适）。

工具支持的新 Chatbot 架构

MCP 从根本上改变了我们设计 Chatbot 架构的方式。它将工具上下文定义为对话中的一个专用空间，用于管理工具交互的状态。这使交互从非结构化的提示转向了明确且结构化的协议。

MCP 为 LLMs 引入了新的上下文：工具上下文。

MCP 框架中的关键概念包括：

• Agent：调用实体，通常是大语言模型（LLM），用于推理何时以及如何使用外部工具。
• 工具：Agent 可调用的外部资源（例如 API、数据库或函数），以执行特定任务。
• 工具调用：Agent 向工具发出的结构化请求，包含操作和参数。
• 工具结果：工具返回的结构化输出。
• 工具上下文：存储对话中所有工具交互历史与状态的数据结构。

Agent 是调用工具的实体，将工具调用的结构化结果作为 LLM 的上下文。

核心原则是将工具相关的逻辑外部化。MCP 通过形式化流程，而非通过提示隐式指示 Agent。当 Agent 确定需要使用某个工具时，它会生成一个结构化的工具调用（Tool Call）。MCP 框架执行该调用，生成的工具结果则存储在工具上下文中。Agent 随后可在后续回合中引用该上下文，以构建回应或发起新的工具调用。这一过程使基于工具的工作流变得透明且可审计。

这种方法具有显著优势：通过显式指令提高可靠性，借助专用的工具上下文实现更好的状态管理，并通过将工具逻辑抽象为明确的组件来提升可重用性。

工作过程

为了说明 MCP 的工作过程，考虑一个监控大 A 行情的 Chatbot。MCP 流程将按以下方式进行：

1. 用户输入：用户说：“美的集团今天股价多少？”
2. Agent 分析：Agent 利用其推理能力，识别出此请求需要一个工具。它确定了“stock_api”工具的“get_stock_code”和“get_stock_price”操作。
3. 工具调用生成：Agent 生成一个结构化的工具调用对象。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

const toolCall = {
  tool_name: "stock_api",
  action: "get_stock_code",
  parameters: {
    name: "美的集团"
  }
};
const toolCall2 = {
  tool_name: "stock_api",
  action: "get_stock_price",
  parameters: {
    code: ["000333"]
  }
};

4. 工具调用：MCP 框架接收工具调用对象，并使用指定参数调用 stock_api。
5. 工具执行：API 执行搜索并返回一个工具结果。

1
2
3
4
5
6
7
8

const toolResult = {
  status: "success",
  code: "000333"
};
const toolResult2 = {
  status: "success",
  price: "83.14"
};

6. 工具结果存储：此工具结果将被添加到工具上下文中。Agent 现在可以访问该结果以制定下一步操作。
7. Agent 回复生成：Agent 使用工具上下文中的工具结果来向用户反馈信息。

工具上下文现在保存了此次交互的历史记录，使代理能够使用得到的股票代码并继续对话。这种明确且分步的过程与单一的提示式方法有本质区别，正是这一点赋予了 MCP 强大的功能和可靠性。

看到这里，我明白了为什么作者说 MCP 提供了状态管理的功能。是因为 MCP 框架需要把多个工具调用的结果作为 LLM 的上下文，这样才能保证 LLM 的推理结果是正确的。这里留一个坑位，研究一下 FastMCP 框架中的状态管理机制，后续另开一篇。

有感而发

MCP 标志着向构建更强大、更易于维护的对话式人工智能系统迈出关键一步。通过规范化代理与工具之间的交互，它解决了基于提示的启发式方法所面临的诸多痛点。专用的工具上下文是一种尤为强大的抽象机制，能够为复杂的流程提供清晰的审计日志和状态管理。

与 LangChain 或 ReAct 等框架相比，MCP 提供了一种更具倾向性和结构化的方法。虽然 ReAct（推理与行动）是一种将推理与工具使用相结合的模式，但其仍往往依赖模型生成整个思维过程和工具调用的单一、非结构化输出。相比之下，MCP 通过将工具调用作为显式的、机器可读的对象来分离这些关注点。这种分离增强了系统的可靠性，并使系统更易于调试和扩展。尽管 LangChain 通过其工具和 Agent 提供了类似的功能，但 MCP 可被视为一种更为基础的协议，而非特定的库实现。它为一种清晰、解耦的架构提供了蓝图。

我相信 MCP 对于构建复杂、以任务为导向的助手至关重要。这标志着一种范式转变，即将大语言模型视为唯一的协调者，转变为被视为在明确且结构化的协议框架内运行的推理引擎。

MCP 的主要功能是给大语言模型插上“连接万物”的翅膀，让它能够与外部系统进行交互，其核心是标准化工具调用的范式。