风险驱动验证计划

为什么要改方向

Context Router Demo 只能证明一个直观事实：上下文库变多后，先路由再检索通常会更快、更省、更少噪音。

这个结论本身价值不大。真正需要验证的是：当我们逐步实现 Evidence capture、Ontology contract、检索投影、embedding、MCP、总线候选、企微主动询问和权限视图后，会遇到哪些工程问题、产品问题和组织问题，哪些问题会让方案无法落地。

所以后续 Demo 应从“证明路由有用”改成“主动制造失败并定位风险”。

最高风险判断

风险	为什么危险	失败信号
入库清洗失真	Agent 后续只会看到被清洗后的结构化上下文，原始语义丢失后很难恢复	搜索命中但证据不完整；摘要替代事实；原文追溯困难
检索质量不可解释	BM25、向量、RRF、rerank 混合后，结果好坏可能难以调试	分数高但内容无关；同一问题多次结果漂移；无法解释为什么命中
权限泄漏	私域知识系统最怕把“存在性、片段、字段、owner”泄露给无权限用户	用户看到不该看的客户、合同、财务或项目线索
MCP 工具边界不硬	如果工具只靠 prompt 约束，Agent 可以误调用、越权调用或被注入诱导	非预期工具调用；敏感输入外发；错误结果进入模型上下文
过早引入总线复杂度	总线、发现、ACL、拓扑都会增加运维面，过早上复杂总线可能比 JSON / Postgres registry 更脆弱	服务发现不稳定；ACL 变更需重启；拓扑问题难排查
主动询问打扰人	如果 ask router 问错人、问太频繁、问得不清楚，组织会失去信任	群发、重复问、没人回、回复无法沉淀
成本和延迟失控	多库检索、embedding、rerank、LLM 读证据会叠加成本	单问题调用链过长；token 增长快于知识规模收益
Review 流程堵塞	补充信息如果都需要人工 review，知识卡片会堆积	inbox 积压；过期卡片被继续引用；没人负责提升
运行时访问路径选错	本该读 Markdown 的问题被送进 RAG，本该查源系统的问题只读过期文档	top-k 限制 Agent 探索；索引命中但原文不权威；大规模数据没有检索入口
任务技能包膨胀或过期	Skill 作为本体层可执行知识对象，如果无人维护，会变成新的过时 prompt 和脚本集合	误触发、低触发、token 膨胀、gotcha 与 ADR 冲突、脚本绕过 Tool Gateway

风险 1：入库清洗失真

问题

数据从 Evidence 进入 Ontology 和检索投影前要经历 normalize、classify、chunk、metadata、embedding。每一步都可能损失语义：

• 聊天上下文被拆碎后，谁在回应谁丢失。
• 会议纪要被摘要后，假设和事实混在一起。
• JSON / 表格字段被扁平化后，字段关系丢失。
• chunk 过短导致证据断裂，chunk 过长导致召回噪音。

下一步实验

做一个 ingestion_quality_demo：

1. 准备 10 条混合输入：群聊、会议纪要、Markdown、JSON、表格。
2. 生成清洗后的 context_document。
3. 对每条输入保留 raw_source_id 和可回溯片段。
4. 评测三件事：
5. 能否从清洗结果回到原文。
6. 关键事实是否丢失。
7. 权限字段是否保留。

通过标准

• 每个 context_document 都能追溯到原始来源。
• 关键事实召回率达到人工标注的 90% 以上。
• 没有把 task-only 材料提升为 team/public。

第一轮结果

已实现 ingestion_quality_demo。当前样例包含 8 条混合输入、42 个预期事实：

• naive summary 事实召回率为 19%。
• structured ingestion 事实召回率为 100%。
• 结构化入库额外保留 34 个事实。
• 原文追溯、权限字段保留和 review 状态保留均为 100%。
• 输出已迁移到正式 ContextDocumentRecord，并可投影为 SearchConnector.ContextDocument。

这个结果不是为了证明结构化一定完美，而是暴露一个明确坑：摘要字段可以存在，但不能成为唯一入库内容。后续 OpenSearch/ES、Postgres FTS/pgvector 或 MCP evidence 都必须保留原文追溯、chunk、权限字段和 review 状态。

详见：Ingestion Quality Demo：入库清洗质量分析。

风险 2：混合检索难调试

问题

Hybrid search 不是“接上 embedding 就行”。无论使用 OpenSearch/ES 还是 Postgres FTS/pgvector，都要处理关键词、语义、过滤、rerank、更新延迟和调试可解释性。以 ES/OpenSearch 为例，kNN 搜索还要求查询向量和文档向量使用同一模型、维度一致；近似 kNN 有内存、延迟和召回取舍；过滤条件可能让 kNN 探索更多图节点，反而降低性能。

真正的问题不是能不能搜，而是：

• 分数怎么解释。
• BM25 和向量权重怎么调。
• RRF / rerank 后为什么这个结果排第一。
• 权限过滤放在检索前还是检索后。
• 新数据 reindex 后结果是否漂移。

下一步实验

原计划做一个 retrieval_failure_benchmark。

外部调研后，这个实验升级为 retrieval_platform_benchmark。它不只验证一种检索投影路线，而是用同一批反例对比 OpenSearch / Elasticsearch 和 Postgres + pgvector / FTS，必要时再加入 Qdrant / Weaviate / Vespa。

1. 每个问题标注应该命中的文档、段落和不可命中的负样本。
2. 同时跑 BM25 only、vector only、BM25 + vector + RRF、weighted fusion、rerank top50 / top100。
3. 记录 Recall@20 / 50、nDCG@10、MRR、无关高分样本、P50 / P95 / P99、索引与 rerank 成本。
4. 专门加入反例：
5. 同义但权限不同。
6. 关键词很像但业务对象不同。
7. 旧资料和新资料冲突。
8. 问题需要跨两个上下文库组合。
9. 合同号、错误码、SKU、政策条款等精确匹配。
10. 旧 chunk 删除、ACL 变更和 embedding model 升级。

通过标准

• 每次结果都能输出 route log、query log、rank log。
• top-3 证据必须包含正确来源，或明确报告 gap。
• 权限过滤必须在证据进入 prompt 前完成。
• 权限泄漏数必须为 0；无权限用户不能看到内容、路径、owner 或存在性线索。

第二轮结果

已实现本地版 retrieval_platform_benchmark。它不是正式 OpenSearch / Postgres 压测，而是先把失败模式固化成可复跑样例：

• 8 条文档，7 个问题。
• 反例覆盖 restricted 薪酬材料、deleted 供应商账号、superseded 星河付款旧记录、WeCom / 企业微信别名、合同号精确匹配和 docs / vault 边界。
• 对比 lexical_unsafe_global、lexical_acl、semantic_acl 和 hybrid_guarded。

当前结果：

策略	Recall@3	Gap 准确率	安全回答率	权限泄漏	生命周期违规
lexical_unsafe_global	60%	0%	14%	2	5
lexical_acl	60%	0%	14%	0	6
semantic_acl	100%	0%	29%	0	5
hybrid_guarded	100%	100%	100%	0	0

核心结论：权限前置只是底线，还必须前置 lifecycle 过滤，并对低置信结果报告 knowledge gap。语义检索能解决 WeCom / 企业微信别名，但单独用语义检索处理不了删除、过期和旧新冲突。

详见：Retrieval Platform Benchmark：第二轮检索风险实验。

选型实验

新增 agentic_search_option_benchmark，专门回答 P0 阶段 Agentic Search 应先落哪条技术路线。

当前合成评分结果：

Profile	Winner	结论
P0 MVP Agentic Search	tiered_markdown_postgres	P0 默认采用 Markdown 渐进披露 + Postgres FTS/pgvector
Scale Multi-Department Search	tiered_markdown_opensearch	规模上来后再切到 OpenSearch/ES hybrid adapter
Ontology Authoring And Review	markdown_progressive_only	Site/Knowledge 仍是本体制品生产和 review 层

核心结论：P0 不直接上 ES/OpenSearch 作为默认主线；ES/OpenSearch 保留为规模化 adapter。纯向量库不作为核心默认方案，因为它不能独自承担精确编号、权限、生命周期、审计和证据追溯。

详见：Agentic Search Option Benchmark：技术路线选型实验。

风险 3：权限模型晚做但不能不设计

问题

我们可以晚做完整 MVC，但不能晚设计权限字段。否则检索投影 index、MCP output、knowledge card、audit log 都会返工。

最小字段至少要有：

tenant_id
department
project
owner
permission_scope
source_acl
field_mask
review_status
expires_at
audit_trace_id

下一步实验

做一个 permission_leak_test：

1. 构造同一问题下不同角色：成员、项目 owner、财务、外部访客。
2. 同一上下文中混入 public、team、project、restricted、task_only 材料。
3. 检查搜索结果、摘要、证据路径、owner 信息是否泄露。

通过标准

• 无权限用户不仅不能看到内容，也不能看到敏感对象存在性。
• 任何进入 prompt 的 evidence 都带权限判断记录。
• 权限不足时只能生成授权路径或主动询问，不泄露证据。

风险 4：MCP 工具安全和可审计性

问题

MCP 是工具协议，不是安全边界本身。MCP 官方工具规范要求服务端校验输入、做访问控制、限流、净化输出；客户端需要对敏感操作做确认、展示工具输入、校验结果、设置 timeout 并记录审计。

如果我们把 MCP server 当成“Agent 想调就调”的开放工具层，会有几个坑：

• 工具描述被注入或误导。
• Agent 把敏感参数传给错误工具。
• 工具返回未净化文本，继续污染模型上下文。
• 错误结果被当成事实写入知识库。

本地实验

原计划做一个 mcp_safety_harness。

外部调研后，这个实验改名为 tool_gateway_safety_harness，因为 MCP 本身不是安全边界。

当前已完成第一轮本地 safety harness：

1. 定义只读工具、受限只读工具、R3 写操作、R4 高风险动作和 fetch 类工具。
2. 给每个工具加 schema、permission、risk_level、allowed_actions、schema_hash 和 egress policy。
3. 注入动态未知工具、schema hash mismatch、越权 user、metadata URL、R4 无审批、R3 直接写、敏感输出和 prompt injection 文本。
4. 验证 Tool Gateway 是否拒绝、降级为 draft-only、要求人工确认、脱敏、审计和标记输出污染。

第一轮结果：

指标	结果
safety cases	9
pass rate	100%
audit secret leaks	0

随后补了第一批和第二批工具族接入验收：SearchConnector Tool Gateway 与 Knowledge Card Tool Gateway。

指标	结果
gateway cases	5
pass rate	100%
unsafe connector output leaks	0

这个验收把 context.search、context.get_document、context.report_gap 放到 Tool Gateway 后面，并验证 allowed_scopes 不能被 Agent 扩大、不安全 connector 返回的 restricted evidence 会被后置过滤。

Ontology Tool Gateway Conformance 进一步把 workspace-topology.json 里的 action/rule/writeback 接入工具调用前治理：action 必须映射到 ToolPolicy，required scopes 必须满足，请求对象必须被 rule 覆盖，pending / rejected / archived 等 lifecycle 状态会阻断执行，writeback event type 必须要求审计。

第二批工具族把 reviewed/promoted knowledge card 的 reindex/search 接到 Tool Gateway 后面：

指标	结果
gateway cases	5
pass rate	100%
permission leaks	0

这个验收验证 knowledge_card.search 会先过 Tool Gateway，再内部调用 context.search；普通 team 用户不能请求 restricted scope，不能看到 restricted card 的内容、路径、owner 或对象 ID；全局 reindex 作为治理动作，仅允许 restricted scope 用户触发。

通过标准

• 高风险工具不能被 Agent 直接执行，只能生成草稿或等待确认。
• 所有工具调用有 trace id。
• 工具输出进入模型前必须做 schema 校验和敏感字段过滤。
• 工具 allowlist、schema hash 和版本固定，不能因为动态工具列表变化绕过审批。

详见：Tool Gateway Safety Harness。

工具族接入见：SearchConnector Tool Gateway 与 Knowledge Card Tool Gateway。

风险 5：总线与服务发现可能过早增加复杂度

问题

Zenoh 适合做 discovery、pub/sub、queryable 和总线组合，但它也带来部署和治理复杂度。

官方部署文档显示 Zenoh 有 peer、client、router、gateway 和 region 等多种拓扑；peer 模式会自动发现可访问节点；ACL 配置可以做 allow/deny，但 ACL 不能运行时更新，需要重启实例才能生效。

对我们来说，真正风险是：

• 服务发现失控：Agent 看到不该看到的 MCP 服务。
• key expression 命名混乱：部门、项目、权限边界无法表达。
• ACL 策略和组织权限模型重复或冲突。
• Debug 难：一次查询跨多个服务后很难知道错在哪里。

外部调研后的修正：当前 Demo 阶段不把 Zenoh 放入核心链路。先用 JSON / Postgres registry + HTTP/gRPC；如果需要内部服务发现和 request/reply，再评估 NATS；如果需要审计事件流和回放，再评估 Kafka / Redpanda；只有出现边缘、弱网络、多机房 queryable 需求时，再单独 spike Zenoh。

下一步实验

短期不要直接引入 Zenoh runtime。原计划先做 zenoh_registry_sim：

1. 用 JSON 模拟 key expression。
2. 定义 capability announce、liveness、queryable 三类记录。
3. 对每条 capability 加 owner、permission_scope、risk_level、ttl。
4. 先验证命名、权限和路由日志。

只有当上下文库超过 5 个、MCP server 超过 5 个、需要跨进程 discovery 时，再接真实 Zenoh。

这条实验现在降级到 registry_bus_spike：

1. 先用 JSON / Postgres registry 验证 capability schema。
2. 对比 HTTP/gRPC registry、NATS service discovery、Zenoh key expression 的调试成本和权限表达。
3. 不在检索、权限和 Tool Gateway 未稳定前引入 Zenoh runtime。

通过标准

• Agent 每次选择 MCP 服务都有可解释 route log。
• discovery 结果经过权限过滤。
• 服务下线、过期、重复注册都能被检测。

风险 6：企微主动询问可能破坏组织体验

问题

主动询问不是“会发消息”就结束。最大风险是问错人、问太多、问得不清楚。

下一步实验

做一个 ask_router_simulation：

1. 用 20 个真实问题模拟问谁。
2. 每题限定最多问 1 到 3 人。
3. 记录选择原因、期待回答格式、超时策略和是否进入知识库。
4. 加入负反馈：被问人说“我不是负责人”后，router 如何学习。

通过标准

• 不群发。
• 每次询问说明原因和用途。
• 回复默认 task_only，review 后才能提升。
• 能记录“问错人”的反馈并调整 owner registry。

第一轮结果

已实现本地版 ask_router_simulation。当前样例包含 9 个主动询问场景：

指标	结果
Top1 准确率	100%
Expected Recall@3	100%
安全路由率	100%
forbidden 命中数	0
未允许候选命中数	0
负反馈处理通过率	100%
节流处理通过率	100%
重复询问抑制数	1
消息契约通过率	100%

本轮暴露并修正了四个坑：当前提问人不能因通用词被排到 owner 前面；not_owner 负反馈必须硬排除；Top3 不能机械填满，需要相对分数阈值过滤弱相关候选；同一 owner、同一任务、同一缺口在冷却窗口内已问过时，系统不能重复打扰，也不能改问 requester 绕过节流。

详见：Ask Router Simulation：主动询问路由仿真。

风险 10：任务技能包膨胀或过期

问题

Anthropic Skills 经验对可执行知识治理有启发，但任务技能包本身也可能成为风险源：

• 包太大，Agent 每次读取大量无关上下文。
• 描述写给人看，不适合模型判断触发。
• gotcha 过期后与当前 ADR 或代码冲突。
• 包内脚本绕过 Tool Gateway、权限审计或人工确认。
• memory 记录被误当成组织事实源。

下一步实验

做一个 task_skill_package_eval：

1. 选 harness_knowledge_ingest 和 agentic_search_benchmark 两个候选包。
2. 给每个包定义触发描述、gotchas、模板、验证命令和 owner。
3. 用 10 个真实/合成任务评估触发准确率、误触发、低触发、token 增量和验证通过率。
4. 检查包内脚本是否全部经过 Tool Gateway 或本地安全边界。
5. 检查包内 memory 是否只记录运行历史，不承载权威事实。

通过标准

• 应触发任务命中率达到 80% 以上，非相关任务误触发低于 10%。
• 包入口保持短小，详细内容通过 references 渐进披露。
• 每个包都有 owner、review 状态、验证命令和维护日志。
• 包内脚本不执行高风险写操作，或者必须显式人工确认。

详见：任务技能包：本体层中的可执行知识。

当前 Demo 应该如何重新定位

context_router_demo.py 保留，但只作为 baseline：

• 验证 registry 结构是否能表达上下文库。
• 验证 benchmark 机制是否可跑。
• 粗估 token 和成本。
• 不再把“路由能省 token”作为主要成果。

下一步真正的 Demo 应该按风险排序：

1. ingestion_quality_demo：已完成第一轮本地验证。
2. agentic_search_option_benchmark：已完成第一轮本地选型验证。
3. retrieval_platform_benchmark
4. permission_leak_test
5. tool_gateway_safety_harness
6. ask_router_simulation：已完成第一轮本地路由验证。
7. registry_bus_spike
8. document_parser_spike
9. context_layer_benchmark

context_layer_benchmark 要对比三种工作流：

• 渐进披露优先：Site/Knowledge + rg + read，模拟 Codex / Claude Code 原生探索。
• 预入库 RAG 优先：先从索引 top-k 取证据，再回答。
• 分层混合：先入口索引、Skill 和稳定知识制品，再按需下探检索投影、Evidence Connector 和 Ask Router。

通过标准不是单纯 Recall，而是证据质量、token、工具调用数、是否发现 gap、权限风险和更新成本。

第一轮结果

已实现本地版 context_layer_benchmark。当前样例包含 11 条上下文记录、8 个问题：

工作流	Recall@3	层级命中	Gap 准确率	安全回答率	权限泄漏	生命周期违规
progressive_only	33%	33%	0%	25%	0	0
rag_unsafe	17%	17%	0%	0%	5	4
rag_guarded	17%	17%	100%	38%	0	0
tiered_hybrid	100%	100%	100%	100%	0	0

核心结论：Markdown 适合稳定本体制品，检索投影适合大规模召回，Evidence Connector 适合实时权威事实，Ask Router 适合问谁；单用任一投影方式都会失效。下一步应把检索投影从本地模拟替换为 Postgres FTS/pgvector 与 OpenSearch/ES adapter 对照。

详见：Context Layer Benchmark：运行时上下文访问对照实验。

官方依据

• Elastic kNN Search：https://www.elastic.co/docs/solutions/search/vector/knn
• Elastic Hybrid Search：https://www.elastic.co/docs/solutions/search/hybrid-search
• MCP Tools Security Considerations：https://modelcontextprotocol.io/specification/2025-11-25/server/tools
• Zenoh Access Control：https://zenoh.io/docs/manual/access-control/
• Zenoh Deployment：https://zenoh.io/docs/getting-started/deployment/
• 技术路线外部调研与方案修正：technology-alternatives-research.md