[!info] related notes

• 所属 MOC：Agent Engineering MOC、Coding Agent Memory MOC
• 核心概念：AI Agent Memory Layer
• 边界关系：Memory、Context、Knowledge 与 Instruction Files 的边界
• 上下文：Context Engineering MOC

Agent Memory Types & Policies

[!abstract] 核心结论 Memory System 的难点不是“把信息存下来”，而是决定什么值得记、写到哪个作用域、什么时候取回、发生冲突时信谁、何时遗忘、谁有权查看和删除。

两种分类维度不要混用

按生命周期

Working / Short-term
→ 当前任务或会话内使用

Long-term
→ 跨会话、跨任务持续存在

按功能与内容性质

Working   → 当前正在处理什么
Episodic  → 过去发生过什么
Semantic  → 稳定事实是什么
Procedural→ 某类任务怎么做

“短期/长期”说的是保留时间；“情景/语义/程序性”说的是内容类型。Working 更强调当前可用的信息工作集，可以临时包含上述几类内容，不是与它们完全正交的内容类别。Episodic Memory 也可以长期保存。

四类记忆

类型	典型内容	更新方式	风险
Working	当前目标、计划、中间结果、未完成步骤	每个 Run 持续变化	与业务状态混淆、过期后误用
Episodic	某次修复、发布、对话或失败经历	从事件/总结提取	过度概括、缺少来源
Semantic	用户偏好、项目约定、稳定事实	Upsert / Versioned Fact	新旧冲突、事实过时
Procedural	构建、测试、发布、排障流程	显式规则或经验归纳	把偶然成功当通用流程

Working Memory 与 Run State 的边界

Working Memory 可以帮助模型推理，但关键执行事实应进入明确 State：

Working Memory
→ 模型当前参考的临时信息

Run State
→ Runtime 判断下一步和恢复位置的权威状态

Business State
→ 业务数据库中的最终事实

不要只靠一段自然语言摘要恢复支付、审批或工具副作用。

一个成熟 Memory Pipeline

Observation / Conversation / Tool Result
→ Candidate Extraction
→ Validate Source / Scope / Sensitivity
→ Classify Memory Type
→ Deduplicate / Resolve Conflict
→ Persist with Provenance + Version + TTL
→ Retrieve by Task / Scope / Relevance
→ Filter / Rerank / Budget
→ Inject into Context
→ Observe usefulness / correction / deletion

Memory 写入和读取都应是受策略控制的过程，而不是每轮自动向量化全部聊天。

Write Policy

写入前至少判断：

1. 信息是否跨任务仍有价值？
2. 是用户明确陈述、工具验证，还是模型推断？
3. 作用域是用户、组织、项目、仓库、分支还是会话？
4. 是否包含 Secret、PII、医疗或其他敏感信息？
5. 是否已有相同或冲突记录？
6. 是否需要用户确认或可见的“记住”提示？
7. 需要永久保存、TTL，还是只保留一次 Run？

[!warning] 推断不是事实 “用户可能喜欢 X”应带置信度和来源，不能无条件覆盖用户明确偏好。

Retrieval Policy

“语义相似”只是候选条件。取回还应考虑：

same user / tenant / project?
fresh enough?
authoritative enough?
relevant to current decision?
conflicts with explicit instruction or current state?
worth the context budget?

建议先做 Scope / Permission / Freshness 过滤，再做相似度或 Rerank。

Conflict Policy

常见冲突：

• 用户新偏好 vs 旧偏好；
• 当前代码 vs 旧架构记忆；
• 显式 AGENTS.md vs 自动归纳的 Procedural Memory；
• 两个来源对同一事实描述不同。

先区分事实判断与行为指令：

• 事实判断：用当前可核实的拥有方数据校正过时记忆，保留历史事实所属的时间和版本。
• 行为指令：按当前系统与任务的指令优先级决定做什么；用户当前明确要求优先于旧偏好或自动归纳的记忆，同时仍受上层权限边界约束。
• 规则冲突：先核实来源、适用范围和授权，不能让检索到的“流程经验”自行变成新指令。

例如用户要求升级旧部署时，“当前仍运行旧版本”是实施起点，不是拒绝升级的更高优先级指令。相反，用户希望部署已成功，也不能把观测到的失败改记为成功。

不要用一个全局“最新时间优先”处理所有冲突。无法确定的冲突应保留证据并标为待核实，不能靠置信度自动覆盖。

Forgetting、Expiration 与 Correction

遗忘不是缺陷，而是正确性机制：

• TTL：时效性强的状态自动过期；
• Supersede：新版本替代旧事实但保留审计链；
• Decay：长期未使用且低价值的候选降权；
• Delete：用户撤回或合规删除；
• Rebuild：从当前权威源重新生成项目记忆。

必须能区分“从检索结果隐藏”和“真正从持久存储删除”。TTL 过期通常只表示不再可用；删除是否覆盖原文、向量索引、缓存、派生摘要与备份，需要按各存储层的保留策略核实。

Privacy 与 Governance

至少具备：

• 明确作用域与租户隔离；
• 来源、创建时间、更新者和用途；
• 查看、修正、删除与导出能力；
• 敏感字段最小化和加密；
• Retention Policy；
• 不把 Secret 或一次性 Token 写入长期记忆；
• 多 Agent 共享前的最小权限检查。

评估 Memory 是否有用

不要只测“能不能检索到”。还要测：

• 任务成功率是否提高；
• 错误记忆是否导致回归；
• Context Token 和延迟增加多少；
• 冲突/过时记忆是否被正确抑制；
• 用户纠正后是否真正更新；
• 不同租户之间是否零泄漏。

掌握标准

• 能区分生命周期分类与内容分类。
• 能说明 Working Memory、Run State 和 Business State 的边界。
• 能设计 Write / Retrieval / Conflict / Forgetting Policy。
• 能为每条 Memory 保留 Scope、Source、Version、Freshness 和 Sensitivity。
• 能解释为什么“全量聊天向量库”不是成熟 Memory System。

Related notes

• AI Agent Memory Layer
• Context Engineering MOC
• Coding Agent Memory MOC