技术 · 深入
上下文不是越摘越短，是越养越准
摘一次丢一点，重写一次塌一点
把上下文当成「一份不断被摘要压缩的东西」，到后面一定会变成一份看起来什么都说了、其实什么都用不上的东西。这一页给的是另一种养法：把它当成一份由三个角色分工维护、只做增量修改的 playbook —— 产出轨迹的只管产出，复盘的只负责提炼「什么成了 / 什么没成」，整理的只往条目里加一行或改一行（⛔ 不是每轮重写整份）。同时点名两个必然会踩到的塌缩模式，以及为什么「每轮重写」看起来更干净、其实破坏最大。
方法 · 一图看懂
1
先分清「这份东西是资产还是消耗品」 — 资产会有来源与追溯，消耗品每轮重写；⛔ 混在一起就必然塌 —
2
把「重写」换成「改条目」 — 只加一条、只改一条、只标失效一条，其它一个字不动 —
3
给每条留来源 — 记清它来自哪一轮 / 哪次失败；⛔ 填不出来源的就是该被怀疑的条目 —
4
分三个环节维护 — 记录只记事实 · 复盘只答「什么成了、什么没成」· 落条目只做加改标失效 —
把「重写」换成「改条目」
直觉上「每轮重写一版更好的」最干净，但结果是每一轮都会悄悄丢掉一点上一轮还活着的东西 —— 丢一次看不出来，丢十轮之后那份 playbook 只剩几句放之四海皆准的废话。增量改的判据是「这次只加/改哪一行」：新学到的加一条，被证伪的改一条，其它一个字不动。这样任何一条经验都能追溯到它是哪一轮、从哪次失败里来的；重写版没有这个追溯。落地做法很土：给 playbook 加一列「来自哪一轮 / 哪一次」，凡是填不出这一列的条目，就是该被怀疑「是不是早该删了」的条目。
两个必踩的塌缩：越摘越薄 · 每轮塌一点
第一个叫 brevity bias（简洁偏置）：每摘要一次，领域细节就掉一层，而细节恰恰是这份上下文有别于通用建议的地方 —— 摘要工具天生偏好「短、通用、听起来对」。第二个叫 context collapse（上下文塌缩）：不是一次砍掉，是每一轮重写都侵蚀一点、且不报错，直到整份东西从「能指导具体动作」退化成「谁看都对、谁用都不灵」。两者的共同症状是「内容还在，但已经不长在你的场景上了」 —— 判据不是长度，是「这份东西里还有没有只有你这个场景才会有的那句话」。
三角色怎么分工（谁写 · 谁提炼 · 谁守门）
把维护这件事拆给三个不同职责的环节，比让一个环节「既干又总结」稳得多：① 产出方只负责记录这次实际做了什么、结果如何；② 复盘方只回答「什么成了、什么没成」，别的都不许写；③ 整理方负责把复盘结论落成条目 —— 加新条目、改旧条目、标失效，但⛔ 不许重写整份。三层分开的好处是：某一条经验错了，你能定位到是复盘结论错了还是落条目时抄错了；混在一起就只能整份重来，而整份重来正是塌缩的入口。
原理 · 为什么有效
为什么值得为这点「整洁」付出代价 —— 因为朴素迭代摘要的成本是延迟暴露的：它在第 3 轮、第 5 轮都不会报错，你在第 20 轮才发现它开始给通用建议。增量维护把问题从「事后才发现」变成「每次都能看见」 —— 每一轮你都知道自己加了几条、改了几条、有没有条目被标失效。参考实测：把上下文按这条思路组织，agentic 任务上 +10.6%、金融推理上 +8.6%，且不需要微调模型，改的只是这份东西怎么被维护。
适用场景
适合：同一个 agent 要连续跑几十轮的人 · 已经有一份「经验总结」但明显感到它在变水 · 上下文快到窗口上限、又不想靠硬摘要续命 · 需要在几个月后回答「这条规矩是哪来的」。
不适合：单轮任务 · 每次都是新会话且不共享经验 —— 没有累积就没有塌缩，直接摘要最省事；也不适合以事实查询为主、几乎不产生经验的场景。判据一句话：「这份上下文三个月后还要不要指导具体动作？」要 ⇒ 按上面养；不要 ⇒ 摘要即可。
自测 · 5 问
你的那份经验总结里，还有几条是「只有你这个场景才会有的」
最近一次更新它，是加了一行，还是整份重来
某一条经验被证伪时，你是改它还是把整份重写一遍
你能不能说出某条规矩是哪一轮、从哪次失败里来的
这份上下文现在的长度，是用来兜底的还是用来指导动作的
怎么上手 · 验证步骤
第一步最省事也最有效：给现有那份总结加一列「来源」（哪一轮 / 哪次失败），填不出来的条目先标黄、别急着删。第二步把「更新」这个动作改成「只加一行或只改一行」——这一条是全部的关键，做不到这条，后面两步都白搭。第三步才把它拆给三个环节：记录、复盘、落条目分开做。⚠️ 不要在没加「来源」列之前就拆三个角色 —— 拆完你会不知道该往哪一条上落。
每周自问两句：① 这一周加的条目里，有没有一条能只在你的场景成立的 ② 有没有哪一条被改过但没说为什么改 —— 第 ① 句答「没有」说明你在收通用套话；第 ② 句答「有」说明改的动作没留痕，下一轮就会重踩。