权限与可见性设计

这篇文档定义的是"谁能看到什么"，不是"谁能写什么"。 写入权限由《产品与架构设计》约束；本文补充多角色服务下的读取边界、字段裁剪和 prompt 注入规则。 如本文与《产品与架构设计》冲突，以后者为准。 最后更新：2026-03-18

---

一、为什么必须单独定义

清海是一个统一存在的 AI，但它面向不同角色提供服务时，不能把同一份全量上下文直接暴露给所有人。

如果只定义写入权限，不定义读取边界，会出现三类典型错误：

1. 员工对话被注入了不该看到的他人事项或管理判断
2. 群聊里因为有高权限成员出现，导致普通成员也间接拿到高敏信息
3. Memory / Fact / Concern 虽然写对了地方，却在读取时越权暴露

所以必须把"可写"和"可读"分开定义。

---

二、核心原则

1. 默认最小可见性。不能证明应该看见的，就默认不注入、不返回。
2. 读取一律走切片，不直接暴露完整真源对象。
3. 能看摘要，不等于能看详情；能看详情，不等于能看原始上下文。
4. prompt 注入前先做可见性裁剪，不能先把全量数据塞给模型再靠回复层兜底。
5. raw_context、内部渠道 ID、执行器错误细节、系统内部推理过程，默认不对普通对话暴露。
6. 群聊按当前说话人的权限裁剪，不因群内存在高权限成员就自动放大可见范围。

---

三、角色与默认可见范围

角色	默认可见范围
owner	当前企业全局范围
admin	被授权的企业管理范围
team_lead	自己、直管下属、负责项目、被明确授权的事项范围
employee	自己、自己参与的事项、当前协作所需的最小他人信息
guest	自己的基础信息 + public 级知识，不读取内部运行态

作用域约束

• owner 的全局可见性仍不包括系统密钥、底层凭证、内部调试数据。
• admin 不是天然全局可见，必须受授权范围约束。
• team_lead 的可见范围跟着 direct_reports / owned_projects / explicit grants 走，不是看到所有员工。
• employee 默认不能读取他人的长期画像、管理判断、全局议程。
• guest 不进入内部 Agenda / Concern / Memory 检索链路。

---

四、按层读取矩阵

层	owner	admin	team_lead	employee	guest
Person	作用域内完整切片	授权范围完整切片	自己 + 直管/负责范围的摘要与工作状态	自己完整切片；他人仅协作所需最小身份信息	仅自身基础信息
Agenda	全局摘要、排序、watch、concern refs	授权范围摘要与排序	负责范围摘要	仅与自己相关的提醒、委托、待回复事项	不可见
Concern	作用域内完整	授权范围完整	自己参与或负责范围内完整，否则不可见	仅本人参与的 concern	不可见
Fact / Action	摘要默认可见，raw 需显式查看	同左，但受授权范围限制	仅自己或负责范围摘要	仅本人相关摘要	不可见
Memory	作用域内可检索	授权范围可检索	负责范围可检索，默认脱敏	仅自有记忆和 reply-safe 经验	仅 public
Knowledge	internal / confidential / public	internal / confidential / public（按授权）	internal + 被授权资料	public + 与本人工作直接相关的 internal	仅 public

---

五、字段级硬规则

5.1 Person

• manager_notes 默认只对 owner 和被明确授权的 admin 可见。
• interaction_policy 只暴露对当前回复必要的部分，不把完整防骚扰配置直接给普通角色。
• 员工读取他人信息时，默认只允许：
  • display_name
  • department
  • title
  • 与当前事项直接相关的最小工作状态摘要

5.2 Agenda

• focus_queue 的全局排序默认只对 owner 可见。
• admin 与 team_lead 看到的是作用域内投影，不是全量 Agenda。
• employee 不读取"系统当前最关注哪些人/哪些项目"这种全局运行态。

5.3 Concern

• 只有事项参与人、发起人、负责管理者、被授权管理员可以看 concern 详情。
• 非参与人即便需要知道结果，也只看 redacted summary，不看 conversation_log 全文。
• conversation_log 默认按最小必要原则裁剪，不把无关参与者的原话泄露给第三方。

5.4 Fact / Action

• raw_context、消息 ID、渠道 open_id、trace_id、执行器错误栈，默认不对普通对话开放。
• 普通读取默认返回摘要视图，不直接返回原始 payload。
• action.result_detail 仅在排障或审计场景对高权限角色开放。

5.5 Memory / Knowledge

• Memory 写入时必须带可见性标签，至少区分：
  • self
  • concern_participants
  • team_scope
  • company_internal
  • public
• 检索发生在可见性过滤之后，不允许先召回再做人工判断。
• Knowledge 至少区分：
  • public
  • internal
  • confidential

---

六、Prompt 注入规则

对话链路里，读取控制落在 prompt 组装前。

identify_user()
  -> 计算 visibility_scope
  -> 读取 Person / Agenda / Concern / Memory 可见切片
  -> 注入 prompt
  -> 生成回复

具体要求

1. person context slice 必须按当前角色裁剪，不能把完整 PersonContext 直接注入。
2. concern 摘要与回复候选 只注入当前说话人与其可见事项相关的部分。
3. MemorySearch 必须以可见性标签为过滤前置条件。
4. QueryBusinessContext 返回的业务数据也要受当前角色和事项范围约束。
5. 群聊场景下，只能注入对当前发言者可见且可安全在群里表达的信息。

---

七、输出规则

读取被裁剪后，输出仍要遵守两条规则：

1. 不能在回复里反推泄露被隐藏字段。
2. 升级、回流、私聊补充说明时，可以根据目标人的更高权限重新组装更完整上下文。

典型例子：

• 员工问"张三怎么还没回"：只能回复与当前协作有关的安全摘要，不能展开张三的长期画像或其他 concern。
• 老板问"这个项目谁卡住了"：可以汇总相关人的事项状态和风险，但仍不暴露系统内部 trace / raw payload。
• 外部角色问内部进展：只能返回允许暴露的公开说明，不读取内部 Agenda。

---

八、当前原则

1. 多角色服务不等于多角色共享同一份上下文。
2. 写入权限和读取可见性必须分开定义。
3. 对话 prompt 只能注入当前角色可见的数据切片。
4. 群聊按最小可见性处理，不做权限放大。
5. manager_notes、全局 Agenda、Concern 全文、Fact raw_context 默认不是普通对话数据。