上下文工程的下一个范式：不是塞更多，是留更少
上下文工程过去一年的最大教训是：塞更多不如留更少。MIT 2026 年的论文发现去掉模型自己的历史回复能砍掉 10 倍上下文，质量还不降。结合 observation masking、外部化写入等策略，上下文管理的范式正在从"怎么装更多"转变为"怎么留更少"。
你的 Agent 跑到第 30 步的时候，上下文里到底有什么？
我之前 dump 过一个跑了 40 轮的多 Agent 系统的完整上下文。结果让我挺吃惊的——72% 的 Token 来自模型自己之前的回复和工具调用返回的原始数据。真正对当前这步推理有用的信息，不到 15%。
也就是说，Agent 每次推理都在为那 15% 付费，同时忍受剩下 85% 的噪声。
这件事让我开始怀疑一个基础假设：我们一直默认上下文窗口里塞的东西越多越好，因为它"保留了完整信息"。但如果大部分保留的信息不仅没用、还在拖后腿呢？
2026 年的几项研究和实践给出了一个反直觉的回答：上下文工程的核心策略正在从"怎么塞更多"转向"怎么留更少"。
MIT 2026：删掉 Assistant 的回复，上下文砍 10 倍
MIT 今年 2 月发了一篇论文，标题很低调——"Do LLMs Benefit From Their Own Words?"——结论一点都不低调。
实验设计很简单：对比两种方式跑多轮对话。标准方式是把完整的消息历史（包括模型自己的回复）全部塞进上下文。而实验组删掉了所有 Assistant 回复，只保留用户消息。
结果：
Removing prior assistant responses does not affect response quality on a large fraction of turns. Omitting assistant-side history can reduce cumulative context lengths by up to 10×.
上下文长度缩减约 10 倍，回复质量几乎不变。而且 36.4% 的多轮提示完全自包含，根本不需要任何历史记录。
为什么？论文给的解释是 context pollution——上下文污染。模型在处理追问时，看到的不仅是新的输入，还有它自己之前每一轮的回复全文，包括其中的错误、幻觉、措辞偏差和错误假设。模型没有任何机制区分"这是我自己的输出"和"这是外部可信信息"。于是早期的偏差通过自我强化的循环被逐轮放大。
这不是记忆丢失的问题——Agent 记性越好，反而被自己的毒话毒得越深。
当然论文也指出了边界：更强的模型（比如 GPT-5.2）从自身历史中提取有用信号的能力更强，移除助手回复确实导致了一定质量下降。所以策略不是"一律删除"，而是选择性过滤——用分类器逐轮判断当前这步要不要保留 AI 之前的输出。
但对大多数 Agent 场景来说，默认假设需要翻转了。问题不应该是"什么时候该修剪？"而应该是"为什么要保留这些？"
四大策略：写出去、即时选、压缩、隔离
MIT 的发现揭示了一个底层问题，但工程落地需要更体系化的方案。今年 Context Engineering 领域逐渐形成了四个清晰的策略方向，每个都有可量化的基准数据。
策略一：写出去（Externalize）
最直接的策略：别让内容留在上下文里。
具体做法是"草稿垫"模式——Agent 把关键发现写入外部存储（文件、数据库、专用记忆工具），上下文中只保留一个轻量级引用（文件路径、文档 ID、URL）。后面的推理步骤不需要完整的历史记录，只需要读自己的笔记。
这听起来简单，但效果显著。Manus 就用了这个模式：Agent 浏览网页后把相关内容保存到文件，然后从上下文中清除网页，只保留 URL 指针。信息可恢复，但不占用注意力预算。
心理模型很简单：把上下文窗口当 RAM 用，不是当硬盘用。
策略二：即时选（Just-in-time Selection）
Agent 不是在会话开始前预加载所有可能相关的信息，而是维护轻量级标识符，在运行时按需调用工具去获取。
最有趣的实践是对工具描述本身也做即时检索。Anthropic 在 2025 年底规范化了"渐进式披露"模式：工具注册时只带简短的发现性描述，Agent 第一次调用某个工具时才加载完整的 Schema。OpenAI、Google、GitHub、Cursor 都迅速跟进了这个做法。
当 Agent 可以访问 50 个以上的工具时，在每一步都呈现所有描述，在第一条消息发出之前就已经消耗掉数万个 Token。渐进式披露把这个问题直接消除了。
策略三：压缩（Compress）
当内容既不能外写也不能即时选时——因为 Agent 确实需要它——压缩是最后一道防线。
这里有个反直觉的真相：LLM 摘要化的效果不如 Observation Masking。
基准数据来自 SWE-bench-Verified：仅靠 observation masking（用占位符 Token 替换旧观察结果，保留推理链但删除原始工具输出）就降低了超过 50% 的成本。混合方法——masking 为主、关键部分选择性摘要——比纯 masking 又降了 7%，比纯摘要化降了 11%。任务成功率还提高了约 2.6%。
原因在于：纯摘要化会使总执行时间增加 13%-15%。摘要步骤本身消耗 Token，而且简化的摘要丢失了足够多的细节，导致后续推理需要更多步骤来弥补。你省了每步的 Token，但增加了总步数。
策略四：隔离（Isolate）
当一个任务确实超出了单个上下文窗口的承载能力时，答案不是塞进去，而是拆开。
多 Agent 架构天然是一种隔离策略。协调者 Agent 把子问题分配给专门的 Worker Agent，每个 Worker 在干净的、聚焦的上下文里运行。只有压缩后的摘要（通常 1000-2000 Token）流回协调者，完整的工作轨迹不会污染主窗口。
代价也不小——多 Agent 架构通常会消耗 10-15 倍的总 Token 量。所以这不是拿来给每个问题都加一套多 Agent 的理由，而是当单 Agent 确实撑不住时的最后选择。
那些"看不见"的成本
再说一个容易被忽视的点：工具设计本身就是上下文工程。
当 Agent 只需要一个函数定义，而你的工具返回了整个大文件的内容时，这就是上下文工程的失败。工具返回的内容应该是最少必要、最大相关。不需要把整个文件塞进去再让模型从中挑——你替模型做过滤，就是帮它省注意力预算。
这跟 MIT 论文的结论一脉相承：Context Engineering 的核心不是在输入端堆信息，而是在每一层做减法。
分层上下文模型：从混乱到有序
把这些策略整合起来，一个更结构化的图景浮出水面。成熟的生产级系统把上下文视为分层状态系统上的编译视图，而不是一个不断追加的字符串：
- 工作上下文（Working context）：单次调用的编译提示词——系统指令、筛选后的历史记录、当前步相关的工具输出
- 会话存储（Session store）：持久化的时序事件日志，结构化记录
- 记忆存储（Memory store）：长期可搜索知识
- 制品存储（Artifact store）：通过句柄引用的大对象，从不直接嵌入
上下文编译——从持久化存储编译成单次工作上下文——变成了一个显式的、可观察的流水线。每个处理器都是过滤、压缩、缓存和路由的插入点。
这种模型带来的一个结构优化值得单独说：把工作上下文分成稳定前缀（系统指令、长期摘要）和变量后缀（最新的输入、新的工具输出）。稳定前缀可以在模型提供商级别缓存，对长时间运行的 Agent 来说，这能显著降低推理成本。
所以
上下文工程不是什么"提示词技巧"。它是一门应用于通过 LLM 上下文窗口的信息流的系统工程学科。那些值得在生产环境部署的 Agent，都是设计者仔细考虑过什么信息进窗口、什么被外部化、什么被压缩、工作在何处被隔离的 Agent。
更大的上下文窗口不是答案。400K 的窗口只会让你推迟崩溃的时间，不会消除崩溃的原因。架构选择——写入、选择、压缩、隔离——才是承重的核心。
而这个领域在 2026 年最大的认知更新是：最好的上下文管理，往往不是你留了什么，而是你扔掉了什么。
Published: https://betterpursue.blogspot.com/2026/06/temppublish_01080083313.html
评论
发表评论