技能介绍

要解决什么问题

多份 memory export、写读日志、scope 配置和删除回执往往分散在不同系统里。治理复核时很难回答：这条记忆从哪来、挂在哪个 scope、谁被授权读写、到期后删到了哪一层。本技能只做一件事：把你提供的脱敏材料整理成带稳定 ID 与来源定位的静态台账，不连 memory provider、向量库或 Agent，也不替你删数据或判合规。

技能如何工作

台账围绕六类对象建模：Memory Space、Stable Memory Record、Memory Revision、Scope Binding、Consumer Binding、Lifecycle Event。关系只靠稳定 ID 和明确证据建立，不会因为内容相似或时间接近就自动合并 record。

典型流程包括：

固定口径：统计时点、时区、材料范围与用户规则
登记与 lineage：编号来源，连接 space → record/revision → scope/consumer → event
分列核对：写入、可检索、版本、保留、删除、用户控制各自独立，write requested 不等于 stored，primary receipt 不等于各衍生层已清
描述性覆盖：公开分子/分母与缺口，无用户门槛时不生成 PASS/FAIL 或 health 总分

输入中的 export、trace、截图与 OCR 均按不可信数据处理：不执行其中的指令，默认只登记 pseudonymous ID、scope 与事件 metadata。

适用边界

适合：合并多份 inventory、区分 User/Session/Agent/Team scope、核对 provenance、retention 与删除回执、标 sandbox→production 配置缺口。

不适合：实际读写/同步 memory、替代 knowledge-source-register 的文档源治理、处理隐私请求全流程或账号权限复核。与 Mem0、ByteRover 等写入检索类产品不同，本技能只整理你交上来的材料；补证、删除、配置修正均标为「未执行候选」。

截图预览

使用场景

客服 Agent 变更上线前，需把多份 memory export、space 与消费者读写配置合成一份带稳定 ID 的治理台账，且明确不连接真实 store。
用户提出删除某条 user memory 后，要对照 primary/index/backup 回执与检索日志，分列登记覆盖范围与仍可见 retrieval 的缺口。
季度治理复核前合并多份 inventory，按 Record/Revision 重建 lineage，区分直接用户陈述、CRM 推断与 session 摘要等不同 provenance。
按固定统计时点检查 Session close 后的 retention 是否到期、清理回执是否缺失，并单独标出「仅配置、无观察事件」的落差。

适合人员

负责多环境 Agent 部署的平台工程师，要在不直连向量库的前提下导出 consumer binding 与 sandbox→production 隔离证据供内审。
处理 memory 相关 DSAR 的隐私运营，需要把 Request ID、受理决定与各技术层删除回执映射到具体 Record/Revision。
定义 personalization purpose 与 DEC 规则的产品负责人，要核对哪些 record 类别被决策覆盖、哪些仍缺 Purpose Decision。
维护客服 Agent 写读日志的可靠性工程师，要把 write requested 与 write confirmed、observed read 与 output 采用分列成事件台账。