Agent下半场隐秘战争的核心战场就是在Harness调度层

DRACO评测揭示的新趋势：模型组织方式正在成为关键变量

在DRACO近期公布的公开评测中，一组数据引起了行业广泛关注。这项涵盖100道高难度研究与分析任务的基准测试，针对开源Agent框架OpenSquilla 0.5.0展开——该框架将DeepSeek、GLM、Kimi、Qwen四款国产模型组合成并行提案架构，再由一个模型负责聚合输出最终结果。

结果如何？质量分达到60.85，比最新旗舰模型Fable5的59.80略高。而单任务平均成本仅为0.39美元，只有后者的三分之一左右。Fable5跑一次则需要1.21美元。

另一组对比更直观：这套多模型集成方案，相比单独运行的Claude Opus 4.8和GPT-5.5，质量分更高，但成本却降低了约86%到92%。

这组数据背后，实际上抛出了一个非常现实的问题：面对复杂任务，是否真的有必要默认交给那个“最强”的单一模型来处理？

过去两年，大模型竞争的核心逻辑非常清晰——围绕基础模型本身展开，比拼参数规模、上下文长度、榜单表现。但进入应用层以后，情况发生了变化。一项任务往往需要经过多轮执行，模型如何选择、如何协作、结果如何验证、失败后如何恢复，这些环节的每一个，都会直接影响最终的质量和成本。

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

01. 被忽视的Harness

要理解这个变化，需要先拆解Agent的基本结构。行业内有一个简洁的公式：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道任务只是一个切片，不能替代真实生产环境，也不能替代长期验证。但它提醒了行业：复杂任务不一定只有“等待更强模型”这一条路。把现有模型组织得更细致、更稳定、更便宜，同样是一条值得投入的路径。