可见性模型:private / team / restricted / agent


文档摘要

可见性模型:private / team / restricted / agent 本节摘要:资产生命周期解决「时间上能否用」,可见性模型解决「空间上谁能用」。本节讲清四级可见性:private(仅 Owner,团队管理员也不可见)、team(团队成员可读)、restricted(按 User/Role/Agent ACL 精确授权)、agent(同团队 Agent 定向装配)。核心原则只有一句——「新记忆默认私有,分享是明确动作,不是默认泄漏」。这四级让团队可以共享经验,却不必共享全部隐私。本节用对照表与典型场景,把四级的边界与用法讲透,为你理解下一节的装配机制铺好「权限范围」这一层。

可见性模型:private / team / restricted / agent

本节摘要:资产生命周期解决「时间上能否用」,可见性模型解决「空间上谁能用」。本节讲清四级可见性:private(仅 Owner,团队管理员也不可见)、team(团队成员可读)、restricted(按 User/Role/Agent ACL 精确授权)、agent(同团队 Agent 定向装配)。核心原则只有一句——「新记忆默认私有,分享是明确动作,不是默认泄漏」。这四级让团队可以共享经验,却不必共享全部隐私。本节用对照表与典型场景,把四级的边界与用法讲透,为你理解下一节的装配机制铺好「权限范围」这一层。

一、四级可见性对照

四级可见性的语义边界,用一张表钉死:

可见性 谁能读 谁能管 典型场景
private 只有 Owner Owner 个人偏好、敏感笔记
team 团队成员可读 Owner / Team Admin 团队共享的排障 Skill
restricted ACL 授权的 User/Role/Agent Owner 只给特定角色的机密资产
agent 同团队 Agent 定向装配 Owner 给某个 Agent 专属配装
可见性范围(由窄到宽) private ──▶ agent ──▶ restricted ──▶ team (最窄,仅Owner) (ACL精确) (全队)

关键概念:这四级不是简单的「公开度递增」,而是不同维度的控制——private 是「排除所有人」,team 是「纳入全队」,restricted 是「按 ACL 精确点名」,agent 是「定向给某个 Agent」。它们解决不同的共享需求。

二、核心原则:默认私有,分享是动作

整套可见性模型最重要的原则:

默认私有原则 新建的 Chat Memory / Skill → 默认 private 分享 → 必须是 Owner 的明确动作(改可见性、审核分享) → 经验不会「默认泄漏」,只会「主动共享」

这条原则的意义在于信任:团队成员可以放心地把敏感信息(如个人偏好、未成型的想法)交给系统,不用担心它们自动被别人看到。分享是「打开一道门」,而不是「门本来开着」。

⚠️ 注意:特别强调一点——private 资产「团队管理员也不可见」。这不是疏漏,而是刻意设计:如果 Admin 能看所有 private 资产,成员就不敢把敏感东西交给系统,「默认私有」的信任基础就塌了。Admin 有「治理权」(管理资产状态),没有「读 private 内容的权」。

三、逐级看用法与典型场景

private:个人的、敏感的

适合:个人偏好(「我喜欢简洁的注释」)、未成型的想法、敏感的项目笔记。
价值:让 Agent 记住你的个人习惯,又不让团队其他人看到。

team:团队共享的成熟经验

适合:经过审核的排障 Skill、团队约定的工作流、公共文档的 Wiki。
价值:「练会一次,全队可用」——这是团队经验复利的载体。

restricted:精确授权的机密资产

适合:只给 Reviewer 角色的发布检查 Skill、只给特定项目的架构 Wiki。
机制:通过 User / Role / Agent 的 ACL 精确点名授权。

restricted 的 ACL(概念) 资产:「发布检查 Skill」 ACL: Role=Reviewer → 允许读 Agent=Release → 允许装配 其他 → 拒绝

agent:定向装配给某 Agent

适合:给某个 Agent 专属配装、不想给全团队的资产。
与 restricted 的区别:restricted 是「按身份精确授权」,agent 是「按 Agent 定向装配」,后者更聚焦于「装配」这个动作。

四、四级可见性如何支撑「共享经验不共享隐私」

回到第 2 章那句反复出现的承诺:「团队可以共享经验,却不必共享全部隐私」。现在可以看清它在工程上是怎么成立的:

一个团队的真实配置(示例) alice 的个人偏好 → private(团队看不到) 团队排障 Skill → team(全队可用) 给 Reviewer 的发布检查 → restricted(ACL: Role=Reviewer) 给 Release Agent 的专属 → agent(定向装配) → 经验在流动(团队/restricted/agent),隐私被保护(private)
需求 用哪级
我想让 Agent 记住我的个人习惯 private
我想让全队都用上这套做法 team
我想只给特定角色用 restricted
我想只给某个 Agent 配 agent

💡 技巧:配置可见性时,问自己一个问题:「这条资产,最少需要让谁看到?」从 private 起步,按需放宽到 agent / restricted / team。从最窄开始放宽,比从最宽开始收窄,更不容易泄漏。

五、可见性与召回的衔接

可见性是召回「过滤」环节的关键判据,它和上一节的生命周期过滤叠加:

召回前的双重过滤 ① 生命周期过滤:状态=可用、当前版本、绑定含当前 Agent ② 可见性过滤:当前用户/Agent 是否在资产的可见范围内 两层都通过 → 进入候选集 → 检索

可见性这一层保证了:即使一条资产被绑定了,如果你不在它的可见范围内,你也召回不到。这就是「团队共享经验不共享隐私」在召回环节的最后一道闸。下一节我们会把「绑定」与「可见性」合起来,讲完整的装配机制。

本节要点回顾

  1. 四级可见性:private(仅 Owner)、team(全队)、restricted(ACL 精确)、agent(定向装配),不同维度非简单递增。
  2. 核心原则:默认私有,分享是明确动作——经验不默认泄漏。
  3. private 连 Admin 都不可见:这是「默认私有」信任基础,Admin 有治理权无读 private 权。
  4. 典型配置:个人偏好 private、成熟经验 team、角色专属 restricted、Agent 专属 agent。
  5. 召回双重过滤:生命周期 + 可见性两层都过才进候选——隐私保护的召回闸门。

可见性划清了「谁能读」,下一节把「绑定」与「可见性」合起来,讲完整的装配机制——记忆如何从「候选集」精确到达「目标 Agent」。


发布者: 作者: 灏天文库 转发
评论区 (0)
U