Domain Router Feedback Eval

结论

本实验把 Context Router 的人工纠错从“经验口头反馈”推进为可运行事件流。

当前机制：

• 路由事件仍由 domain_router_feature_v1 产生。
• 人工纠错写入 domain/orgreorg-demo/context-router-feedback-events.json。
• 每条事件包含 task_id、question、actor_view_id、expected context libraries、rejected context libraries、reviewer、reason。
• 下一轮 route_domain_context 会把匹配事件作为 feedback_expected / feedback_rejected feature 加入候选库评分。
• 反馈只影响排序，不能绕过 permission view。

当前结果

运行命令：

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

当前 case：

Case	目的	结果
project-docs-vault-router-feedback	把“docs/vault 怎么组织”从通用组织目录纠正到项目知识库	corrected top1 为 project_orgreorg_knowledge
project-finance-feedback-permission-gate	即使反馈认为财务库相关，项目维护者也不能越权加载财务上下文	department_finance_ops 仍被 permission view 过滤

输出：

• vault/50-outputs/domain-router-feedback-results.json
• vault/50-outputs/domain-router-feedback-analysis.md

为什么这件事重要

OrgReOrg 的研用测一体要求系统能从团队使用中改进。路由错了以后，如果只把纠错写进聊天记录，下一轮 Agent 仍然会重复犯错。

这个实验把纠错变成三层资产：

1. domain/ 中的结构化反馈事件。
2. router trace 中的可解释 feature。
3. 实验报告和项目看板中的可观察指标。

这也解释了为什么反馈不能直接“强制加载”上下文。企业上下文管理的目标是最小充分上下文和权限安全之间的 trade off：纠错可以告诉系统哪个库更相关，但最终是否能进入 prompt 仍由当前 permission view 决定。

下一步

1. 把真实团队问题和人工纠错继续追加到 feedback event log。
2. 接 Postgres / OpenSearch adapter 后复用同一组 feedback fixture，观察真实检索层是否放大错误路由。
3. 把 feedback 事件接入 No-WeCom MVP 主链路和未来企微回调。