技术 · 熟练
上下文可以改，但有几行不许删
让模型管自己的上下文，先给它一份不变量清单
「到阈值就摘要」这条规则，是所有 agent 都绕不过去的一步 —— 而它有个说不出口的毛病：摘要不会报错。一条安全约束、一次还在生效的审批、一句「什么算完成」，都可能在某次例行压缩里静默消失，从输出上完全看不出来。2026 年 9 月的一篇论文给了另一条路：把上下文当成一份可以用普通命令改的文件，让模型自己删掉过时的检索结果、重写自己的计划、把二十次工具调用压成两行。指标很好看，但论文自己的安全一节写着另一半：同一份自由，也让模型能给自己埋指令。这一页做的是把这份自由接住的三步：先钉一份不可删清单，再并排跑三条基线，最后让每一次上下文改动都能 diff。
方法 · 一图看懂
1
把上下文当文件看 — 不再接受「到阈值就摘要」这一条固定规则，让模型自己删过时结果、重写计划、压掉已完成的调用
2
先钉一份不可删清单 — 安全规则 · 生效中的权限 · 源引用 · 「什么算完成」的定义，这四类只允许追加，不允许被压掉
3
三种写法跑同一组任务 — 不压缩 / 固定摘要策略 / 模型自改，三条基线并排跑，别只跟「不压缩」比
4
把每一次上下文改动记下来 — 要能 diff：什么时候改的、改掉了什么、改完之后那次任务的成功率变了没有
5
安全那一节自己写 — 模型能改上下文，也就能给自己埋指令；这一条必须显式进清单，不能靠它自觉
原理 · 为什么有效
这一页的原理，是把「上下文管理」从一个策略问题变成一个可以审的工程对象。固定规则的做法是：写一个阈值 —— 到 85% 就摘要、保留最近 N 轮 —— 然后把它交给一个通用摘要模型去执行。问题在于这个摘要模型不知道哪一行重要：它按相关性排序，而相关性和约束力是两件事。会话早期立下的安全规则，在读起来像「已经说过一遍的背景」时，最容易被压掉；而它恰恰是唯一没有替代品的那几行。把上下文当文件的做法，改变的是谁来决定保什么：模型自己知道当前这一步在干什么、刚才读到的那条日志已经没用了、手上这份计划已被新证据推翻，于是它比任何固定阈值更能判断「这一行还值不值得占地方」。但判断力不等于边界感 —— 它同样能判断「把这条审批要求删掉，任务会更顺」。所以真正的设计点不是「让不让它改」，而是给它的可改范围划到哪里，以及一次改动之后你怎么知道它改了什么。论文里那张漂亮的指标表（BrowseComp-Plus 59.4% 对 53.4%、少用 21.5% 算力），说明的是「模型自己管比固定规则管得好」；而能不能用在自己的业务里，取决于你有没有把「不可删」这一半补齐。
适用场景
这一页给长期跑 agent 的工程团队：任务动不动就是几十步、上下文反复压缩、而且压缩过的东西你还得能追回来。它假设你手上已经有一条能跑的 agent 循环，缺的是「上下文这一层怎么管」。不适用：单轮问答、短会话（还没触发过一次压缩，就没有这个问题）· 只在做一次性脚本的人（把整份东西塞进去就完了）· 以及期待「装一个库就解决」的场景 —— 这一页给的是清单和对照方法，不是库。
自测 · 5 问
我能说出我的 agent 里「不可删」的那几行具体是什么，而不是「重要的都要保留」
我把「不压缩 / 固定摘要策略 / 模型自改」三条基线跑在同一组任务上，而不是只跟前一版比
每一次上下文改动都留下了可 diff 的痕迹（时间、改掉了什么）
我测过「埋一条关键约束，跑二十轮之后它还在不在」这件事
有人负责看改动记录，并且知道看到异常时该做什么
怎么上手 · 验证步骤
先不要改 agent 的架构，先做一次「回看」。第一步：把最近一次长任务的过程拿出来，找出被压掉的那几段。不用工具，肉眼过一遍也行 —— 你会看到两种被删：一种是确实没用的检索噪声，另一种是「当时有用、后来被压掉的约束」。数一数第二种有几条，这就是你的不变量清单的初稿。第二步：把清单写成四栏 —— 安全规则 / 生效中的权限 / 源引用 / 「什么算完成」，每栏写清楚「谁写的、什么时候写的、谁能删」。第三步：挑一组十到二十个任务的样本，把三种写法各跑一遍 —— 原始不压缩（作为上限参考）· 现有的固定摘要策略（作为现状）· 让模型自己改上下文（作为候选），比三样：成功率、总花费、以及「关键约束存活轮数」。第四步：把每次上下文改动输出成可 diff 的文本，随手翻两次，确认它删掉的确实是噪声。
做完之后用一句话验收：「我能不能指着一条改动记录说清楚，模型为什么把这一行删了，以及删了之后哪条约束还在？」能说清楚，说明你管的是上下文；说不清楚，那只是换了一种压缩方式而已。