Fixed Binding + ACL:从权限范围到召回

Fixed Binding + ACL:从权限范围到召回

本节摘要:本章前三节分别讲了元数据、生命周期、可见性,本节把它们收束成一个完整的装配机制——Fixed Binding + ACL。核心流程只有一句:先按 Team / User / Agent / 可见性缩小权限范围,再对缩小后的集合做检索。这种「先过滤后召回」让团队可以共享经验库,但每个 Agent 只召回到「它被装配的、它有权看的」那一小撮。本节讲清这套机制的流程、它与「全局 Prompt」的根本差异,以及为什么「换 Agent 只需重新装配,不必重新训练」在工程上成立。

一、装配机制的核心:先过滤后召回

把前三节的过滤条件叠起来,就是完整的装配流程:

完整的装配过滤(从全量到候选集)
  全部记忆资产
    │
    ├─ ① Team 过滤:当前 team_id 能看到的
    ├─ ② User 过滤:当前 user_id 在可见范围内
    ├─ ③ Agent 过滤:绑定含当前 agent_id(Loadout)
    ├─ ④ 可见性过滤:private/team/restricted/agent 判定
    ├─ ⑤ 生命周期过滤:状态=可用、当前版本
    │
    ▼
  候选集(已大幅缩小)
    │
    ▼
  按当前问题检索(BM25+向量+RRF,第6章)
    │
    ▼
  召回结果(注入上下文)
​

关键概念:这套机制的精髓在「顺序」——先缩小范围,再检索。如果反过来(先在全量里检索,再过滤权限),不仅浪费算力,还可能把不该看的先检索出来再丢弃,既有泄密风险又慢。「先过滤后召回」是把权限检查前置,既安全又快。

二、Fixed Binding:把资产「固定」给 Agent

「Fixed Binding」指的是把特定资产显式绑定到指定 Agent,让它成为该 Agent 的常驻装备:

Fixed Binding 的效果(以 Loadout 为例)
  Builder Agent 的绑定:
    ├─ 产品 Wiki(team 可见 + 绑定 Builder)
    ├─ 项目 CodeGraph(team 可见 + 绑定 Builder+Reviewer)
    └─ Feature Delivery Skill(team 可见 + 绑定 Builder)
  
  Reviewer Agent 的绑定:
    ├─ 历史事故 Chat Memory(restricted: Role=Reviewer)
    ├─ 项目 CodeGraph(同上,共享)
    └─ Release Checklist Skill(agent: 定向 Reviewer)
​

注意 Builder 和 Reviewer 共享 CodeGraph(都绑定了),但其他装备不同——这就是「不同角色不同 Loadout」。Fixed Binding 让「配装」成为一个明确的、可管理的动作,而不是「系统能不能自己猜该给什么」。

💡 技巧:配装时遵循「少给噪音多给所需」——只绑定该 Agent 完成职责真正需要的资产。给 Builder 塞发布检查单、给 Reviewer 塞竞品分析,都是噪音,会稀释真正有用的记忆。第 11 章场景实战会详细讲 Loadout 设计。

三、ACL:在可见性基础上的精确授权

ACL(Access Control List)是 restricted 可见性的实现机制,它让你在「可见性」之上做更细的「点名」:

ACL 的作用层次
  可见性 = restricted  (这级才用 ACL)
    └─ ACL:
         User=bob       → 允许
         Role=Reviewer  → 允许
         Agent=Release  → 允许装配
         其他           → 拒绝
​

ACL 与 Fixed Binding 的关系:ACL 管「在 restricted 这级,谁能读」,Fixed Binding 管「读到了之后,谁常驻装备」。一条资产可以是 restricted 可见性 + ACL 点名 + 同时绑定给被点名的 Agent——三层叠加,精确控制。

四、与「全局 Prompt」的根本差异

装配机制与传统「全局 Prompt」(把所有相关内容塞进 system prompt)的根本差异,在于「范围控制」:

全局 Prompt 模式(传统)
  所有相关内容 → 全塞进 system prompt
  问题:内容随时间膨胀,占满上下文;无法按 Agent 区分
  
装配模式(本系统)
  每个 Agents → 只装配它该有的(先过滤)
  问题当前 → 只召回与问题相关的(再检索)
  结果:上下文精简、按 Agent 定制、按问题聚焦
​

⚠️ 注意:这就是第 2 章那条命题——「记忆不是全局 Prompt,而是 Agent 的 Loadout」——的工程实现。它不是风格选择,而是「上下文窗口有限」这一硬约束下的必然设计。

五、「换 Agent 不必重新训练」为什么成立

装配机制带来一个重要的工程红利:换 Agent 或换框架,只需重新装配,不必重新训练。

传统模式(重新训练)
  换 Agent → 重新喂数据、重新训练/微调 → 成本极高
  
装配模式(重新装配)
  换 Agent → 在控制台给它配新的 Loadout → 即时生效
  记忆资产不变,只是「谁带哪些」变了
​

成立的原因是:记忆资产与 Agent 框架解耦——资产是「数据」,Agent 是「消费者」,装配是「绑定关系」。换 Agent 只是换消费者,资产不动,重新绑定即可。这就是 README 里说的「记忆资产与 Agent 框架解耦,可以跨框架迁移」的工程含义。

本节要点回顾

1. 核心流程:先按 Team/User/Agent/可见性/生命周期缩小范围,再检索——权限前置,既安全又快。
2. Fixed Binding:把资产显式绑定给 Agent,成为常驻装备;配装遵循「少给噪音多给所需」。
3. ACL 三层:可见性(粗)+ ACL(中)+ Binding(细),三层叠加精确控制。
4. 与全局 Prompt 的根本差异:装配是「按 Agent 过滤 + 按问题检索」,全局 Prompt 是「全量塞」——这是上下文有限约束下的必然设计。
5. 换 Agent 不重训:资产与框架解耦,换 Agent 只是重新装配——跨框架迁移的工程红利。

第 3 章到此完成,资产统一模型(元数据 + 生命周期 + 可见性 + 装配)的全貌已清。下一章深入资产内部——以 Chat Memory 为例,看它内部的 L0-L3 四层记忆如何生长。