上下文腐化

LLM 的表现会随输入上下文变长而下降——且下降是不均匀的，即便任务本身很简单。同一个问题，在 1k token 的上下文里能答对，到了 100k 就会答错，而这种退化不是一条平滑的尾巴：干扰项、位置、以及周围文本 与问题的语义相似度，都会调制退化的程度。"上下文窗口支持这个长度"不等于"这个长度的上下文窗口被用好了"。

对 agent harness 的含义：一个长时间运行的主 agent，其判断质量是一种随上下文被填满而耗竭的资源—— 因此上下文卫生（驱逐、隔离、摘要）不是记账工作，而是能力保全。这正是 certificate-is-the-subagent-boundary 背后那条承重的事实：从子 agent 传回来的东西必须小，既是为了可核查，也是为了不让父 agent 的上下文腐化。

来源：Chroma Research 技术报告《Context Rot》（2025）——通过类似 needle-in-haystack 的评测展示了退化 随输入长度增长而不均匀出现；在 2026-07 的 wiki 提升过程中，从 certificate-is-the-subagent-boundary 引用而来

这条纪律在会话起点的一面：在大型代码库里，开局放进上下文的应该是地图，而不是代码——按目录树形状建的索引，加上文件之间的双向链接，这正是代码本身的两种形状。把 IDE 给人的导航操作（跳定义、查引用）做成工具给 agent，文件只有在被导航到时才进入上下文。其余的一切都刻意留在外面——预加载正是腐化的起点。见 give-the-agent-a-map。