上下文与记忆管理 (C)
ETCLOVG 之 C 层：模型跨时间尺度看到什么。为何须工程化、三层记忆、长程技巧、上下文漂移与极限。
本节对应综述《Agent Harness Engineering: A Survey》§5，是 ETCLOVG 七层的第三层，也是 prompt／context engineering 与 harness engineering 交汇之处。核心工程问题一句话可述：在每一步给模型恰好正确的信息、不多不少。上下文太少，agent 缺乏 正确行动所需的状态；太多，性能会以可度量、跨模型一致、却尚未被完全理解的方式退化。本节按时间尺度组织。
为何上下文必须被工程化
综述从架构层面说明“更大的窗口并不能解决记忆问题”，给出三条机制性证据：
- 注意力的二次成本：transformer 自注意力对每对 token 计算关系，n 个 token 产生 n² 权重，计算与内存随长度二次增长。 FlashAttention 与位置编码插值只降常数因子，二次结构是架构性的——把上下文翻倍不是成本翻倍而是翻四倍，因此上下文 窗口是稀缺资源。
- U 形注意力曲线（Liu et al., 2024）：在 20 篇文档的多文档问答中，相关文档位于上下文中部时准确率比置于首尾下降 超过 30%，且该曲线跨模型、任务、长度普遍成立（含专门长上下文训练的模型）。含义直接：信息的位置与信息的存在 同样重要。
- 规模下的 context rot（上下文腐坏）（Hong et al., 2025）：在隔离输入长度与任务难度的受控条件下评测 18 个前沿模型 （GPT-4.1、Claude Opus 4、Gemini 2.5、Qwen3 等），每个都随输入增长退化，且退化非均匀、在窗口填满前就开始——标称 200K 的模型可能在 50K 就显著掉分；语义歧义查询比精确匹配退化更陡。这不是边界情形，而是任何跨多步累积工具结果、 中间推理、文件内容的 agent 的正常工况。
从 prompt engineering 到 context engineering
二者的差别是范围的差别：prompt engineering 优化对单次模型调用的、大体静态的文本输入；context engineering 优化多步 任务中每一步模型可见的完整信息状态。Anthropic 应用 AI 团队将其定义为“在 LLM 推理时策划并维护最优 token 集合的策略集， 包括所有可能落入其中、prompt 之外的信息”，其指导原则是“寻找使每一步产生期望结果概率最大化的、最小的高信号 token 集合”。 推理时的上下文包含系统提示、工具定义与 schema、历史轮次、当前轨迹的工具结果、检索到的文档或记忆、动态注入的工作状态—— 它们竞争同一份有限的注意力预算。生产实践已收敛出与操作系统内存层级对应的三层记忆架构（活动窗口／会话级／跨会话）。
短期：管理活动上下文窗口
| 技术 | 要点 | 代表 |
|---|---|---|
| 系统提示校准 | 找“合适的 altitude”——过具体则脆弱、过笼统则无指引；从最小提示起步、经验性补充 | Effective Context Engineering |
| token 高效的工具设计 | 工具定义每次调用都注入，大集可在读到用户请求前耗数万 token；宁可少而富表达 | — |
| 即时检索与渐进披露 | 维护路径/查询/链接等轻量标识按需加载；Claude Code 会话开始载 CLAUDE.md、以 glob/grep 即时导航 | Agent Skills |
| KV-cache 感知设计 | Manus 称 KV-cache 命中率为“生产 agent 最重要的单一指标”（缓存 $0.30 vs 未缓存 $3.00/MTok）；三规则：前缀稳定、append-only、确定性序列化 | Manus Context Engineering、Context Management |
Manus 的一个精细处理：用上下文感知状态机在解码时 mask token logits 以阻止选择不可用动作，而非在运行时修改工具定义 列表（后者会因工具定义位于序列化上下文前部而令后续缓存全部失效）。
中期：会话状态与跨运行持久化
介于活动窗口与完整长期记忆之间。几百 token 的结构化工作状态即可桥接本会让 agent 丢失全部进度的上下文重置。
| 技术 | 要点 | 代表 |
|---|---|---|
| 结构化笔记 | 维护 NOTES.md/todo.md，运行开始读、清理前更新，把工作记忆外部化 | Structured Note-Taking |
| 基于文件的规划 | 把完整规划表示写盘、按需选择性加载 | planning-with-files、Trellis |
| 跨运行注入 | 捕获上一运行显著输出并前置到下一运行，无需向量/图库 | claude-mem、everything-claude-code（>150K stars） |
中期取舍：以远低于长期记忆的基础设施成本提供更多连续性，但信息只向前流动、不从索引存储检索，且不擅长大体量历史。
长期：持久记忆系统
提供跨会话、任务、实例的、可索引可检索的存储，支持任意召回。
| 系统 | 贡献 |
|---|---|
| MemGPT | 把窗口类比 RAM、外部存储类比 disk，给模型显式换页的函数调用——OS 虚拟内存的精确类比 |
| Generative Agents | Memory Stream 的“观察—反思—检索”三元组成标准模板，检索融合 recency／importance／relevance；消融显示三者各自独立贡献 |
| MemoryBank | Ebbinghaus 遗忘曲线式动态遗忘 + 用户人格摘要 |
| Mem0 | 部署最广（向量＋图＋KV 三后端；LOCOMO 上比原生记忆高 26% 准确率、省 90% token；被 AWS Agent SDK 选为记忆提供方） |
| A-MEM | Zettelkasten 式动态知识网络，新记忆回溯更新既有相关笔记 |
| Hindsight | retain/recall/reflect；主张“学习”而非仅“记住”；LongMemEval SOTA |
| Honcho | “dreaming”后台推理构建用户模型；实体中心支持多 agent 共享用户 |
| cq | 跨 agent 实例的集体记忆，MCP 原生、三层（本地/组织/跨团队），post-error hook 防重复失败 |
学术分类：Zhang et al. (2025) 区分短期工作记忆与长期（再分语义／程序／情节），形式化 write-read-manage 循环；Du (2026) 以 POMDP 循环 + 三维分类归纳 Pattern A 单体上下文／B 窗口＋检索／C 分层＋学习式控制策略（大致对应短/中/长期）。
长程技巧：让 agent 在 100+ 轮保持连贯
- 上下文压缩（compaction）：窗口逼近上限时摘要累积状态后重启；调优应先最大化 recall 再迭代提升 precision，不可反向 （过早删多会丢失后续所需且不可恢复）。最轻形式是工具结果清理（用紧凑路径引用替换已被行动过的完整输出，现为 Anthropic 平台产品级特性）。
- 子 agent 上下文隔离：把子任务交给拥有全新窗口的专属 agent，只回传 1000–2000 token 浓缩结论；Manus 指出共享上下文 昂贵（更大 prefill + 丧失跨系统提示的 KV-cache 复用），共享与否须按任务显式权衡。
- 混合决策框架：按任务结构选择——总需要的预载、条件需要的即时检索、窗口饱和时压缩、探索会污染时派生子 agent；配合 checkpoint/resume 挺过瞬时失败。综述据此给出责任划分：上下文管理应是基础设施的职责而非 agent 的。
上下文漂移与当前方法的极限
综述在约束瓶颈论下把 context drift 刻画为控制器侧失败模式：模型只看到 harness 暴露的状态投影，上下文丢失或失真是 harness 属性而非仅模型属性。它与 context rot 同源但不同——rot 是单步属性（固定上下文加更多 token 降低质量），drift 是 长轨迹属性（100+ 轮后重复已做工作、无意识自相矛盾、丢失动机目标）。根因不只是窗口饱和：即便激进压缩，每步幸存摘要的 细微不准会随时间累积，当前架构无法检测这种偏离。评估侧有缺口（MemBench 多会话记忆质量、MemoryArena 相互依赖的多会话、 增量多轮评估隔离记忆与生成质量）——它们证明漂移发生，但尚不足以提供防止它所需的机制性理解。综述由此论证：上下文工程本身 不能解决长程可靠性，需要带验证回路、战略性 human-in-the-loop 检查点、行为偏离异常检测的完整 harness——这正是把 O 层 与 G 层 作为上下文工程必要补充而非独立关切的动机。