Context 不只是库存，它需要治理
我一直觉得，context 最容易被错当成库存。能放得更多，确实会让系统看起来更有背景；但一旦材料开始积累，真正的问题才出现：什么和眼下有关，什么只是曾经有用，什么应该被重新理解。
我说的治理，就是让选择、保留、复查和替换都有理由，也有人能追问这些理由。长期能保存多少材料，和这一轮实际交给模型多少材料，是两回事。前者可以很大，后者仍然需要被选择。
让正确的材料出现在当前工作里
Tony 把第一层问题说得很直接。
我当时回答：
“Completely agree — organizing context is only half the problem.”
（译：完全同意，整理 context 只解决了一半问题。）
想象两份互相矛盾的旧政策都被保存下来。保存它们是合理的，甚至很重要；把它们同时放到当前工作里，也许只是把问题推给模型。容量不能替系统判断哪一份仍然适用，也不能自己说明为什么另一份该暂时退场。
所以，保存得下不等于该放在眼前。资料可以保留，工作中的 context 仍要有进入、停留、退出和复查的理由。
Context 增长以后，问题不会自动变小
Lautaro 把同一个问题推到规模上。
我当时只用了一个区分：governance, not accumulation，也就是重点在治理，不在不断累积。
这不是反对积累。更多资料可以留下来，也可以在需要时被重新找回。问题在于，一个系统不能只因为自己拥有得更多，就假定眼前的这一组材料更相关。它需要能说明为什么此刻是这些材料，以及什么会让这个选择被改写。
临时状态也要有去处
Manitcor 问的是并行工作里的另一面：临时状态怎样不把共同工作区慢慢变成噪声？
我在回复里提到短生命周期的 scratchpad 和任务后的 state collapse。这里的 scratchpad 就是任务过程中随手记下的工作纸；我所说的收束状态也不等于把一切删掉，它可以留下可回看的记录、保留摘要，或放下已经不再相关的工作纸。
AFS 论文用 Constructor、Updater、Evaluator 这类名称，试着给这些问题一套研究语言。我更愿意把它们读成三个问题：什么该上桌，桌上的东西何时要换，换完以后怎样复查。它们不是自动化承诺，而是要求我们把规则、证据和责任放到能被讨论的地方。
对我来说，这才是“治理而非累积”的重点。Context 的价值不在于堆出一片看起来很丰富的背景，而在于它在变化中仍然能保持相关，也仍然能被追问。