Devin Fusion（8分钟阅读）

# Devin Fusion 来源：https://cognition.com/blog/devin-fusion ## Devin Fusion：前沿性能，成本降低 35% 作者：Cognition 团队 2026 年 6 月 29 日 工程团队正在烧钱。 在所有任务上使用最昂贵的模型已不可持续。但现有的模型混合工具表现糟糕。它们在大多数基准测试上表现不错，却无法写出你愿意合并的代码。 在 Cognition，我们专注于在前沿模型之间进行路由，同时不牺牲智能。今天，我们分享一种新型多模型框架的研究成果——**Devin Fusion**，它在混合模型方面表现显著更优，能够降低成本并在真实场景中保持智能。我们发现，它在 **FrontierCode**（一个衡量代码正确性和质量的最新先进编码基准）上，**以降低 35% 的成本，保持了前沿和 Fable 5 级别的性能**。 #### Devin Fusion：前沿性能，成本降低 35% FrontierCode Extended Benchmark 上的得分与每个任务的平均成本 | 成本 | 得分 | |------|------| | $3.00 | Fusion + Fable 5 | 57.6 | | $5.12 | Fable 5（中等） | 57.0 | | $3.24 | Opus 4.8（高） | 48.8 | | $2.38 | Fusion | 47.9 | | $3.64 | GPT-5.5（高） | 44.8 | | $2.70 | GLM-5.2 | 43.0 | 在本文的其余部分，我们将剖析良好的模型路由为何如此困难，以及使其生效的两种技术：**“副手”方法与动态会话内路由**。 欢迎你在 app.devin.ai/signup 预览 Devin Fusion。 ## 诀窍：副手 我们架构的关键思路是并行运行两个代理：一个使用前沿模型，另一个使用更经济的“副手”模型。两者都是完全具备能力的代理，拥有各自的工具集，并能独立收集和操作上下文。 副手架构：一个前沿主代理和一个小型副手代理并行运行，各自拥有缓存的上下文随着任务推进，主代理决定哪些任务交给副手，哪些亲自完成。然而，要让副手在实践中运作良好，需要深度调优交互模式。我们发现，主代理应尽量减少操作，只读取绝对必要的内容。默认情况下，它应当委派和监控，同时做出重大决策：规划、解读歧义、最终审查。 这种方法解决了更基础模型路由的主要问题： - **它保留了真实的前沿智能，而非“基准分数”智能。** 路由器经常过度拟合特定基准。通过在前沿模型中保留副手方法，系统能持续受益于前沿模型的创造力和通用智能。 - **它超越了单提示任务和问答场景的泛化。** 模型路由器通常为整个任务路由到单一模型。提示往往不包含足够信息来准确判断难度。此外，用户可能对简单的初始提示提出困难的后续问题。能够在智能模型和副手之间动态切换，使系统更加鲁棒。 - **它避免了模型间路由时代价高昂的缓存未命中。** 我们之前探索过“Smart Friend”工具，Anthropic 也发布了类似的“Advisor”工具。这两个想法的核心都是让一个模型拥有查询另一个模型以获取有用建议的工具。但问题是：每次调用另一个模型时，任务上下文不会以缓存方式共享，因此代价高昂。在副手设置中，主模型和副手模型都维护各自持久且已缓存的上下文。 当然，我们克服了许多实现细节才达到 Devin Fusion 的能力。例如，大多数缓存输入只有 5 分钟的有效期。我们鼓励读者思考如何绕过这个限制。我们很乐意交换笔记。 ### 副手随模型变得更智能而更好地扩展 近期模型，尤其是 Fable 5，在这些多代理设置中表现异常出色。Fable 能更智能地委派工作、更高效地请求上下文、并更精确地规划，所有这些都能在以极小智能影响的前提下带来更大的成本改进。这表明，随着基础模型变好，副手模式将变得更加有用。 在我们的测试中，Fusion 搭配 Fable 5 比纯 Fable 5 框架便宜 41%，而使用 Opus 和 GPT-5.5 级别模型时则为 35%。这个差距看似不大，但我们认为它低估了实际差异。非 Fable 的数据反映了 Devin Fusion 框架多轮调优的结果；Fable 5 的数据则未经过调优，因为在应用之前访问已中断。* ### 副手实际应用示例 为了更好地理解副手的工作原理，我们检查了在一组代表性 FrontierCode 任务上使用副手对成本和性能的影响。下面我们展示副手使用的良好和不良示例。 ## 动态会话内路由 有了副手工具，你仍然需要确保为任务选择合适的模型。我们根据任务类型和复杂度为主代理或副手选择不同的模型。然而，一开始选择了一个模型，后来发现另一个模型更合适，这可能很危险。同样，如果副手任务过于困难，你可能也想将任务从副手移回主代理。为了处理这些情况，我们在任务执行期间使用轻量级分类器，以提示何时需要切换到主代理或完全使用不同的模型。 我们希望在不同模型间切换时保持缓存效率，这需要一些巧妙的工程技巧。我们通过在上下文压缩期间切换模型来实现这一点，这无论如何都会触发缓存未命中。每次触发压缩时，我们都将其视为评估情况并切换负责模型的机会，从而有效地“免费”获得模型切换。注意，这意味着我们甚至可以“升级”副手模型而无需回到主模型，且没有额外的缓存代价。 为了说明，我们从内部开发中选择了一个使用 Devin Fusion 的任务。 ## 结果 我们对新框架进行了基准测试，包括和不包括使用 Fable 5* 的情况，发现两种配置都有令人振奋的改进。 在不包括 Fable 5 的情况下，我们的 Devin Fusion 多模型框架在 FrontierCode 上相比 GPT-5.5 和 Opus 4.8 等前沿模型**成本降低了 35%**，同时保持了与前沿模型匹配的性能。 Fable 5 在这个多模型框架中表现出色，**实现了 41% 的成本降低**，同时**保持了与 Fable 5 在传统代理框架中相同的性能**。虽然 Fable 目前还不是普遍可用的模型，但我们很高兴一旦恢复访问，就将 Fable 扩展到 Devin Fusion 的用户。 #### FrontierCode Extended 得分 vs 成本 （图表：横轴为每个 rollout 的平均成本（美元），纵轴为得分；包含 Fable 5*、Fusion + Fable 5*、Opus 4.8、Fusion、GPT-5.5、GLM 5.2 等数据点，呈现出成本与得分的分布关系。） \* 2026 年 6 月 12 日，根据美国政府指令，Fable 5 的访问被暂停（来源：anthropic.com/news/fable-mythos-access）。截至本文发表时，访问尚未恢复。使用 Fable 5 的结果基于暂停前的测量数据，以及当时内部版本的 Devin Fusion。 ### 合理性检查 我们着手构建一个不仅在基准测试上表现良好，而且在真实使用中也感觉不错的框架。我们在 Cognition 内部为一组用户启用了 Fusion，发现 **88% 他们合并的 PR 完全由自动化的 Fusion 路由器驱动**。 当然，我们最终希望将这个框架测试到比内部使用覆盖的更广泛任务上。这就是为什么我们非常兴奋地向云代理中的用户发布 Devin Fusion 的预览版。 ## 混合模型框架的重要性日益凸显 **一个模型包揽所有工作的时代即将结束。** 前沿智能的成本正在上升，在大小工程组织中已达到令人望而却步的水平。此外，现在有越来越多的模型选项，价格和智能水平各不相同，通过适当的提示，许多次前沿模型完全有能力完成大部分工程工作。你不会开着兰博基尼去杂货店，那又为什么要用一个能发现软件零日漏洞的模型去打磨一个按钮的圆角？ 此外，使用多模型框架可以让你**捕捉各前沿模型的相对优势**。例如，在 Cognition，我们发现某些模型特别擅长 UI 测试，而不同的模型则擅长识别 PR 中的复杂错误。此外，还有越来越多有能力的开源模型。这使得针对特定领域训练专门的智能变得更加容易。随着擅长特定语言、任务或库的模型不断涌现，投资多模型能力只会变得更加重要。 我们在此分享我们使用的技术，因为对于代理构建者来说，利用日益多样化的智能模型只会变得更加重要。我们才刚刚开始，而 Devin Fusion 只是这条路上的众多步骤之一。 我们希望你将它应用于真实任务，并告诉我们它在何处失效。在 app.devin.ai/signup 尝试它，如果你对我们的工作感兴趣，考虑与我们合作。