AI Agent 记忆与删除权：可落地的隐私架构

长期记忆能让 Agent 跨会话保持有用，也会把一次性对话变成可持久化记录：它可能被复制、摘要、向量化、缓存、记录、导出，再展示给另一个模型。

隐私问题不是“向量很神秘”，而是一个生命周期问题：

收集 -> 推断 -> 存储 -> 派生 -> 检索 -> 披露 -> 保留 -> 删除

每条箭头都可能产生新的数据处理操作。删除一行，却留下摘要、缓存、备份或训练导出，不是完整的删除设计。

本文是工程指南，不是法律意见。GDPR 及类似法律的适用取决于 Controller/Processor 角色、目的、数据类别、辖区、例外、合同和具体请求。真实产品应与隐私专业人员共同评估。

核心结论

• 没有明确的未来用途，不要增加长期记忆。
• 分离 Thread State、Workflow State、Long-term Memory、Artifact、Audit Evidence 与 Training Data。
• 每条记忆记录 Purpose、Subject、Tenant、Sensitivity、Provenance、Retention 和 Deletion Status。
• Embedding、Summary、Cache、Log、Export 与 Fine-tuning Dataset 都需要独立清单和政策。
• Namespace 或 Tenant 隔离能限制爆炸半径，但不能独自证明合规。
• 删除应是异步、幂等的工作流，包含 Tombstone、依赖追踪、重试和验证。
• 备份与法律保留必须有明确政策，不要承诺立即覆盖每个物理扇区。
• 不要把用户陈述静默变成永久事实，应提供查看、纠正、过期和删除控制。
• 将删除后的残余检索与跨租户泄漏作为安全属性测试。

记忆首先是产品决策

Agent 不需要记住所有内容才能个性化。存储候选记忆前回答：

1. 哪个未来任务会使用它？
2. Session 或 Workflow State 是否足够？
3. 最低敏感度的表示是什么？
4. 它有多长的有效期？
5. 用户如何查看、纠正、导出或删除？
6. Account、Tenant 或 Purpose 结束后会发生什么？

例如：

Memory 不是 Persistence 的同义词，而是受政策控制的派生产品。

记忆数据模型

不要把所有内容塞进一张 memories 表，应区分记录类型：

ThreadState       当前对话和回合元数据
WorkflowState     可恢复的业务进度和外部 ID
SemanticMemory    有来源的可复用偏好或事实
EpisodicEvidence  支持结论的源事件
Artifact          有所有者和保留期限的文件/报告/导出
AuditEvent        安全与删除证据
TrainingExport    单独批准的模型开发数据集

一条 Memory 至少应包含：

{
  "memory_id": "mem_123",
  "tenant_id": "tenant_a",
  "subject_id": "user_42",
  "purpose": "personalize_code_examples",
  "value": "prefers Python examples",
  "source_refs": ["turn_8"],
  "assertion_type": "explicit",
  "sensitivity": "normal",
  "created_at": "2026-07-17T09:00:00Z",
  "expires_at": "2026-10-17T09:00:00Z",
  "status": "active",
  "derivatives": ["embedding:mem_123", "summary:thread_8"]
}

Schema 不是合规证书，但会让政策变得可测试。

什么可能属于个人数据

如果信息与已识别或可识别的人有关，或能在上下文中关联到某个人，是否属于个人数据取决于实际事实。看似随机的向量，如果服务能把它关联到用户，或用它推断用户属性，也可能需要按个人数据保护。

需要纳入清单的资产包括：

• Prompt、Transcript、附件和语音；
• 抽取事实、分类、情感和风险评分；
• Embedding 与 Vector Metadata；
• Summary、标题、Search Index 和 Rerank Feature；
• Tool 参数、结果、URL 和生成文件；
• Log、Analytics、Support Export 和 Trace；
• 用于训练的 Prompt、Adapter、Checkpoint 或 Dataset；
• Backup、Replica、灾备 Snapshot 和 Legal Hold。

按目的和访问权限分类，不要按文件扩展名分类。一份 JSON Summary 可能比一个原始文本片段更敏感。

删除权需要工作流

GDPR 第 17 条在特定条件下规定删除权，同时包含例外并与其他义务交互。它不能被概括为“所有物理扇区必须立即销毁”。真实服务需要记录完整的权利请求流程：

1. 验证请求者，防止账号接管；
2. 明确 Controller、Processor、Tenant 与处理目的；
3. 界定 Subject 和请求范围；
4. 检查法律、合同、安全和保留例外；
5. 阻止新的派生和检索；
6. 枚举源资产与派生资产；
7. 删除或不可逆去标识符合条件的资产；
8. 向 Processor 和下游存储传播请求；
9. 按政策处理 Backup 与灾备副本；
10. 验证完成情况，并说明已做、未做及原因。

响应期限和例外依法律与事实而异，不要把统一的“14 天”写死在产品代码中。

删除图

用数据血缘图表示派生关系：

turn_8
  ├── summary_8
  ├── memory_mem_123
  │     └── embedding_mem_123
  ├── retrieval_cache_query_44
  ├── trace_span_900
  └── training_export_batch_7

每个节点记录：

• Owner 与 Tenant；
• Purpose 与 Retention Policy；
• 存储位置和 Processor；
• Source References 与派生子节点；
• 删除能力和验证方法；
• 状态：Active、Blocked、Deleted 或 Pending Expiry。

不一定要引入 Graph Database；持久化 Metadata Table 加 Outbox 也能实现同一契约。关键是系统能回答“这份数据去了哪里”，而不是靠猜测搜索各个系统。

隔离与访问控制

语义检索前先执行 Tenant 和 Subject 边界：

认证 -> 鉴权 Tenant/Subject -> 应用 Purpose Filter
    -> 检索合资格记录 -> 执行 Sensitivity Policy

不能依靠 Prompt 说“只使用这个用户的记忆”。过滤必须在 Database 或 Retrieval Service 执行，并在 Tool 边界再次检查。

按威胁模型、可用性、查询规模和删除保证选择。没有哪种布局“天然合规”。

保留与过期

保留期限由目的驱动：

• Thread State：任务结束或短期运营窗口；
• 临时 Tool Result：工作流所需的最短时间；
• Preference：用户可见的过期和纠正；
• 受监管记录：适用的业务和法律计划；
• Audit Evidence：完整性与事故要求，同时限制访问；
• Training Export：独立批准、Dataset 版本和删除流程。

TTL 只是机制，不是政策。过期任务可能失败，Cache 可能超期，Replica 可能延迟。应发出过期事件、监控执行，并验证记录不会在过期后被检索。

删除架构

删除不应是一个同步请求，串行调用五个数据库。使用持久化命令：

ForgetRequest(id, subject, scope)
  -> 认证并鉴权
  -> 写 Tombstone，停止新派生
  -> 将删除任务投递到各资产 Adapter
  -> 重试临时失败
  -> 记录 Processor 确认
  -> 验证检索和 Cache 中不存在
  -> 关闭请求或升级例外

Tombstone 防止竞态：源数据删除后，新的 Summary 或 Embedding 不能再次生成。Memory Write、Retrieval、Export 和 Training Job 都应先检查它。

概念性 Python 状态机

from dataclasses import dataclass
from enum import Enum


class ForgetStatus(str, Enum):
    REQUESTED = "requested"
    BLOCKED = "blocked"
    RUNNING = "running"
    VERIFIED = "verified"
    ESCALATED = "escalated"


@dataclass(frozen=True)
class ForgetRequest:
    request_id: str
    tenant_id: str
    subject_id: str
    status: ForgetStatus
    remaining_assets: tuple[str, ...]


def next_status(
    request: ForgetRequest,
    *,
    authenticated: bool,
    exception_requires_review: bool,
    failed_assets: tuple[str, ...] = (),
) -> ForgetRequest:
    if not authenticated:
        return request
    if exception_requires_review:
        return ForgetRequest(
            request.request_id,
            request.tenant_id,
            request.subject_id,
            ForgetStatus.BLOCKED,
            request.remaining_assets,
        )
    if failed_assets:
        return ForgetRequest(
            request.request_id,
            request.tenant_id,
            request.subject_id,
            ForgetStatus.RUNNING,
            failed_assets,
        )
    return ForgetRequest(
        request.request_id,
        request.tenant_id,
        request.subject_id,
        ForgetStatus.VERIFIED,
        (),
    )

这段代码不会删除数据，只展示重要分离：请求状态和鉴权是确定性的；真实系统还需要实现存储 Adapter、Processor 契约和验证器。

Backup、Cache 与 Legal Hold

删除承诺经常失败，是因为团队遗漏了二级系统：

• CDN 或语义 Cache；
• Search Index 与 Rerank Feature；
• Observability 和 Support Export；
• Object Storage Version；
• Replica 与灾备 Snapshot；
• 含未处理 Payload 的 Queue；
• Legal Hold 或必须保留的记录。

为每类资产制定政策。一种常见设计是：立即阻止 Subject 的新处理，及时删除在线系统，按正常周期淘汰不可变 Backup，限制恢复权限，并在恢复后重新应用 Tombstone。是否足够取决于法律、合同与风险，必须经过审核并留下证据。

Embedding 与隐私增强技术

加密保护传输和静态存储的机密性，但不自动满足删除要求：只要 Key、明文、Metadata 和派生副本仍可用，个人数据仍可能存在。

Crypto-shredding 在以下条件下可能有用：

• Key 按 Subject 或 Dataset 清晰划分；
• 所有可用副本都受该 Key 保护；
• Key 销毁持久且可审计；
• 设计覆盖 Backup、轮换、恢复和 Legal Hold。

Differential Privacy、TEE、同态加密和联邦学习解决的是不同威胁，并有不同的可用性和运营成本。它们不能互相替代，也不能被宣传为通用删除方案。

Fine-tuning 与 Unlearning

RAG 记录和模型训练影响是两类资产。删除源记录可以阻止未来检索，但不会自动改变已经训练的模型；反过来，训练使用某条记录也不代表模型一定记住了它。

如果个人数据进入训练：

• 保留 Dataset 和 Checkpoint 血缘；
• 训练前定义审批和保留政策；
• 分离评测、生产和研究副本；
• 评估是否需要重训、替换模型或记录例外；
• 测试 Memorization 与残余披露；
• 不要仅凭 Vector Delete 宣称“已经忘记”。

机器 Unlearning 仍是研究和工程领域，不是标准 API 保证。应诚实描述残余风险。

用户体验也是隐私

用户应该能够：

• 看到 Memory 是否开启；
• 查看和纠正重要记忆；
• 理解为什么保留、用于什么目的；
• 在可行时设置保留偏好；
• 删除单条记忆或完整账户范围；
• 获得清晰的删除状态和升级路径。

不要提供只显示模型摘要的欺骗性 Memory Dashboard。展示来源，并区分 Explicit Statement 与 Inference。不能把敏感推断静默写成用户永久事实。

评测与证据

把隐私测试纳入与 Utility 相同的发布门禁：

测量删除延迟、剩余资产数、删除后的检索 Recall、Processor 确认、失败任务和误删率。删除很快但无法证明删了什么的系统，并不成熟。

生产检查清单

• [ ] 每类 Memory 有 Purpose、Owner、Sensitivity、Retention 和 Deletion Policy。
• [ ] Thread、业务状态、Memory、Artifact、Audit Event 与训练数据分离。
• [ ] 记录 Provenance 和派生资产血缘。
• [ ] 检索前执行 Tenant 与 Subject 鉴权。
• [ ] Memory Write 检查依据/目的和活动 Tombstone。
• [ ] 监控并验证过期，而不是只配置 TTL。
• [ ] 删除具备幂等、重试和 Processor 传播能力。
• [ ] 覆盖 Cache、Index、Queue、Export、Replica 和 Backup。
• [ ] Legal Hold 与例外有升级路径。
• [ ] Embedding 按可能的个人数据保护。
• [ ] 模型训练有独立 Dataset 血缘和删除分析。
• [ ] 用户能以可理解的状态查看、纠正和删除 Memory。
• [ ] 发布前运行跨租户、竞态、恢复、注入和残余检索测试。

常见问题

删除 Transcript 会删除模型的全部影响吗？

不会。它可以删除 Transcript 和有完整血缘的检索派生物；Training Influence、Cache、生成 Artifact 和人工导出需要独立处理。

每用户 Namespace 一定比共享 Index 好吗？

它可能简化批量操作并降低影响范围，但会增加成本，且不覆盖 Log、Backup 和派生数据。共享 Index 在强制 Tenant Filter 和完整删除血缘下也可能安全。应根据威胁模型选择。

只存匿名 Summary 可以吗？

Summary 仍可能识别或描述某个人，摘要过程还可能引入错误的敏感推断。应最小化数据、保留来源、定义目的，并提供纠正和删除。

本文是 GDPR 合规认证吗？

不是。本文是架构与工程指南。法律义务取决于真实产品、参与方、辖区、处理目的、合同和例外。

总结

隐私友好的 Agent Memory 不是“全部记住”和“完全不记”二选一，而是一组明确契约：

• 只为明确的未来用途收集；
• 保留最低敏感度的有效表示；
• 检索前执行身份和目的控制；
• 记录派生数据的来源；
• 用持久化工作流过期和删除；
• 不承诺无法证明的物理清除；
• 验证被删除 Subject 不再影响在线检索。

最值得信任的 Agent，不是记得最多的 Agent，而是能解释为何记住、允许用户修改，并证明用户要求忘记后发生了什么的 Agent。

一手资料

• GDPR Regulation (EU) 2016/679，EUR-Lex
• GDPR Article 17，EUR-Lex
• European Data Protection Board：Secure Personal Data
• European Data Protection Board：What Is Personal Data?
• NIST Privacy Framework