章节主旨
先讲 MCP 是什么、client 与 server 如何分工、如何自建并分享;再转到「为什么不能什么都用 MCP」——因为工具定义与工具响应会大量占用上下文窗口,而模型的表现随 token 增多而下降。最后给出应对:压缩提示信息密度、靠 compaction 摘要历史、并挑选质量过关的 server。
核心论点
- MCP 是「AI 的 USB」——一套跨模型家族的通用适配器,让任意 assistant 用同一协议接任意数据源与工具。(→ 详解1)
- MCP 分 client 与 server 两端,靠 resources / tools / prompts 三种原语通信,client 是 agent 的外壳,server 是围绕具体工具的执行脚本。(→ 详解2)
- 自建 MCP server 已经很容易,可自用、可分享给他人、可作为 API 的接入层反哺公司收入。(→ 详解3)
- 不该什么都用 MCP:每个工具的 name/description/schema 常占几百 token,五个 server 各十个工具,啥都没干就已烧掉约 1.5 万 token。(→ 详解4)
- 上下文越长,模型越笨:token 数与准确率强负相关,长上下文里的信息会被「遗忘」,检索命中率随之暴跌。(→ 详解5)
- 应对之道是提升信息密度:把提示改写得更短更密、靠 compaction 摘要历史、并避开灌爆 context 的劣质 server。(→ 详解6)
知识点详解
1. MCP:AI 的通用适配器 2:35:59
MCP(Model Context Protocol)被类比成「AI 的 USB」。早年 USB 有 USB1/2/A 等几百种线缆,直到 USB-C 出现并被标准化,任何设备插任何设备就能通。MCP 就是给 AI agent 做同样的事:一套通用适配层,免去为每条连接自造专用「线缆」。
它由 Anthropic 于 2024 年 11 月提出,是 AI assistant 连接外部数据与工具的标准化方式。关键在于它不是 Claude 专属——OpenAI、Gemini 等模型家族同样适用,相当于给所有 agent 立了一门「世界语」。
2. Client / Server 架构与三种通信原语 2:37:36
MCP 分两端。MCP Client 是承载 agent 的 AI 应用,即 antigravity、VS Code、Claude Desktop、ChatGPT 这类「外壳」——呼应课程前文「聊天界面只是 agent 暂借的接口」的说法,client 本质就是那层接口/外壳。
MCP server 则围绕具体工具而建:Apify server、Apollo server、Google Drive server、Sheets server 等。你在工作区里放进哪些 server 的配置文件,当前 client 就能调用对应工具,例如让它读 Drive 文件、转成 CSV、再喂给 Apify。你还能写高层 directive 指导它更可靠地把多个 server 串起来。
三种通信原语要分清 2:39:23:resources 是结构化数据(文档、代码、数据库记录);tools 是 agent 可调用的函数,等价于我们这端的执行脚本;prompts 类似针对某 server 的系统提示,指导模型「何时该调哪个脚本、该读哪个 resource、分页只取前 50 行」等,提升可靠性。
3. 自建并分享 MCP server 2:40:22
MCP 的目标是把整个互联网变得对 agent 可访问:每个工具都有自己的 server,agent 只加载真正需要的那几个,于是不必从零造工具就能获得广度。
除了用现成 server,你也能自建。刚推出时很难,如今借 AI 助手很容易——Nick 称没读过文档、十分钟就搭出一个能用的。自建的价值有二:一是自用;二是分享,可让别人付费请你搭,或作为 API 公司为自家功能建 server、降低接入门槛从而增收。
分享的另一好处是协作迭代:同一个 server 给全组织用,行为始终一致(因为是同一份 server),且能由多人共同改进,而非只靠你一个人维护。
4. MCP 的代价:工具定义灌满上下文 2:41:20
既然 MCP 这么好,为什么不全用它?因为 MCP 很吃 token,而模型处理的上下文越多就越笨。MCP 会把几乎所有可用函数都载入 agent 的上下文窗口。
算笔账 2:43:47:每个函数都带 name、description、schema,通常合计几百 token。若连了 5 个 server、每个 server 有 10 个工具(如 Drive server 的 get file / read file / share file……),按每个定义 300 token 计,就是 15,000 token——这还是在你什么都没做之前。等于一开局就已经站在性能下降曲线的中段。
有些新方案在缓解此问题,如运行时(runtime)按需智能加载 server,但 MCP 作为框架尚新,现存 server 质量参差,总体仍会把大量 token 塞进 context。
5. 上下文越长,模型越笨 2:41:31
同一诉求,用 10 个词写的提示往往比啰嗦冗长的版本表现更好——前者也许 99% 成功率,后者可能掉到 85%。token 数与性能强负相关:通常先随信息增加略有上升(给了足够示例),越过某点后随无关 token 堆积而持续下滑。这种现象可称上下文腐化。
实证很直观:老模型(如 GPT-3.5-turbo-16k)在输入 5 篇文档时约 75% 准确,翻倍到 10 篇掉到 65% 出头,再翻倍近 60%,继续加就跌到 50–60%。文档数在这里约等于 token 数,性能下滑极快。机理类似生成时每一步 next-token 的分支方差随序列变长而暴涨,维持准确与连贯越来越难。
另两组曲线佐证:memory retrieval——埋在超长 context 深处的某个 token,在 3 万 token 时几乎 100% 找到,到 200 万 token 时会大面积「遗忘」到根本没意识到它存在;大海捞针(needle in a haystack)——token 越多,模型有意义地追踪信息的能力越差。本质就是同时要兼顾的东西越多、忘掉任一个的概率越高。
6. 应对:信息密度、compaction 与挑好 server 2:49:07
第一招是提升信息密度:把提示改写得更短更密就能显著提升产出质量。同一首「写关于人生意义的诗」的诉求,从 47 词砍到 22 词、信息量不变,token 从约 67 降到约 28,统计意义上后者产出更好。模型内部其实也在做这件事——reasoning token 就被特意训练成极短、极高密度的写法(如 GPTOSS 那种「need define X but also Y maybe Z」的电报体)。
第二招是 Compaction 2:51:12:模型每次都要把你俩的全部历史消息一并喂入,compaction 就是当 token 达到某阈值(如额度的 50%)时,把整段历史摘要成一条精炼消息,再喂给下一实例。会丢些细节,但多数细节本就无关紧要,换来的是远少于全量历史的 token。
还要警惕两点。其一,agent 直接调 MCP 工具时,整个响应都会进 context 2:51:55——拉一份 Drive 文档、查一张 10 行 20 列的表(即 200 个单元格)都会整块塞进来,用通用型工具很快撞上 context 天花板、烧钱。其二,server 质量参差 2:52:29:很多 server 为蹭热度仓促上线,不返回像样的错误码、甚至没正确对接 API;perplexity、n8n 的算好例子,劣质的一交互就报错、模型立刻变蠢,一试便知。
关联
- 印证:Greg·Skill 工作原理 给本章的上下文窗口机制补了 Compaction 的具体触发数字(起步 2 万 token、逼近 25 万触发压缩,Claude Code 与 Codex 皆同),并同样主张控制常驻上下文占比。
术语
- MCP(Model Context Protocol):AI 与外部数据/工具连接的标准化协议,跨模型家族通用,被喻为「AI 的 USB」。
- MCP client:承载 agent 的 AI 应用外壳(如 VS Code、Claude Desktop、ChatGPT)。
- MCP server:围绕某具体工具而建的执行脚本集合(如 Drive server、Sheets server)。
- resources / tools / prompts:MCP 三种通信原语,分别为结构化数据 / 可调函数 / 面向 server 的指导性提示。
- 信息密度(information density):单位 token 承载的有效信息量,密度越高产出越好。
- Compaction:把历史对话摘要压缩后再喂入下一模型实例,以省 token。
- 大海捞针(needle in a haystack):考察长上下文中检索单个信息能力的测试。
自检问题
- 为什么「什么都用 MCP」不是好主意? 答案:MCP 会把几乎所有可用函数(每个含 name/description/schema、约几百 token)载入上下文窗口,5 server × 10 工具就约 1.5 万 token,尚未干活就已推高 token、拉低性能;且工具响应整块进 context,极易撞天花板。见详解4 2:43:47。
- MCP 的 client 与 server 各是什么?三种通信原语分别指什么? 答案:client 是承载 agent 的 AI 应用外壳(VS Code、Claude Desktop 等),server 是围绕具体工具的执行脚本集合;三原语为 resources(结构化数据)、tools(可调函数)、prompts(面向 server 的指导性提示)。见详解2 2:37:36。
- 面对「上下文越长模型越笨」,本章给了哪些应对手段? 答案:提升提示信息密度(改写更短更密)、用 compaction 摘要压缩历史再喂入、并避开会灌爆 context 的劣质 server;必要时靠运行时按需加载 server。见详解6 2:49:07。