124 lines
4.5 KiB
Markdown
124 lines
4.5 KiB
Markdown
# Bookworm v7.0 Evolution Roadmap
|
||
|
||
> 基于 v6.3 双轮 16 维度审查的深度洞察，规划下一代架构演进方向。
|
||
|
||
## 核心演进主题
|
||
|
||
### Theme 1: 真正的语义理解（替代双 TF-IDF）
|
||
|
||
**现状**: v6.3 的 "semantic" 通道实际是第二个 TF-IDF，与 BM25 信息重叠度 >85%。30% 融合权重几乎浪费。
|
||
|
||
**目标**: 集成轻量级 embedding 模型，实现真正的语义路由。
|
||
|
||
```
|
||
方案 A: ONNX Runtime + all-MiniLM-L6-v2 (22MB, 384维)
|
||
- 优点: 跨语言、语义理解、零 API 调用
|
||
- 缺点: 首次加载 ~500ms, 需要 onnxruntime-node 依赖
|
||
- 实施: 预计算 94 skill embeddings, 运行时只计算 query embedding + cosine
|
||
|
||
方案 B: 本地 TF-IDF + 字符级 CNN (自训练)
|
||
- 优点: 无外部依赖, 可增量学习
|
||
- 缺点: 需要标注数据, 模型质量取决于数据量
|
||
|
||
方案 C: Claude API embedding (ada-002 级别)
|
||
- 优点: 最高质量
|
||
- 缺点: 需要网络调用, 延迟不可控, API 费用
|
||
|
||
推荐: 方案 A (离线 embedding, 一次加载终身复用)
|
||
```
|
||
|
||
### Theme 2: 项目级自适应路由
|
||
|
||
**现状**: 全局统一路由权重，不区分项目类型。React 项目和 Python 后端项目使用相同的技能偏好。
|
||
|
||
**目标**: 按 cwd/项目类型自动调整路由权重。
|
||
|
||
```
|
||
设计:
|
||
1. 项目指纹检测: package.json → frontend, requirements.txt → python, go.mod → golang
|
||
2. per-project 融合权重: debug/project-weights/{fingerprint}.json
|
||
3. 项目级反馈隔离: 不同项目的 correction 互不干扰
|
||
4. 冷启动: 新项目从全局权重开始, 逐步学习项目偏好
|
||
```
|
||
|
||
### Theme 3: 多步骤任务编排
|
||
|
||
**现状**: 每次用户输入独立路由到单个技能。多步骤任务需要用户手动切换。
|
||
|
||
**目标**: 自动检测多步骤任务，生成技能执行计划。
|
||
|
||
```
|
||
设计:
|
||
1. 任务图构建: "从零搭建 React+Express+PostgreSQL 全栈" →
|
||
[architect-expert → database-tuning → backend-builder → frontend-expert → tester-expert]
|
||
2. 技能依赖: enhances/requires 关系 → 拓扑排序
|
||
3. 渐进执行: 每步完成后评估是否需要调整计划
|
||
4. 与 orchestrator agent 集成
|
||
```
|
||
|
||
### Theme 4: 实时协作路由
|
||
|
||
**现状**: 多个 Claude Code 会话通过文件系统间接通信，存在竞态和污染。
|
||
|
||
**目标**: 会话间共享路由智能，但隔离状态。
|
||
|
||
```
|
||
设计:
|
||
1. 共享学习: fusion-weights 和 disambiguator-state 使用 CRDT 合并
|
||
2. 隔离状态: route-state 完全 per-session (v6.3 已部分实现)
|
||
3. 协作缓存: skills-index 的 embedding cache 跨会话共享
|
||
4. 实现: Unix domain socket 或 named pipe 替代文件系统通信
|
||
```
|
||
|
||
### Theme 5: MCP 工具路由
|
||
|
||
**现状**: 路由仅覆盖 94 个 skills，26 个 MCP 工具不在路由范围内。
|
||
|
||
**目标**: 将 MCP 工具选择也纳入智能路由。
|
||
|
||
```
|
||
设计:
|
||
1. MCP 工具描述索引: 类似 skills-index 但针对 MCP tools
|
||
2. 工具推荐: 当路由到某技能时, 推荐该技能常用的 MCP 工具
|
||
3. 安全集成: mcp-safety-gate 与路由决策联动
|
||
```
|
||
|
||
### Theme 6: 自然语言规则引擎
|
||
|
||
**现状**: 42 条消歧规则用 JSON + regex 定义，需要开发者手动维护。
|
||
|
||
**目标**: 用户用中文定义路由规则，系统自动编译。
|
||
|
||
```
|
||
示例:
|
||
用户: "当用户同时提到 Docker 和 CI/CD 时，优先路由到 devops"
|
||
编译为: { trigger: "docker.*ci|ci.*docker", boost: "devops-expert", weight: 0.3 }
|
||
|
||
实现:
|
||
1. LLM 解析自然语言规则 → 结构化 JSON
|
||
2. 规则沙箱: 新规则先在 shadow mode 运行, 不影响实际路由
|
||
3. 规则效果评估: 自动计算新规则对 MRR 的影响
|
||
4. 规则冲突检测: 新规则 vs 现有 42 条的冲突矩阵
|
||
```
|
||
|
||
## 版本规划
|
||
|
||
```
|
||
v6.3 (当前) — 生产级审查修复, 16 维度加固
|
||
v6.4 — 路由准确率攻坚 (Golden Set, BM25 调参, 同义词扩展)
|
||
v6.5 — 基础设施稳定化 (测试覆盖, 监控告警, 灾难恢复)
|
||
v7.0 — 语义路由 (embedding 集成) + 项目级自适应
|
||
v7.1 — 多步骤编排 + MCP 路由
|
||
v7.2 — 自然语言规则 + 实时协作
|
||
```
|
||
|
||
## 技术债清单（从 v7.0 开始偿还）
|
||
|
||
| 债务 | 来源 | 偿还方式 |
|
||
|------|------|---------|
|
||
| route-interceptor-bundle 760行上帝模块 | v5.x 遗留 | 拆分为 pipeline 阶段模块 |
|
||
| 4 个 tokenizer 不一致 | v4.x-v5.x 各自实现 | 统一 tokenizer 模块 |
|
||
| JSONL 全文扫描 | 日志查询无索引 | SQLite 替代或 time-range 索引 |
|
||
| 72 处 existsSync 冗余 | 历史习惯 | 替换为 try-catch readFileSync |
|
||
| hook-errors.log 纯文本 | v5.x 设计 | 已部分修复(v6.3 JSONL去重) |
|