# 建议把"选模型"升级为"编排模型"：单一 / 级联 / 评审三档运行时

**URL:** <https://forum.qoder.com/t/topic/12834>\
**Category:** Feature Requests\
**Tags:** agent\
**Created:** [September 24, 2026, 10:08am UTC](https://forum.qoder.com/t/topic/12834 "2026-09-24T10:08:22Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![ZuiKe\_JiangHu](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.qoder.com/zuike_jianghu/32/5668_2.png) [@ZuiKe\_JiangHu](https://forum.qoder.com/u/ZuiKe_JiangHu)\
**Post date:** [September 24, 2026, 10:08am UTC](https://forum.qoder.com/t/topic/12834/1 "2026-09-24T10:08:22Z")

</div>

## **Problem**

Qoder 已经内置多款模型并按需智能路由，这点比很多同类工具走得靠前。但现在的路由本质是 **“挑一个最合适的模型去跑完整个任务”** ，而真正卡住体验的是另外三件事：

**1. 简单任务也在烧最强档。** 改两行代码、补个函数注释，和重构一个模块调用的是同一个档位。“选最合适的模型"听起来合理，但实际分配里"合适"往往被保守地理解成"足够强”，成本大头就是这么来的。

**2. 长任务中途跑偏，没人拦。** Qoder 已经把编程能力外扩到文档处理与数据分析，这类任务动辄十几步。一旦中间某一步理解偏了，后面每一步都在错误的地基上继续堆，而系统没有任何机制在中间喊停——只有等最终结果出来，由人来发现。

**3. 自评躲不开同源盲区。** 让产出模型自己检查自己的结果，和让另一个厂商的模型来检查，是两回事。同一个模型族的训练数据、偏好和系统性偏见是共享的，自己查自己查不出这一类问题。

**4. 单供应商就是单点。** 模型涨价、限流、下线，或者某次更新后能力波动，整条链路只能跟着抖。

## **Solution**

参考 GitHub Copilot 刚放出的 **HydraFusion** （研究预览）：把执行过程当成优化问题，用能力信号评估请求复杂度（多步推理、自动代码生成、结构化调试、高级工具使用），再路由到三种运行时模式——  
模式  
机制  
适用  
**单一**  
模型能力足够就直接跑，求延迟最优  
小改动、补全  
**级联**  
快模型先出草稿，过质量门控就采纳，不通过才升级到更强的模型  
中等复杂度、批量任务  
**评审**  
起草模型出初稿 → **来自不同模型族、且没有工具执行权限** 的只读模型交叉评估 → 起草模型据此做一次结构化修订  
长任务、高风险改动

**为什么评审模型必须"独立模型族 + 无工具权限"** ：前者是为了避开同源盲区（第 3 条），后者是防止评审者越权直接改代码——它只能说，不能动。这是整套设计里最容易被忽略、但最关键的一环。

**配套五条工程约束** （缺了这些，编排层在生产环境会出事）：

- 每个阶段（起草 / 评审 / 修订 / 升级 / 重试 / 回退）的 token 计账

- 严格超时与取消边界

- 评审步骤在无工具环境隔离

- 验证失败即拒绝打补丁的 fail-safe 补丁应用

- 路由启动前预检模型可用性与绑定关系

**他们给的离线数据** ：TerminalBench 2.1 上比 Claude Opus 5 完成质量高 **4.9 个百分点、预估成本低 67%** ；内部多轮基准 CheckpointBench 上平均会话得分与 Opus 5 只差 **0.1 个百分点、成本低 65%** ——质量持平甚至略优的前提下拿到的。

**建议的落地顺序** （不用一次做完）：

1. **先做级联 + 质量门控** 。门控先不请模型评审，用规则 + 一个轻量判分模型即可，成本收益立刻能拿到。

2. **再加评审模式** ，务必放进无工具权限的只读沙箱。

3. **最后补可观测性** ：每个阶段花了多少 token、哪家的模型出的稿、评审改了什么，要能在会话里回看。路由对用户体验来说是黑箱的话，出问题难排查，也难建立信任。

**两个坑提前说** ：

- 评审会加延迟。建议长任务、高风险改动（批量改文件、删除类操作）默认开，补全、小修这类强交互场景默认关。

- 编排层要一起做威胁建模。前几天 Claude Code 加入 AGENTS.md 支持、五大工具收敛到同一指令文件标准之后，安全研究者随即演示了通过恶意 AGENTS.md 劫持 agent 目标（OWASP ASI01/ASI02）。规则文件和评审指令的加载路径请一并纳入审计—— **编排层越灵活，注入的收益也越大** 。

## **Use Case**

**场景一：小改动不再烧最强档** 在 Qoder 里让 agent 修一个函数签名、补几行错误处理、改一处配置——这类任务占了日常调用的大头。级联模式下，便宜档先出草稿，门控判定通过就直接交付，只有判定不通过才升级。对每天都在用 Qoder 的人来说，这一步省的是真金白银。

**场景二：长任务中途被拦住** 用 Qoder 处理一份跨多个文件的数据分析任务：先理解需求 → 拆步骤 → 写脚本 → 跑 → 修 → 出结论。第 2 步理解偏了，第 3 到 6 步全在错误的方向上。评审模式在关键节点插一个只读评审者，它不改代码，只判断"这一步和原始目标还一致吗"，不一致就触发修订。 **长链路里单步错误是累积的，中途拦一次的价值远大于最后检查十次。**

**场景三：跨厂商互评，顺带摸清各家模型的能力边界** 手边有 GLM、Qwen、Kimi、DeepSeek 等多家供给，"评审须来自独立模型族"这条在国内反而最容易满足。A 家出稿、B 家评审，既避开同源盲区，又能顺带统计出各家模型在各类任务上的真实表现——这份数据是纯路由方案拿不到的副产品。

**场景四：文档与数据分析这类非代码任务** Qoder 已经把能力从编程外扩到文档处理与数据分析。这类任务的难度分布比纯编程散得多——同一条指令可能前 3 步很简单、第 4 步突然需要深度推理。固定档位很难两头兼顾，级联路由在这里的收益比纯编程场景更明显。

## **Priority**

- 🔴 High - Blocking issue
- 🟡 Medium - Important improvement
- 🟢 Low - Nice to have

## **Additional Info**

(Optional: screenshots, examples, links)