3,000 场评测显示：Fable 5 在 Fusion 架构下比 Opus 4.8 更省钱

Devin 团队表示，在 FrontierCode 1.1 上把 Opus 4.8 换成 Fable 5 后，账单不升反降。按每 token 计价，Fable 5 约是 Opus 4.8 的两倍，但在 Fusion 架构下同时运行两者时，Fable 的整体成本反而更低，得分也更高。

这篇内容源自 Joon Lee 在 X 发布的文章。团队称，他们围绕四种配置完成了 3,000 场评测工作阶段：Fable 与 Opus 分别担任主导模型，并各自在有无同一廉价副手模型的情况下执行，以拆解 agent 成本结构。

四种配置下的得分与成本

在不使用副手模型的纯执行模式下，结果与直觉一致：Fable 得分高于 Opus，但成本也更高。Fable 的得分为 60.8，Opus 为 55.4；平均每次执行成本分别为 4.03 美元和 3.06 美元。

真正出现变化的是加入副手模型之后。在相同副手条件下，成本排序发生反转：Fable + 副手的平均每次执行成本为 1.86 美元，低于 Opus + 副手的 2.04 美元；得分则分别为 60.7 和 54.6。与纯 Fable 执行相比，Fable + 副手把成本压低了 54%，分数几乎不变。

• Fable 5（low）+ 副手：得分 60.7，平均成本 1.86 美元
• Opus 4.8（medium）+ 副手：得分 54.6，平均成本 2.04 美元
• Fable 5（low）：得分 60.8，平均成本 4.03 美元
• Opus 4.8（medium）：得分 55.4，平均成本 3.06 美元

文章认为，仅看“每 token 贵两倍”会误判 agent 的总成本。真正决定账单的，是主导模型走了多少轮、携带了多少上下文，以及它决定不亲自处理哪些工作。

Fusion 架构如何分工

按照文中说明，Fusion 的副手架构中，主导 agent 负责整个工作阶段，包括与用户对话、规划任务、审查结果以及提交 commit。与此同时，系统会保留一个常驻副手子 agent 供其委派任务。主导模型以自然语言写出交接简报，再由一个成本更低的模型驱动子 agent，在自己的上下文中执行任务并返回结果，最后由主导模型审查并决定下一步动作。

为了追踪成本流向，团队做了两项分析。第一，他们解析了全部 3,000 场工作阶段中的每一次 LLM 调用，记录由哪个模型发起、调用了哪些工具、读写了多少 token，以及每次调用的成本。第二，他们额外挑选 40 个任务做近距离对比，覆盖 Fable 明显更便宜、Opus 明显更便宜，以及中间区间的随机样本，并将 Fable 主导执行与 Opus 主导执行逐一并排分析。

主导模型与副手各自花了多少钱

文章给出的拆分数据显示，在带副手的执行中，Fable 确实在副手部分花得更多，但它在主导模型自身上的开销下降得更明显。

按文中数据，Fable 每次执行在副手上比 Opus 多花 0.27 美元，但在自己身上少花 0.45 美元。Fable 的主导模型平均只走 11.5 个回合，Opus 为 26.5 个；Fable 写出的 output token 约为 Opus 的三分之一，文中列出的数字为 6.1k 对 19.0k，输入 token 规模也大致只有三分之一。

团队还提到，Fable 的 token 节省来自它主动避开部分工作。在 81% 的 Fable 主导执行中，主导模型从头到尾没有亲自做过任何一次代码编辑；Opus 的这一比例为 24%。另有 13% 的 Fable 主导执行里，主导模型甚至没有亲自读取任何 repo 文件。

两种管理方式：微观管理与提前交接

文章把两种主导模型的差异，概括为“带实习生的微观管理者”和“带资深工程师的经理”。团队称，两者委派次数其实相近，每次执行都大约发生 3 次交接，因此“Fable 只是委派更多”并不能解释成本差异。真正不同的是它们在何时委派、委派哪些内容。

按文中观察，Fable 往往很早就开始交接。典型的 Fable 主导执行会先对 repo 做几次侦察，然后写出一份接近规格文档级别的简报，把“实现 + 测试 + lint”的完整循环一次性交给副手完成，之后再通过一次 git show 审查 diff，最后提交。

相比之下，Opus 经常在较晚阶段才开始委派。在那之前，它会先独自完成长时间的探索、设计与实现，通常会经历 20 到 45 个回合；等到交接发生时，设计决策已基本确定，重要文件已经被装入上下文，较贵的工作也已经由主导模型自己做完。

文章还提到，有时 Fable 在一个工作阶段里的第一个动作就是交接。团队认为，表面上看可以通过强制 Opus 更早委派来修正这一点，但他们同时指出，强行施加这类行为通常会拉低表现，因为“什么时候可以安全委派、什么时候必须自己做”本身就是一种判断能力。

交接质量也会影响结果

在文章的描述中，Opus 在委派实现任务时更像是在下指令，Fable 则更像是在写设计文档。团队认为，委派不只是重新分配成本，也会改变工作的质量。

文中举了一个哈希任务的例子。该任务规格要求，哈希函数在指针长度上的复杂度必须是 O(1)。Opus 选择亲自实现，但没有把这项限制明确写出来，随后在某一步忘记了这一要求，最终交付了一个线性时间实现，得分为 25。Fable 则通过高层限制完成交接，简报中写明“operator() 在指针长度上必须是 O(1)：不得做完整的 token 扫描”，副手最终实现该要求，拿到 94 分。

团队表示，他们在多个任务上都观察到了相似模式。Fable 的交接内容通常会列出约束条件、边界情况，以及“完成”的判定标准，这既减少了主导模型自己下场处理的工作，也让副手更低成本地完成实现。

副手交回结果后，主导模型如何处理

文章称，两个主导模型在接收副手结果后，常常都会进行类似的廉价检查，例如两到三次 git diff 或 git show 调用。但 Opus 往往不会止步于此。

按照团队统计，Opus 把副手生成的文件重新拉回主导模型上下文的频率，是 Fable 的 2 倍；它再以主导模型价格进行修正性编辑的次数，最高可达 Fable 的 4 倍。文中提到，在最极端的案例里，Opus 甚至完全回滚副手的产出，再亲自重写一遍。

不过文章也指出，这种不信任并没有换来更高正确性。在一些评测任务里，Fable 只通过一次 diff 审查就定位出副手真正的 bug，然后选择再做一次廉价交接，而不是像 Opus 那样频繁诉诸主导模型级别的重写。

哪些任务里委派无法发挥作用

文中同时强调，Fable 的委派策略并不适用于所有任务。当任务没有可拆分、可委派的组成部分时，这套方法就失去效果。

团队列出了两类较难拆解的任务：

• 只包含少量主导模型回合的短任务。在“决定”与“交付”之间，没有足够内容可供委派。
• 串行调试任务。其根因追查依赖一连串连续判断，累积形成的上下文本身就是工作的一部分。

文章称，在这些任务上，Fable 几乎不会委派。这种能写出高质量简报的判断力，也同样会告诉模型什么时候不该写简报。若一个任务没有值得交接的内容，委派就无法对成本产生明显作用。

在正式生产环境中，Fusion 会在另一个层面处理这个问题：委派用于决定哪些工作留给昂贵模型，路由则决定昂贵模型是否需要参与。

实验结论指向“判断力”定价

团队表示，他们最初原本是想衡量 Fable 2 倍溢价会把成本推高多少，结果看到的是相反方向：有效委派让总体成本下降。按照文中的总结，Fable 更倾向于明确限制与结果，而不是逐步写死实现；它更常给出反馈，而不是亲自修改；而在多数情况下，它根本不会直接碰代码。

文章最后写道，随着副手模型变得更便宜、能力也更强，未来将有更多工作可以交给副手完成；仍然值得支付前沿模型价格的部分，将是“判断力”：决定做什么、约束什么，以及该由谁来写。