从对话到操作

最开始，大模型更多像一个“会聊天、会写字、会回答问题”的系统。用户问它一个问题，它返回一段文字；用户让它解释、总结、翻译，它也主要是在对话框里完成回应。但随着使用场景越来越复杂，人们很快发现，很多需求并不只是“得到一个回答”就够了，而是希望模型把事情继续往下做。比如，不只是告诉你某份文件可能有问题，而是直接去读取文件内容；不只是帮你规划待办，而是进一步创建提醒、查询日历、调用外部服务。于是，大模型的角色开始从“对话”走向“操作”。

大模型之所以能够从“对话”走向“操作”，本质上是因为它开始接入外部工具与系统。也就是说，模型不再只是围绕用户输入生成一段文字，而是能够在理解任务之后，进一步调用函数、接口、数据库或应用服务来完成具体动作。在这个过程中，模型负责理解用户意图、判断任务目标，并决定是否需要借助外部能力；如果需要，它就会按照约定的方式发起调用，获取结果后再结合这些信息继续生成回应。这样一来，大模型的能力边界就从单纯的文本生成，逐渐扩展到了对现实任务流程的参与和推动。

统一转接口

当大模型开始真正接入外部工具时，事情就不再只是“让它调一次接口”这么简单了。因为搜索、文件、数据库、业务服务这些能力，本来就来自不同系统，它们各自的接入方式、参数结构和返回结果都不一样。工具少的时候，这种差异还可以靠手工适配解决；但工具一多，开发者就不得不反复为不同系统编写连接逻辑。表面上看，模型都是在“调用工具”，实际上却是在面对一组彼此不统一、难以复用的接口。MCP 正是在这样的背景下被提出的。官方将它定义为一种把 AI 应用连接到外部系统的开放标准，用来让模型能够访问数据源、调用工具并参与工作流。

你可以把 MCP 理解成一层统一转接口，但它的意义并不只是“多加了一个中间层”。按照官方架构，MCP 采用 host、client、server 的分层方式：host 是承载模型的 AI 应用，client 是 host 内部负责与某个 MCP server 建立连接的组件，server 则按统一规则暴露能力。协议的数据层建立在 JSON-RPC 之上，也就是用统一的远程调用消息格式来传递请求与结果；在这套规则里，server 可以暴露 tool（工具）、resource（资源）、prompt 等能力，客户端再按统一方式去发现、读取和调用它们。这样一来，模型在接入不同外部系统时，就不必每次都重新适配一套私有接口。

也正因为如此，MCP 的价值不只是“让模型能调工具”，而是让模型连接外部世界这件事第一次有了较统一的公共规则。过去，不同工具往往各说各话，模型每扩展一种能力，就可能多出一套新的对接方式；而在 MCP 之下，外部能力开始被放到同一种协议框架里描述，模型、客户端和服务端之间的协作也因此更容易复用和扩展。OpenAI 的 Apps SDK（应用开发工具包）也明确把 MCP server 作为连接 ChatGPT 与外部能力的基础层：MCP server 负责定义应用可用的能力，必要时还可以配合界面组件一起工作。换句话说，MCP 并不是在已有工具之外再增加一个工具，而是在为“模型如何使用工具”建立一套更统一的转接规则。只有这层规则逐渐稳定下来，大模型从“会对话”走向“能操作”，才真正具备持续扩展的基础。