第 16 章：Memory Retrieval 与 Memory Governance

本章导读

  • 核心问题：如何安全、可解释地召回和治理 Memory。
  • 关键词：Memory Retrieval、Scope、Permission、Freshness、Conflict Resolution、Audit
  • 学习产出：设计 CI 分析中历史类似失败的召回、过滤、更新和废弃策略。

1. 本章要解决什么问题

上一章讨论了 Memory 的分类和写入原则。

但 Memory 系统真正难的地方不只是“存进去”，而是：

如何在正确任务中找回来？
如何判断它是否仍然可信？
如何处理冲突和过期？
如何允许用户删除？
如何审计它为什么影响了 Agent？

这就是 Memory Retrieval 与 Memory Governance。

如果没有治理，Memory 很容易变成“长期上下文污染源”。

常见问题包括：

  • 召回不相关记忆；
  • 使用过期项目规则；
  • 不同用户记忆串用；
  • 错误记忆长期影响 Agent；
  • 用户无法删除自己的偏好；
  • Agent 无法解释为什么引用某条记忆；
  • 敏感数据被写入或召回。

本章核心观点是：

可用的 Memory 系统不仅要能记住，还要能忘记、纠错、授权、审计和解释。

2. Retrieval 不是简单向量搜索

很多 Memory 系统的第一版实现是：

把记忆 embedding 后存入向量库
当前任务来时做相似度 topK

这只是起点，不是完整方案。

Memory Retrieval 至少要考虑：

  • 语义相关性；
  • 作用域；
  • 权限；
  • 时间；
  • 置信度；
  • 任务阶段；
  • 敏感度；
  • 冲突；
  • token budget。

例如当前任务是修改 order-service，就不应该召回 payment-service 的项目记忆，哪怕语义很相似。

3. Memory Retrieval 管线

推荐管线：

Query Understanding
  ↓
Scope Filter
  ↓
Permission Filter
  ↓
Candidate Retrieval
  ↓
Freshness / Confidence Filter
  ↓
Conflict Resolution
  ↓
Ranking
  ↓
Context Budget Packing
  ↓
Injection with Explanation

3.1 Query Understanding

先理解当前任务需要什么记忆。

例如：

用户偏好？
项目规则？
历史相似问题？
过程经验？
架构决策？

不同任务需要不同 Memory 类型。

3.2 Scope Filter

作用域过滤必须在语义检索前或检索中执行。

例如：

userId = 当前用户
projectId = 当前项目
teamId = 当前团队

3.3 Permission Filter

即使记忆相关，也必须检查用户是否有权限。

权限过滤应由程序强制执行。

3.4 Candidate Retrieval

候选检索可以组合：

  • 向量检索；
  • 全文搜索；
  • 标签匹配；
  • 时间范围过滤；
  • 类型过滤；
  • 引用关系。

3.5 Freshness / Confidence Filter

过期或低置信度记忆不应直接注入。

可以降权或要求验证。

3.6 Conflict Resolution

记忆可能冲突。

例如：

旧记忆：项目使用 Java 17。
新记忆：项目已升级 Java 21。

冲突解决策略：

  • 新记忆优先；
  • 高置信度优先；
  • 官方文档优先；
  • 用户明确确认优先；
  • 冲突时提示 Agent 验证。

3.7 Injection with Explanation

Memory 进入上下文时，应带上来源和原因。

例如：

Relevant project memory:
- When modifying OrderStatus, update OrderStateMachine and run OrderServiceTest.
  Source: tasks #1021, #1188, #1340. Confidence: high.

这比无来源的隐式提示更可控。

4. Memory Governance

Memory Governance 关注 Memory 的全生命周期治理。

4.1 写入治理

写入前检查：

  • 是否值得记住；
  • 是否包含敏感信息；
  • 作用域是否正确；
  • 是否需要用户确认；
  • 是否已有相似记忆；
  • 是否只是临时假设。

4.2 更新治理

Memory 应支持更新，而不是无限新增。

例如同一用户偏好变化：

旧：用户喜欢详细解释。
新：用户现在要求简洁回答。

应更新或废弃旧记忆。

4.3 删除治理

用户应能删除自己的记忆。

企业应能删除过期或违规记忆。

删除应记录审计日志。

4.4 合并治理

多个重复记忆可以合并。

例如三条类似历史经验合并为一条项目规则。

4.5 审计治理

系统应能回答：

这条记忆什么时候写入？
谁写入？
来源是什么？
什么时候被召回？
影响了哪些任务？
是否被修改或删除？

5. Memory Policy

企业 Agent 应有 MemoryPolicy。

示例：

用户偏好：需要用户确认或显式表达
项目事实：需要来自代码、文档或工具验证
临时假设：不写入长期 Memory
敏感数据：禁止写入
低置信度推断：只写入短期 Memory

6. 架构图 / 流程图

Memory Retrieval 与 Governance
图 16-1 Memory Retrieval 与 Governance 这张图展示 Memory 检索、权限、时效、冲突处理、注入解释和写入治理。 Mermaid 源文件

6.1 Memory Retrieval

Memory Retrieval
图 16-2 Memory Retrieval Mermaid 源文件

6.2 Memory Governance

Memory Governance
图 16-3 Memory Governance Mermaid 源文件

6.3 冲突处理

冲突处理
图 16-4 冲突处理 Mermaid 源文件

7. Java / Spring Boot 落地方案

7.1 MemoryQuery

public record MemoryQuery(
    String userId,
    String projectId,
    String objective,
    Set<MemoryType> types,
    Set<MemoryScope> scopes,
    int limit,
    double minConfidence
) {}

7.2 MemoryRetriever

public interface MemoryRetriever {
    List<RankedMemory> retrieve(MemoryQuery query, MemoryAccessContext context);
}

7.3 RankedMemory

public record RankedMemory(
    MemoryRecord memory,
    double relevance,
    double freshness,
    double confidenceScore,
    double finalScore,
    List<String> reasons
) {}

7.4 MemoryPolicy

public interface MemoryPolicy {
    boolean canWrite(MemoryWriteRequest request);
    boolean canRead(MemoryRecord memory, MemoryAccessContext context);
    boolean shouldExpire(MemoryRecord memory);
    boolean requiresUserConfirmation(MemoryWriteRequest request);
}

7.5 MemoryAuditLog

public record MemoryAuditLog(
    String id,
    String memoryId,
    String action,
    String actorId,
    String taskId,
    String reason,
    Instant createdAt
) {}

操作类型：

WRITE
READ
INJECT
UPDATE
MERGE
EXPIRE
DELETE

7.6 MemoryConflictResolver

public interface MemoryConflictResolver {
    ConflictResolution resolve(List<MemoryRecord> memories, MemoryQuery query);
}

8. 企业案例：用户偏好治理

用户说：

以后回答我尽量简洁，除非我要求详细解释。

可以写入用户记忆：

{
  "type": "USER_PREFERENCE",
  "scope": "USER",
  "content": "User prefers concise answers unless detailed explanation is requested.",
  "source": "explicit_user_instruction",
  "confidence": 1.0
}

如果后来用户说：

这本书的章节请写详细一点。

这不一定覆盖全局偏好。

它可能只是当前项目偏好。

因此 Memory 系统要区分：

全局用户偏好
当前任务偏好
当前项目偏好

9. 常见误区

9.1 只做向量检索

Memory Retrieval 需要权限、作用域、时间和置信度过滤。

9.2 不支持删除

用户和企业必须能删除记忆。

9.3 冲突记忆同时注入

冲突会让模型困惑，应先解决或要求验证。

9.4 没有审计

Memory 会影响 Agent 行为，必须可追踪。

9.5 把低置信度推断当事实

Agent 推断应标记低置信度，不能直接当项目规则。

10. 贯穿案例：CI 失败分析 Agent

当未来另一次 CI 失败也涉及 OrderStatus，MemoryRetriever 可以召回 build #4312 产生的项目记忆。

但召回前必须经过治理管线：

Scope Filter：只在 order-service 项目中召回
Permission Filter：确认当前用户有项目权限
Freshness Filter：确认记忆未过期
Confidence Filter：确认置信度足够高
Conflict Resolution：检查是否已有更新规则覆盖它
Context Budget：判断是否值得注入当前上下文

注入时应带来源和解释：

Relevant project memory:
- 修改 OrderStatus 时，必须同步更新 OrderStateMachine.allowedTransitions，并运行 OrderServiceTest。
  Source: CI build #4312 analysis. Confidence: 0.92.

如果项目后来重构了状态机，这条 Memory 应被更新或废弃。否则过期记忆会误导 Agent。

因此，CI 失败分析案例也说明：Memory 不仅要能写入和召回，还必须能更新、删除、审计和解释。

11. 本章小结

本章讨论 Memory Retrieval 与 Governance。

核心结论：

  1. Memory Retrieval 不是简单向量 topK，而是带作用域、权限、置信度和预算的检索管线。
  2. Memory 进入上下文前需要排序、冲突处理和解释。
  3. Memory Governance 包括写入、更新、合并、过期、删除和审计。
  4. 企业 Memory 必须支持用户删除权、权限隔离和敏感数据策略。
  5. 没有治理的 Memory 会成为长期上下文污染源。

一句话总结：

Memory 系统的目标不是让 Agent 永远记住一切，而是让它在正确时间、正确范围内、可解释地记起正确内容。

12. 实践任务

任务 1：实现 MemoryRetriever

实现基于 scope、type、confidence 的过滤，再接语义检索。

任务 2：设计 Memory 删除 API

定义：

DELETE /memories/{id}
GET /memories?userId=...
PATCH /memories/{id}

任务 3：冲突解决

设计 Java 17 与 Java 21 两条项目记忆冲突时的处理策略。

任务 4：审计日志

设计 MemoryAuditLog 表，记录每次 Memory 被注入上下文的原因。

results matching ""

    No results matching ""