模型路由（稳定核心）

本文件是三角色默认模型档位和升级规则的单一事实源（SSOT）。目标：在不牺牲质量的前提下降低 token 和模型成本——把昂贵的强模型留给需要判断的工作，把机械执行交给较弱模型。

角色定义见 roles-and-permissions.md（Coordinator 编排 / Test 验证 / Developer 实现）。本文件只补一层正交的「用哪个档位的模型」。

默认档位

角色	默认模型档位	理由
Coordinator (PM)	强模型	需求拆解、验收信号设计、优先级、终检对齐意图、三轮失败复盘都需要高质量推理
Test	中低模型	按既定验收信号执行浏览器/API/脚本，主要做观察、记录、逐条 pass/fail
Developer	中低模型（按任务升级）	多数实现可照规格执行；跨系统、数据迁移、重复失败时再升级

关键点：Coordinator 用强模型但不亲自跑测试（测试由 Test 承担），所以强模型的 token 花在思考和终检上，而不是反复点击页面、跑 smoke、复制日志。这一分工天然省 token，同时保持「验证者 ≠ 实现者」。

什么时候用强模型

新需求理解、产品取舍、范围决策。
架构与数据模型决策。
把验收写成可观测信号（见 optimization-method.md §1）。
需求含糊、规格与实现/测试冲突时的裁决。
Coordinator 终检：读证据、对齐原始意图。
重复失败后的根因复盘与重新拆分。

什么时候用中低模型

Test：跑浏览器用例、API smoke、逐条比对期望与实际、产出证据。
Developer：从清晰规格实现范围明确的任务、跑构建与单测、回报 worker_done。

升级规则

升级到 Coordinator（强模型）复盘，当：

同一验收路径 Developer 连续失败三轮（见 optimization-method.md §4）。
Test 两次仍无法给出清晰失败证据。
任务需要改动产品范围或验收标准。
修复涉及持久化数据、破坏性文件操作、安全或回滚。
规格、测试、实现三者出现冲突。

升级 Developer 模型档位，当：

任务横跨多个子系统。
改动涉及数据模型或迁移。
需要设计新的抽象。
低档位反复产出表面修复。

升级动作本身由 Coordinator 判断并记录（可写进 tasks.yaml 的 dispatch 备注或 resolution）。

如何给 worker 指定模型（编排相关）

模型不由编排层设置。 Orca 的 orchestration task-create / dispatch 没有 --model 参数——dispatch 只是把任务投递给一个已存在的终端 handle。模型在创建 worker 终端、启动 agent CLI 时用 CLI 自带的 flag 固定，之后该终端的所有 dispatch 都用这个模型。

因此「档位 → 具体模型」的映射是 agent 相关 的，落地方式见 orca-adapter.md §「给 worker 终端固定模型」。常见 CLI：

Agent CLI	指定模型的方式
Cursor (`cursor-agent`)	`cursor-agent --model <model>`；`--model auto` 让 Cursor 自动选（推荐给 Test/Developer worker）
其它（codex / opencode 等）	用各自 CLI 的模型参数或配置

本 kit 对 Cursor 的默认建议：Test 与 Developer worker 用 cursor-agent --model auto（自动选型，天然偏向高效模型，符合"中低档位"意图）；需要更强时改成具体强模型（如 --model claude-opus-4-8-thinking-high）。Coordinator 作为强模型脑，通常就是发起编排的那个会话本身。

成本原则

强模型产出高密度、可复用的产物：需求、架构决策、验收信号、任务拆分、失败复盘。中低模型消费这些产物，产出可核对的执行证据：测试结果、快照、API 响应、构建日志、改动文件清单。

这样把昂贵推理挡在重复执行之外。

一句话

Coordinator 是脑，Test 是眼，Developer 是手。脑用最强的模型且不做机械测试，眼和手用便宜模型，只有常规闭环卡住时才升级。

4.1 KiB Raw Blame History Unescape Escape