Context Management Eval：最小充分上下文指标

结论

本轮实验把“知识构建和搜索服务于上下文管理”转成可运行指标，而不是继续验证“路由会不会更省”这种直观结论。

当前结果：

• Case 数：4。
• 通过数：4。
• 平均 evidence coverage：75%。
• 平均 token 节省：24.6%。
• 权限过滤候选数：4。
• knowledge gap 数：1。
• ask event 数：1。
• trace event 数：9。
• SearchConnector rank_log case 数：4。
• SearchConnector rank_log gateway filtered output 数：4。
• ask message contract 通过率：100%。
• Context Router scorer：domain_router_feature_v1。
• Context Router feature score candidate 数：12。
• router 权限过滤库数：4。
• safe output 泄漏标记数：0。

这说明当前受控路径可以在个人、部门、项目三类任务里返回最小充分上下文，并在项目任务需要财务部门内部上下文但无权限时显式产生 knowledge gap 和 ask event，而不是硬答或越权读取。

本轮已把原先散落在评测里的本地路由逻辑沉淀为 framework/context/domain_router.py 的 route_domain_context。Domain Scope Eval 和 Context Management Eval 现在共用同一条 router contract：候选库评分、feature breakdown、permission view 过滤、最终选择和 trace_log 都由同一个模块输出。

当前 scorer 是 domain_router_feature_v1。它仍然是本地 deterministic scorer，但已经不再只是合成关键词匹配，而是组合 lexical overlap、关键词短语、task binding、source path、scope signal、permission scope、ontology binding、lifecycle 和 unknown topology penalty。

本轮也把原先散落在 Context Management Eval 里的 ask event 沉淀为 framework/workflows/ask_router.py 的 route_ask_request。现在 gap case 会先生成结构化主动询问事件，再形成 review_status=pending 的 knowledge_card，真实企微接入后只替换 delivery / callback adapter，不替换 ask message、knowledge card 或 trace contract。

运行命令：

bash python scripts/context_management_eval.py --write-report

结果文件：

• vault/50-outputs/context-management-eval-results.json
• vault/50-outputs/context-management-eval-analysis.md

实验定位

OrgReOrg 的核心不是“做一个知识库”或“做一个搜索系统”，而是做 Agentic Context Management：

text 当前用户 + 当前任务 + 当前权限 -> 选择最小充分上下文 -> 控制 token、噪声和权限风险 -> 证据不足时显式产生 gap -> 主动询问 owner 并沉淀新知识

所以本实验观察四类指标：

指标	含义
baseline_context_tokens	候选上下文库如果全进 prompt 的估算 token
managed_context_tokens	实际返回给 Agent 的受控上下文 token
evidence_coverage	必需上下文是否被覆盖
permission_filtered_count	Tool Gateway 过滤掉多少越权候选输出
knowledge_gap_count	是否显式发现证据或权限不足
suggested_owner_ids	gap 后应该主动询问谁
route_candidates	Context Router 候选库评分、命中原因和权限可见性
search_connector_rank_log	SearchConnector 经过 Tool Gateway 清洗后的 rank log
trace_events	route、search、ask 三段可审计运行事件
ask_event	knowledge gap 后是否生成结构化主动询问事件

Case 明细

Case	类型	预期	结果
personal-onboarding-reimbursement	personal	个人业务读取本人上下文和组织目录，不泄漏财务或项目上下文	pass，token 节省 24.2%
department-finance-policy	department	财务部门事项读取财务上下文和组织目录，不泄漏个人或项目上下文	pass，token 节省 24.4%
project-framework-development	project	当前项目读取项目上下文和组织目录，不读取财务或个人上下文	pass，token 节省 25.0%
project-finance-budget-gap	project	项目申请预算时缺少财务权限，应产生 gap 并建议询问财务 owner	pass，建议 owner 为 finance-owner

Route / Ask 观测

本轮把 Context Router、SearchConnector 和 Ask Router 的未来接入点先固化为本地指标 contract：

• 每个 case 都输出 route_candidates：候选库、总分、feature breakdown、是否被当前 permission view 允许、命中原因。
• 每个 case 都输出 router_selected_context_libraries 和 router_permission_filtered_libraries。
• 每个 case 都输出 trace_events：context.route 由 route_domain_context 的 trace_log 水合，随后是 context.search，gap case 额外输出 context.ask。
• 每个 case 都输出 search_connector_rank_log：candidate_count、scored_candidate_count、returned_count、tool_gateway_filtered_output_count 等经过 Tool Gateway 清洗后的计数字段。
• gap case 输出 ask_event：selected_owner_ids、top1_owner_id、use_scope、review_status、pending knowledge_card、trace_log 和 ask message contract。

当前 project-finance-budget-gap 的结果是：财务库相关但被权限视图过滤，因此不进入 prompt；系统通过 route_ask_request 生成 ask_event，top1 owner 为 finance-owner，消息 contract 通过，review 状态为 pending，同时生成 source_type=local_ask_router 的 pending knowledge card。

得到的 Insight

1. 知识构建和搜索是上下文管理的服务层，不是目标本身。
2. “最小充分上下文”必须同时看质量、成本和权限，单看检索召回会误导架构判断。
3. 权限不足但任务需要相关上下文时，正确行为是显式 gap 和主动询问，而不是扩大检索范围。
4. rank_log、候选库 ID、owner、source URI 都可能成为泄漏面，必须通过 Tool Gateway 清洗。
5. route trace、SearchConnector rank_log、ask event 和 pending knowledge card 是 Loop 状态的一部分。真实 adapter 接入后，Context Router、SearchConnector、Ask Router 和 knowledge card 都要写入同一套可观测指标。
6. route_domain_context 已升级为 domain_router_feature_v1。后续真实 embedding / learning-to-rank scorer 可以替换打分来源，但不能绕过 permission view、feature trace、trace_log 或 Tool Gateway。

下一步

• 用真实团队问题和人工纠正日志校准 domain_router_feature_v1 的 feature 权重。
• 把 route_ask_request 的本地消息投递替身接到真实 Ask Router / 企业微信消息事件，同时保持同一 ask message、knowledge card 和 trace contract。
• 接 Postgres/OpenSearch adapter 后继续输出同一 search_connector_rank_log，并补充延迟、索引成本、上下文 token 和人工纠正。
• 增加跨部门项目、权限变更、stale index 和 owner 缺失 case。