Context Router Demo：效果与成本分析¶
这个 Demo 验证什么¶
本 Demo 只是私域上下文库架构的 baseline，不是关键技术风险验证。
它验证一个直观判断：
text
不要让 Agent 每次都调用所有上下文库；
先根据任务、实体、部门、项目和权限选择少数候选库，再检索和组装上下文。
当前实现不调用付费模型 API，也不依赖真实 ES。它用本地 docs/、vault/ 和 JSON registry 模拟：
- Context Registry。
- Context Router。
- 多上下文库检索。
- 全量搜索 vs 路由搜索对比。
- prompt token 估算。
- 示例模型价格下的成本估算。
运行命令：
bash
python scripts/context_router_demo.py --write-report
输出报告：
text
vault/50-outputs/context-router-demo-analysis.md
当前样例结果¶
基于 6 条本地 benchmark 问题：
| 指标 | 全量搜索 | 路由搜索 |
|---|---|---|
| 预期上下文库召回率 | - | 100% |
| 输入 prompt tokens | 5044 | 4423 |
| 估算成本 | $0.025384 | $0.024918 |
| 平均 prompt token 节省 | - | 12.2% |
| 平均估算成本节省 | - | 1.8% |
这个结果说明：第一版 Context Router 已经能选中预期上下文库，但这不是最重要的结论。路由在规模变大后更快、更省、更少噪音是直观事实，真正需要验证的是后续技术方案会在哪里失败。
当前 token 成本节省也不大。原因是当前 Demo 不把全部文档塞进 prompt，而是全量搜索和路由搜索都只注入 top evidence；因此路由带来的主要收益先体现在：
- 减少扫描文件和 chunk。
- 降低无关证据进入候选集的概率。
- 让路由日志能解释“为什么查这些库”。
- 为后续权限裁剪和 MCP 服务选择打基础。
当接入真实 ES、embedding、rerank 和更大的证据片段后，token 节省会更明显。
这个 Demo 没有验证什么¶
- 没有验证 ES hybrid search 的召回、延迟和调参问题。
- 没有验证清洗入库后是否丢失事实。
- 没有验证权限过滤是否会泄露敏感对象。
- 没有验证 MCP 工具输入校验、输出净化和审计。
- 没有验证 Zenoh discovery、ACL 和拓扑复杂度。
- 没有验证企业微信主动询问是否会问错人或打扰人。
这些才是下一轮 Demo 应该验证的重点。
配置文件¶
上下文库 registry：
text
vault/90-system/context-libraries.json
样例问题集：
text
vault/90-system/context-router-benchmark.json
分析输出：
text
vault/50-outputs/context-router-demo-analysis.md
当前实现边界¶
- token 估算是本地启发式，不等于模型供应商的精确 tokenizer。
- 成本估算使用 registry 中的示例价格，不代表最终生产价格。
- 检索仍是本地 Markdown/JSON token overlap，不是真实 Elasticsearch hybrid search。
- 路由仍是规则打分，不是学习型 router。
- Zenoh 当前只体现在 registry 设计上，尚未接入运行时 discovery。
下一步¶
下一步不应继续证明“路由有用”，而应做风险驱动实验：
ingestion_quality_demo：验证清洗、chunk、metadata、review 是否丢事实。retrieval_failure_benchmark：验证 BM25 / vector / hybrid / rerank 在反例中的表现。permission_leak_test：验证不同角色下是否泄露内容、路径、owner 或存在性。mcp_safety_harness：验证 MCP 工具输入校验、权限、限流、输出净化和审计。ask_router_simulation：验证主动询问是否问对人、是否过度打扰、回复能否沉淀。zenoh_registry_sim：先模拟 discovery / queryable / ACL，再决定是否接真实 Zenoh。
详细计划见：风险驱动验证计划。