第六周：MCP，以及什么时候不该自己造 server

最后一周讲 MCP（Model Context Protocol）—— 一个让 agent 接外部工具的协议。

三个角色，别搞混

MCP 的架构有三个角色，名字容易望文生义：

角色	是什么	具体例子
Host	那个跑 agent 的应用	Claude Code、你写的 agent 程序
Client	Host 里负责和一个 server 通信的那部分	通常是框架帮你管的
Server	提供工具的一方	文件系统 server、Playwright server

最容易搞反的是 server：它不是「服务器」那种意义上的远端服务，它是工具的提供方，而且很多时候就是你机器上的一个本地进程 —— 比如测试 agent 用的那个浏览器 server。

本地和远程，传输方式不同

本地 server —— 通过 stdio 通信，Host 直接把它当子进程起起来
远程 server —— 通过 HTTP 一类的传输，能被多个 Host 共享

这个区分有实际后果：本地 server 能看见你的文件系统，远程 server 不能。 而且本地 server 的生命周期绑在 Host 上，Host 退出它就没了。

它到底解决了什么

在 MCP 之前，给 agent 加一个工具意味着：在你的代码里写一个函数，再写一份 schema 描述它。 换个框架，这套东西要重写。

MCP 把「工具的提供」和「工具的使用」拆开了：

写工具的人发布一个 server，不用关心谁来用
用工具的人接一个 server，不用关心它怎么实现的

这是个接口标准化的故事，不是能力故事。 它没让 agent 变聪明，它让工具变得可移植；真正能带来几十个点的，是工具描述本身写得好不好。

值得对照一个更早的经验：Anthropic 拆 brain / hands / session 的时候，工具执行那一侧的接口简化成了 execute(name, input) → string。MCP 本质上是把这个接缝做成了跨进程、跨厂商的协议。

什么时候不该自己写 server

这一周有一讲叫「为什么要写自己的 MCP server（以及什么时候不该）」，我认为「不该」那一半更重要。

不该写的情况：

已经有现成的。 文件系统、浏览器、数据库这些常见的 server 社区都有。自己写一个的收益基本为零，维护成本却是真的。
你的工具只有自己用。 MCP 的价值在可移植；如果只有你自己的 agent 会调它，那么直接写个函数更简单、更快、更好调试。
性能敏感的路径。 跨进程通信有开销。一个每轮都要调几十次的工具，走进程内函数比走协议划算。

该写的情况：

工具要给多个 agent、多个团队、或者多个框架用
工具背后是一套复杂的领域逻辑，值得独立演进和独立测试
你想让别人在不改你代码的前提下用上它

判据其实是一句老话：为一个只有一个使用者的东西做接口标准化，是过度设计。

这条是我自己做过的取舍，也是我的判断。我那套东西没有用 MCP，工具就是几个直接调用的函数。理由很简单：它的工具只有一个使用者，就是它自己；接上协议我会多一层进程、多一层序列化、多一处出错的地方，换来的是一个我现在用不上的可移植性。等到真的有第二个消费方要用同一套工具，那一天再接不迟 —— 而这一天到来之前，我省下的是每一次调试都要多穿一层的成本。

那个 44 工具的项目

收尾项目是一个多 agent 交易台，接了若干 MCP server、总共 44 个工具。

这类项目最值得琢磨的不是它多酷，是工具一多会出什么问题：

一、模型选错工具的概率上升。 44 个工具的描述全塞进上下文，本身就是几千 token，而且相似的工具会互相干扰。

二、你没法靠跑分知道它到底行不行。 有一份 2026 年的工具调用评测审计请人逐条复核了 496 个任务，发现评测器的判定和人不一致的比例是 18.5%；分基准看，专门测 MCP 生态的 LiveMCPBench 误判率 30.5%，BFCL v4 是 20.0%。更要命的是同一个基准原地重跑 23 次，分数在 57.9% 和 76.8% 之间晃，最大跨度 18.9 个百分点。你以为量到的是「接了 44 个工具之后掉了多少」，很可能只是量到了噪音。

三、工具描述的质量变成瓶颈。 描述写清楚能带来几十个点，而工具越多，这件事越要紧也越难做好 —— 44 份描述里只要有几份含糊，表现出来就是「模型偶尔选错」，而这看起来像模型不行。

所以「接了 44 个工具」不是成就，是一个需要被管理的成本。按需加载工具、按场景分组，比一次全塞进去更实际。

边界与代价

MCP 是协议，不是安全边界。 接一个第三方 server 意味着让它的工具描述进入你的上下文 —— 而工具描述是文本，文本可以携带指令。这是提示词注入的一个真实入口，而且很容易被忽略。

协议也会漂。 MCP 在快速演进，传输方式和规范都在变。它比自己写一套稳，但不是不变的。

这一周是整个课程的收尾，但不是终点。 六周走完你有的是：一个能自己写的循环、几个框架的词汇表、一套 MCP 的接线能力。缺的那格是可观测和评测 —— 怎么知道你的 agent 这周比上周好。那不是这门课教的，但它决定了前面六周的东西能不能进生产。