模型越聪明越健忘？"上下文腐烂"背后的 3 个解法
你有没有遇到过这种情况？
Agent 刚开始干活时又快又准。聊着聊着，它开始忘事、跑偏、重复犯错。
于是你回去改提示词，加规则，再加规则。结果越改越乱。
Anthropic 应用 AI 团队最近发了一篇工程博客，给这个问题换了个问法：不是"怎么写好提示词"，而是"什么样的上下文配置，最可能让模型做出我们想要的行为"。
这就是 上下文工程（Context Engineering）。今天用 5 分钟，讲清它的核心思路。
↗一、从提示词工程到上下文工程
提示词工程，关心的是怎么写好指令，尤其是系统提示词。它面对的多是一次性的分类、生成任务。
但 Agent 不一样。它在循环里工作，跨多轮推理、跨很长的时间。
每一轮都会冒出新信息：工具返回的结果、外部数据、消息历史、MCP 接入的内容......
所以问题变成了：这些东西里，哪些该进入有限的上下文窗口？
Anthropic 的定义很清楚：上下文，是调用大模型时放进去的那一组 token。上下文工程，就是在 LLM 的固有限制下，持续筛选、维护这组 token，让它的效用最大化。
关键区别在于：写提示词是一次性动作，而上下文工程是迭代的------每次决定"给模型看什么"时，都在做一次策展。
↗二、为什么必须做：模型也有"注意力预算"
很多人以为，窗口越大越好，全塞进去就行。
Anthropic 的观察是：不行。
研究"大海捞针"类基准发现了一种现象，叫 上下文腐烂（context rot）：上下文里的 token 越多，模型准确回忆其中信息的能力就越下降。
这在所有模型上都会出现，只是有的模型下降得更平缓。
原因出在 Transformer 架构上。每个 token 都要和其他所有 token 建立关联，n 个 token 就有 n² 个两两关系。长度一增加，注意力就被摊薄了。
再加上训练数据里短序列更常见，模型对"全文范围的长程依赖"经验更少。
文章用了一个很形象的说法：LLM 和人类一样，有有限的**"注意力预算"**。每多一个 token，就消耗一点。
所以结论是：上下文是一种边际收益递减的有限资源。
注意，这是"性能梯度"，不是"断崖"。模型在长上下文下依然很强，只是检索精度和长程推理会变弱。
↗三、好的上下文长什么样
原则只有一句话：用尽可能少的高信号 token，最大化达成目标的概率。
注意，"少"不等于"短"。该给的信息还是要给够。
具体到各个组成部分：
1. 系统提示词：找到"恰当的高度"
两种常见的失败：
→
太低：把复杂的 if-else 逻辑硬编码进提示词，脆弱，难维护。
→
太高：只给模糊的大方向，既没有具体信号，又假设模型和你共享背景。
好的状态是中间的"金发姑娘区"：足够具体来引导行为，又足够灵活，给模型强有力的启发式。
建议用 XML 标签或 Markdown 标题把提示词分区。但文章也坦言，随着模型变强，格式本身的重要性在下降。
实操建议：先用最好的模型测一个最小提示词，再根据失败案例逐步补充指令和示例。
2. 工具：别让 Agent 做选择题
工具是 Agent 与环境之间的契约。要保证它返回的信息 token 高效，也要鼓励高效的行为。
最常见的失败，是工具集臃肿、功能重叠。
文章有一句很扎心的话：如果人类工程师都说不清该用哪个工具，就别指望 AI Agent 能做得更好。
3. 示例：给"图"，别给"清单"
少样本示例依然强烈推荐。但别把所有边界情况都塞进提示词。
更好的做法是精选一组多样且典型的示例。对 LLM 来说，示例就是"一图胜千言"。
↗四、让 Agent 自己找："即时检索"策略
传统做法，是在推理之前，用 embedding 检索把相关数据预先塞给模型。
现在越来越多团队加入了**"即时（just in time）"策略**：
Agent 不预先加载全部数据，只保存轻量的引用------文件路径、已存的查询、网页链接------需要时再用工具把数据读进上下文。
Claude Code 就是这样处理大型数据库的：写针对性的查询，存下结果，用 head、tail 这类命令分析数据，从不把完整数据对象装进上下文。
这很像人类。我们不会背下整个图书馆，而是依赖文件系统、收件箱、书签。
引用本身还携带信号。同样叫 test_utils.py，放在 tests 文件夹里，和放在 src/core_logic/ 里，含义完全不同。目录结构、命名习惯、时间戳，都是线索。
这带来了渐进式披露：Agent 一层层探索，只把必要的东西留在工作记忆里。
当然有代价：运行时探索比预计算慢，而且需要精心设计工具和启发式，否则 Agent 会误用工具、钻死胡同。
所以很多场景最有效的是混合策略：一部分数据提前加载保证速度，其余让 Agent 自主探索。Claude Code 就是如此------CLAUDE.md 文件一开始就放进上下文，而 glob、grep 让它按需检索其他文件。
文章给出的底线建议是："做最简单有效的事情"。
↗五、长程任务的三把钥匙
当任务长达几十分钟甚至数小时，比如大型代码库迁移、综合性研究，token 总量会远超上下文窗口。
等更大的窗口不是答案，因为上下文污染和相关性问题，对所有尺寸的窗口都存在。
Anthropic 总结了三种技术：
① 压缩（Compaction）
对话接近窗口上限时，先总结，再用摘要开启一个新窗口。
在 Claude Code 里，模型会保留架构决策、未解决的 bug、实现细节，丢掉冗余的工具输出，再带上最近访问的 5 个文件继续工作。
难点在于取舍。压得太狠，可能丢掉当下看不出、之后才关键的细节。
建议先最大化召回 ，再逐步提升精度。最安全、最轻量的一种压缩，是清除已经用过的工具调用结果。
② 结构化笔记（Agentic Memory）
让 Agent 定期把笔记写到上下文窗口之外，需要时再读回来。
就像 Claude Code 维护待办清单，或者你的 Agent 维护一个 NOTES.md。成本极低，却能在几十次工具调用中保住关键进度和依赖。
文章举了"Claude 玩宝可梦"的例子：它能在上千步里精确统计进度，自己画出已探索区域的地图，记下哪些招式对哪类对手有效。上下文重置后，读自己的笔记，就能接着训练或探索。
Anthropic 还在 Claude 开发者平台上推出了基于文件系统的记忆工具（公测）。
③ 子 Agent 架构
不让一个 Agent 扛下整个项目，而是让专门的子 Agent 带着干净的上下文窗口处理聚焦的任务。
主 Agent 负责高层规划，子 Agent 可能消耗数万 token 深入探索，但只返回一份 1,000--2,000 token 的精炼摘要。
好处是关注点分离：详细的搜索过程被隔离在子 Agent 内部。Anthropic 的多 Agent 研究系统，在复杂研究任务上明显优于单 Agent。
怎么选？取决于任务特点，文章原文在这里列了具体建议，但在我抓取到的页面文本中这部分内容缺失，这里不做臆测，建议到原文查看。
↗六、给你的 4 条行动清单
1→
把上下文当预算花。 每加一段内容，先问：它值得消耗注意力吗？
2→
精简工具集。 功能重叠、边界模糊的工具，先砍再说。
3→
示例要精，不要多。 3--5 个典型案例，胜过一长串边界规则。
4→
长任务早设计记忆。 压缩、笔记、子 Agent，按场景组合，从最简单的开始。
↗写在最后
模型会越来越聪明，需要的"手把手"工程会越来越少。
但 Anthropic 的判断是：只要上下文还是有限的，把它当作珍贵资源来对待，就永远不会过时。
你在做 Agent 的时候，踩过哪些"上下文爆炸"的坑？欢迎在评论区聊聊。觉得有用，转发给正在做 Agent 的朋友。
· · ·
原文：Effective context engineering for AI agents(Anthropic Applied AI 团队）
SEO 关键词：上下文工程、AI Agent、上下文腐烂