Agent 下半场的隐秘战争发生在 Harness 调度层

国产模型的价值，正在从单点能力转向组合能力

文 | 王熠

在 DRACO 最近做的一项评测中，一组数据引起了行业注意。

这是一个公开基准测试，包含 100 道高难度的研究与分析任务。开源 Agent 框架 OpenSquilla 0.5.0 把 DeepSeek、GLM、Kimi、Qwen 四个国产模型组织成并行提案架构，再由一个模型聚合输出。

结果显示，这套全国产阵容取得了 60.85 的质量分，略高于最新旗舰模型 Fable5 的 59.80。单任务平均成本约为后者的1/3，分别为 0.39 美元和 1.21 美元。

在另一组对比中，这套多模型集成方案相较单跑的 Claude Opus 4.8 和 GPT-5.5，质量分更高，成本降低约 86%~92%。

这组数据真正提出的问题是，复杂任务是否还需要默认交给单一最强模型。

过去两年，大模型竞争主要围绕基础模型展开，模型能力、上下文长度和榜单表现最受关注。进入应用层，一项任务往往要经过多轮执行，模型怎么选、如何协作、结果怎么验证、失败后怎么恢复，都会影响最终质量和成本。

模型本身当然重要，模型如何被组织起来，也开始变得同样重要。

01. 被忽视的 Harness

要理解这个变化，需要先拆开 Agent 的基本结构。行业常用这个公式来表达Agent和Harness的关系——Agent = Base Models + Harness。

也就是基础模型提供语言理解、推理、代码生成、工具使用等能力，Harness 负责把这些能力接入具体流程，让输出可执行、可观察、可验证。

如果说模型提供能力，Harness 负责的是使用能力的方式。它包括上下文管理、执行控制、工具调用、输出验证、失败恢复，也包括多个模型之间的协作安排。一个模型单独调用时，只是在回答问题；进入 Harness 之后，它才被放进一套完整的工作流。

Harness 的价值并不只是工程包装。

基元律动团队此前在 Claw-SWE-Bench 研究中提到，同一个模型在不同 Harness 配置下，任务完成率最多可以相差 27.4 个百分点。也就是说，不换模型，只调整外围执行框架，最终结果就可能出现接近三成的差异。

放到日常场景里，这个差异会被放大。

在很多任务中，模型调用很少停留在一次问答。系统需要理解任务、拆解步骤、检索资料、调用工具，再完成验证和修正。中间任何一个环节不稳，最终交付都会受到影响。

单纯把所有任务交给最贵模型，曾经是一个省心选择。复杂任务怕失败，就默认调用旗舰模型；简单任务也混在里面，一样消耗高价算力。账单越来越高，结果仍然不完全可控。

模型数量增加之后，选择标准也变了。不同模型开始形成各自侧重，要解决的不只是选最强模型，还要在具体步骤里匹配合适的模型。

这正是 Harness 所要做的事情。它不参与基础模型竞争，却决定模型如何被调度、互补和验证，最后能否形成稳定交付。

02. OpenSquilla 0.5.0，把模型组织成一支队伍

OpenSquilla 0.5.0 Preview 和同步发布的《Agentic Routing》技术报告，把这套思路应用到了具体产品上。

OpenSquilla 不是新的大模型，而是一套开源、可本地托管的 Agent 运行框架。它不训练基础模型，主要做模型之上的调度和组织。

Agentic Routing 可以理解为步骤级模型路由。传统路由通常只在请求进入时做一次判断，系统根据用户问题选择一个模型。Agentic Routing 的判断发生在 Agent 执行过程中，每一步都会根据当前状态重新选择模型。

简单工具调用，轻量模型就能处理；复杂推理、长上下文归纳或代码生成，则可能需要更强模型参与。有些步骤还会同时调用多个模型，让它们并行给出方案，再由系统聚合。

0.5.0 的核心能力是多模型集成协作。

在这套机制里，四个国产模型被放在并行提案位置上，各自独立完成搜索、推理和答案生成。第五个模型负责聚合，综合多个候选答案后形成最终输出。

这套方法并不神秘，它处理的是单模型执行时常见的信息盲区。

单个模型查资料，容易漏掉关键信息源；处理复杂约束时，也可能顾此失彼。多模型并行探索，相当于让几个能力结构不同的模型从不同角度做补位，再通过聚合降低单一模型失误带来的影响。

OpenSquilla 团队在 DRACO 评测中列了几组对比。

在跨文化电商结账流程任务里，单模型漏掉了 Rakuten 平台的确认机制和 30 分钟取消窗口，多模型集成方案把这些平台细节补了进来。

在 AI 代码补全的用户体验分析中，单模型把调试和功能开发的触发策略说反了，多模型方案给出的交互策略和时延预算更准确。

在澳洲热泵烘干机比较任务里，单模型没有完整覆盖各机型的容量参数，多模型方案给出的比较维度更完整。

这几组对比说明，单模型在复杂任务中容易留下盲区。多模型并行提案再聚合，可以补足部分细节，也让结果更稳。

值得一提的是，OpenSquilla 0.5.0 并非突然转向多模型集成。往前看，它前面几个版本一直在围绕模型调度、工作流编排和结果验证做迭代：

v0.1.0 做智能路由，把简单任务交给更低成本的模型；v0.3.0 做 MetaSkill 自组织工作流，让 Agent 按任务目标编排子任务；v0.4.0 引入可验证编码和签名桌面版，把代码生成放进可执行验证流程。到了 v0.5.0，多模型集成被放进 Harness 层。

几次更新一路延续下来，目标都很清楚，就是让模型调用更可控、成本更低、结果更稳定。

03. 国产模型的价值，正在从单点能力转向组合能力

OpenSquilla 0.5.0 的 DRACO 结果，本身只是一个阶段性观察。它的意义在于提供了一个切口，让人看到两件事正在同时发生。国产模型能力在分化，模型组织方法也在成熟。

先看模型。

在 DRACO 单模型评测中，DeepSeek V4 Pro 得分 50.32，Qwen 3.7 得分 49.34，GLM-5.2 得分 48.28，和 Fable5 的 59.80 仍有差距。单模型层面，它们还谈不上追平旗舰模型。

但国产模型的角色已经变了。它们不再只是低价替代品，开始在不同任务类型中形成各自侧重。单个模型未必全面胜出，放进一套合理的组织框架里，组合价值会被放大。

再看组织方法。

以 Agentic Routing 为代表的路由机制，已经从“按问题选模型”，推进到“按执行状态调度模型”。在 Agent 场景里，系统要看任务走到了哪一步、风险是否升高、是否需要验证或恢复，再决定下一步该调用哪个模型。

OpenSquilla 的路由设计包含四层，从复杂度过滤、任务类型分类，到上下文状态识别，再到最终模型排序。关键不在于某个具体算法，而在于路由开始理解任务所处的执行状态。

同一个任务，在不同阶段需要的模型可能不同。前期拆解可以用低成本模型，遇到复杂证据恢复时再切换到更合适的模型；验证失败后，也可以让更强模型介入修正。路由判断的对象不再只是用户问题本身，是任务执行到当前阶段之后的状态。

每一次路由决策还会留下执行数据，包括模型选择、结果和成本。这些数据会继续反哺路由器，也可能训练更适合在 Harness 中运行的本地模型。路由越准，同样预算下能执行的任务越多，系统后续优化的空间也越大。

OpenSquilla 0.5.0 的表现说明，当模型池足够丰富、调度系统足够精细，复杂任务就不一定要默认交给最贵模型。

04. Agent 最终要回到交付

使用 AI，最终衡量的是交付结果。

一个 Agent 能否进入真实工作流，取决于任务能否完成、结果能否验证和成本能否覆盖这几个基本条件。过去很多项目不是模型做不了，是规模化之后成本算不过来。

OpenSquilla 0.5.0 代表的思路，是把成本控制从简单降配，推进到能力匹配。

简单降配只是把贵的模型换成便宜模型，结果往往不稳定。能力匹配要解决的是，哪些步骤必须调用强模型，哪些步骤可以交给轻量模型，哪些场景需要多模型协作。它追求在成本和质量之间找到平衡点。

在这套逻辑里，降本就是减少不必要的高价调用。复杂任务也不必始终依赖单个旗舰模型，只要模型组合、执行状态和验证机制设计得当，一组成本更低的模型，也可能在部分任务中取得接近甚至更好的结果。

当模型使用成本可以通过系统工程压缩，一些原本“ROI 算不过来”的项目，才有重新评估的空间。使用者未必关心系统背后调用了多少模型，也未必关心某个单模型的榜单排名。它们更关心同样预算下，系统能稳定完成多少任务，出错后能否恢复，最终结果能否交付。

因此，AI 行业的效率红利，正在从基础模型一侧，延伸到模型组织和执行框架一侧。

DRACO 上的 100 道任务只是一个切片，不能替代真实生产环境，也不能替代长期验证。但它提醒行业，复杂任务不一定只有等待更强模型这一条路径。把现有模型组织得更细致、更稳、更便宜，同样是一条值得投入的路径。