S3-架构方法论篇-04-数据治理与记忆边界

🗄️ 数据治理与记忆边界：信息如何被记住，又如何被遗忘

本文是《从零吃透企业级 AI 平台》第三季·架构方法论的第 4 篇

⚠️ 事实锚点速记：本篇沿用第三季事实锚点——以「万悟（Apache-2.0 开源，源码可查）↔ WorkBuddy（闭源产品，仅公开方法论）」双平台作方法论对照；完整声明、信源与"为何不把两者都当开源"见 《00 · 第三季导读》。

🎯 本文目标

读完本文，你将：

理解"数据存进去"只是生命周期的 1%，真正的难题在于分级、流转、加密、留存和销毁

看清万悟如何用多租户隔离 + Casbin 策略引擎治理"企业数据的生命周期"

看清 WorkBuddy 如何用分层记忆治理"Agent 该记住什么、忘记什么、谁来控制"

能够区分"企业数据合规删除"与"个人记忆主权删除"这两个常被混为一谈的概念

前置知识：了解基本的对称 / 非对称加密概念；了解 GDPR / 《个人信息保护法》的基本框架即可，无需法律背景

1. 一份企业文档的"生老病死"

一个看似简单的问题：你的 AI 平台里的一份企业文档，从上传到彻底消失，经过了几双手、几个存储、几次加密？

大多数工程师的第一反应是："上传 → 存数据库 → 分析 → 返回结果 → 完事了。"

实际上，一份文档在平台中的完整生命周期可能是这样的：

上传（API 网关）
  → 临时存储（对象存储，明文，TTL 24h）
    → 解析（Parser，内存中明文）
      → 结构化存储（PostgreSQL，字段级加密）
        → 规则匹配（读解密后数据）
          → LLM 分析（prompt 中含文档原文）
            → 分析结果存储（与原文分离）
              → 报告生成（含原文摘录）
                → 报告存储（加密）
                  → 客户下载（临时解密）
                    → 留存期到期
                      → 软删除（标记，保留 30 天）
                        → 硬删除（覆写 + 备份清理）
                          → 销毁证明（审计日志）

十几个环节，多种存储介质，多种加密状态，至少 6 个模块会接触到原文。

💡 关键洞察：数据治理的核心难题不是"怎么存"，而是"谁在什么时候、以什么形态、看了什么、做了什么、之后数据去了哪里"。每个环节都是一个潜在泄露点，每个存储副本都可能让"被遗忘权"落空。

换个场景：一道菜从食材入库到最终上桌，经过冷库、解冻台、切配区、灶台、摆盘台、传菜口。食品安全不是"把菜做熟"就够了——你需要知道：冷链有没有断？生熟有没有交叉？留样有没有保留 48 小时？过期食材有没有彻底销毁而不是"往后挪了挪"？

一个真实的痛点：2024 年某 AI 文档平台被曝出，用户删除文档后，LLM 的 prompt 缓存中仍保留了原文片段长达 90 天。"删除"只是从数据库中移除了记录，但数据在 LLM 服务商的日志里、在向量数据库的 embedding 里、在 CDN 的缓存里，仍然活着。

2. 四种数据治理方案横向对比

2.1 无治理（"存了再说"）

# 伪代码：最常见的"数据治理"
@app.post("/upload")
def upload_doc(file: UploadFile, tenant_id: str):
    # 明文存 S3
    s3.put_object(Bucket="docs", Key=f"{tenant_id}/{file.filename}", Body=file.read())
    # 明文存数据库
    db.execute("INSERT INTO docs (tenant_id, content) VALUES (%s, %s)",
               (tenant_id, file.read()))
    # 问题：无分级、无加密、无 TTL、无审计、删除 = DELETE FROM

2.2 全盘加密（"一把锁锁所有"）

# 伪代码：数据库开启 TDE（Transparent Data Encryption）
db_config = {
    "encryption": "AES-256-TDE",
    "key_management": "AWS_KMS",  # 或阿里云 KMS
}
# 进步：静态数据加密了
# 不足：所有字段用同一把钥匙 → DBA 能看到所有数据
# 不足：无分级 → 金额和标题用同等保护
# 不足：无生命周期 → 数据永远不删

2.3 字段级加密 + 数据分级

# 伪代码：按敏感度分级，不同字段不同密钥
class DocRecord:
    id: str                    # L0 公开：无加密
    tenant_id: str             # L1 内部：传输加密
    title: str                 # L1 内部：传输加密
    parties: str               # L2 敏感：字段级加密（租户密钥）
    amount: Decimal            # L2 敏感：字段级加密（租户密钥）
    full_text: bytes           # L3 高度敏感：信封加密（数据密钥 + 主密钥）
    llm_prompt_cache: None     # L3：禁止持久化，仅内存

2.4 全生命周期治理（策略引擎驱动）

# 伪代码：数据从产生到销毁，每一步都有策略驱动
class DataLifecyclePolicy:
    classification: DataClassification   # L0~L3
    encryption: EncryptionPolicy         # 传输 / 静态 / 使用中
    retention: RetentionPolicy           # 留存期（按法规 / 数据类型）
    access: AccessPolicy                 # 谁能看、谁能改、谁能删
    destruction: DestructionPolicy       # 怎么删、删几份、要不要证明
    audit: AuditPolicy                   # 每次访问是否记录

    def on_create(self, data): ...       # 自动分级 + 加密
    def on_access(self, user, data): ... # 权限校验 + 审计
    def on_expire(self, data): ...       # 触发销毁流程
    def on_delete_request(self, data): ... # 被遗忘权：级联清理所有副本

横向对比

	无治理	全盘加密	字段级加密 + 分级	全生命周期治理
静态数据保护	❌	✅（但粒度粗）	✅（字段级）	✅
最小权限访问	❌	❌（DBA 全可见）	⚠️（应用层控制）	✅（策略引擎）
数据留存合规	❌	❌	⚠️（手动清理）	✅（自动过期）
被遗忘权支持	❌	❌	⚠️（需手动找副本）	✅（级联销毁）
审计追溯	❌	❌	⚠️	✅
实现复杂度	零	低	中	高
性能开销	0	~5%	~15%（加解密）	~20%
适合阶段	原型	单租户 MVP	多租户生产	金融 / 法律 / 医疗

📌 小结：企业文档天然属于高敏感（涉及商业机密、个人身份信息、法律条款）。"字段级加密 + 分级"是底线，"全生命周期治理"是目标。但还有一个被很多人忽略的孪生问题——Agent 自己记下的"记忆"，边界又在哪里？ 这正是本篇要补的另一半。

3. 两个真实平台怎么选

数据治理与记忆边界，看似两件事，其实是同一个问题的两面："什么信息该被记住、记住后谁控制、能不能被遗忘"。万悟与 WorkBuddy 给出了两种答案：万悟治理的是企业数据的生命周期（多租户隔离 + 策略引擎 + 合规留存），WorkBuddy 治理的是Agent 记忆的可控性（记忆分层 + 用户主权 + 作用域边界）。一个偏"企业合规"，一个偏"用户主权"。

3.1 万悟：用多租户隔离 + 策略引擎治理企业数据

万悟是开源企业级平台，其数据治理建立在已核实的底座上：

多租户隔离前置：数据从入口（bff 网关）即按租户上下文隔离，租户 A 的数据在策略层就被固定，无法越权访问租户 B——这一点在权限体系（Casbin + JWT + RSA）中统一裁决。
Casbin 策略引擎做数据访问鉴权：谁能读哪个库的哪个字段、谁能导出、谁能删，由 Casbin 模型在调用前裁决，而非业务代码各自判断。
租户级数据密钥：敏感数据按租户加密，密钥与租户绑定。
合规留存：操作日志、审计等按合规要求留存（具体分级与留存策略以开源仓库为准）。

万悟的路径是"企业数据合规治理"——把数据生命周期的权责写进多租户底座与策略引擎，强调的是"组织如何合法、隔离、可审计地持有数据"。这也呼应汪晟杰 Agent OS 基础设施层"数据安全合规 + 湖仓一体"与智能服务层 KeyVault 的层级归属。

3.2 WorkBuddy：用分层记忆治理"Agent 该记住什么"

WorkBuddy（闭源）面对的不是"企业多租户数据"，而是"单个用户与 Agent 协作中产生的记忆"。其记忆系统（社区多源一致拆解 + 本机可验证）分为：

记忆分类（Anne M-C-H-L 五类）：稳定事实、用户知识背景、行为信号、表达偏好、会话延续——均为陈述性记忆；而程序性记忆（怎么做某事）不进长期记忆，改存为 Skill。
三层 / 五层记忆架构（社区多源一致）：用户级 ~/.workbuddy/（SOUL.md / IDENTITY.md / USER.md / MEMORY.md / skills/）、项目级 {workspace}/.workbuddy/memory/（MEMORY.md + 按日日志）、任务级对话 / 结果区。
用户主权：记忆可查看、可编辑、可删除；用户级记忆跨项目生效，项目级记忆仅限当前工作区。

🔎 最稳的锚点（一手可验证）：你正在与之对话的这个运行实例，就是 WorkBuddy 记忆系统的活样本——它有 SOUL.md（身份设定）、USER.md（你的偏好）、MEMORY.md（长期记忆）、按日日志，以及项目级 memory/ 目录。社区拆解描述的"三层记忆"，在这个真实实例里逐一对得上。这是本季所有 WorkBuddy 论述中，唯一你能亲手打开文件夹验证的一条。

3.3 对照表：企业数据生命周期 vs Agent 记忆边界

维度	万悟（企业数据治理）	WorkBuddy（Agent 记忆边界）
治理对象	多租户企业数据	单用户与 Agent 的协作记忆
核心机制	Casbin 策略 + 租户隔离 + 密钥	记忆分层（用户/项目/任务）+ 用户主权
记忆分类	按敏感度分级（合规视角）	五类陈述性记忆（Anne）+ Skill 承载程序性
可控性	组织级：合规留存 / 被遗忘权	用户级：可查看 / 编辑 / 删除
跨域	租户间强隔离	用户级记忆跨项目，项目级限工作区
信源	开源仓库可核实	社区多源一致 + 本机实例可验证
诚实缺口	—	无专门"企业多租户合规"框架（偏用户主权）

3.4 同一问题，两种答案：被遗忘权

万悟：被遗忘权是"分布式事务"——主存储、备份、日志、embedding 全部级联清理，并保留一条不含原文元数据的销毁证明。这是 GDPR / 《个人信息保护法》意义上的企业合规删除。
WorkBuddy：用户删除的是"记忆"——删除 USER.md / MEMORY.md 中的某条，或清空项目级 memory/。它治理的是"Agent 别记住不该记的"，而不是"组织持有的企业数据"。

两者都回答"信息如何被遗忘"，但粒度不同：万悟在"企业数据合规"层面，WorkBuddy 在"个人记忆主权"层面。对读者而言，这恰是选型启示：做 B2B 多租户平台，数据治理必须到位（学万悟）；做个人 AI 助手，记忆边界必须清晰（学 WorkBuddy）——而真正的企业 Agent 平台，两者都要。

⚠️ 诚实标注：WorkBuddy 的记忆系统是"用户主权"视角，目前没有公开材料显示它有专门的企业多租户数据合规框架（如跨租户的强隔离、合规留存审计、被遗忘权的分布式清理）。它的 KeyVault（密钥）与"数据安全合规"底座（汪晟杰 Agent OS 基础设施层）解决了"平台侧"的安全，但"多租户企业数据治理"这层，万悟明显更完整。读者不要因为 WorkBuddy 记忆边界清晰，就误以为它能替代万悟式的企业数据合规。

4. 业界怎么做的

4.1 Ironclad：合同管理平台的合规实践

Ironclad（美国 AI 合同管理平台）在其安全白皮书中公开了数据分级策略：合同元数据（标题、日期、状态）标准加密；合同正文客户自持密钥（BYOK）；AI 分析结果与原文分离存储、不同访问权限。这套"分级 + 分离 + 客户持密钥"的逻辑，与万悟"多租户隔离 + Casbin 鉴权 + 租户级密钥"的企业数据治理思路一脉相承——都是从"组织如何合法持有企业数据"出发。

4.2 Anthropic / OpenAI：LLM 服务商的数据承诺

2025 年后，主流 LLM 服务商陆续推出"零数据保留"（Zero Data Retention）API：OpenAI 不用于训练、30 天后删日志（企业合同）；Anthropic 不缓存、不训练、即时删除（Enterprise）。这意味着：任何向 LLM 传出企业原文的平台，必须把"服务商不保留"写进合约——这是数据治理在 LLM 调用边界上的延伸。

4.3 欧盟 AI Act（2025 年生效）

欧盟 AI Act 对"高风险 AI 系统"提出明确的数据治理要求：训练 / 推理数据可追溯、数据最小化、人类监督、日志保留至少 6 个月。这从法规层面把"数据治理"从"工程最佳实践"升级为"法律义务"。万悟的审计日志与多租户隔离设计，正是面向这类合规要求的企业级底座。

4.4 产品级记忆：个人 AI 助手的"记忆边界"趋势

与 Ironclad 的企业合规相对，另一股趋势是"个人 AI 记忆主权"——产品（如 WorkBuddy）记住你的偏好、背景、表达习惯，让你每次对话都"接着上次聊"。这类系统的治理对象不是企业数据，而是个人记忆：用户要能随时查看、编辑、删除 Agent 记住的东西。这恰是 3.2 节的记忆分层所解决的问题。两种趋势并不冲突：企业平台需要"Ironclad 式合规"，个人助手需要"WorkBuddy 式记忆主权"——而企业 Agent 平台，必须两者兼备。

5. Trade-off 与常见误区

5.1 这个选择的代价

代价	具体表现	通用应对
字段级加密有性能开销	每次读取 L2/L3 字段需要解密，~2ms/字段	批量查询一次解密多个字段；热数据缓存解密后的值（TTL 5min）
脱敏降低 LLM 分析质量	`[PARTY_A]` 替代真实公司名后，LLM 无法判断"关联方"	仅脱敏人名 / 公司名，保留逻辑结构；关联方检测在脱敏前完成
信封加密增加密钥管理复杂度	每个租户一把数据密钥，KMS 调用有延迟和成本	数据密钥本地缓存（加密存储），KMS 仅在轮转时调用
销毁流程涉及多个存储	任何一个遗漏 = 合规风险	销毁编排器有集成测试，模拟"删除后搜索所有存储确认不存在"

5.2 三个常见误区

误区 1："加密了就是安全的。"

加密保护的是"静态数据被物理窃取"的场景（硬盘被盗、备份泄露）。但如果应用层有注入漏洞，攻击者通过正常查询就能拿到解密后的明文——加密形同虚设。加密是必要条件，不是充分条件。必须配合访问控制、参数化查询、最小权限。万悟用 Casbin 把"谁能读"卡在策略层，正是这一原则的落地。

误区 2："用户删了就是删了。"

DELETE FROM docs WHERE id = ? 只是从主表中移除了行。但数据可能还存在于：每日 / 每周备份中、只读副本中、对象存储的版本历史中、CDN 缓存中、LLM 服务商的日志中、向量数据库的 embedding 中、审计日志的"操作记录"中。真正的"删除"是一个分布式事务，需要协调所有存储。万悟的被遗忘权是组织级分布式清理；WorkBuddy 的"记忆删除"是用户级单点清理——两者复杂度天差地别。

误区 3："合规是法务的事，工程师不用管。"

GDPR 罚款上限是全球年营收的 4%，《个人信息保护法》上限 5000 万元或上一年度营业额 5%。这些罚款针对的是"技术措施不到位"，而不是"法务没写好隐私政策"。工程师是数据治理的第一道防线——你在代码里写的每一个 s3.put_object、每一个 logger.info(f"content={doc_text}")，都是合规决策。同时，WorkBuddy 式记忆系统提醒我们：即便不做企业合规，个人记忆的"可删、可查、可控"也是工程师对用户的基本责任。

5.3 一个开放问题

企业数据治理与个人记忆主权，未来会走向融合吗？一个理想的企业 Agent 平台，既要像万悟那样"租户强隔离、合规可审计"，又要像 WorkBuddy 那样"记住每个用户的偏好、跨项目延续上下文"。但这两者存在张力：记忆越跨项目延续，越容易触犯"数据最小化"原则；隔离越严格，记忆越难有用。这个平衡点在哪里，目前没有标准答案——也正是万悟（企业底座）与 WorkBuddy（记忆主权）尚未在公开材料中给出统一方案的地方。

6. 动手练习

场景：你的 AI 文档分析系统有 50 家企业客户，使用 PostgreSQL + S3 + 某 LLM API。一位客户（某上市公司）发来法务函：

"根据《个人信息保护法》第 47 条，我司要求贵平台在 15 个工作日内彻底删除我司所有文档数据（含原文、分析结果、日志、备份），并提供书面销毁证明。"

任务：

盘点：列出你的系统中，一份文档数据可能存在的所有位置（至少 8 个）。提示：不要只想"数据库"和"S3"。
设计销毁流程：为每个存储位置设计具体的删除操作，并标注哪些可以自动化、哪些需要人工确认。
处理悖论：审计日志中记录了"用户 X 查看了文档 Y"。删除文档 Y 后，这条审计日志要不要删？删了 = 审计链断裂；不删 = 数据没有"彻底"消失。你怎么设计？
双平台视角：如果客户同时要求"Agent 别再记得我们公司的任何偏好"，这在万悟式（企业数据合规删除）和 WorkBuddy 式（记忆主权删除）下分别是哪个动作？两者能不能用同一套流程解决？
销毁证明：设计一份销毁证明的模板，需要包含哪些字段才能满足法律要求？

评估维度	好的答案应该覆盖
完整性	不遗漏任何存储副本（包括缓存、备份、日志、embedding）
可验证性	删除后能证明"确实删了"（而不是"我说删了"）
时序性	先删什么后删什么？有没有依赖关系？
合规性	区分"必须删"和"法律要求保留"的数据（如反洗钱日志）
现实性	承认有些事你做不到（如 LLM 服务商侧），并说明如何 mitigate

⏱️ 30 秒速览

这篇你只需要记住 3 件事：

数据治理的核心是「数据生命周期」每个环节都有责任人和规则，不是"存进去"就完了
万悟治理企业数据生命周期（多租户隔离 + Casbin 鉴权）；WorkBuddy 治理 Agent 记忆边界（分层 + 用户主权）
被遗忘权有两种粒度：企业合规删除（分布式事务）vs 个人记忆删除（单点清理）——别混为一谈

📌 本文小结

企业文档的生命周期有十几个环节，每个环节都是一个潜在泄露点——"存进去"只是 1%
万悟用多租户隔离 + Casbin 策略引擎 + 租户级密钥治理企业数据，强调合法、隔离、可审计
WorkBuddy用分层记忆（用户 / 项目 / 任务）+ 用户主权治理 Agent 记忆；记忆分类为 Anne 五类陈述性记忆，程序性记忆存为 Skill
本机运行实例就是 WorkBuddy 记忆系统的活样本，是唯一可一手验证的 WorkBuddy 论述
诚实缺口：WorkBuddy 偏用户主权，无专门企业多租户合规框架；真正的企业 Agent 平台需两者兼备
"删除"是分布式事务：主存储、备份、向量库、CDN、LLM 服务商日志，一个都不能漏

📚 参考资料

GDPR Article 17, Right to Erasure ('Right to be Forgotten') — gdpr-info.eu/art-17-gdpr
《中华人民共和国个人信息保护法》第 47 条 — 国家互联网信息办公室
NIST SP 800-57, Recommendation for Key Management — csrc.nist.gov
Ironclad Security Whitepaper, 2024 — ironcladapp.com/security（合同管理平台的分级与 BYOK 实践）
Anne《从模型到 Harness：WorkBuddy 如何把 Agent 做成可用产品》（腾讯技术工程，2026-07-24）— Memory 五类（陈述性记忆）、程序性记忆存 Skill
汪晟杰《从一个人到一支队伍，AI 如何重写生产力》（腾讯新闻，2026-07-22，WAIC）— Agent OS 基础设施层"数据安全合规 + 湖仓一体"、智能服务层 KeyVault
WorkBuddy 记忆系统（社区多源一致拆解 + 本机实例可验证）— 三层 / 五层记忆架构、用户主权

📖 下一篇预告

第三季·第 5 篇：性能与上下文效率

平均延迟 2 秒的系统，为什么有人等了 40 秒？当 200 份文档同时涌入，Parser 的解析、规则引擎的匹配、LLM 的 token 生成——哪一步是真正的瓶颈？更本质的是：AI 平台的"性能"到底指什么？是吞吐 / 尾延迟，还是 token 成本 / 上下文窗口？下一篇，我们聊聊"长尾延迟不是玄学，是资源竞争的必然结果；而上下文效率，是 LLM 时代独有的性能观"。

📱 关注公众号，追更不迷路

本系列文章首发于微信公众号「农夫三拳有点癫」，每周更新源码拆解与架构实战。

在微信扫描下方二维码即可关注：

posted @ 2026-09-02 20:09 老羅阅读(16) 评论(0) 收藏举报

刷新页面返回顶部

laoluo2025