我们知道，获取到的大模型原始文件只是由海量参数构成的静态权重数据，本身并不具备独立运行的能力。要让模型真正落地可用，必须将这些权重加载到计算环境中，并搭配推理引擎，才能对外提供输出内容的服务。这类服务既可以部署在本地设备，也可以搭建在远程服务器上，通过对外开放的 API 接口与用户进行交互。

为了更便捷地与大模型交互，我们通常会借助 Cherry Studio 这类第三方 AI 客户端。它通过调用云端模型 API 或本地模型 API，自动完成接口请求、指令传输、结果解析和界面渲染，大幅降低了普通人使用大模型的门槛。

1. 先天局限

在实际使用过程中，我们很快会遇到一个明显的瓶颈：让大模型写诗、写文案、做创作，它总能表现得游刃有余。但一旦询问：明天北京的天气如何？这类实时性问题，或者要求它总结 D 盘下的 README.md 文件内筒，模型要么答非所问，要么凭空编造出看似合理却完全错误的内容。

究其根源，大语言模型的核心能力仅限于接收文本、输出文本，它天生不具备联网功能，也没有本地文件读写权限，更无法直接操作系统硬件。它本质上是一个封闭的静态知识系统，完全不具备处理外部实时信息或本地资源的能力。正因如此，当问题超出其训练数据覆盖范围时，模型便会频繁产生幻觉，即编造并不存在的信息来填补认知空白。

大模型本身只是个会聊天的书呆子，只会根据已有知识生成文本，既上不了网，也读不了本地文件。

2. 函数调用

这一局限该如何突破？

目前的做法就是，预先封装好各类实用工具（如天气查询、本地文件读取、文档解析等函数），并将这些工具的功能描述、调用方式及参数格式一并告知大模型。如此一来，模型在回答问题时，便有了两种输出路径：若问题在其能力范围内，则直接生成答案文本；若涉及自身无法获取的外部信息，则输出结构化的工具调用指令。

客户端接收到该指令后，会自动执行对应的工具调用，获取真实有效的外部数据，再将结果回传给大模型。模型结合这些真实数据进行推理，最终输出准确、可信的回答。这一让大模型联动外部工具的机制，便是我们常说的 Function Calling（函数调用）。

{
  "candidates": [
    {
      "finishReason": "FUNCTION_CALL",
      "content": {
        "parts": [
          {
            "functionCall": {
              "name": "get_weather",
              "args": {
                "city": "北京"
              }
            }
          }
        ]
      }
    }
  ]
}

Function Calling 就是让大模型在遇到不会的问题时，能输出一条帮我查一下的指令，客户端收到后去调用外部工具拿到真实数据，再回传给模型生成靠谱回答。

3. 通信标准

Function Calling 从机制上明确了大模型可以通过输出工具调用指令来扩展自身能力，但它并未规定这些工具的具体实现位置：既可以定义在 AI 客户端内部，也可以部署在客户端外部的独立服务中。

若将工具实现于客户端内部，虽能快速落地，但工具扩展性受限，且难以在不同应用间复用。而将工具独立部署于外部服务，则具备更好的灵活性、可维护性和跨平台复用能力，更适用于复杂业务场景。

然而，工具外部部署后，随之而来的新问题是：AI 客户端与外部工具服务之间应如何通信？例如，如何传递工具名称与调用参数？如何接收工具执行后的返回结果？

MCP（Model Context Protocol，模型上下文协议） 正是为此而生。它规定了 AI 客户端与工具服务之间标准化的通信规则，涵盖工具调用发起、工具信息获取、执行结果返回等全流程交互细节，从而使大模型与外部工具的连接变得规范、统一，为构建可扩展的智能应用奠定了坚实基础。

MCP 规定了工具如何注册、调用请求如何发送、执行结果如何返回，让任何客户端都能即连即用，任何工具都能即插即用。