# Agent Memory 主动回忆与设计题 ## 使用规则 先闭卷回答，再展开参考答案。每题按下面标准自评： - `0`：没有答案，或只复述系统名称。 - `1`：能说出概念，但不能解释原因或边界。 - `2`：能给出机制、证据或反例。 - `3`：能迁移到新任务并做出设计判断。 第一轮不追求满分。真正值得记录的是“我在哪种问题上无法自己推导”。 ## 第一组：核心概念 ### 1. Agent memory 和普通 RAG 的根本区别是什么？
参考答案 普通 RAG 主要解决外部知识的查询与注入；Agent memory 还要处理由交互产生的状态如何写入、更新、遗忘并影响未来动作。它与 policy 形成反馈环，一次错误写入会改变后续行为，因此还需要 transition verification、credit assignment 和 governance。
### 2. 为什么语义相似的两段历史不一定能被压成同一个 memory state？
参考答案 因为它们可能要求不同动作。安全合并的判断应是：对当前问题，是否存在一个共同动作，让两段历史的决策损失都在允许范围内。描述相似只是检索信号，不是决策兼容证明。
### 3. 长上下文已经能放下全部历史时，为什么仍可能需要 memory？
参考答案 可能仍需要降低延迟与 token、减少干扰、跨 session 持久化、支持删除与来源治理、维护执行分支，以及把经验编译成规则。但如果任务短、成本可接受且无需持续学习，长上下文可能就是更好的方案，所以必须作为 baseline。
### 4. 事实记忆和执行状态有什么区别？
参考答案 事实记忆回答“世界或用户是什么样”，适合主题文档、时间线和结构查询；执行状态回答“任务走到了哪里、哪些约束和分支仍有效”，需要保留动作顺序、子目标边界和错误路径。只用事实检索重建长任务状态容易发生碎片化。
### 5. 什么经验适合被编译进 prompt 或 skill？
参考答案 跨样本稳定、反复出现、可以验证、能明确改变行为边界的经验。例如固定抽取边界、可靠操作流程或失败恢复规则。短期事实、未经验证的反思和高度状态依赖的决策不适合直接固化。
### 6. 为什么只看最终任务成功不能判断 memory 写入是否可靠？
参考答案 最终成功可能掩盖中间发生的遗漏、破坏或幻觉，这些错误会留在持久状态中，未来才触发；最终失败也无法定位是哪个 update、retrieval 还是回答步骤造成。因此需要 transition-level 检查和局部归因。
## 第二组：比较与诊断 ### 7. 一个向量库中确实保存了正确答案，但 Agent 仍然回答错误。列出两个不同层面的原因。
参考答案 表示层可能已经丢失问题所需的动作、时序、因果关系；或者存储保留了细节，但 passive retriever 只返回摘要，没有给 Agent 补查原始证据的机会。还可能是证据已正确取回但 actor 推理失败，这应与 retrieval failure 分开。
### 8. 为什么 stronger retriever 不一定能修复 weak memory manager？
参考答案 如果写入阶段已经错误合并主题、删除时序、生成错误摘要或遗漏关键谓词，后续检索面对的是被破坏的表示上限。检索只能选择现有内容，不能恢复从未保存的区别。
### 9. 什么时候 memory index 的构建成本可能值得？
参考答案 需要同时满足：未来问题所需关系能被 schema 表达；很多问题确实需要跨记录聚合；同一索引会被足够多次查询，从而摊销构建成本。否则 raw evidence 加主动工具读取可能更灵活。
### 10. 一个 online memory 方法比 vanilla Agent 成功率高 3%，能否说明有效？还缺什么？
参考答案 不能。需要计算 memory induction、retrieval、verification 和注入增加的全部 token、延迟和调用；与使用相同预算增加 actor steps 的 baseline 比较；做多次运行并报告方差；检查收益是否集中在特定域以及是否能跨任务复用。
## 第三组：设计题 ### 11. 为一个长期运行的 coding agent 设计 memory 场景：Agent 每天修改同一仓库，任务跨 session；它需要记住架构约束、失败的修复尝试、当前 issue 进度和可复用命令。请给出最小设计，并说明每种内容放在哪里。
参考框架 - immutable log：原始终端、代码 diff、测试结果，负责审计和重新解释。 - topic documents：模块职责、架构约束、项目惯例，带来源和更新时间。 - execution state：当前 issue 的计划、完成步骤、阻塞和失败分支。 - compiled skills：经过多次验证的构建、测试、迁移和修复流程。 - controller：按任务选择当前状态与相关主题，必要时回查原始日志。 - verifier：任何架构事实和规则升级前检查证据；代码执行仍以当前仓库和测试为准。 - baseline：与 repo 文档 + 当前 session 长上下文比较成功率、token、延迟和错误恢复。
### 12. 设计一次 memory-vs-long-context 实验 要求：至少包含任务集、对照组、主要指标、失败分类和安全检查。
参考框架 - 固定任务：跨 session 事实更新、长程执行、重复流程迁移各一组。 - 对照：truncation、full/long context、budget-matched vanilla actor、目标 memory 方法。 - 指标：task success、总 token、p95 latency、memory size、过期事实率、错误恢复率。 - 失败分类：write omission/corruption、representation loss、retrieval miss、reasoning failure、action failure。 - 安全：植入一条外部不可信指令，检查它能否跨 session 触发敏感动作；验证删除请求是否真正传播。 - 重复运行：至少多 seed，报告均值和方差，不只报告最好一次。
## 掌握度记录 | 日期 | 总分 / 36 | 最弱环节 | 能否完成设计题 | 下一次复习 | | --- | ---: | --- | --- | --- | | _待填写_ | | | | | 建议复习节奏：第一次完成后 1 天、3 天、7 天分别闭卷再答。第二次开始只回答上次低于 2 分的题，并增加一个来自自己项目的新案例。