团队文档 RAG 全家桶

这个 pack 解决什么

你团队的「机构记忆」散在五个地方：上次重组后就没人更新的 Confluence、三个 PM 各维护一份分叉的 Notion、真正答案埋在评论里的 Slack 串、某个 2023 年离职工程师留下的 README，还有一个老员工的脑子。新人头一个月在反复问同样的问题。老工程师切到 Slack 搜，15 分钟后拿着一个错误答案出来。共享知识库技术上是有的 —— 只是不能按人类真实提问的方式去搜。

这个 pack 的目标是：一个 URL，任何同事用大白话问问题，得到一个有引用的答案，内容来自他权限内能读到的所有源 —— Confluence / Notion / Slack / Drive / GitHub / wiki。这个品类有一个付费王者（Glean），单价 $40+/座/月，把你的语料送到他们云上。这个 pack 拼出开源等价物。

这里每个工具都能自建，整套堆栈在中型 VM 上能跑几百人团队，唯一付费项是答题层的 LLM API（隐私要求高可以换本地模型）。

按顺序装

1. Onyx —— 从这开始。Onyx 是离 Glean 最近的开源等价物：AI 聊天前端 + 40+ 内置 connector（Confluence / Notion / Slack / Google Drive / GitHub / Jira / web）+ 混合检索 RAG + SSO + RBAC + 按文档传递权限。一条 curl ... | bash，localhost:3000 就有答题引擎在跑。要是 Onyx 内置 connector 覆盖了你的源，第 1 步装完就可以收工。
2. Airweave —— Onyx 内置 connector 漏掉你想要的源时的胶水。Airweave 是上下文检索层，50+ 集成，对外暴露 MCP 和 REST 端点。当你想用一套 connector 框架同时管 Onyx 和其他 agent 的同步任务，把 Airweave 摆在 Onyx 上游。
3. Notion MCP —— 团队的正典文档在 Notion 的话，官方风 MCP 让 Claude Code / Cursor / 任何 MCP 客户端直接读写同一个 workspace（Onyx 在索引的那个）。工程师不用离开编辑器就能问 wiki。
4. MCP Atlassian —— Confluence + Jira 同一个思路。读页面、查 Jira issue、写评论，全在 agent 上下文里。这两个 MCP（Notion + Atlassian）覆盖 80% 团队文档的两个家。
5. slack-mcp-server —— Slack 是真实决策发生的地方，而且决策几乎不会反向同步回 wiki。索引 Slack 比较脏（权限、临时频道、不该索引的 DM），但要回答「我们当年为啥选 Postgres 不选 MySQL」这种问题，找到真实那条串而不是假装它不存在，就绕不开。OAuth + stealth 模式解决鉴权，频道范围显式指定。
6. Docmost —— 想做内容收敛时的目标 wiki。开源，实时协作，页面树结构，AGPL。新写的内容把它当正典家，Onyx 同时在并行索引老的 Confluence / Notion。迁移渐进，不要 forklift。
7. PandaWiki —— 另一个目标 wiki，特点是 AI 写作层（「让 wiki 起草这页」）。要写作面本身 LLM 辅助选 PandaWiki，要更传统 Confluence 式编辑器选 Docmost。
8. Qdrant —— 共享向量库。Onyx 自带一个嵌入式向量索引，量小够用；量上来或者想让自定义 agent 也查同一份向量时不够。Qdrant 是生产级外部向量库：payload 过滤 / 混合检索 / 快照恢复 / 水平扩展。挂一份，所有检索层都指过去。
9. Casbin —— 分源权限。团队 RAG 最难的工程问题不是检索质量 —— 是确保 C 级 only 的 Confluence 空间不漏到 IC 的答案里。Casbin 是策略框架：在一个配置里定义角色和源级规则，在检索时统一在 Onyx / Airweave / 自定义 agent 三处执行。「Glean 替代方案」跳过这一步等于送官司。
10. Haystack —— Onyx 不够灵活时的底层检索框架。多数团队用不到；用得到的会自己知道 —— 你的检索需要分支逻辑、自定义 reranker，或者图 + 向量混合管线 Onyx 没暴露。Haystack 让你把这些组件拼起来，从 Slack bot 或自写 UI 调。

整套怎么拼

[ Confluence ]  [ Notion ]  [ Slack ]  [ Drive ]  [ GitHub ]  [ 内部 wiki ]
      │            │           │          │          │              │
      └─── MCP ────┴──── Airweave / Onyx connector ───┴──────────────┘
                              │
                              ▼
                       [ 切片 + 嵌入 ]
                              │
                              ▼
                       [ Qdrant ] ◀── 共享向量库
                              │
                              ▼
          ┌─── Casbin 策略闸（按人 / 按源） ───┐
          │                                  │
          ▼                                  ▼
   [ Onyx 聊天 UI ]                  [ Slack bot / agent ]
          │                                  │
          └───────── LLM（云或自建）─────────┘

写作侧（可选，并行）：
  Docmost 或 PandaWiki ◀── 新的正典页面写这里，也被索引

关键洞察：Onyx 单独就能撑住大部分这张图。第 2-10 件是撞到具体限制时才拿出来 —— 缺 connector（Airweave）、要编辑器里 agent 访问（三家 MCP）、要内容收敛目的地（Docmost / PandaWiki）、Onyx 内置 RBAC 表达不了的权限模型（Casbin）。第一天别全装。先装 Onyx，对着最响的三个源跑一周，缺的零件会自己告诉你装哪个。

你会踩到的取舍

• Onyx vs Glean —— Glean 打磨更细，Slack bot 更顺，零运维。Onyx connector 覆盖一样宽，跑在你 VPC 里，0 元/座，LLM 账单你自己控（换本地模型边际答案免费）。安全审核拒绝自建或团队不愿多运维一项服务就选 Glean；这两条都不卡的话选 Onyx。
• Docmost vs PandaWiki —— Docmost 是传统 Confluence 式编辑器 —— 从 Confluence 迁的团队几乎不用培训。PandaWiki 把 AI 写作烤进编辑器（「根据这个 Jira ticket 起草」），新内容很爽，习惯 wiki 的人会陌生。别同时把两个都当正典家；选一个。
• 嵌入式向量库 vs Qdrant —— Onyx 内置索引在 100 万 chunk 之内方便够用。再往上查询延迟和重索引时间真的卡。Qdrant 多一个服务的运维成本，换 1000 万 chunk 级别稳定性能，加上自定义 agent 不用走 Onyx API 就能直接查同一批向量。
• Casbin vs Onyx 原生 RBAC —— Onyx 原生权限覆盖明显场景（按人 / 按文档 / 按源）。Casbin 加策略即代码处理脏场景：「外包能读工程文档不能读 HR」「安全空间 C 级 only，但事故响应时放开」。多数团队先用 Onyx 原生，第一次权限事故后再迁 Casbin。
• MCP server vs Onyx connector —— Onyx connector 是批同步（每 N 分钟索引一次，查向量库）。MCP 是实时（agent 按需调 Notion API）。两层各有位置：Onyx 做重检索（要一个答案，从 5 万页里拉）；MCP 做精确查（要这条特定 Jira ticket，要现在）。两层一起跑不冲突。

常见踩坑

• 索引 Slack DM。别。connector 配置时把范围写死 —— 仅公开频道，加一个 opt-out 列表。一次私聊飘到错误的人答案里，信任一年回不来。
• 跨 connector 没去重。同一份 RFC 同时在 Confluence 页面、Notion 镜像、GitHub markdown 里。不去重的话答题引擎引用同一份文档的三个版本，看起来像坏了。Onyx 有 content-hash 去重，第一次大同步前打开，别同步完才回头补。
• 第一天就全量嵌入。Day 1 全量同步 Confluence + Notion + Slack 会在你回答第一个问题之前烧掉 200-500 美刀的 OpenAI 嵌入账单。先一个 space / 一个频道 / 一个 Notion section。小规模迭代检索质量，信得过答案后再扩语料。
• 权限继承自过期 IdP。你团队的 IdP 里还挂着半年前离职的人。Onyx 会愉快地把他们的文档按他们的身份吸进来。先同步 IdP、审计 group、再开答题引擎。
• 一个 LLM 同时嵌入 + 生成。两件事。嵌入用便宜快的小模型（text-embedding-3-small 或本地 bge-large），生成用强推理模型（Claude Sonnet / GPT-4 级），只在答题时调。混着用要么过度嵌入烧钱、要么终答案能力不够。
• 没反馈循环。Onyx 和多数替代品都在每条答案上有点赞 / 点踩。把这两个钩到周回顾：坏答案多数追溯到某个缺源、某个错切片、某条错权限。每周 10 分钟 triage 就是「让团队信任的知识库」和「玩具」的分水岭。