fix: route deepseek through opencode
This commit is contained in:
Codex
@@ -43,13 +43,13 @@
|
||||
|
||||
## 模型和成本路由
|
||||
|
||||
Code Queue 派单模型按成本、可信度和 blast radius 分层：GPT-5.5/Codex 处理高风险和复杂任务，DeepSeek/Codex 处理中等复杂度且边界清晰的任务，MiniMax/OpenCode 处理简单、低权限、可复核任务，生产重启、密钥、数据库手工写入和运行中任务控制保留给指挥官或人工。
|
||||
Code Queue 派单模型按成本、可信度和 blast radius 分层：GPT-5.5/Codex 处理高风险和复杂任务，DeepSeek/OpenCode 处理中等复杂度且边界清晰的任务，MiniMax/OpenCode 处理简单、低权限、可复核任务，生产重启、密钥、数据库手工写入和运行中任务控制保留给指挥官或人工。
|
||||
|
||||
当前提交合同由 `bun scripts/cli.ts codex submit` 暴露：prompt 必须来自位置参数、`--prompt-file` 或 `--prompt-stdin`；可选字段包括 `--queue/--queue-id`、`--provider-id/--provider`、`--cwd/--workdir`、`--model`、`--reasoning-effort`、`--execution-mode/--mode`、`--max-attempts` 和 `--reference-task-id/--reference/--ref`。这些字段写入任务 payload 后由 `code-queue-mgr` 入 PostgreSQL，核心任务字段包括 `queue_id`、`provider_id`、`execution_mode`、`model`、`cwd`、`prompt/base_prompt`、`reference_task_ids`、`reasoning_effort`、`max_attempts` 和 `task_json`；队列记录至少有 `id/name/created_at/updated_at`。模型治理应优先看任务 payload 和数据库字段，不靠 worker final response 自报。
|
||||
|
||||
运行态默认模型仍是 `gpt-5.5`。`CODE_QUEUE_MODELS` 当前长期合同至少包含 GPT-5.5、GPT-5.4、GPT-5.4 Mini 和 MiniMax M2.7；`minimax-m2.7` 会走 OpenCode port，其余模型走 Codex port。DeepSeek 属于 dry-run policy 和指挥治理层推荐模型；只有当执行面 `/health` 或等价配置已经显示 DeepSeek 模型可用、并完成轻量 runner smoke 后，才允许真实提交 `--model deepseek-chat`。补 DeepSeek 运行态配置必须作为单独任务处理，不能在派单治理任务里顺手改 admission 或 Kubernetes manifest。
|
||||
运行态默认模型仍是 `gpt-5.5`。`CODE_QUEUE_MODELS` 当前长期合同至少包含 GPT-5.5、GPT-5.4、GPT-5.4 Mini、DeepSeek Chat 和 MiniMax M2.7；`deepseek`/`deepseek-chat` 与 `minimax-m2.7` 会走 OpenCode port，其余模型走 Codex port。只有当执行面 `/health` 或等价配置已经显示 DeepSeek 模型可用、并完成轻量 runner smoke 后，才允许真实提交 `--model deepseek-chat`。
|
||||
|
||||
`codex submit --dry-run` 是派单前的轻量 preflight。它只输出 `routingRecommendation` 和 `policyContract`，帮助指挥官看到推荐 runner/model、风险信号、缺失的 prompt guard、模型分层和并发上限；它不会修改真实提交 payload，也不会替代指挥官判断。真实派单是否使用 `--model minimax-m2.7`、`--model deepseek-chat` 或 `--model gpt-5.5` 仍由指挥官显式决定。
|
||||
`codex submit --dry-run` 是派单前的轻量 preflight。它输出 `routingRecommendation`、`policyContract` 和模型注册表，帮助指挥官看到推荐 runner/model、风险信号、缺失的 prompt guard、模型分层、并发上限、`opencodeModels` 和 `modelPorts`；它不会修改真实提交 payload，也不会替代指挥官判断。真实派单是否使用 `--model minimax-m2.7`、`--model deepseek-chat` 或 `--model gpt-5.5` 仍由指挥官显式决定。
|
||||
|
||||
并发治理按模型和风险一起决定。GPT-5.5 常规并发目标是 5 条 lane；当写入范围互不重叠、heartbeat/trace 健康、完成质量稳定时可以短时提高到 10。MiniMax 只承接简单任务时可以提高到 10，但必须保留指挥官审阅和证据核验。DeepSeek 用于中等复杂度任务，默认按约 5 条 lane 观察质量，再根据成功率和 reviewer 负载逐步调整。并发扩张的前提永远是任务质量和可观测性，而不是模型价格。
|
||||
|
||||
@@ -58,7 +58,7 @@ Code Queue 派单模型按成本、可信度和 blast radius 分层：GPT-5.5/Co
|
||||
| 首选模型 | 适用任务 | 必须满足 | 禁止下放 |
|
||||
| --- | --- | --- | --- |
|
||||
| GPT-5.5/Codex | 高风险、复杂、跨模块、运行态、CI/CD、release、deploy、安全、最终质量裁决 | 多信号诊断、可回滚边界、必要的轻量或 dev 验证 | 不因成本把运行态和生产风险降级 |
|
||||
| DeepSeek/Codex | 中等复杂度的前端功能、局部用户服务模块、局部 CLI/helper、明确 contract guard 或 unit test | prompt 自包含、写入范围窄、无生产/密钥/DB 写入、验证命令明确、指挥官审阅 | 不处理 Code Queue runtime、backend-core、provider-gateway、k3sctl-adapter、release/v1 或部署变更 |
|
||||
| DeepSeek/OpenCode | 中等复杂度的前端功能、局部用户服务模块、局部 CLI/helper、明确 contract guard 或 unit test | prompt 自包含、写入范围窄、无生产/密钥/DB 写入、验证命令明确、指挥官审阅 | 不处理 Code Queue runtime、backend-core、provider-gateway、k3sctl-adapter、release/v1 或部署变更 |
|
||||
| MiniMax/OpenCode | 只读调查、文档、简单前端/样式、低风险样板、轻量 dry-run/preflight 和小范围测试补齐 | issue 只作辅助引用、必须给出 diff/路径/命令证据、完成后保持未读待审 | 不处理共享核心、隐式远端状态、生产、密钥、DB、重启、复杂 bug 或最终裁决 |
|
||||
| 指挥官/人工 | 真实生产动作、运行中任务控制、密钥/数据库/破坏性 Git、批量已读和高风险恢复 | 用户授权、只读诊断、恢复方案、记录 issue/#20/#24 | 不把执行权交给普通 worker |
|
||||
|
||||
|
||||
Reference in New Issue
Block a user