Context Router Demo：效果与成本分析

这个 Demo 验证什么

本 Demo 只是私域上下文库架构的 baseline，不是关键技术风险验证。

它验证一个直观判断：

不要让 Agent 每次都调用所有上下文库；
先根据任务、实体、部门、项目和权限选择少数候选库，再检索和组装上下文。

当前实现不调用付费模型 API，也不依赖真实 D3 检索投影引擎。它用本地 workspaces/variai/site/、workspaces/variai/knowledge/ 和 JSON registry 模拟：

• Context Registry。
• Context Router。
• 多上下文库检索。
• 全量搜索 vs 路由搜索对比。
• prompt token 估算。
• 示例模型价格下的成本估算。

运行命令：

python scripts/context_router_demo.py --write-report

输出报告：

workspaces/variai/outputs/context-router-demo-analysis.md

当前样例结果

基于 6 条本地 benchmark 问题：

指标	全量搜索	路由搜索
预期上下文库召回率	-	100%
输入 prompt tokens	5094	4434
估算成本	$0.025421	$0.024926
平均 prompt token 节省	-	12.9%
平均估算成本节省	-	2.0%

这个结果说明：第一版 Context Router 已经能选中预期上下文库，但这不是最重要的结论。路由在规模变大后更快、更省、更少噪音是直观事实，真正需要验证的是后续技术方案会在哪里失败。

当前 token 成本节省也不大。原因是当前 Demo 不把全部文档塞进 prompt，而是全量搜索和路由搜索都只注入 top evidence；因此路由带来的主要收益先体现在：

• 减少扫描文件和 chunk。
• 降低无关证据进入候选集的概率。
• 让路由日志能解释“为什么查这些库”。
• 为后续权限裁剪和 MCP 服务选择打基础。

当 D3 检索投影接入真实 Postgres FTS/pgvector、OpenSearch/ES、embedding、rerank 和更大的证据片段后，路由的主要收益会体现在更少扫描、更少噪音、更清晰的权限裁剪和更可解释的投影选择。

这个 Demo 没有验证什么

• 没有验证 D3 检索投影底座的召回、延迟和调参问题。
• 没有验证清洗入库后是否丢失事实。
• 没有验证权限过滤是否会泄露敏感对象。
• 没有验证 MCP 工具输入校验、输出净化和审计。
• 没有验证 NATS、Kafka/Redpanda 或 Zenoh discovery、ACL 和拓扑复杂度。
• 没有验证企业微信主动询问是否会问错人或打扰人。

这些才是下一轮 Demo 应该验证的重点。

配置文件

上下文库 registry：

workspaces/variai/knowledge/system/context-libraries.json

样例问题集：

workspaces/variai/knowledge/system/context-router-benchmark.json

分析输出：

workspaces/variai/outputs/context-router-demo-analysis.md

当前实现边界

• token 估算是本地启发式，不等于模型供应商的精确 tokenizer。
• 成本估算使用 registry 中的示例价格，不代表最终生产价格。
• 检索仍是本地 Markdown/JSON token overlap，不是真实 Postgres FTS/pgvector 或 OpenSearch/ES hybrid search。
• 路由仍是规则打分，不是学习型 router。
• 总线当前只体现在 registry 设计上，尚未接入 NATS、Kafka/Redpanda 或 Zenoh runtime discovery。

下一步

下一步不应继续证明“路由有用”，而应做风险驱动实验：

1. ingestion_quality_demo：验证清洗、chunk、metadata、review 是否丢事实。
2. retrieval_platform_benchmark：对比 OpenSearch/ES 与 Postgres+pgvector/FTS 在反例中的表现。
3. context_layer_benchmark：对比 D2 稳定知识制品、D3 预入库检索投影、D4 Evidence Connector 和 D5 主动询问的边界。
4. permission_leak_test：验证不同角色下是否泄露内容、路径、owner 或存在性。
5. tool_gateway_safety_harness：验证 MCP 工具输入校验、权限、限流、输出净化和审计。
6. ask_router_simulation：验证主动询问是否问对人、是否过度打扰、回复能否沉淀。
7. registry_bus_spike：先模拟 JSON/Postgres registry、NATS、Kafka/Redpanda、Zenoh 的 discovery / queryable / ACL，再决定是否接真实总线。

详细计划见：风险驱动验证计划。