有没有遇到过这种情况：Agent 跑了半小时，开始忘记你们之前约定好的规范；改 A 处时把 B 处改坏了，而半小时前它明明知道 B 的存在；明明上下文窗口还有余量，回答质量却一路下滑。

我自己踩过这个坑。我让 Hermes 每天跑选题推荐，前几周一直很稳，后来突然开始漏掉重复检测——不是我改了什么，是那一周积累的日志和中间结果把规则挤到了窗口深处。

多数人的第一反应是"模型不行了"或者"该换更强的模型了"。但真实原因往往更朴素：窗口里塞的东西太多了。

 

这个现象有个专门的名字，叫上下文腐烂（context rot）。这篇文章把 Context Engineering（上下文工程）这个 2026 年最热的硬话题讲透——从原理到四层管理策略，再到三个今天就能用的招。

上下文越长，Agent 为什么反而越笨？

先讲原理。Transformer 的注意力机制有个天然属性：每个 token 都在和其他所有 token 竞争注意力。上下文短的时候，候选项少，重要信息容易拿到高权重；上下文一长，候选项暴增，模型要在一大堆内容里判断该把注意力分给谁——即使关键信息还在窗口里，也可能被冗余内容和表面相似的 token 挤掉权重。

注意，不是"上下文长就一定差"。长上下文的价值真实存在：看更多证据、跨文档推理、干更复杂的活。真正的问题是边际收益：当新增内容的信号密度不高时，收益开始递减，然后变成负的。

有个斯坦福的实证研究特别能说明问题。给模型 10 到 20 个文档，其中只有一个包含正确答案，系统性地改变答案文档的位置。结果是一条 U 型曲线：答案放开头或结尾时，正确率约 75%；被夹在中间时，掉到约 35%——甚至低于什么都不给、纯靠模型自己答的闭卷基线（56.1%）。也就是说，塞给模型更多信息，有时候反而变成了负贡献。

这背后还有个更硬的账：每个 token 都在消耗注意力预算。Transformer 的自注意力让 n 个 token 算 n×n 个分数，上下文越长，推理越慢、等待越久、钱花得越多。加一段无关的 1000 token 文档，不是中性操作，是在主动损害有效信息的信号强度。

所以上下文工程的定义可以一句话说清：在有限的注意力预算下，找到尽可能小、但信号最强的一组 token，让任务成功率最大化。 等更大的窗口解决不了这个问题——窗口再大，信号密度不高的内容照样稀释注意力。100 万 token 的窗口只是把死亡线往后挪，没有取消它。

把上下文当内存管理，不当仓库用

原理清楚了，手段就顺理成章。工程界的成熟做法是把上下文分四层处理，这个框架可以直接套到自己 Agent 上。

第一层，大结果外置。工具返回 238 条接口变更记录，别把原始 JSON 全塞进 prompt，存进对象存储，上下文里只放一个引用：{"refId": "artifact_1024", "summary": "238 条记录，17 条影响核心链路"}。模型需要细节时再按引用取。

第二层，智能压缩。重点不是"把文字变短"，是保留后续步骤真正需要的事实：数量、状态、风险项、已经失败的方案。把 3000 字会议记录压成 500 字流水账，不算压缩；压成"目标 X、已确认 Y、已否决 Z、待办 W"才是。

第三层，结构化交接。长对话与其删最早的消息（关键约定经常就在最早那批），不如生成一份结构化交接记录再开新窗口。Anthropic 用 Claude 玩《宝可梦》做过演示：Agent 靠持续写笔记，跨数千个游戏步骤记住了目标、训练进度、地图探索状态；上下文重置后读自己的笔记接着玩。真正重要的不是 AI 会玩游戏，是它证明了一件事：长任务不必依赖一个永不清空的聊天窗口，关键状态完全可以外置。数据也支撑这套打法：Anthropic 给 Opus 配的 Memory Tool（本质就是结构化笔记的工程化版本），在长时间工作流里把 token 消耗砍掉了 84%。

第四层，子 Agent 架构。任务本身需要大量探索（读几十个文件、跑十几轮搜索）时，单 Agent 硬扛上下文必然爆。拆开：主 Agent 只管计划和协调，子 Agent 负责深入探索。子 Agent 内部可以烧几万 token 去翻文件，但最终只把压缩后的结论交回主 Agent——探索的账单留在子 Agent 那里，主 Agent 的窗口只进摘要。

装 15 个 Skill 只花 1200 token？渐进式披露了解一下

四层管理解决"对话和历史"的问题，还有另一类问题：怎么给 Agent 挂一大库的程序性知识（规范、流程、参考资料），而不把它塞爆？

Anthropic 做 Skills 时的答案叫渐进式披露（progressive disclosure），三级加载。算笔账就明白这套设计多值：假设装 15 个 skill，平均每个 3000 token。全量加载是 45000 token，代码还没写一行，上下文先吃掉一小半。三级加载下，常驻的只有 metadata 层约 1200 token，触发哪个才加载哪个的正文——差 37 倍，而且 skill 越多、参考材料越厚，差距越大。

一个好用的类比：这就像手机上的 App。图标永远在桌面，界面点开才加载，设置页要进到里面才看。没人会为了"可能用某个 App"把它所有页面常驻内存。

两个工程细节值得单独说。第一，skill 的底层就是文件系统：一个目录加一个 SKILL.md，可以 git 管理、可以 diff、可以 review。第二，SKILL.md 一旦加载，整个 session 都占着上下文，所以正文每一行都是持续成本，写得越紧凑越好；长的参考材料一律下沉到引用文件里。description 是唯一必填字段，因为它决定了 skill 什么时候被触发——描述写得好，等于给检索做了一个高质量的索引。

三个今天就能用的招

不用搭框架，不用改架构，今晚就能试。

第一招，手动 compaction。一篇文章和 AI 改了 30 轮，越来越混乱，别硬撑。让它先整理一份"当前工作摘要"：目标是什么、已确认哪些事实、删掉了哪些观点、剩什么问题、有什么硬性风格要求。拿这份摘要加最新稿，开个新对话继续。核心不是把旧对话搬过去，是把影响下一步的状态搬过去。

第二招，建一份项目 NOTES.md。只放长期有效的信息：目标、已完成的里程碑、关键技术决策、不能改的约束。每次开新对话把它带上。这就是结构化笔记的手动版，Anthropic 那套 Memory Tool 的思想内核。

第三招，把自己的参考资料改造成三级结构。你有 SOP、规范文档、API 备忘？别一股脑贴进 prompt。给每份材料写一行高质量的描述（什么场景该用它），正文和细节放文件里。用的时候先给描述，让模型判断要不要展开。描述写得好，等于建了一个免费的索引。

说到底，Agent 的每次决策都只基于它当时看得见的东西。 上下文工程管的正是这个。它不像换模型那么性感，但它有个特点：每一点优化都直接变成质量和成本，而且不依赖任何供应商的进步。未来真正好用的 Agent，未必是"什么都记得"的 Agent，更可能是"知道什么时候该去哪里找"的 Agent。前者在等窗口变大，后者已经在干活了。