4.1 KiB

Raw Blame History

Council Plan — openclaw-claude-code MiniMax 路由补丁设计

Round 1 — 2026-04-14 Branch: council/PM → main 状态：Planning Round

Task Summary

为 @enderfga/openclaw-claude-code 插件设计可配置的 MiniMax 路由方案，解决硬编码 provider: 'anthropic' 导致路由失效的问题。

核心约束：

配置优先（不硬编码）
向后兼容（默认走 Anthropic 官方）
可还原（插件更新不被覆盖）
显眼易懂（有注释说明）

4 Q Discussion (Round 1)

Q1 (Backend): proxy handler 如何读取 provider URL 配置？

选项：

A: 环境变量 (MINIMAX_BASE_URL)
B: OpenClaw config (~/.openclaw/openclaw.json → providers.minimax-portal.baseUrl)
C: 插件独立配置文件 (openclaw-minimax.json)

Backend 立场：B — OpenClaw config

理由：providers section 已有 MiniMax 配置示例，符合 OpenClaw 插件生态
插件可通过 this.config.providers 读取，无需额外解析逻辑
环境变量不统一，插件独立配置增加用户认知负担

Q2 (Architect): models.js provider 映射如何支持配置覆盖？

选项：

A: 启动时从外部配置注入覆盖默认值
B: 修改 plugin 源码，动态读取 provider
C: Monkey patch after plugin load

Architect 立场：A — 启动时覆盖

理由：不修改 node_modules，通过 OpenClaw hook 在插件加载前注入配置
符合"可还原"原则，插件更新后仍生效

Q3 (PM): 配置项放在 OpenClaw config 哪个 section？

参考：

{
  "providers": {
    "minimax-portal": {
      "baseUrl": "https://api.minimaxi.com/anthropic",
      "apiKey": "minimax-oauth",
      "api": "anthropic-messages"
    }
  },
  "defaults": {
    "model": { "primary": "minimax-portal/MiniMax-M2.7" }
  }
}

PM 立场：建议新增 routing section，结构如下：

{
  "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
读取层：plugin handler 从 config.routing 读取覆盖配置
注入层：通过 OpenClaw hook 在 plugin 加载前注入配置（不修改 node_modules）
回滚：删除 routing 配置项即可还原默认行为

Task Checklist

A1: Backend Q1 回答 - provider URL 读取方式
A2: Architect Q2 回答 - provider 映射配置覆盖机制
A3: PM Q3 回答 - 配置项位置与命名
A4: 综合 Q4 回答 - 推荐方案（待整合）
B1: 交叉评审（Backend 评审 Architect/PM 输出）
B2: 交叉评审（Architect 评审 Backend/PM 输出）
B3: 交叉评审（PM 评审 Backend/Architect 输出）
C1: 综合结论合并到 main，投票

Phase Breakdown

Phase	内容	状态
Draft	4 Q 独立回答 + 等待同步	🔄 In Progress
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	`[Pending]`
B1: 交叉评审	council/Backend	`[Pending]`
C1: 最终投票	council/All	`[Pending]`

[CONSENSUS: NO] — Round 1 Q1-Q3 已完成，等待 Q4 综合方案后进入 Review 轮

4.1 KiB Raw Blame History Unescape Escape