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