为什么要管理 Context

context 需要管理，是因为模型这一轮能看到的材料是有限的。

更准确地说，不只是 token 数量有限，注意力也有限。即使某些材料在技术上塞得进去，也不代表它们应该进入这一轮。

一个很常见的误解是：既然模型有更长的 context window，那就把资料都丢进去。这样听起来省事，但实际会带来几个问题。

第一是噪音问题。

历史对话、工具输出、失败尝试、日志、检索结果、用户偏好、系统指令都混在一起时，模型不一定能稳定抓住重点。它可能被最近的失败日志带偏，也可能把外部文档里的文字当成当前任务指令。

第二是预算问题。

输入占得越满，留给模型输出、推理、调用工具参数、解释证据的空间就越少。长 context 也通常意味着更高延迟和更高成本。

第三是时效问题。

旧信息不一定还对。之前的任务状态、旧版本代码、过期网页、已经被用户修正过的偏好，如果继续留在主上下文里，可能会污染当前判断。

第四是权限问题。

系统能拿到某些资料，不代表当前 agent、当前用户、当前任务就应该看到。权限过滤不能只靠 prompt 里一句“不要看不该看的东西”。如果信息不该进入这一轮，就应该在 context 组装之前被挡住。

所以 context 管理的目标不是“更多”，而是“更合适”。

这一轮模型最该看到什么？哪些材料只是背景？哪些是硬约束？哪些是证据？哪些只是失败轨迹？哪些信息已经过期？哪些来源不可信？哪些内容应该保留原文，哪些可以变成摘要？

这些问题都属于 context 管理。

例如一个 coding agent 连续跑了几次命令，前几次失败，最后一次成功。下一轮不一定还需要看到完整失败输出。更好的做法可能是：

- 主上下文只保留最后成功路径

- 失败轨迹压缩成一条摘要

- 原始日志留在 trace 里，需要时再展开

这样不是篡改历史，而是把“当前工作视图”和“完整事件记录”分开。

再比如检索资料时，系统可能先找到十几段相关内容。但进入当前轮的，不应该是所有结果的堆叠，而是少量有来源、有时间、有相关性的证据。其它候选材料可以留在外部，等模型需要时再展开。

这也解释了为什么 context 是模型这一轮能看到的材料，不是系统知道的一切。系统知道很多东西，但每一轮都要重新决定：现在到底递给模型哪一小部分。

agent 的很多能力，其实都可以先看成 context 管理的不同形式。

`memory` 是把不在当前窗口里的信息取回来。

RAG 是从外部知识源取回候选证据。

compact 是把长历史改写成更短、更稳定的当前状态。

`subagent` 是给局部任务创建更小、更干净的 context。

skill 是在合适的时候把一组任务规则、输出契约和工具偏好放进 context。

`smart read layer` 是在材料进入候选 context 前，先把不同类型的对象处理成更可用、可追溯、可展开的形态。

所以一个 agent 不是简单地把聊天记录越堆越长。它更像是在持续维护一个工作台：把当前任务需要的材料摆上来，把过时和无关的东西收起来，把证据贴近结论，把高层约束放在不会被淹没的位置。