From 688851414a996b9bf2250619e7308b5719335ac0 Mon Sep 17 00:00:00 2001 From: Codex Date: Wed, 20 May 2026 12:02:58 +0000 Subject: [PATCH] docs: define code queue model routing policy --- docs/reference/code-queue-supervision.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/reference/code-queue-supervision.md b/docs/reference/code-queue-supervision.md index e2460b05..54fbf030 100644 --- a/docs/reference/code-queue-supervision.md +++ b/docs/reference/code-queue-supervision.md @@ -41,6 +41,19 @@ 当一个指挥机需要突发创建大量 Code Queue 任务时，submit 默认应串行或接近串行。为了避免控制面在确认任务前被打爆，可以使用短本地锁或短延迟，尤其是在低内存主机上。目标是保持任务创建可观测且稳定，而不是最大化瞬时入队吞吐。 +## 模型和成本路由 + +MiniMax/OpenCode runner 的可用性是 Code Queue 的主要能力方向之一。它不是可选实验项，而是控制 GPT-5.5 成本、扩大并发吞吐、让简单任务不占用高成本模型的基础设施能力。 + +指挥官派单时应按任务难度、风险和验收成本选择模型： + +- 低风险、边界清晰、可用文件/命令/commit 直接验收的任务，优先分配给 MiniMax/OpenCode，例如只读调查、文档初稿、表格整理、轻量 CLI contract、局部测试补齐和小范围样板代码。 +- 中等复杂度、需要跨文件判断但不触碰生产运行态的任务，可以在 MiniMax 可用且已有成功样本后尝试分担；prompt 必须更窄，验收证据必须更具体。 +- 高风险任务继续优先使用 GPT-5.5，例如生产部署、凭证和网络变更、Code Queue/backend-core 运行态修复、跨模块架构调整、复杂回滚、以及最终质量裁决。 +- MiniMax 任务不得降低验收标准。指挥官必须核验它声称读取的文件、执行的命令、远端 commit、测试输出和 live 证据；对推测、遗漏、伪造或把失败写成成功的情况，应拆小重派或改用 GPT-5.5。 + +MiniMax 路由策略的前置条件是 runner live smoke 稳定通过，并且失败能被结构化归类。若 MiniMax/OpenCode 本身不可用，相关修复归入 Code Queue 运行态维护线；在修通前，不应用 MiniMax 承担会阻塞主交付链路的任务。 + ## GitHub Issue 和 PR 使用 GitHub issue 是长期需求、缺陷、阻塞和决策的 source of record。聊天上下文、Code Queue final response 和指挥简报可以帮助恢复现场，但不能替代 issue 中的可检索记录。指挥简报自身也按 issue 主体维护，当前入口是 GitHub issue #24；后续只更新 #24 正文，不在评论区追加，且所有时间统一使用北京时间。