N1Mem 记忆分层共享模型

谁能看到哪条记忆？—— 一页讲清 · 2026-09-30 · 随 013/028/029/030/031 落地

给赶时间的你（30 秒版）

N1Mem 里每条记忆都有一个"可见范围"，从最私密到最开放共四级；另外每个记忆都贴着一个"项目"标签。规则只有两句：

谁可见：整个组织org —— 组织级
团队的经验、技能、协作约定。默认落点：大家都能看到，才能"越用越懂团队"。

谁可见：同一支团队team —— 团队级
只在某支团队内流动的记忆（如某条产品线的内部约定）。

谁可见：同一个 Agent 岗位agent —— Agent 岗位级
为敏感岗位设计：财务 Agent、超级账号管理员 Agent 的记忆，普通 Agent 看不到。岗位名属敏感前缀的，需管理员登记后使用（防止普通 Agent 冒名绕过隔离）。

谁可见：只有写入者本人private —— 私有
个人偏好、私密笔记。也是数据库的兜底默认：任何"没有明确说要共享"的写入，都落在这里 —— 宁可不共享，不可泄密。

一条 org 级的记忆可以属于"prod"项目，另一条属于"dev" —— 召回时只带出当前项目的记忆 （dev 的数据库地址绝不会出现在 prod 的上下文里）。项目的使用规则：

规则	说明
首用即登记	第一次用到新项目名，自动进本组织的项目台账，无需预先申请。
Skill 项目绑定	技能（Skill）可绑定项目；绑定后其他项目的会话拿不到它 —— 错配可能导致故障，所以这是硬边界不是降噪。
global 保留字	跨项目的通用记忆（如"团队用什么代码规范"）落 global，所有项目可见。

#	防线	做什么
1	显式声明	写入方可以明确说"这条要 org / agent / private"—— 声明优先级最高。
2	路径默认	没声明时按组织配置走（默认 org = 充分共享；合规客户可整组织改为 private）。
3	敏感扫描	检出密钥 / 敏感级别 ⇒ 强制收窄为 private，且只收紧、永不放宽。扫描在服务端，客户端绕不过。

净效果：官方接入的客户开箱即享充分共享（零配置）；敏感内容被自动收窄；绕过官方路径的裸调用落到最私密的兜底。效率与安全各得其所。

机制	实现
可见性合成	`final = narrower(期望, 扫描上限)`；排序 `private < agent < team < org`（单一定义点 `c2_api/visibility.py`）
列默认兜底	数据库列默认 `'private'`（fail-closed）；应用层显式写值 ≠ 条件分支默认
强制执行	PostgreSQL RLS 策略 + CHECK 结构约束（"私有但无主"/"Agent 私有但无岗"不可表示）
主体归属	请求显式声明 > Key 级默认主体（发钥时定人）> 服务端钉定（内部通道）—— 主体即账目与可见性的锚点
无主体写入	结构性拒绝（CHECK），409 文案指向重装自动预填 —— 不存在静默丢失
Agent 供值	`app.agent_id` 与策略同一常量组供值（供值方/消费方不共享常量 = 差异原理上测不出来）