可见性模型:private / team / restricted / agent 本节摘要:资产生命周期解决「时间上能否用」,可见性模型解决「空间上谁能用」。本节讲清四级可见性:private(仅 Owner,团队管理员也不可见)、team(团队成员可读)、restricted(按 User/Role/Agent ACL 精确授权)、agent(同团队 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 内容的权」。
适合:个人偏好(「我喜欢简洁的注释」)、未成型的想法、敏感的项目笔记。
价值:让 Agent 记住你的个人习惯,又不让团队其他人看到。
适合:经过审核的排障 Skill、团队约定的工作流、公共文档的 Wiki。
价值:「练会一次,全队可用」——这是团队经验复利的载体。
适合:只给 Reviewer 角色的发布检查 Skill、只给特定项目的架构 Wiki。
机制:通过 User / Role / Agent 的 ACL 精确点名授权。
restricted 的 ACL(概念) 资产:「发布检查 Skill」 ACL: Role=Reviewer → 允许读 Agent=Release → 允许装配 其他 → 拒绝
适合:给某个 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 是否在资产的可见范围内 两层都通过 → 进入候选集 → 检索
可见性这一层保证了:即使一条资产被绑定了,如果你不在它的可见范围内,你也召回不到。这就是「团队共享经验不共享隐私」在召回环节的最后一道闸。下一节我们会把「绑定」与「可见性」合起来,讲完整的装配机制。
可见性划清了「谁能读」,下一节把「绑定」与「可见性」合起来,讲完整的装配机制——记忆如何从「候选集」精确到达「目标 Agent」。