跳转至

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

核心判断

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

更合理的做法是：先把原始资料保存在 Evidence，再在 Ontology 中建模组织对象、关系、规则、知识制品和 Skill，最后由 Runtime Projection 根据组织、部门、员工、项目、具体事项、来源系统、权限边界和任务类型，选择 1 到 3 个最相关的上下文库组合调用。

本质上，这是一套上下文管理系统：根据当前需求加载最小充分上下文，让智能体完成任务，同时控制 token 成本、噪声和权限风险。

企业微信 / Web / CLI 输入
  -> Task Understanding
  -> Context Router
  -> Ontology：对象 / 关系 / 规则 / Skill / 知识制品 / 权限视图
  -> Runtime Projection：Markdown / SearchConnector / Connector / Ask Router
  -> Tool Gateway
  -> Evidence 回查与 Writeback

当前任务上下文没有出现在这条链路中，是因为它已经在当前 Agent session 内部。Context Router 只在当前上下文不足时决定继续读取哪些本体制品、检索投影、原始证据或主动询问对象。

外部调研后，Zenoh 从第一阶段主线降级为后置 spike。第一阶段先用 JSON 或 Postgres registry + HTTP/gRPC；需要内部服务发现和 request/reply 时优先评估 NATS，需要审计事件回放时评估 Kafka / Redpanda，需要边缘、弱网络或多机房时再 spike Zenoh。

详见：技术路线外部调研与方案修正。

新的核心模型见：本体驱动上下文架构。运行时读取顺序见：运行时渐进披露与上下文访问路径。

检索、MCP、总线的分工

层 职责 不负责什么
Postgres + pgvector / FTS P0 检索投影、context document 表、RLS、强一致更新、低运维 hybrid search 不适合未经验证就承担大规模 ANN，也不是最终事实源
OpenSearch / Elasticsearch 规模化检索投影、BM25、向量检索、RRF、rerank、过滤、聚合、证据片段 不做最终事实源，也不作为 P0 默认主线
MCP 把上下文库搜索、读取、缺口上报、知识卡片提交暴露给 Agent 不负责安全边界
Tool Gateway 身份、scope、审批、审计、限流、输出净化 不替代 MCP 协议和业务工具
Ontology / Registry 描述对象、关系、规则、知识制品、Skill、上下文库和工具能力 不直接执行工具
NATS / Kafka / Zenoh 后续按服务发现、审计事件、边缘 queryable 分别评估 不作为第一阶段硬依赖
Context Router 判断当前任务该投影哪些本体制品、检索索引、Connector 和询问对象 不全量广播所有 MCP 服务
Markdown Wiki / Docs 承载稳定、可审查、可发布的本体制品，便于 Codex / Claude 渐进披露读取 不适合承载全部原始数据和实时业务状态

第一版可以先用本地 JSON registry 模拟能力发现。等上下文库和 MCP 服务数量增长后，再决定扩展到 Postgres registry、NATS service discovery 或 Zenoh key expression / queryable。

当前已新增 SearchConnector contract，先把检索投影 adapter 边界固定下来，再做 Postgres FTS/pgvector 与 OpenSearch/ES 的真实对照。详见：SearchConnector Contract。

上下文管理目标

上下文管理不是“把所有相关资料都塞给模型”。更准确的目标是：

minimize(context_tokens + irrelevant_noise + permission_risk)
subject to:
  enough_evidence_for_task = true
  required_permissions_satisfied = true
  knowledge_gaps_are_explicit = true

实际场景：

  • 员工个人业务：加载本人材料、当前业务状态、相关制度和职能部门通知；不能顺手加载其他员工或部门内部材料。
  • 职能部门事项：加载部门制度、历史活动、领导要求、执行反馈和相关审批；不能把财务、市场、HR 的敏感内部上下文混用。
  • 具体项目/任务：加载项目目标、成员、历史讨论、进度、预算、依赖系统和相关制度；不能默认继承所有部门资料。

所以 Context Router 的输出应是“最小充分上下文集合”，而不是“召回尽可能多的片段”。

入库清洗链路

进入检索投影或上下文库前，数据要先被清洗、重组、结构化并映射到本体：

capture
  -> normalize
  -> classify
  -> extract ontology objects / relationships / rules / actions
  -> chunk
  -> enrich metadata
  -> generate embeddings
  -> index
  -> review / promote

最小字段建议：

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、项目、负责人、时间。
  • 已知上下文覆盖范围和权限标签。
  • 最近任务会话中已经使用过的证据。

路由流程：

1. 解析任务意图和实体。
2. 先判断能否通过入口索引、Skill 和稳定知识制品解决：项目指令、Site、Knowledge、ADR、项目页。
3. 如果稳定制品不足，再根据组织目录、项目目录和 source catalog 生成检索投影、Connector 和 Evidence 候选。
4. 通过本地 registry 或后续服务发现获取可用 MCP / HTTP 工具和能力。
5. 对候选库打分：权限可见性、任务相关性、更新时间、owner 置信度、层级成本。
6. 并行调用前 1-3 个 Search Server 或 Connector。
7. 融合结果并读取高价值原文证据。
8. 如果证据不足，生成 knowledge_gap，并选择主动询问对象。
9. 新补充信息先进入 knowledge card，review 后再进入本体制品、docs 或检索投影。

这里有两个闭环：

  • 输入闭环：收集、清洗、结构化、review、沉淀，形成公司上下文资产。
  • 输出闭环：按任务和权限选择上下文，给智能体使用，发现缺口再反向补充。

上下文库划分

第一阶段不要按技术组件划分知识库，而要按组织使用边界划分。当前边界已经前置到 workspaces/variai/registry/workspace-topology.json：

organization
  -> departments
  -> people
  -> projects
  -> tasks
  -> context_libraries
  -> routing_rules
  -> permission_views

Context Router 不应该只看“问题关键词 -> 某个 MCP 服务”。它还要先知道：

  • 当前用户是谁，拥有哪个 permission view。
  • 当前任务属于个人、部门、项目还是组织级事项。
  • 候选上下文库各自属于哪个 scope owner。
  • 最终允许调用哪些上下文库，允许披露哪些 scopes。

这样才能避免个人报销问题误查项目知识，项目研发问题误拉财务部门资料，部门政策问题误泄漏员工个人材料。

外部 Palantir 本体论材料给这里补了一层判断：组织私域拓扑长期不只是 context library registry，还应表达 metadata、对象、关系、规则、知识制品、Skill、动作和写回。也就是说，Context Router 不仅要知道“去哪里查”，还要知道“当前对象处于什么状态、哪些规则约束动作、哪个 Skill 可执行、动作结果要写回哪里、能否追溯到原始 Evidence”。P0 仍保持轻量 JSON contract；当前 workspace-topology.json 已把 ontology contract 加到 personal / department / project 三类 demo 中，并通过 topology lint 与 Workspace Scope Eval 输出指标。详见：本体驱动上下文架构 和 Agentic Engineering 与本体论参考。

当前第一批上下文库类型：

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

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

新增的 Workspace Scope Eval 已把这一点变成验收实验：个人域、部门域、项目域三类基础 demo 加上跨部门项目、员工调岗、项目归档、权限变更 stale index 四类风险探针，同一套 Framework 通过 route_context_libraries 的 context_router_feature_v1 先做候选库 feature-based 评分和 permission view 过滤，再进入 SearchConnector / Tool Gateway；即使底层 connector 故意不安全，也能做到 expected libraries 返回、forbidden libraries 不泄漏。

新增的 Context Management Eval 则把目标推进到“最小充分上下文”：同一套 topology 在 4 个 case 中同时记录 evidence coverage、token 节省、权限过滤、knowledge gap 和建议询问 owner。它现在和 Workspace Scope Eval 共用同一个 router contract，验证的是知识构建和搜索是否服务于上下文管理，而不是单纯检索是否更快。

MVP 开发路径

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

  1. 建立 context_libraries.json，描述每个上下文库的 scope、owner、source、权限、MCP endpoint 和索引名。
  2. 建立 workspace-topology.json，把组织、部门、人员、项目、任务、上下文库、路由规则和权限视图连起来。
  3. 扩展本地 Demo：用户问题先经过 Workspace Topology 和 Context Router，再调用本地 search backend。
  4. 先用本地 Markdown 索引模拟 context document；P0 设计 Postgres FTS/pgvector schema，保留 OpenSearch/ES mapping 作为规模化 adapter。
  5. 定义 knowledge_card 到 context_document 的提升流程。
  6. 增加 10 个真实问题样例，验证路由是否能选对上下文库。
  7. 第二阶段做真实 adapter benchmark：同一 SearchConnector contract、同一数据集对比 Postgres FTS/pgvector 与 OpenSearch/ES。
  8. 第三阶段实现 Tool Gateway，把 MCP server 放到身份、scope、审批、审计和输出净化之后。
  9. 第四阶段再评估 NATS、Kafka / Redpanda 或 Zenoh 是否进入运行时。

调研依据