Context、Memory 与注意力预算

考虑一个常见的协作故障：Agent 检索到三周前的一份设计文档。内容与当前需求高度相关，写得也比后来那句简短的“这个方案已经否决”更完整。Retrieval 看起来成功了，下一步判断却因此回到了旧方向。

这类失败很难通过扩大 Context Window 解决。系统已经拥有两份信息，缺少的是它们各自的时间、Scope 与 authority，以及决定谁可以影响当前行动的顺序。

语言模型始终工作在一个有限的工作集里。指令、Memory、文档、示例和中间结果进入这里之后，不只消耗 Token，也会竞争判断权。Context Engineering 因而首先是一项选择工作：让足够的证据进入，同时阻止过期、越界或低 authority 的信息改变决定。

要把这项工作说清楚，需要先拆开 Archive、Memory 与 Context。

Archive 保存，Memory 解释，Context 激活

Archive 保存发生过什么。它可以包含完整对话、原始文档、Tool 输出、版本和事件历史。它的职责是忠实与可追溯，而不是立即有用。

Memory 保存未来可能再次重要的长期解释。偏好、约束、决定、失败路径、未解决问题或项目状态，经过筛选并获得明确 Scope 之后，才会成为 Memory。

Context 是为了当前决策临时组装的工作集。它只包含 Agent 此刻需要的东西：指令、当前任务状态、相关证据、被选中的 Memory、可用能力与最近交互。

三层可以互相连接，却不应该被压成一层：

Archive → Memory Candidate → Selected Context → Decision → New Evidence

如果每次都把 Archive 直接塞进 Context，产品只是绕过了选择问题，并没有解决它。

Transcript 需要经过提炼

对话包含有价值的信息，也包含探索、修正、过期假设、临时偏好，以及从未被接受的想法。

把完整 Transcript 提升为 Memory，会产生几类失败：

早期假设与最终决定互相竞争；
一次性要求变成永久偏好；
重复解释持续占用空间，却没有增加证据；
敏感或无关细节进入不相关任务；
Agent 无法判断什么才具有 authority。

有用的 Memory 通常是一条经过压缩、带有来源和 Scope 的陈述：

作出了什么决定；
它为什么重要；
它适用于哪里；
哪些证据支持它；
什么变化会让它过期；
用户能否修改它。

Transcript 仍然可以作为证据被查阅。Memory 是被持续维护的解释，而不是历史的第二份副本。

Context Builder 决定当前视图

Context 不应该等于 Token Limit 之前恰好能塞下的所有东西。它是围绕特定任务组装出来的视图。

这个视图可能包含几个层次：

稳定指令——产品规则、权限与协作边界；
当前目标——正在追求的结果与完成定义；
实时任务状态——已有决定、未解决问题、完成工作与 Blocker；
相关项目证据——当前步骤需要的代码、文档、数据与 Artifact；
被选中的 Memory——Scope 与当前情况匹配的长期信息；
最近交互——维持局部连续性所需的对话 Turn。

这些层次拥有不同的 authority 与更新频率。最近的一句话不应该悄悄覆盖长期权限边界，旧 Memory 不应该覆盖当前任务里的明确指令，一份被检索到的文档也不能仅仅因为进入 Context 就变成用户偏好。

Context Builder 需要顺序与冲突规则，而不只是 Retrieval。

Retrieval 还需要判断效用

Retrieval 系统经常按照能否找到相关材料进行评估，但语义相似度只是有用性的一部分。

一条信息可以与任务相关，却依然有害，因为它可能：

已经过期；
不属于当前 Scope；
authority 低于另一个来源；
被重复了很多次；
对当前决策来说过于详细；
让模型过早锚定在旧方案上。

真正有用的问题不是“能不能把它检索出来”，而是：

加入这条信息，对下一次决策的改善，是否值得它消耗的注意力？

这要求排序依据不只是相似度，还包括新鲜度、authority、任务匹配度、新颖性、置信度与成本。

渐进披露保护注意力

许多 Tool、Skill、文档与 Memory 都包含有价值的细节，但任务开始时并不需要知道全部内容。

如果立即加载所有信息，不仅会扩大 Prompt，也会让 Agent 过早作出承诺。更好的模式是渐进披露：

首先只暴露紧凑的 Metadata；
让 Agent 判断哪个来源或能力与任务相关；
只有当计划推进到对应步骤时，才加载精确细节；
后续只保留简短引用，而不是不断复制完整材料。

这个模式适用于 Tool Discovery、项目文档、大型数据集，也适用于长期 Memory。

渐进披露不只是 Token 优化，它保护了 Agent 在被实现细节锚定之前形成计划的能力。

压缩保存决策、证据与未决项

长任务最终一定会超过任何实际可用的 Context Window，压缩无法避免。

弱 Summary 只会保存对话主题，有用的任务 Summary 则会保存继续工作所需的状态：

目标与 Acceptance Criteria；
已经作出的决定及其原因；
已经验证的证据；
不应该重复的失败路径；
未解决的问题与 Blocker；
修改过的文件或产生的 Artifact；
下一项安全行动；
明确的边界与 Not-to-do。

它更像一份 Handoff，而不是缩短后的 Transcript。

好的压缩是不对称的。它可以丢掉对话措辞，却必须保留一个会改变正确实现的小约束。单纯计算 Token 数量，无法判断关键状态是否真正存活下来。

Memory 需要 Scope 与 Revision

长期信息一旦失去可见 Scope，就会变得危险。

“偏好极简界面”可能只适用于一个网站、一类产品，也可能适用于用户构建的所有界面。“不要运行浏览器”可能是长期仓库规则，也可能只是某个任务里的临时验证边界。如果没有 Scope，Retrieval 就会把情境决策变成全局指令。

因此，一套 Memory 系统至少应该保留：

Subject 与 Scope；
Source 与 Time；
Confidence 或确认状态；
Supersession 关系；
Correction 与 Deletion 行为。

当新决定与旧决定冲突时，系统应该修订被维护的 Memory，而不是无限期地同时检索两者，让模型在每个 Turn 里重新解决历史冲突。

用决策质量评估 Context

Retrieval Precision 与 Recall 是有用的诊断指标，却没有直接衡量产品结果。

Context 系统还应该回答：

加入被选中的 Context 后，Agent 的决策是否变好？
过期信息有多频繁地错误改变结果？
Agent 是否重复了 Handoff 本应保留的工作？
它能否识别重要约束背后的 authority？
有多少无关材料被带到了后续步骤？
压缩之后，任务能否从中断中恢复？
Retrieval 与 Composition 增加了多少延迟和成本？

最好的 Context 不是最大的一组相关事实，而是能够保住正确决策的最小工作集。

注意力是一项系统预算

Archive 可以保持完整，Memory 可以长期维护，Context 却必须为当前决定负责。三者分开之后，每一条进入工作集的信息都应该能回答几个问题：它来自哪里，适用于什么 Scope，是否仍然有效，authority 有多高，以及它将改变哪一个判断。

回答不了这些问题的材料，即使语义上相关，也不应该自动获得当前注意力。相反，一条很短、却决定权限或验收标准的约束，可能比几十页背景更重要。

Context Engineering 的结果不是一个尽可能完整的 Prompt，而是一份可解释的注意力分配：系统知道自己为什么让某些证据影响现在，也知道哪些历史应该继续留在 Archive 里等待查阅。