H9 · 如何管理 Agent System 的数据与生命周期？ - Data Governance

所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：03 · 如何让 Agent System 稳定、安全、可控地运行？ - Engineering & Governance
文档类型：数据治理、生命周期管理与数据工程专题研究
版本：v1.1
更新日期：2026 年 10 月 29 日
核心问题：当 Agent System 持续读取外部资料、生成中间推理与执行事件、调用工具、共享状态、形成长期记忆并向用户交付产物时，如何确定数据的来源、用途、权限、质量、保留期限和删除责任，使其在整个生命周期内可追溯、可控制、可验证？

专题导读

本篇属 Engineering & Governance。Agent System 的数据治理并非传统数据库管理的简单延伸。系统会把用户输入、网页和文档内容、模型输出、工具结果、运行轨迹、长期记忆、向量索引和最终交付物连接起来；同一份内容还可能以原文、摘要、嵌入向量、缓存、日志和备份等多种形态存在。只删除主数据库中的一条记录，并不代表该信息已经从整个系统中消失。

本文继续使用“技术研究报告 Studio”作为贯穿案例：用户上传项目资料，多个 Agent 调研、分析、审核，生成报告并发布。研究重点是如何为资料建立数据契约、血缘与权限，如何防止错误资料和过期记忆进入报告，以及如何在保留审计证据的同时满足删除、最小化和保留期限要求。

研究边界： L2 Platform Services 负责提供存储、消息和索引能力；L3 Model Services 负责模型请求中的数据外发控制；L4/H4 管理执行状态与 Checkpoint；H1 管理观测数据；H2 管理安全防护；H3 管理评估数据；H5 管理配置版本。H9 的独立职责是跨层的数据分类、使用目的、所有权、质量、血缘、保留、删除与生命周期治理。 H12 进一步规定组织层面的制度和问责。本文不是法律意见；具体合规义务取决于司法辖区、数据类型和业务场景。

阅读目标： 能识别 Agent System 的数据资产，设计数据分类和生命周期模型，构建来源与产物血缘，实施访问与用途控制，制定保留和删除流程，并通过可执行的验收实验检验治理措施。

一、Data Governance 的定义与系统边界

1.1 定义

Agent System 的 Data Governance 是围绕数据资产建立的责任分配、分类标识、使用规则、质量控制、生命周期执行与证据验证体系。它回答六个问题：数据从哪里来、谁可以使用、允许用于什么、是否可信、应该保存多久、到期后如何处理。

它既包含政策层的规则，也包含工程层的强制执行点。仅在文档中写明“不得泄露用户资料”，却不限制检索权限、模型调用的外发范围或日志采集，不能视为有效治理。

1.2 数据、状态、记忆与证据的区别

概念	主要用途	治理关注点
原始数据	用户输入、文件、网页、API 结果	来源、授权、敏感级别
执行状态	Run、Step、Checkpoint	一致性、恢复、保留
长期记忆	跨任务复用的偏好与事实	适用范围、过期、撤回
派生数据	摘要、Embedding、索引	血缘、重建、删除传播
观测数据	Log、Trace、Metric	脱敏、采样、保存期限
审计证据	审批、访问、发布记录	完整性、访问限制、留存
交付产物	报告、表格、代码、图像	版本、归属、发布范围

同一数据对象可以同时具备多种属性。例如报告正文既是交付产物，也可能包含来自受限文档的派生内容；因此治理标签应随数据流传播，而不能只由存储位置决定。

1.3 责任模型

至少明确：数据控制责任人决定目的和保留策略；数据管理员/Steward维护分类、质量与元数据；系统所有者落实执行机制；Agent/工具执行身份只获得任务范围内的访问能力；审计者验证记录和控制有效性。不同组织可能采用不同职务名称，但责任不可缺位。

要区分“数据所有权”与“版权、合同授权、个人信息控制权”。上传者不一定拥有向第三方模型传输全部内容的权利；从互联网公开可访问，也不意味着允许任意用途、永久保存或再分发。

二、建立 Agent System 数据资产地图

2.1 按来源识别数据

1. 用户提供：提示词、上传文件、账号信息、审批意见、人工标注。
2. 组织内部：知识库、数据库、工单、代码仓库、业务 API。
3. 外部取得：搜索结果、网页、第三方数据集、供应商 API 响应。
4. 系统产生：模型请求和输出、工具调用参数与结果、执行事件、错误日志。
5. 加工派生：切块、清洗文本、摘要、Embedding、实体关系、报告草稿。
6. 治理与评估：授权决策、访问审计、标注、评估样本和质量报告。

资产登记不能只列“PostgreSQL、对象存储、向量数据库”。还要登记数据逻辑对象及其在不同存储系统中的副本和派生形态。

2.2 数据资产登记的最小契约

建议每个逻辑数据集维护：dataset_id、owner、tenant_id、source_type、purpose、classification、legal_or_contract_basis（按需）、region、retention_policy_id、deletion_policy_id、quality_rule_set、lineage_root、version、status。

每个具体对象维护：object_id、dataset_id、created_at、source_ref、content_hash、access_policy_ref、expires_at、derived_from[]、storage_locations[]。Hash 只用于内容完整性或关联，不应作为访问授权凭据；对低熵敏感值直接散列也可能泄露信息。

2.3 分类模型：敏感度 × 使用限制 × 生命周期

单一的“公开/内部/机密”标签通常不足以表达约束。建议采用三维标签：

维度	示例	决定什么
敏感度	公开、内部、受限、高敏感	访问、加密、脱敏
使用目的	研究、客服、评估、禁止训练	可用场景与外发
生命周期	临时、项目期、法定保留	保留、归档、删除

还应附加租户、数据主体、地域、合同限制、许可证与来源可信度等标签。分类规则由组织明确，示例标签不是通用法定等级。对组合数据应采用不低于组成部分中最严格限制的策略，除非经过可信的脱敏和重新评估。

三、数据生命周期：从进入系统到可验证删除

3.1 八个阶段

获取/接收 → 分类与登记 → 校验与清洗 → 存储与索引 → 使用与共享 → 派生与发布 → 归档/保留 → 删除/销毁

实际运行并非严格线性：一份文件可能被多次检索、更新、撤回或重新分类。系统应为每个对象记录生命周期状态与允许的状态转移。

3.2 接入阶段：在进入模型前完成治理

用户上传资料时先完成格式与大小检查、恶意文件扫描、来源记录、租户绑定、访问策略和敏感度初判；对于无法确认授权或用途的内容，可进入隔离区等待人工处理。网页抓取应记录 URL、抓取时间、来源声明和可使用条件；对动态网页，应避免将一次抓取结果误当作永久有效事实。

不要让 Agent 通过“先读取全部内容再判断是否有权读取”的方式实施权限控制。访问检查应发生在受信任的数据服务端。

3.3 使用阶段：目的限制与最小化

每次读取应判断 subject + resource + action + purpose + context。subject 是实际执行身份和代表的用户/租户，purpose 是已批准的任务用途，context 包括会话、任务、时间和目标模型/工具。只有资源可见不代表可被传给任意外部模型。

使用数据最小化原则：优先检索相关段落而非整库导出；在调用模型前裁剪无关字段；在可行时将个人标识符替换为短期映射；对模型输出和日志采用独立的脱敏规则。脱敏并非万能，仍需评估上下文再识别风险。

3.4 共享与派生阶段

数据从原文进入切块、摘要、Embedding、缓存、搜索索引、报告和审计记录后，应建立 derived_from 关系。派生数据是否仍属于受限信息，取决于其是否保留可识别、可还原或受合同约束的内容，不能因为“已经变成向量”就自动降级。

向量索引不应绕过文档级权限；检索前后均需考虑权限过滤。仅在召回后进行权限过滤可能造成召回不足或侧信道风险，应结合索引架构、租户隔离与访问策略设计。

3.5 保留、归档与删除

保留期限应按数据类别与用途定义，区分业务数据、执行日志、审计证据、备份、模型供应商侧保留和法律保全。不同副本可以具有不同保留期，但必须能解释依据与删除行为。

删除请求的完整流程应包含：身份和范围核验 → 查找原始对象与派生关系 → 检查合法保留例外 → 阻止继续使用 → 删除在线副本与索引 → 处理缓存与备份策略 → 通知受影响的下游处理方（如适用） → 生成不暴露原文的删除证明。无法即时删除的备份，应采取访问隔离、到期覆盖与恢复后重放删除指令等措施，并明确恢复窗口。

关键限制： 已发送给外部模型供应商的数据，无法通过本地数据库删除自动撤回。必须依据供应商实际的数据保留、删除和处理协议确认可执行范围。已经公开发布、被第三方复制或写入不可变审计介质的内容，也可能存在删除限制。

四、数据血缘、来源可信度与引用可验证性

4.1 为什么 Agent System 更需要血缘

传统 ETL 通常有较稳定的变换管线；Agent 的检索、工具选择和摘要生成具有动态性。同一结论可能来自多条证据，也可能来自模型未被证实的补全。缺少血缘时，无法解释报告中的结论依据，也无法在原始数据撤回后找到受影响的产物。

4.2 血缘图的最小节点与边

节点：Source、DocumentVersion、Chunk、RetrievalResult、ModelCall、Claim、ArtifactVersion、Publication。边：extracted_from、retrieved_for、used_as_input、supports、derived_from、published_as、supersedes。

为每条边记录发生时间、操作身份、Run/Step ID、版本与可核验的引用位置。血缘记录的存在不自动证明结论正确；它只提供可检查的证据链。

4.3 引用质量控制

对于研究报告 Studio，要求每个关键事实主张指向具体的文档版本、页码或文本片段，并校验引用对象确实存在。把“引用存在”“引用支持该主张”“来源本身可靠”设为三个独立检查。引用 URL 可访问不代表来源权威，来源权威也不代表具体论断获得支持。

模型可能编造标题、页码或 URL，因此引用应从实际检索结果的可信标识生成，而非由模型自由填写。审查时抽样或全量核对高风险结论。

4.4 数据撤回的影响分析

如果某份合同资料被撤回，血缘图应能定位相关 Chunk、Embedding、缓存、报告草稿和已发布版本，并分别执行删除、重建、重新评估或下架。对不能可靠追踪的历史派生数据，应明确不确定性并采用更保守的处置。

五、数据质量：让 Agent 使用可信、适用、及时的数据

5.1 质量不是一个分数

质量维度	典型问题	检验方式
完整性	文档缺页、字段缺失	Schema、页数校验
准确性	OCR 错字、过期数字	原件抽查、交叉核验
一致性	同一指标定义不同	口径、版本比对
时效性	政策或价格已变化	更新时间、TTL
可追溯性	无法定位原始证据	血缘完整率
适用性	资料不覆盖当前任务	范围、用途检查
唯一性	重复文件造成偏差	指纹与版本关系

Agent 的输出质量和输入数据质量相关，但二者不能混为一谈。高质量来源也可能被错误理解；低质量来源也可能被模型流畅地转述。因此应分别记录数据质量问题与 H3 的结果评估。

5.2 数据契约与摄取门禁

对结构化数据定义字段类型、非空约束、枚举、主键、时间口径和版本兼容性；对非结构化资料定义 MIME 类型、解析状态、语言、来源、页码映射、内容完整性与权限标签。若关键字段不满足契约，进入隔离队列而非静默降级。

对外部 API 数据应区分业务字段缺失与“本次查询没有结果”；对模型生成的结构化内容应进行 Schema 校验和事实核验，不能因为 JSON 解析成功就视为可信。

5.3 知识更新与过期控制

为不同来源定义新鲜度策略：产品文档和价格表可能频繁变化，历史档案可能长期稳定。记录 observed_at、source_updated_at、valid_from/to 和 retrieval_at，区分“我们何时看到”与“事实何时有效”。

知识更新时，应有选择地重建受影响的切块和向量索引，并记录索引版本。不能让旧 Embedding 与新正文混用却不保留映射关系。

六、长期记忆与知识库的专项治理

6.1 记忆写入是治理决策

Agent 不应将所有对话自动转为长期记忆。写入前应判断是否具有长期价值、是否获得适当授权、是否包含不应持久化的敏感信息、是否存在明显的不确定性。记忆记录建议包含 fact、source、confidence、purpose、scope、created_at、review_at、expires_at、supersedes。

confidence 是记录来源或验证状态的元数据，不应被解释为事实的客观概率。用户纠正信息后，系统应能定位并撤销旧记忆及其下游索引。

6.2 记忆读取的作用域

区分单次 Run、会话、用户、团队、组织和公共知识。一个用户的偏好不能未经授权传播到其他用户；组织内部知识不应因为被摘要成“经验”就成为公共记忆。跨 Agent 共享记忆应遵循相同的租户、目的和最小权限约束。

6.3 RAG 与向量数据库的治理

推荐流程：授权摄取 → 文档版本化 → 解析/切块 → 元数据绑定 → 嵌入生成 → 索引发布 → 权限过滤检索 → 引用校验 → 过期/撤回处理。

需管理切块版本、Embedding 模型版本、索引版本、权限标签、删除传播和重建策略。Embedding 不是天然匿名数据；是否涉及个人信息或商业秘密需依据具体内容与处理方式判断。

6.4 训练与评估数据的二次用途

生产对话、工具轨迹和用户上传文件不能因为“有助于提高模型质量”就自动转为训练或评估数据。建立独立的用途许可、数据最小化、脱敏、标注人员权限、数据集版本和删除联动机制。H3 负责评估方法，H9 负责评估数据的治理合法性、质量和生命周期。

七、数据访问、跨境传输与第三方处理

7.1 访问控制的执行点

应在上传、检索、对象下载、工具调用、模型外发、产物发布和导出等关键路径设置服务端授权。对多租户系统，租户边界必须由受信任的身份与资源关系判定，而不是仅由模型提示词或客户端传入的 tenant_id 控制。

授权策略可采用 RBAC、ABAC 或关系型权限模型；具体选择取决于资源层级和协作方式。对于动态协作，ABAC/关系型策略更便于表达“仅限此项目、此用途、此版本”的限制，但增加策略测试复杂度。

7.2 第三方模型与工具的数据流

在外发前登记处理方、数据类别、处理目的、地域、保留与删除能力、是否允许用于模型改进，以及合同/产品配置约束。模型服务层应依据已核准的供应商与区域策略路由请求。不同供应商、产品套餐、端点和企业协议的数据处理条件可能不同，不能套用单一结论。

对搜索、浏览器、代码执行、邮件、云存储等工具同样建立外发清单。对用户批准的动作记录准确的目标和数据范围，不将“批准发送摘要”扩展为“允许上传全部原始资料”。

7.3 跨境与合规边界

涉及个人信息、行业敏感数据或受地域限制的数据时，应根据实际适用法律、合同与处理角色评估跨境传输、数据主体权利、保存期限及处理方责任。GDPR、欧盟 AI Act、中国《个人信息保护法》等规范的适用条件并不相同；本文不对具体业务作法律合规结论。

八、数据治理的参考架构

8.1 控制面与数据面

                        Governance Control Plane
   Data Catalog ─ Policy Registry ─ Retention Rules ─ Lineage Graph
         │               │                 │              │
         └────────── Policy Decision / Audit ──────────────┘
                                │
                         Enforcement Points
                                │
 User/API → Ingestion → Object Store / DB → RAG / Memory → Agent Runtime
                   │                 │                │
                   └──────── Model Gateway / Tool Gateway ───────→ External
                                │
                     Artifact / Publication Service
                                │
                    Deletion & Retention Orchestrator

控制面定义分类、策略、目录、血缘和保留规则；数据面在每次实际读取、外发、发布与删除时执行这些规则。审计记录应尽量保存动作元数据与决策证据，避免将原始敏感内容复制到不可控日志中。

8.2 关键组件

组件	职责	主要输出
Data Catalog	数据集与对象登记	元数据、责任人
Classification	分类与标签传播	敏感度、用途
Policy Engine	访问与使用决策	Allow/Deny、原因
Lineage Service	来源与派生追踪	血缘边、影响范围
Quality Gate	数据契约与校验	隔离、质量报告
Retention Engine	到期与保留例外	保留/删除任务
Deletion Coordinator	跨副本删除与核验	删除状态、证明
Audit Service	访问和治理操作证据	可查询审计事件

不必在 MVP 阶段全部建设为独立微服务；可以先用数据库表、应用层策略与异步作业实现，但应保持契约清晰，避免把治理逻辑分散在各 Agent 的 Prompt 中。

8.3 最小数据模型

-- 说明性 SQL：字段、约束和索引需按实际数据库与业务补充
CREATE TABLE data_objects (
  object_id TEXT PRIMARY KEY,
  tenant_id TEXT NOT NULL,
  dataset_id TEXT NOT NULL,
  classification TEXT NOT NULL,
  purpose_policy_id TEXT NOT NULL,
  source_ref TEXT,
  content_hash TEXT,
  retention_until TIMESTAMPTZ,
  lifecycle_status TEXT NOT NULL,
  created_at TIMESTAMPTZ NOT NULL
);

CREATE TABLE data_lineage (
  parent_object_id TEXT NOT NULL,
  child_object_id TEXT NOT NULL,
  relation_type TEXT NOT NULL,
  run_id TEXT,
  created_at TIMESTAMPTZ NOT NULL,
  PRIMARY KEY (parent_object_id, child_object_id, relation_type)
);

CREATE TABLE deletion_jobs (
  job_id TEXT PRIMARY KEY,
  root_object_id TEXT NOT NULL,
  requested_by TEXT NOT NULL,
  status TEXT NOT NULL,
  exception_reason TEXT,
  created_at TIMESTAMPTZ NOT NULL,
  completed_at TIMESTAMPTZ
);

实际设计应考虑复合租户约束、循环血缘、版本化、事件重放、外键和索引。删除任务应通过幂等 Job ID 和各存储适配器的执行回执追踪，不应仅凭一个 deleted=true 字段宣布完成。

九、关键流程与失败语义

9.1 安全摄取流程

1. 用户提交文件；API 验证身份、项目和上传目的。
2. 文件进入隔离存储，进行类型、完整性与恶意内容检查。
3. 登记来源、数据类别、访问策略、保留规则和版本。
4. 解析与切块继承父对象标签，生成血缘边。
5. 索引构建完成后以原子方式切换可检索版本。
6. 记录摄取结果与异常；失败时避免暴露半成品索引。

9.2 受控检索与模型外发

Run 请求知识 → 鉴权与用途校验 → 按租户/权限检索
  → 结果重新校验 → 内容最小化 → 目标模型数据政策校验
  → 模型调用 → 输出登记 → 产物血缘关联

权限可能在任务执行中发生变化，不能仅在 Run 创建时校验一次。对敏感外发和发布动作，应在执行前重新评估当前策略。

9.3 删除流程与部分失败

删除协调器先阻止新读取并标记待删除，再依次处理原文、切块、Embedding、缓存、检索索引和可控派生对象。每个适配器报告 pending/succeeded/failed/not_applicable/retained_by_exception，失败时可重试且不重复产生副作用。只有满足策略定义的全部必需条件，才能将任务标记为完成。

删除与业务审计可能冲突：例如必须保留某些最小审计元数据用于安全或法定义务。应记录具体例外、访问限制和到期时间，而不是将保留例外泛化为永久保存全部内容。

9.4 数据恢复后的删除重放

从旧备份恢复系统可能让已删除对象重新出现。恢复流程应在开放访问前重放删除墓碑（tombstone）与撤回策略，并验证搜索索引和缓存未重新暴露已删除内容。若恢复期间不能保证该条件，应限制服务开放范围。

十、研究报告 Studio 贯穿案例

10.1 场景与数据流

某企业使用 Studio 生成产业研究报告：用户上传内部会议纪要，调研 Agent 检索公开资料，分析 Agent 形成结论，审核 Agent 检查引用，用户批准发布。系统同时记录 Trace、Checkpoint 和审批证据。

主要风险：内部纪要被发送到未经批准的外部模型；调研网页失效导致引用无法验证；某份文档撤回后报告仍使用其摘要；向量索引跨项目召回；报告删除后备份恢复造成数据再出现。

10.2 分阶段治理设计

阶段	治理控制	可验证证据
上传	分类、项目授权、隔离扫描	摄取记录
检索	租户与用途过滤	授权决策日志
模型调用	外发策略、最小化	请求元数据
研究分析	引用、来源版本、血缘	Claim→Source 关系
人工审核	版本绑定与审查权限	审批事件
发布	内容检查、发布范围	Artifact 版本
删除	派生追踪、跨存储处理	删除任务回执

10.3 一个具体撤回事件

用户撤回一份内部访谈记录。系统首先冻结对该文档及其派生索引的访问；根据血缘查找三段引用、一份分析草稿和一份已发布报告；对草稿重新生成受影响章节，对已发布报告发起下架或修订流程；清除缓存与向量条目；对备份设置删除重放要求；最终给出“已完成”“因保留例外未删除”“外部副本无法保证删除”的分项结果。这比返回一句‘删除成功’更符合可验证治理。

十一、技术选型与实现策略

11.1 从 MVP 到生产级

MVP： 数据对象登记、租户隔离、基本分类、上传与发布授权、来源版本、统一保留策略、手工可追踪删除。优先覆盖高风险数据路径，不追求一次性建设复杂的数据治理平台。

成长阶段： 建立统一数据目录、自动标签传播、血缘图、跨存储删除协调器、质量门禁、数据访问审计与供应商数据流登记。

生产级： 支持跨地域/多租户策略、数据主体请求流程、备份恢复删除重放、自动影响分析、定期治理证明、异常访问检测与外部处理方对账。

11.2 可参考的技术能力

• OpenLineage：提供数据血缘事件的开放规范；在 Agent 系统中通常需要自定义运行、引用和模型调用实体映射，不能直接假定其覆盖全部 Agent 语义。
• Apache Atlas / DataHub / OpenMetadata：可用于目录、元数据和血缘管理；具体集成、权限模型和部署成本需要单独评估。
• PostgreSQL Row-Level Security：可辅助数据库层租户隔离，但仍需正确的角色、连接与策略配置；不能替代对象存储、向量库和工具 API 的授权。
• 对象存储生命周期规则：可执行到期转储或删除，但需要协调派生索引、缓存和法律保留例外。
• OpenTelemetry：可承载数据访问的观测关联信息，但不是独立的数据保留或隐私合规解决方案。

选型时优先验证与现有 L1 - L2 - L3 - L4 - L5 - L6 架构的契约，而不是把“部署了治理产品”视为完成治理。

十二、测试、度量与验收

12.1 治理指标

指标	定义示例	注意事项
分类覆盖率	已分类对象 / 应分类对象	分母需完整
血缘覆盖率	可追溯派生对象占比	区分完整与部分
越权访问阻断率	被测试越权请求中阻断比例	需测试集覆盖
删除完成率	按策略完成的删除任务比例	保留例外单列
删除完成时延	请求到必需步骤完成的时间	记录 P95/P99
过期数据残留率	超期仍可访问对象占比	包括索引缓存
引用可验证率	引用可定位且支持论断的比例	需人工抽样
数据质量失败率	未通过契约的摄取对象比例	区分源头问题

这些指标用于发现问题，不能单独证明符合法律义务。尤其不能用“删除任务状态成功率”代替对实际存储副本的抽样核验。

12.2 必须执行的工程实验

实验 A：跨租户隔离。 为租户 A/B 建立相同关键词但不同权限的资料，分别测试搜索、向量检索、缓存命中、对象下载和 Agent 工具调用；预期无跨租户泄露。

实验 B：用途限制。 同一份资料允许内部摘要但禁止外发，测试模型网关和工具网关能否在真实调用前阻断；预期仅产生拒绝事件，不向外部发送内容。

实验 C：血缘撤回。 上传文件→切块→Embedding→生成报告→撤回原件；预期能枚举受影响派生对象并完成对应处理。

实验 D：备份恢复。 删除后恢复删除前的备份；预期在重新开放检索前完成删除重放，不出现已撤回对象。

实验 E：日志泄露。 输入带有敏感字段的测试数据，检查日志、Trace、错误报告与告警通知；预期不出现未经允许的明文。

实验 F：引用真实性。 注入不存在的页码、错误版本和不支持论断的来源；预期引用校验区分三类错误。

12.3 最小策略判定示例（说明性伪代码）

# 说明性伪代码；不是生产级授权引擎，也未在本篇执行测试。
def can_use(subject, data, action, purpose, destination):
    if subject.tenant_id != data.tenant_id:
        return False
    if action not in data.allowed_actions:
        return False
    if purpose not in data.allowed_purposes:
        return False
    if destination not in data.approved_destinations:
        return False
    if data.lifecycle_status != "active":
        return False
    return True

真实系统还需处理身份认证、角色关系、资源层级、属性来源可信度、策略版本、撤销与缓存失效、默认拒绝、审计以及并发竞态。示例仅说明“数据使用必须由多个维度共同决定”。

12.4 验收清单

1. 能列出主要数据集、责任人、来源、分类和保留规则。
2. 能解释一个用户请求从原始资料到模型外发、报告发布的完整数据流。
3. 未经授权的租户、Agent 或外部处理方无法读取受限数据。
4. 关键报告结论可定位到具体来源版本和引用位置。
5. 撤回原始资料时能找到主要派生对象并实施控制。
6. 删除任务覆盖数据库、对象存储、向量索引、缓存和备份策略。
7. 备份恢复不会在开放访问后重新暴露已删除对象。
8. 日志、Trace、评估数据集具有独立的保留和脱敏规则。
9. 供应商侧处理条件与本地删除能力的边界有明确记录。
10. 治理策略变更可追踪、可回滚，并能通过回归测试。

十三、常见误区与反模式

误区一：数据都在内网，所以无需治理。 内部工具、日志、索引和权限配置仍可能造成越权访问；Agent 还可能将内容外发到模型或搜索服务。

误区二：Embedding 不是原文，所以不敏感。 向量可能保留信息并支持相似性推断，仍应考虑原始数据限制和删除要求。

误区三：删除主表就等于完成删除。 派生数据、缓存、备份、第三方处理方和已发布产物需要分别处理。

误区四：模型提供了引用，就代表结论可信。 引用需校验存在性、支持关系和来源可靠性。

误区五：所有数据都应永久保存，方便以后训练。 长期保存增加暴露面、成本和治理责任；二次用途需要独立审查。

误区六：只要 Prompt 写明保密，数据就不会外泄。 Prompt 是行为引导，不是可信的授权边界。

误区七：只给数据库加 RLS 就完成多租户隔离。 对象存储、缓存、向量索引、消息系统和工具接口都需要对应的隔离措施。

误区八：数据治理就是合规部门的文档工作。 有效治理必须体现在可测试的 API、策略、状态机、日志与删除流程中。

研究结论

1. 数据治理的对象是贯穿 Agent System 的数据生命周期，而非某个存储系统。 用户输入、工具结果、模型输出、Checkpoint、长期记忆、Embedding、日志和最终产物都需要纳入资产视图。
2. 数据分类至少要表达敏感度、使用目的和保留规则。 只依赖“公开/机密”标签，无法充分约束模型外发、二次训练、跨项目共享和到期删除。
3. 数据血缘是可追溯与可撤回的基础，但不自动保证事实正确。 应把来源定位、引用支持性和事实核验分别设计为可验证的控制点。
4. 访问控制必须在受信任的数据服务、模型网关、工具网关和发布服务中执行。 Agent Prompt 不能承担授权职责。
5. 删除是一项跨系统、可失败、需要证据的工作流。 必须区分在线副本、派生数据、缓存、备份、第三方保留和合法例外，不能将本地标记删除等同于全面销毁。
6. 长期记忆和评估数据集属于独立的治理对象。 其写入、复用、撤回和二次用途应有明确的授权与生命周期。
7. 治理能力应按风险渐进建设。 对研究报告 Studio，优先落实租户隔离、受控外发、来源版本、血缘追踪与删除传播，再逐步完善目录平台和自动化治理。

附录 A：参考文献与原始资料

以下以标准、监管机构和开源项目官方资料为主。链接用于定位原始材料；部分内容具有持续更新特征，实施时应复核当前版本与适用条件。本文的工程架构和数据模型属于综合设计，不应视为任何单一来源的逐字要求。

[R1] NIST, AI Risk Management Framework (AI RMF 1.0)：www.nist.gov/itl/ai-risk-management-framework 。用于 AI 系统风险治理与生命周期管理的总体背景。

[R2] NIST, Privacy Framework：www.nist.gov/privacy-framework 。用于隐私风险识别与治理框架背景。

[R3] European Union, Regulation (EU) 2016/679 (GDPR)：eur-lex.europa.eu/eli/reg/2016/679/oj 。用于数据保护原则、处理权利与义务的原始法条；具体适用需法律评估。

[R4] 全国人大网，《中华人民共和国个人信息保护法》：www.npc.gov.cn/ 。用于中国个人信息保护制度的官方查阅入口；具体条款应以官方公布文本为准。

[R5] OpenLineage, Specification：openlineage.io/docs/spec/ 。用于数据血缘事件与开放元数据规范。

[R6] PostgreSQL, Row Security Policies：www.postgresql.org/docs/current/ddl-rowsecurity.html 。用于数据库层行级安全机制。

[R7] OpenTelemetry, Documentation：opentelemetry.io/docs/ 。用于日志、指标、追踪关联的工程背景。

[R8] Apache Atlas, Project Documentation：atlas.apache.org/ 。用于数据目录与治理平台的技术参考。

[R9] DataHub, Documentation：docs.datahub.com/ 。用于元数据目录与血缘产品的技术参考。

[R10] OpenMetadata, Documentation：docs.open-metadata.org/ 。用于目录、数据质量与血缘的技术参考。

[R11] Amazon S3, Managing the lifecycle of objects：docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html 。用于对象存储生命周期策略参考。

[R12] OWASP, Top 10 for Large Language Model Applications：genai.owasp.org/ 。用于 LLM 应用安全风险背景，具体控制细节应与 H2 对照。

[R13] W3C, PROV Overview：www.w3.org/TR/prov-overview/ 。用于来源（provenance）数据模型概念。

[R14] OpenAI, API Data Usage Policies：openai.com/policies/api-data-usage-policies/ 。用于说明第三方模型服务的数据处理条件应按实际产品和政策核验；不代表其他供应商的规则。

附录 B：研究证据、验证声明与适用边界

B.1 证据分层

• 规范与官方事实： 数据保护制度、RLS、对象生命周期、血缘标准等以附录 A 所列官方资料为参考，实施时需要核验最新版本。
• 工程推导： 数据资产模型、生命周期状态、删除协调器、受控外发与验收矩阵是基于系统设计原则形成的参考方案，不属于外部标准强制规定的唯一实现。
• 案例假设： “技术研究报告 Studio”是用于解释架构的示例场景；其中的数据对象、组织角色和流程并非对某个真实生产系统的审计结果。
• 未验证内容： 本篇未连接真实对象存储、向量数据库、模型供应商或多租户服务；SQL 与 Python 片段均为说明性参考，未进行集成测试或压力测试。

B.2 验证声明

本篇完成的是文献导向的技术综合与工程设计，而非合规认证、渗透测试或生产级验证。删除传播、权限隔离、恢复后重放和跨境数据处理需要在具体部署环境中通过实验、合同审查及必要的法律评估确认。

B.3 适用边界

适用于具备外部数据接入、工具调用、RAG、长期记忆、多 Agent 协作和交付物管理的 Agent System。对完全离线、无个人信息且无外部数据共享的最小实验系统，可以简化治理组件，但仍应保留来源、用途和删除的基本约束。

B.4 与后续专题的关系

H10 Testing & Validation 将进一步研究如何通过测试工程验证数据权限、删除传播和质量契约；H11 Deployment & Operations 研究这些控制如何在发布和运维过程中持续生效；H12 Policy & Governance 研究如何把数据治理责任与其他系统治理政策统一起来。