106 lines
3.2 KiB
Markdown
106 lines
3.2 KiB
Markdown
# Council Plan — openclaw-claude-code MiniMax 路由补丁设计
|
||
|
||
> Round 1 — 2026-04-14
|
||
> Branch: council/Architect → main
|
||
> 状态：**Draft Phase 完成，待 Review**
|
||
|
||
---
|
||
|
||
## Task Summary
|
||
|
||
为 `@enderfga/openclaw-claude-code` 插件设计可配置的 MiniMax 路由方案，解决硬编码 `provider: 'anthropic'` 导致路由失效的问题。
|
||
|
||
**核心约束**：
|
||
1. 配置优先（不硬编码）
|
||
2. 向后兼容（默认走 Anthropic 官方）
|
||
3. 可还原（插件更新不被覆盖）
|
||
4. 显眼易懂（有注释说明）
|
||
|
||
---
|
||
|
||
## 4 Q Discussion (Round 1)
|
||
|
||
### Q1 (Backend): proxy handler 如何读取 provider URL 配置？
|
||
|
||
**Backend 立场**：**B — OpenClaw config**
|
||
- 理由：`providers` section 已有 MiniMax 配置示例，符合 OpenClaw 插件生态
|
||
- 插件可通过 `this.config.providers` 读取，无需额外解析逻辑
|
||
|
||
### Q2 (Architect): models.js provider 映射如何支持配置覆盖？
|
||
|
||
**Architect 立场**：**A — 启动时覆盖**
|
||
- 理由：不修改 node_modules，通过 OpenClaw hook 在插件加载前注入配置
|
||
- 符合"可还原"原则，插件更新后仍生效
|
||
|
||
### Q3 (PM): 配置项放在 OpenClaw config 哪个 section？
|
||
|
||
**PM 立场**：新增 `routing` section，结构如下：
|
||
```json
|
||
{
|
||
"routing": {
|
||
// 路由覆盖配置
|
||
"modelProviderOverride": {
|
||
// 模型名 → provider 映射
|
||
"claude-sonnet-4-20250514": "minimax-portal",
|
||
"claude-opus-4-6": "minimax-portal",
|
||
"claude-haiku-4-20250514": "minimax-portal"
|
||
},
|
||
// 可选：baseUrl 覆盖（如果 provider 配置的 baseUrl 需要临时覆盖）
|
||
"baseUrlOverride": {
|
||
"minimax-portal": "https://custom-api.minimaxi.com/v1"
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
**理由**：
|
||
- `routing` 语义清晰，表示"路由规则"
|
||
- `modelProviderOverride` 显式声明哪些模型走哪个 provider
|
||
- 放在顶层 `routing` 而非嵌套在 `providers` 里，醒目且独立
|
||
- 向后兼容：不配置则使用默认行为
|
||
|
||
### Q4 (综合): 推荐方案
|
||
|
||
**推荐方案**：
|
||
- **配置位置**：`~/.openclaw/openclaw.json` → `routing.modelProviderOverride`
|
||
- **读取层**：proxy handler 从 `config.routing` 读取覆盖配置
|
||
- **注入层**：通过 OpenClaw hook 在 plugin 加载前注入配置（不修改 node_modules）
|
||
- **回滚步骤**：删除 `routing` 配置项即可还原默认行为
|
||
|
||
---
|
||
|
||
## Task Checklist
|
||
|
||
- [x] A1: Backend Q1 回答 - provider URL 读取方式
|
||
- [x] A2: Architect Q2 回答 - provider 映射配置覆盖机制
|
||
- [x] A3: PM Q3 回答 - 配置项位置与命名
|
||
- [x] A4: 综合 Q4 回答 - 推荐方案
|
||
- [ ] B1: 交叉评审（各 Agent 互相评审）
|
||
- [ ] C1: 最终投票
|
||
|
||
---
|
||
|
||
## Phase Breakdown
|
||
|
||
| Phase | 内容 | 状态 |
|
||
|---|---|---|
|
||
| **Draft** | 4 Q 独立回答 + 综合方案 | ✅ Done |
|
||
| **Review** | 交叉评审，输出 `reviews/` 文件 | ⏳ Pending |
|
||
| **Finalize** | 合并到 main，投票 | ⏳ Pending |
|
||
|
||
---
|
||
|
||
## Claim Status
|
||
|
||
| Task | Owner | Status |
|
||
|---|---|---|
|
||
| A1: Q1 回答 | council/Backend | `[Done]` |
|
||
| A2: Q2 回答 | council/Architect | `[Done]` |
|
||
| A3: Q3 回答 | council/PM | `[Done]` |
|
||
| A4: 综合结论 | council/Architect | `[Done]` |
|
||
| B1: 交叉评审 | council/All | `[Pending]` |
|
||
| C1: 最终投票 | council/All | `[Pending]` |
|
||
|
||
---
|
||
|
||
**[CONSENSUS: NO]** — Draft 完成，等待 Review 轮 |