Agent Context Manager
面向长时间 agent 工作的跨 harness 上下文压缩与召回。
结论先行
GitHub: OpenCodexLabs/agent-context-manager.
Agent Context Manager 起点是一个非常普通的痛点：严肃的 agent 工作不会发生在一个干净的聊天窗口里。它会在 Codex、Claude Code、CodeBuddy、本地终端、浏览器会话、写到一半的笔记和旧调试轨迹之间来回移动。
这个项目围绕一句话展开：全局召回，本地压缩，有意识地应用。 目标不是给 agent 无限记忆，而是在正确时刻找回正确的工作集，并让人或 agent 在影响下一轮会话前先审阅它。
为什么需要它
痛点通常出现在第三次或第四次 handoff。你昨天已经解释过项目约束，已经在另一个 harness 里找到了坏掉的命令，也已经决定过不要碰某个高风险文件。但下一次 session 重新开始时是空白的，于是用户又变成了记忆总线。
这不仅烦人，还会改变工作质量。agent 可能重复失败路径、错过旧决策，或者花前十分钟重建同一份上下文。本地 trace 明明存在，但埋在错误的位置和错误的格式里。
核心想法
缺失的层不是另一个私有记忆盒子，而是一张上下文恢复工作台。旧 trace 应该可搜索；当前 session 应该可压缩；结果应该作为候选上下文被预览，而不是静默注入 prompt。
所以 Agent Context Manager 刻意保持小。它坐在 harness 旁边，不试图成为 agent、IDE 或操作系统。它只给 workflow 提供三个具体动作：recall、compact 和可审阅的 jobs。
| 操作 | 含义 | 为什么重要 |
|---|---|---|
| Recall | 在旧的本地 agent trace 里搜索相关片段。 | 下一轮 session 可以恢复先前决策，而不必让用户重新讲一遍。 |
| Compact | 把当前 session 总结成更小的候选上下文块。 | 长任务可以继续推进，而不需要复制整段 transcript。 |
| Jobs | 排队、预览、应用或丢弃上下文结果。 | 上下文在影响当前 agent 前保持可审阅。 |
工作流
一个好的上下文工作流应该像清理工作台。先搜索旧 trace，再把当前 session 压缩成更小的 handoff，然后审阅候选块。只有在这之后，下一轮 agent 才应该接收这段上下文。
审阅步骤就是产品边界。上下文很强，但过时或不相关的上下文也很危险。Agent Context Manager 把上下文保持为一个显式 job，可以预览、应用或丢弃。
为什么重要
更深一层看，agent context 正在成为一等 artifact。它不只是聊天历史，而是决定下一轮 agent 是否能负责任行动的项目状态。
对于长时间 coding 工作，当前 prompt 应该包含当前目标、硬约束、先前决策、动过的文件、试过的命令和未解决风险。它不应该包含旧 transcript 的每一个分支。Agent Context Manager 是一种从本地证据重建这个工作集的实际方式。
什么时候使用
| 适合使用 | 不该滥用 |
|---|---|
| 你在多个 coding-agent 工具之间切换。 | 任务只是一次性小编辑，没有先前项目上下文。 |
| 你需要恢复旧决策、bug 或约束。 | 旧 trace 可能包含你不希望被搜索的敏感内容。 |
| 你想在 session 之间做 compact handoff。 | 你需要一个完全自动、没有人工审阅的记忆系统。 |
一句话故事
如果 agent 要做严肃的多日工作，它就需要一层上下文恢复机制。不是因为模型应该记住一切，而是因为用户不应该成为昨天 trace 和今天任务之间唯一的桥梁。
Agent Context Manager 把散落的本地 trace 变成可审阅的上下文操作：recall、compact，并有意识地 apply。