boss

Appearance

ADR-001 · Multi-anchor 架构: boss-skills 与 per-anchor 知识库解耦 ​

字段值
状态proposed · A 档已实施 (config.yaml + panel.yaml 注入 anchor_slug 字段)
日期2026-05-28
决策者CTO + 项目主理
相关CLAUDE.md §4.5 (Phase 4 panel) · panels/default.yaml · config.yaml

1. Context · 现状与问题 ​

V0 期的 boss-vault 把两件本质不同的事耦合在一起:

动作当前实现锚点假设
A · 知识库建设飞书 → feishu_sync_filter.py 过滤 → anchors/tian/raw/feishu-sync/ → sage-wiki ingest → _wiki/{entities,people,concepts}/ → 抽出 anchors/tian/perspective/SKILL.md 的 mental_modelshardcode 某具体锚点
B · 判断流水线/boss <议题> → Phase 0-5 → 评委独立合议 → anchor_delta → 版本化hardcode anchor_slug: tian

当前耦合点 (硬编码了"某个具体锚点"假设):

  • 目录: anchors/tian/perspective/, skills/tian-judgement-orchestrator/, skills/feishu-sync-adapter/
  • 数据: anchors/tian/raw/feishu-sync/, anchors/tian/raw/interviews/
  • 配置: panels/default.yaml 内 judge_slug: tian
  • 脚本: scripts/feishu_sync_filter.py, scripts/install_tian_skill.sh

问题: 想给第二个老板 (e.g., jobs / musk / 任意创始人) 建知识库 + 用 boss skills 时, 必须 fork 整个 vault 或大量参数化, 无法平滑扩展。

洞察: A 与 B 在概念上是两层 — A 是 per-anchor 数据 instance, B 是通用判断平台。架构上应解耦。

2. Decision · 决策 ​

演进到 multi-anchor 架构: 同一套 boss-skills (Phase 0-5 + 6 维度评委 + 5 镜头 + adversarial_view + attribution) 可服务任意锚点; 每个锚点持有独立的数据 instance (raw + Wiki + perspective skill)。

演进路径分 3 档 (本 ADR 接受 A 档为当前阶段):

2.1 · A 档 · 轻量参数化 (当前 — 已实施) ​

做什么: 把硬编码的 anchor 身份抽成 config.yaml 的 anchor: 段; panels/*.yaml 加 anchor_slug 字段绑定到对应 perspective skill。文件结构不动, 路径仍含历史命名。

实施改动 (本 ADR PR):

  • config.yaml 新增 anchor: 段, 含 slug, display_name_cn/en, perspective_skill, orchestrator_skill, raw_dirs, filter_script, source_adapter 字段
  • panels/default.yaml anchor judge entry 新增 anchor_slug: tian 字段, 绑定 config 锚点
  • 不改 skills/ 目录名 (anchors/tian/perspective/ 保留, 内部 ID)
  • 不改 raw/ 目录名 (anchors/tian/raw/interviews/ 保留)
  • 不动 orchestrator / Phase 0-5 实现

适用场景: 当前 V0 期单锚点。为 B 档预留语义入口。

2.2 · B 档 · Per-anchor profile · 中期 ​

做什么: 引入 anchors/<slug>/ 子目录结构, 一个 vault 可同时持有多个锚点的知识库:

anchors/
├── tian/
│   ├── raw/                    ← 该锚点的一手素材
│   ├── _wiki/                  ← 该锚点的 Wiki 编译产物
│   └── perspective/SKILL.md    ← 该锚点的 mental_models
├── jobs/                       ← 假想第二锚点
│   ├── raw/
│   ├── _wiki/
│   └── perspective/SKILL.md
└── ...

调用: /boss "议题" --anchor jobs 选用哪个锚点 panel。

改动范围:

  • refactor anchors/tian/perspective/ → anchors/tian/perspective/
  • refactor anchors/tian/raw/interviews/ anchors/tian/raw/feishu-sync/ → anchors/tian/raw/
  • sage-wiki config: output: anchors/<slug>/_wiki 参数化
  • panels/*.yaml anchor_slug 决定查找 anchors/<slug>/perspective/
  • 适配器 (feishu_sync_filter / source_adapter) 接受 --anchor 参数

适用场景: 项目主理 / SuperIntern 同时维护 ≥ 2 个老板的知识库, 判断时切换锚点。

2.3 · C 档 · 两 repo 分离 · 终极开源形态 ​

做什么: 拆 boss-skills (通用流水线) 与 boss-vault-<slug> (per-anchor 数据):

github.com/&lt;org&gt;/boss-skills        ← 开源 · 通用 Phase 0-5 + 评委 + 流程
github.com/&lt;org&gt;/boss-vault-tian    ← 私有 · 该锚点的 raw + Wiki + perspective
github.com/&lt;org&gt;/boss-vault-jobs    ← 私有 · 第二锚点的数据

boss-vault-<slug> 通过 git submodule / 配置文件引入 boss-skills:

yaml
# boss-vault-tian/config.yaml
boss_skills_version: v1.0.0    # 通过 pip / submodule 引入
anchor:
  slug: tian
  ...

适用场景: 开源 boss-skills 让外部用户自建; 内部多锚点完全隔离 confidentiality。

3. Consequences · 接受的 Tradeoff ​

3.1 · 收益 ​

  • 解耦: A 动作 (数据采集 + Wiki 建设) 与 B 动作 (判断流水线) 概念上分开
  • 可扩展: 添加新锚点的代价从 "fork vault" 降到 "建新 panel + 新 perspective skill"
  • 配置集中: anchor 身份从散落在文件名变成 config.yaml 单点
  • 开源演进路径明确: A → B → C 三档逐步, 不必一步到位

3.2 · 成本 ​

  • A 档当前: 路径仍含 tian / feishu-sync 等历史命名, anchor_slug 字段是 "符号性" 的指针, 不实际改路径; 工具脚本仍 hardcode 路径。这是承认的 tech debt, 由 B/C 档清理。
  • B 档若实施: 需要 refactor 约 15 个文件 (orchestrator + 评委 + filter), 一次性 1-2 天工作量
  • C 档若实施: 需要 git submodule / pip 包管理, CI/CD 同步, 跨 repo 版本协调, 约 1 周工作量

3.3 · 推迟决定的部分 ​

  • 第二锚点何时建? — 等用户实际需求出现再触发 B 档
  • 是否走 pip 包发布? — C 档实施时再决定 (可能 git submodule 更轻)
  • adversarial 评委的多 anchor 情况下是否独立? — 当前 adversarial_view 分布式内化, 与 anchor 无关, 保持现状

4. Alternatives Considered · 考虑过的其他方案 ​

方案为什么没选
C 档直接做 (一步到 boss-skills + boss-vault-* 拆 repo)当前只有 1 个锚点, 拆 repo 收益不抵管理成本; A 已足够支撑未来扩展
保持现状 (不引入 anchor_slug 概念)用户明确诉求是"可拓展, 建立任何老板的知识库"; 不引入抽象等于关门
B 档直接做 (一次性 refactor 到 anchors/<slug>/ 目录)refactor 风险较大 (15 文件 + 工具脚本), V0 验收前不必动
通过环境变量 ANCHOR_SLUG 注入 (代替 config.yaml 字段)不集中, 难追溯; 单 yaml 字段更明确 + 可 grep

5. Migration Plan · 演进时机判断 ​

触发 B 档的信号 (满足任一即启动):

  • 项目主理或 CTO 明确要建第二锚点
  • 当前路径硬编码 (anchors/tian/raw/interviews/) 阻碍工作
  • 想给外部某老板做 demo 但不想暴露当前锚点数据

触发 C 档的信号:

  • B 档稳定运行 ≥ 1 季度
  • 外部用户对 boss-skills 表达兴趣
  • 多锚点的 confidentiality 隔离需求出现

B 档启动 checklist (B 实施时勾选):

  • [ ] anchors/<slug>/ 目录建立, 把 anchors/tian/raw/interviews/ + anchors/tian/raw/feishu-sync/ 迁过去
  • [ ] _wiki/ 迁到 anchors/tian/_wiki/
  • [ ] anchors/tian/perspective/ → anchors/tian/perspective/
  • [ ] config.yaml 加 anchor.vault_root: anchors/tian
  • [ ] panels/*.yaml 用 anchor_slug 查 anchors/<slug>/perspective/SKILL.md
  • [ ] scripts/feishu_sync_filter.py 接 --anchor 参数
  • [ ] sage-wiki config 输出路径参数化
  • [ ] 写 ADR-002 记录 B 档实施时的具体取舍
  • [ ] 更新 CLAUDE.md §2 (权责边界) 反映新目录结构

6. 当前实施状态 (A 档) ​

✅ config.yaml anchor: 段已加 (本 ADR PR) ✅ panels/default.yaml anchor_slug: tian 字段已加 (本 ADR PR) ✅ ADR 本身入 git (docs/adr/) ⏳ 工具脚本读取 anchor_slug (推迟到下次需要时, 当前 hardcode 仍工作) ⏳ orchestrator skill 通过 config.yaml 解析 anchor 身份 (推迟)

不变的承诺 (A 档维持的语义):

  • 同一议题 (同 brand-slug) 跑出来的判断, 在 anchor 切换前后应该不同 (anchor 是判断主体)
  • panels/<name>.yaml 的 anchor_slug 字段是 panel 与 anchor 的唯一绑定点
  • 历史 versions/v{n}_*.md 不可变性不受 anchor 切换影响

ADR-001 · proposed · 2026-05-28 · 见 docs/adr/README.md

判断力工程化 · Judgement, Engineered · 主站 · GitHub

© 2026 boss-vault contributors