跳转至

私域上下文库与检索总线架构

核心判断

OrgReOrg 不应该把所有组织知识都塞进一个通用向量库，也不应该让所有任务都调用同一个 MCP Search Server。

更合理的做法是：按组织、部门、项目、来源系统、权限边界和任务类型划分上下文库，再由 Agent 的 Context Router 选择 1 到 3 个最相关的上下文库组合调用。

text 企业微信 / Web / CLI 输入 -> Task Understanding -> Context Router -> Zenoh Capability Registry -> MCP Context/Search Servers -> Elasticsearch Context Indexes -> Vault / GitHub / 文档系统 / 项目系统 / 业务系统

ES、MCP、Zenoh 的分工

层 职责 不负责什么
Elasticsearch BM25、向量检索、RRF、rerank、过滤、聚合、证据片段 不做最终事实源
MCP 把上下文库搜索、读取、缺口上报、知识卡片提交暴露给 Agent 不负责底层索引和组织路由
Zenoh 服务发现、事件总线、queryable、capability registry 不替代 ES 做向量库
Context Router 判断当前任务该查哪些上下文库 不全量广播所有 MCP 服务

第一版可以先用本地 JSON registry 模拟 Zenoh 发现。等上下文库和 MCP 服务数量增长后，再把 registry 扩展成 Zenoh key expression 和 queryable。

入库清洗链路

进入 ES 或上下文库前，数据要先被清洗、重组和结构化：

text capture -> normalize -> classify -> extract entities -> chunk -> enrich metadata -> generate embeddings -> index -> review / promote

最小字段建议：

text object_id source_system source_uri object_type title body summary department project owner permission_scope visibility created_at updated_at chunk_id parent_id embedding_model ingest_pipeline_version review_status

review_status 是关键字段。企业微信、会议、临时讨论进入 inbox 或 raw 后，不应直接变成正式知识；需要经过 review 后再提升到 wiki、项目页或发布文档。

上下文路由

Context Router 的输入包括：

  • 用户身份、部门、角色、项目关系。
  • 当前任务类型：查询、写作、代码、财务、客户、项目管理等。
  • 问题中提到的实体：客户、合同、repo、项目、负责人、时间。
  • 已知上下文覆盖范围和权限标签。
  • 最近任务会话中已经使用过的证据。

路由流程：

text 1. 解析任务意图和实体。 2. 根据组织目录、项目目录和 source catalog 生成候选上下文库。 3. 通过 Zenoh 或本地 registry 获取可用 MCP 服务和能力。 4. 对候选库打分：权限可见性、任务相关性、更新时间、owner 置信度。 5. 并行调用前 1-3 个 MCP Search Server。 6. 融合结果并读取高价值证据。 7. 如果证据不足，生成 knowledge_gap，并选择询问对象。 8. 新补充信息先进入 knowledge card，review 后再进入正式上下文库。

上下文库划分

第一阶段不要按技术组件划分知识库，而要按组织使用边界划分：

上下文库 主要内容 首批来源 适用任务
team_vault 团队知识、决策、项目计划 vault/、docs/ 设计问答、路线图、知识维护
github_engineering repo、issue、PR、CI、代码文档 GitHub 技术开发、代码 review、发布
project_ops 任务、里程碑、负责人、状态 项目管理系统 项目推进、缺口识别
org_directory 部门、角色、负责人、项目归属 企业微信通讯录、人工维护 主动询问路由
business_docs 制度、方案、会议纪要、合同摘要 文档系统 业务查证和写作

财务、CRM、BI 等上下文库应独立接入，因为它们天然有更强的权限、审计和脱敏要求。

MVP 开发路径

企业微信接口可以由另一位成员并行推进。知识库方向先做以下开发：

  1. 建立 context_libraries.json，描述每个上下文库的 scope、owner、source、权限、MCP endpoint 和索引名。
  2. 扩展本地 Demo：用户问题先经过 Context Router，再调用本地 search backend。
  3. 先用本地 Markdown 索引模拟 ES 文档结构；保留 ES mapping 和 ingest pipeline 设计。
  4. 定义 knowledge_card 到 context_document 的提升流程。
  5. 增加 10 个真实问题样例，验证路由是否能选对上下文库。
  6. 第二阶段接入 Elasticsearch：先索引 docs/、vault/、GitHub issue/PR 的小子集。
  7. 第三阶段把 registry 从 JSON 替换或扩展为 Zenoh discovery/queryable。

调研依据