从零跑通 MCP 文件服务：Trae 配置 filesystem 全流程

说白了，MCP 就是 AI 界的 Type-C

很多人一看到「协议」这个词就头大，先别想术语，讲个大家都懂的例子。

想想以前手机充电线有多混乱：苹果用 Lightning，老安卓用 Micro USB，新安卓用 Type-C，出趟门得带三根线，充电宝上得插三个头。大模型接工具以前也是这副德行：你想让 Claude 读个本地文件，得专门写一套对接代码；想给 GPT 接同样的功能，又得改成适配 OpenAI 函数调用的格式；换到 Cursor 编辑器，插件规则又不一样了。

MCP 做的事，就是把这些乱七八糟的接口统一成 Type-C。只要你做出来的工具符合 MCP 协议——不管是文件系统、飞书、数据库还是发邮件的服务——所有支持 MCP 的 AI 客户端都能直接拿过来用，再也不用为每个客户端重新写适配代码。

它不是某个工具，也不是一个 SDK，更不是某家公司的产品。它就是一套中立的通信规则，规定了大模型和外部工具之间怎么打招呼、怎么传参数、怎么返回结果。有点类似于 HTTP 协议，不管你用什么服务器、什么浏览器，大家都按这一套规则来。

三层架构：谁在干活，谁在传话

不少人一开始会误以为 MCP 就是个插件市场，点一下安装就能用。后来搞清楚它的三层关系，才明白完全不是那么回事。

最贴近普通用户的是

，就是我们日常用的那些 AI 工具：Trae、Cursor、Claude Desktop 这些。在设置里添加 Server、管理工具列表，都是在这一层操作。它的角色相当于一个「转接头」，把 MCP 服务的能力翻译成大模型能理解的格式。

中间那一层是大模型本身，也就是所谓的「宿主」。模型不会直接去碰你的文件或者 API，它只负责干自己最擅长的事——推理。判断当前任务是否需要调用工具、调用哪一个、传什么参数，这些都是模型来决定，但具体的执行层面它不碰。

最底层是

，这才是真正干活的角色。比如这次用的 filesystem Server，它负责真实地去读取文件、写入文件、列出目录，然后把结果返回给上层。所有实际操作都发生在这一层，安全边界也在这里控制。

三层之间全靠 MCP 协议来通信，彼此都不用关心对面到底是怎么实现的，只要按协议说话就行。你换个客户端、换个模型，只要它们都支持 MCP，服务端的代码一行都不用改。

从零配置一个 filesystem MCP Server

说回实操，就拿官方的文件系统 Server 来举例，这也是最常用、最适合上手的一个。

官方已经把包发布到 npm 上了，下载安装后直接用 npx 就能跑起来。

全局安装：

复制代码    @modelcontextprotocol/server-filesystem

直接 npx -y 就能运行：

复制代码{
  "mcpServers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "D:/workspace/xjl_ai/ai/mcp/mcp-test"
      ]
    }
  }
}

stdio 模式是通过标准输入输出来通信，不用开端口、不用配网络，本地使用起来最轻量。args 里最后一个路径，就是你允许 AI 访问的目录。

第一个测试：Claude cli

首先 npx -y 在对应 JSON 配置目录下本地启动，会出现这样的提示：

启动 claude ，输入 /mcp，claude 成功连接本地启动的 mcp 服务：

这时候就可以使用文件系统的功能了。

第二个测试：Trae

不少人为了图省事，直接把路径写成了 D 盘根目录，写完就觉得不对劲——这等于给 AI 开了整个 D 盘的读写权限？

后来查了官方文档才放心，filesystem Server 做了严格的目录限制：它只能访问你配置里指定的目录及其子目录，上层目录根本碰不到。相当于你给 AI 递了一把抽屉的钥匙，而不是把整个家的钥匙都给了它。

即便如此，也建议只给项目所需的最小目录，权限收得越紧越安全。

跑通第一个 MCP 调用

在 Trae 的设置中打开 MCP 配置：

点击添加，选择手动配置，选择原始配置，并粘贴刚刚的 JSON 配置：

返回之后就可以看到连接成功：

以前 AI 改文件，是编辑器把文件内容读出来塞给模型，模型改完再由编辑器写回去；现在是模型通过标准协议调用工具，工具自己完成操作。前者是「你把东西给我，我帮你改」，后者是「我指挥工具去完成操作」。

后者才是 Agent 该有的样子。

以前就有函数调用，MCP 新在哪？

相信不少人都会有这个疑问：大模型的函数调用早就有了，MCP 到底新在哪里，值得这么多人关注？

以前的函数调用，是「各家自扫门前雪」。OpenAI 有自己的函数调用格式，Anthropic 有自己的工具调用规范，每个厂商的实现细节都不一样。你写了一个文件操作的工具，想同时支持 Claude 和 GPT，就得写两套适配逻辑。更别提各种第三方 AI 客户端了，每家的插件系统都不一样。

MCP 是把这件事标准化了。它不绑定任何模型厂商，也不绑定任何客户端，就是一套中立的通信协议。写一个 MCP Server，所有支持 MCP 的环境都能用，不用再重复造轮子。

而且它不止能接「工具」，还能接「资源」。比如你可以做一个数据库的 MCP Server，让模型直接查数据；做一个飞书的 Server，让模型直接读文档、发消息；做一个 GitHub 的 Server，让模型直接提 PR。这些能力以前不是做不到，但每次都要重新写对接代码，成本太高了。

说得大一点，这东西是把 AI 从「聊天机器人」往「智能体」推了一大步。以前的模型只能在对话框里给你输出文字，现在它能通过标准协议，真实地操作你电脑上的文件、云端的服务、公司里的系统，而且是安全可控的。

几个容易搞错的认知

聊几个刚开始接触时容易踩的认知误区，估计不少人都会遇到。

第一个，MCP 不是框架也不是 SDK。很多新人一听新名词就想去 npm install，其实它本质是一套通信协议规范。你用 JS、Python、Go 都能写 MCP Server，只要符合协议格式就行。我们用的 filesystem，只是官方实现的一个现成服务端示例而已。

第二个，开了 MCP 不等于 AI 能随便翻你硬盘。这是最让人担心的一点。实际上所有操作都被 Server 限制在授权范围内，你给它哪个目录它就只能用哪个目录，你还可以在 Server 层加权限控制、加操作审计。安全边界是可控的，不是一开就全盘裸奔。

第三个，MCP 不只能跑在本地。最开始看到的例子都是 stdio 本地进程模式，很多人以为只能本机用。其实它还支持 SSE 远程连接，你可以把 Server 部署在服务器上，本地 AI 客户端通过网络来调用。比如公司内部的数据库、文档系统，都可以做成内网 MCP 服务，不用暴露到公网。

最后说点实在的

折腾完这一圈，有三个感触最深。

一是协议的力量真的被很多人低估了。技术圈每次生态爆发，背后基本都有统一协议的影子。HTTP 带火了整个互联网，USB 统一了所有外设，MCP 如果真能成为行业共识，以后 AI 工具的生态会比现在繁荣太多，不用再每家重复造轮子。

二是 AI 的主战场早就不在模型本身了。现在各家模型的能力差距越来越小，真正拉开体验差距的是上下文、是工具接入、是能不能真实解决问题。MCP 做的就是这件事：给所有模型搭一个统一的工具接入底座，大家不用再在对接这件事上内耗。

三是不用追概念焦虑。很多人一看到 MCP、Agent 这些词就慌，怕自己跟不上。其实剥开概念外壳，核心都是老问题的新解法。MCP 解决的就是「大模型怎么标准化地接入外部能力」这件事，想通了这一点，上手特别快。

当然它也不是万能的。如果你就是写个一次性脚本，自己调个 API，完全没必要套一层 MCP。它真正的价值，是在需要复用、跨端、多工具协同的场景里，帮你省掉大量重复的适配工作。

接下来可以自己写个简单的 MCP Server，接一下本地的笔记库，让 AI 能直接搜索写过的东西。如果你也在折腾 MCP，或者有什么有意思的服务端推荐，评论区可以留个言，也去试试。