第 1 章 — AI 集成危机与智能体架构的兴起
LLM Primer IV: Designing AI Cognition with MCP 章节走读的第一篇。2024 年那个主流模式 — 一段长长的 system prompt、几个工具、一个上下文窗口被要求干所有事 — 是怎么按一个可辨识的顺序败下去的,以及它指向的那一层协议,其实整个领域早就在悄悄朝那边走。
这一章为什么存在
差不多两年时间,搭一个 LLM 应用的标准做法是:写一段长长的 system prompt,挂几个工具,管它叫一个 agent。这个做法 demo 是能跑的。它也很守时地,在表面积长大之后崩掉。Prompt 慢慢爬过了六千个 token。工具清单慢慢爬过了四十个。团队打补丁、做审计、跑回归测试,然后某一天发现加新功能这件事比过去贵了不止一个数量级。诊断不是团队偷懒、也不是工程不好。是这个架构强迫所有事都挤在一个共享资源 — 模型的上下文 — 上面,而它底下还藏着一个更深的组合爆炸问题。
这一章按团队实际遇上的顺序走一遍那些故障模式,给每一个起个名字,再把架构上的出路框出来。出路是垫一层协议,让模型和工具不再靠定制胶水互相找到对方,加上一种纪律 — 上下文工程 — 把模型看到的那部分内容当成一份要管的预算,而不是一段随便写的自由文本。这两个想法撑起了后面整本书。
1.1 单体智能体的 system prompt 为什么终究会绷不住
第一代生产里的 LLM 应用形状很简单。一段几千 token 的 system prompt 描述角色、工具、约束、口吻、各种边界情况。在窄表面上工作得不错。团队一段一段往里加新功能,这段 prompt 慢慢变成了代码库里最长的单个文件,基本只增不减,因为删任何一行都觉得太冒险。
这段 prompt 在模型内部到底在做什么,用注意力最容易讲清楚。Transformer 在上下文里每一个 token 上都算注意力权重,包括 system prompt 里的每一个 token。一段六千 token 的 prompt 不会被略读 — 它会被平均掉。Prompt 越长,注意力的质量越被摊在跟当前这一步无关的指令上。这个现象有好几个名字:上下文稀释、指令冲突、能力漂移。团队观察到回归,定位不到原因,因为原因是三条新规则和两个 sprint 之前加的一句话之间的相互作用。
工具层会出现一种相关的故障。十个工具的时候模型挑得对;四十个的时候,挑工具的准确率开始掉,有时候掉得很厉害。团队的补丁是加一些消歧的说明,这一加 prompt 又长了,注意力又被稀释了一些。系统这时候已经在跟自己之间形成一个反馈循环。
1.2 专精能力,以及那条往错方向弯的维护曲线
Prompt 问题底下还藏着一个更深的。前沿通用模型是强通才,但通才的表现是在巨大表面上的一个平均,而平均会把悬崖藏起来。法律合同审查、结构化医疗编码、财务对账 — 每一个都有自己内部的术语、自己内部的规则、对错误的容忍度跟通用训练优化的方向不一样。本能反应是靠 prompt 来专精;代价是花掉更多注意力预算换来更少回报。真正的专精想要自己的组件、自己专注的上下文,而单体智能体根本没地方放这种东西。
维护成本也是按错的方向放大的。一个跨四个域、挂着五十个工具的单体智能体,维护负担不是 "一个五工具、一个域" 的十倍 — 它更多,因为每个功能都通过那段共享 prompt 跟所有其他功能耦合。团队的速度被维持现有表面的协调成本决定,而不是被造新东西的成本决定。推理费用按上下文长度算,所以缩 prompt 的经济压力和加 prompt 的工程压力是反向拉的。
1.3 N 乘 M 的集成问题
就算你接受要把它拆开。你现在有 N 个带模型的组件、M 个工具集成。没有共享协议,集成成本就是 N 乘 M — 每个模型都要为每个工具写定制适配代码,每个模型的怪癖跟每个工具的怪癖做笛卡尔积。换一个模型就要重新测所有工具。加一个新工具就要写 N 份适配。
计算机的历史里,这个形状有个名字,这个修法也有个名字。LSP(2016)之前,每个编辑器要跟每种语言做集成 — 编辑器乘语言。LSP 引入了一层协议;矩阵塌成了加法。USB 之前,每一类外设有自己的接口、每一个操作系统出货自带驱动。USB 之后,一个 host、一个 device、中间一层共享协议。Model Context Protocol 就是把同一招用在模型和工具之间。它没消灭适配器;它把它们标准化了。第一个集成更慢;第一百个快了很多;第一千个基本上免费,因为周边的工具链已经积累起来了。整盘棋都在这条累计曲线上。
带发现机制的协议还顺手塌掉了另一个比较安静的矩阵 — 描述矩阵。模型不再需要在启动时就把每一个工具枚举进 system prompt;它可以问协议 "现在有什么能用?" 然后从权威来源 — server 自己 — 收到一份结构化的目录。
1.4 从 prompt 工程到上下文工程
术语的变化跟着架构变。2022 到 2023 年这门手艺叫 prompt 工程 — 找到那种能把模型轻推到想要行为上的措辞。到了 2025 年,prompt 只是众多输入里的一个。模型同时还看到检索来的文档、工具描述、之前的对话轮次、工具结果、scratchpad 笔记、记忆片段。每一步上下文里该放什么,答案不再是措辞。答案是一套架构,按这一轮的情况决定模型现在应该看到什么。
这个术语沉淀下来叫上下文工程。它把上下文窗口当成一份要管理的预算。现在的长上下文模型号称百万 token 窗口,但表现会随着上下文被填满而非线性地退化 — 这个现象有时候被叫做 context rot。一个被塞了百万 token、答案埋在中间的模型,表现往往比同一个模型被塞十千个精挑细选的 token 还差。真正重要的预算不是窗口大小;是模型面前那部分内容里有用信号的密度。
MCP 在某种意义上,就是让上下文工程成为可能的那一层基础设施。协议给了 host 一套机制 — 去问哪些工具、哪些数据源可用,去在对的时机取出相关的那些,去协商模型能调用哪些能力。Host 按当前任务实际需要的东西,在每一轮动态地把上下文搭出来。
第 1 章接下去会怎么走
诊断分三块:单体智能体之所以败,是 prompt 长了稀释注意力;专精能力没法住在一个共享 prompt 里;在两者之下还有 N 乘 M 的集成问题。每一块都指向同一个方向 — 在模型底下垫一层,中介模型和工具怎么互相找到、互相描述、协商各自能做什么。第 2 章把那一层正式介绍出来:MCP 定义的三个角色、那一小套概念原语,以及从显式能力协商开始的会话生命周期。
明天 — 第 2 章:揭开 Model Context Protocol。MCP 是什么、"AI 的 USB-C" 这个说法到底指什么,Host、Client、Server 的三分,以及动态发现和双向消息为什么让 MCP 在那些真正重要的场景里跟 REST API 不一样。
