模型上下文协议（MCP）：一个 AI 应用调用另一个程序的标准方式

为什么需要一个接口​

在有一个通用协议之前，每个助手和每个数据源都得各写一套对接。十个助手、十个数据源，就是一百个连接器，每个都有自己的鉴权方式、自己对「文档」的理解、自己把工具讲给模型听的说法。MCP 把这件事压平了：一个服务端把工具暴露一次，任何符合协议的客户端都能调。

形状很小。服务端发布一份工具清单，每个工具有一个名字、一段说明，以及一份描述参数的 JSON Schema。客户端——也就是那个助手——读这份清单，判断哪个工具能回答用户的要求，然后把参数发过去。服务端执行，返回文本、结构化数据或图片。此外还有 resources（可读的东西）和 prompts（用户可以菜单里直接挑的现成任务），所以一个助手可以把「校对这份文档」做成一条命令，而不是指望你把话正好说成那样。

这个设计带来两个后果，它们都比管线本身重要。

是模型在做选择，所以工具说明就是提示词。 一个工具的说明是给模型读的，不只给开发者读，而它要在这份清单里和其它所有工具竞争。写得含糊，就会调错；写得过于急切，就会调出没人要的调用。

服务端才是安全边界。 MCP 里没有「这个工具不许删除」这种概念。它描述的是能力；暴露什么、对谁暴露、某个动作要不要人点头，都是服务端自己决定的。一个把 shell 递出去的 MCP 服务端，不是协议的漏洞——那是设计选择，而协议会忠实地把它执行到底。

MCP 在实际中难在哪里​

一个文件路径不等于一座资料库。 面向知识工作的 MCP 服务端，最常见的做法是暴露「读这个文件」和「搜这个文件夹」。拿到这两样的 agent，能找到什么就打开什么；可一本五百页的书就变成一堵没有结构的文字墙，一个横跨若干章的问题，也无从导航。接口本身没问题，是它背后的材料太薄。

权限不会跟着连接一起过来。 协议里没有「提出一个改动，然后等批准」这套词汇。要么服务端把它实现成一个独立的工具，要么 agent 直接写下去，用户事后才发现。

本地和远程是两种不同的承诺。 跑在 127.0.0.1 上的服务端，数据留在本机。一个走 HTTPS、被云端助手使用的服务端，意味着请求由那个助手的供应商中转——材料也跟着一起中转。两者都成立，但它们不是同一个承诺；把两者都叫「MCP」来宣传，是混淆的主要来源。

工具清单会越来越长。 每接一个服务端，模型的上下文里就多一批工具，它的选择也多一批。过了几十个，调用会变得更含糊、也更容易调错。把清单管好是设计服务端的一部分，不是事后再说的事。

MindMax 怎样处理​

MindMax 在桌面应用里跑一个 MCP 服务端，走本机回环地址，所以同一台电脑上的助手可以对着你打开的那个文件夹干活。上面那三个难点，正是这个产品要解决的问题：

• 给的是资料库，不是文件路径。 一份长文档以「地图」的形式交出——章节、每章一句说明、每一节的 id——所以 agent 是在导航，而不是在跳读。见这个连接怎样工作。
• 工具集里有一道评审门。 对你写过的东西的改动，是先提议、以修订形式显示、你接受之后才写入的。新文件可以直接建；没有任何东西被覆盖或删除——机制在修改在等你。
• 本地是构造出来的，不是承诺出来的。 没有远程端点，这条路径上也不运行任何 MindMax 的模型，所以文件和额度都不离开这台机器。设置步骤见连接一个 AI 应用，工具清单见agent 工具参考。