第 9 章 — 管理注意力预算

发布于: 2026-04-07 最后更新于: 2026-06-12 版本: 1

第 9 章 — 管理注意力预算

LLM Primer IV: Designing AI Cognition with MCP 章节走读的第九篇。百万 token 的上下文窗口其实是天花板值,不是工作点;而 "模型变差了" 的相当一部分,其实是 "模型被埋掉了"。


这一章为什么存在

上下文窗口看起来像免费的空间。它不是。一个 agent 读的每个 token 都花延迟、花钱,而且 — 不那么明显但更重要 — 花质量。"百万 token 窗口意味着塞下一切" 是当前实践里最贵的几个误读之一,占了被诊断成 "模型回归" 的生产故障里相当大一份。模型并没有变差。它被埋掉了。这一章讲的是把上下文当成有限预算而不是免费资源来对待:什么在吃预算、预算不是对的工具时有什么替代方案、怎么落进那个甜区 — agent 拿到正好需要的东西,多一份都没有。

一句话总结:上下文是一个成本中心,不是一个免费输入 — 一支只加工具不删、不压缩历史、把检索来的每一块都塞进窗口寄希望于 "多多益善" 的团队,正在曲线上 "每加一份都让事情更糟" 那一段工作。

9.1 Context rot 与那道非线性悬崖

上下文长度和质量的关系不是线性的。Prompt 长度翻倍并不会让质量减半;过了某个点是减得更多。沉淀下来那个技术名 — context rot — 非正式但准确。Stanford 的 Liu 等人那项经典研究表明,模型在文档列表里找信息时,如果相关文档在中间,表现比在两端时差很多。这条 U 形曲线在不同模型家族、不同上下文长度上都被复现。一段长 prompt 的中间,在某种有意义的意义上,在注意力上比两边更廉价,虽然架构在每个位置上是一视同仁的。

2023 到 2024 年成为标准的 "大海捞针" benchmark 一开始看上去反驳了这幅图 — 100K、200K 甚至 1M token 上接近完美的检索。更仔细的后续工作显示这些 benchmark 太简单了。一根显眼的针扎在同质的草堆里,跟在二十段话题相关的干扰里找一个相关事实是两回事。2025 年底发布的 MCP-Universe 和 BIG-Bench-Long 把这种对抗性结构内置了进去,数字让人清醒:100K token 时前沿模型相对于同样任务在 8K 上掉 10 到 20 分,500K 时差距可以到 40。

MCP agent 还有第二种特定的腐蚀。工具在 system prompt 里堆起来时,模型 对工具的准确率会退化。MCP-Universe 显示工具选择准确率从 5 个工具时的约 90% 掉到 40 个时的低于 60。从业者现在叫它 tool-loadout rot,它是 "我们加了更多能力之后 agent 变蠢了" 这种现象的最常见单一原因。机制在两边一样:注意力有限,prompt 越长,每个 token 拿到的份额越小。

9.2 对同一个问题的三个答案:MCP、RAG、微调

当一个模型缺它需要的知识时,有三个架构答案,而把其中一个当成另一个用,是一份相当可观比例的工作被错误分配的原因。MCP 契合的是 运维型 知识 — 当前库存、今天的日程、构建的状态。这些有权威源、持续在变,任何预加载上下文都不可能保持最新。赢的不只是新鲜,还有可追溯:当模型说 "构建是绿的",用户能问 "依据什么",答案是 "构建服务器,在这个时间戳查的"。

RAG 契合的是 文档型 知识 — 一个大到塞不进窗口但稳到能建检索索引的语料。内部文档、支持文章、合同、大型代码库。本系列第三卷整本都是关于 RAG 工程,依然是经典参考。微调契合的是 行为 缺口 — 一致的格式、特定的口吻、对某一类请求可靠的拒绝。行业里反复出现的错误分配,是用微调注入会变的事实知识,产出一个一开始让人惊艳、然后随着世界从它冻结的快照漂走而逐渐变错的模型。

三者不互斥。一个成熟的 agent 通常组合三者:微调管行为、RAG 管文档型知识、MCP 管运维型知识。有用的框架是 给对的鲜度需求选对的衬底。行为在模型代际的尺度上稳定;把它烤进权重。文档型知识在天的尺度上变;给它建索引。运维型知识在秒的尺度上变;靠工具去拿。把衬底配错的架构 — 用冻结权重装快变事实、用检索索引装活状态 — 在正确性、延迟或两者上付代价。

9.3 Goldilocks 区:够用的上下文,不要太多

日常的问题是每次调用要传多少上下文。中间那段甜区比大多数团队一开始以为的要窄。最有后果的杠杆是 system prompt。好的是短、具体、稳定。差的是那种 防御性 prompt,靠堆积变长,模型每出一次错就加一句,直到它变成一份模型已经没法可靠跟随的千字规则文档。每季度审计、把 "删" 当目标的团队,一年后的 prompt 比之前更短,产出的行为反而更好。

第二根杠杆是工具清单。对 tool-loadout rot 的矫正是 渐进披露:注册一小组高层工具,让模型通过一个发现工具往细处钻。四十个窄工具变成四个广工具加内部分派,工具选择准确率把丢掉的大部分找回来。第三根是对话历史 — 从第一轮就压缩,不要等到窗口 90% 满。第四根是工具结果:返回模型需要的字段,不要整行。纪律是 有意纳入:对每一份内容,团队应该能回答 "如果这一份不在,会发生什么"。如果答案是 "agent 行为一样",就该删掉。

值得记住:上下文不再是放东西的地方;它是 东西的地方。按角色测每 token 花销、在设计时做预算而不是 debug 时、跨上下文长度跑质量回归、把前缀稳定性当成缓存纪律要求、稳的内容放前面、变的放后面。让单次推理调用成功的纪律,就是让长会话可持续的纪律。

第 9 章接下去会怎么走

这一章把上下文当成单次推理调用内部的有限预算来框。它没覆盖的是 时间 这个问题。一个跑 30 秒的 agent 有一个塞进单窗口的预算问题。一个跑 30 分钟、3 小时、3 天的 agent 有一个任何实际尺寸的窗口都装不下的记忆问题。这种规模工作的策略在 种类 上不一样,不只是程度上。


明天 — 第 10 章:长时任务记忆通过滑动窗口和 ReAct scratchpad 的短期机制,通过情景向量和语义存储的长期机制,以及让 agent 跨小时跨天工作的压缩技巧。

想看完整的全貌?书里详细走 MCP-Universe 和 BIG-Bench-Long 的数字,展开各种衬底的成本和延迟特征,还给出生产团队收敛到的七条运维实践 — 从按角色 token 测量到位置感知的 prompt 构造,再到沿 agent 循环跨调用做预算分配。在 Amazon 查看 LLM Primer IV →

下田 昌平
下田 昌平
作为株式会社Receipt Roller的CEO兼CTO,目前负责开发电子收据服务以及自动将对话分类并生成行动任务的系统「ACTIONBRIDGE」。从小便接触编程,1996年参与开发测量仪器的相关程序,始终保持着对技术的深刻探索与热情。 在此前的职业生涯中,曾担任日本最大呼叫中心行业企业的子公司——一家研究开发公司的CEO/CTO,领导了多个技术开发项目。目前,我依然活跃在编程的最前沿,持续书写代码。