[RFC]OpenViking增加隐私信息统一管理，SKILL自动提取隐私信息 #1465
yeshion23333
started this conversation in
RFC
Replies: 3 comments
|
建议 admin 角色也默认不能访问 user 的隐私数据 |
0 replies
|
初版方案实现见：#1745 目前遇到新的待讨论点：
比如： |
0 replies
|
是否考虑直接复用 POSIX-like 的文件权限设计和 ACL 规则设计呢？因为 OpenViking 已经提供了一种 filesystem-like 的 context 组织形式，无妨将这个思路推向极致，提供一套符合 POSIX 规范的文件权限管理体系。这么做的好处包括但不限于：
|
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
OpenViking User 隐私信息管理方案
一、背景
这样设计的好处是：
因此，本方案将问题拆成两层：
二、目标
本期方案要实现的核心目标如下：
1. 建立通用的 User 隐私配置体系
由 OpenViking 统一管理用户的隐私/敏感配置，而不是分散在 Skill 文本、配置文件或外部系统里。
2. 支持分类（Category）
隐私配置按分类组织，第一版至少支持：
skill未来可扩展：
toolprovider3. 支持按 User 隔离
每个 User 拥有自己独立的隐私配置空间。
4. 支持多版本管理
每个 User 在每个 category 下、针对每个对象（例如某个 skill），都可以：
5. 支持 OpenViking 内部业务接入
以 Skill 为第一批接入业务，要求：
skill分类三、调研结论
3.1 OpenViking 已具备的能力
1）统一安全存储底座已经存在
关键文件：
openviking/crypto/encryptor.pyopenviking/crypto/providers.pyopenviking/storage/viking_fs.py现状：
write_file/write_file_bytes/write_context在 encryptor 启用时会自动加密后再落盘read_file/read_file_bytes在 encryptor 启用时会自动解密encryption.enabled是否开启；如果未开启，则按明文落盘加密实现方式：
这意味着：
2）多租户与 User 访问隔离已经存在
关键文件：
openviking/server/identity.pyopenviking/server/auth.pyopenviking/storage/viking_fs.py现状：
RequestContextaccount_id/user/roleuser_space/agent_space已有访问控制逻辑这意味着：
3）版本管理有参考实现
关键文件：
openviking/session/session.py现状：
这意味着：
4）Skill 添加与读取主链路明确
关键文件：
openviking/utils/skill_processor.pyopenviking/core/skill_loader.pyopenviking/service/fs_service.pyopenviking/storage/viking_fs.py现状：
SkillProcessor.process_skill()FSService.read()这意味着：
3.2 OpenViking 当前缺失的能力
虽然基础很好，但通用 User 隐私配置体系目前还没有：
UserPrivacyConfigService所以本次重点不是重做存储，而是补这层抽象。
四、总体架构
整体架构拆成两层。
4.1 第一层：通用 User 隐私配置框架
负责：
4.2 第二层：业务接入适配层
Skill 是第一个 category 接入对象。
负责：
未来还可以接入：
五、核心概念设计
5.1 Category
User 隐私配置的一级分类。
第一版建议支持：
skill未来扩展：
toolprovider作用
category 让 OpenViking 的隐私配置体系从一开始就是通用框架，而不是 Skill 专属实现。
5.2 Target Key
每个 category 下都需要有一个“配置对象标识”。
对于 Skill：
target_key = skill_name例如：
category=skilltarget_key=browser-search未来如果 category=provider：
target_key=volcengine这样结构上统一。
5.3 Active Version
每个 User、每个 category、每个 target_key，都允许有多个版本，但始终只有一个当前生效版本。
读取配置时：
查看历史时：
六、存储模型设计
6.1 URI 结构
统一放在 user 空间下：
viking://user/{user_space}/privacy_configs/{category}/{target_key}/current.jsonviking://user/{user_space}/privacy_configs/{category}/{target_key}/history/version_001.jsonviking://user/{user_space}/privacy_configs/{category}/{target_key}/history/version_002.jsonviking://user/{user_space}/privacy_configs/{category}/{target_key}/.meta.json其中：
current.json当前 active version 的完整配置。
history/version_xxx.json每个历史版本快照。
.meta.json配置元数据：
categorytarget_keyactive_versionlatest_versioncreated_atupdated_atupdated_bylast_accessed_atlabels存储安全说明
current.json/history/version_xxx.json/.meta.json都建议通过 VikingFS 写入kvfs中，因为现有kvfs是内存型实现、无持久化，进程重启后数据会丢失kvfs更适合作为运行时缓存层，而不是隐私配置的主存储层6.3 数据模型
UserPrivacyConfigMeta
建议字段：
categorytarget_keyactive_versionlatest_versioncreated_atupdated_atupdated_bylabelsUserPrivacyConfigVersion
建议字段：
versioncategorytarget_keyvaluescreated_atcreated_bychange_reason其中：
values是一个结构化 dict七、通用能力设计
7.1 配置创建
为某个 User、某个 category、某个 target_key 创建第一版配置。
行为：
version_001current.jsonhistory/version_001.json.meta.json7.2 配置更新
为某个 User、某个 category、某个 target_key 创建新版本。
行为：
version_xxxcurrent.json.meta.json.active_version7.3 配置查看
支持查看：
这是 User 直接管理配置的基础。
7.4 生效版本切换
支持：
行为：
.meta.json.active_versioncurrent.json这样读取统一只看
current.json即可，避免每次都解析 meta + history。7.5 列出配置对象
支持：
例如：
八、Skill 作为 category=skill 的接入方案
8.1 Skill 与通用配置框架的关系
Skill 不再拥有独立的一套 secret store。
而是映射到：
category = skilltarget_key = <skill_name>这意味着：
8.2 Skill 添加时的自动抽取
改造点
openviking/utils/skill_processor.py插入时机
在：
_parse_skill()之后_generate_overview()之前推荐时序
当前：
改为：
category=skill的 user privacy config为什么这里最合理
因为可以确保：
额外安全边界说明
必须强调：
8.3 Skill 自动抽取策略
优先抽取的字段类型
api_keytokenakskaccess_keysecret_keyclient_secretbase_url（如业务上认定也属于隐私配置的一部分）8.4 Skill 正文 placeholder 化
为了让 Skill 可以脱敏存储，建议统一引入 placeholder。
例如：
{{ov_privacy:skill:browser-search:api_key}}{{ov_privacy:skill:browser-search:ak}}设计原则：
这样版本切换时不需要回写 Skill 文本。
8.5 Skill 读取时自动还原
改造点
openviking/service/fs_service.py:read()行为
读取文本时：
SKILL.mdprivacy_configs/skill/{skill_name}/current.json为什么只在 read 时还原
因为：
读取还原的安全约束
读取还原虽然合理，但还需要补充约束：
8.6 是否可以把 active version 放到 kvfs
可以讨论，但建议定位为“缓存”而不是“真相源”。
当前 kvfs 的现实情况
kvfs插件抽象kvfs是内存型实现，无持久化结论
不建议把 active version 的唯一权威状态只放在 kvfs 中。
更合理的做法是：
viking://user/{user_space}/privacy_configs/{category}/{target_key}/.meta.jsoncurrent.json仍作为当前生效版本的落盘快照{user_space}/{category}/{target_key} -> active_version{user_space}/{category}/{target_key} -> current values推荐分层
好处
九、接口与服务建议
9.1 通用服务层
新增：
UserPrivacyConfigService负责：
9.2 通用数据结构
建议新增：
UserPrivacyConfigMetaUserPrivacyConfigVersion9.3 Skill 接入适配层
新增：
skill_privacy_extractor.pyskill_privacy_placeholder.pyskill_privacy_restore.py职责分别为：
9.4 可选的 API 方向
如果后续需要 User 显式管理配置，可以新增通用 API，例如：
注意：
本期即使不先暴露完整外部 API，也建议先把 Service 层和存储模型打好。
十、总结
本次方案的核心调整是：
一句话总结：
All reactions