我们将 Opus 4.8 替换为 Fable 5，Devin 的账单反而降了。
Fable 5 每个 token 的成本是 Opus 4.8 的两倍。但当我们使用新的 Fusion 架构在 FrontierCode 1.1 上运行这两个模型时，Fable 的成本反而更低。意料之中，它的得分也更高。本文将解释原因，以及这对代理工作定价意味着什么。
引言
所有运行编码 Agent 的人都知道，更强的模型能带来更好的结果，但成本也会随之增加。
当我们推出 Devin Fusion 时，我们展示了一种出路：让一个前沿模型负责主导，将任务委托给一个更便宜、更快的副手，这样就能以降低 35% 的成本获得前沿级别的性能。
但一旦主导模型将大部分工作委托出去，它的每 token 价格还会主导账单吗？Fable 5 每 token 的成本是 Opus 4.8 的两倍，因此以 Fable 主导的 Agent 按理说应该更贵。为了验证这一点，我们在 FrontierCode 1.1 上运行了 3,000 次评估会话，共四种配置：Fable 和 Opus 分别担任主导角色，每种配置都分别搭配和不搭配同一个廉价副手。
纯模型运行的结果完全符合直觉：Fable 得分高于 Opus (60.8 vs 55.4)，且成本更高。模型更强，账单更大。
而启用副手的运行，情况变得有趣起来。
在相同的副手配置下，成本顺序发生了反转：Fable + 副手的成本低于 Opus + 副手（$1.86 vs $2.04），同时得分更高（60.7 vs 54.6）。 与纯 Fable 相比，Fable + 副手的成本降低了 54%，而得分几乎保持不变。
配置 | 得分 | 每次运行成本（平均） |
|---|---|---|
Fable 5 (低) + 副手 | 60.7 | $1.86 |
Opus 4.8 (中) + 副手 | 54.6 | $2.04 |
Fable 5 (低) | 60.8 | $4.03 |
Opus 4.8 (中) | 55.4 | $3.06 |
原来每 token 价格的两倍并不是应该关注的关键数字。Agent 的成本主要由主导模型执行的轮次数量、它拖拽的上下文量，以及最重要的是——它决定 不 亲自做的事情所决定。差异归根结底在于管理风格：Opus 像一个带着实习生的微观管理者；Fable 则像一个带着能干工程师的管理者。
实验设置
快速回顾一下 Fusion 的副手架构是如何工作的。主导 Agent 拥有会话的所有权：它与用户对话、制定计划、审查工作并提交代码。它还有一个持久的 副手 子 Agent 用于委派任务。主导 Agent 用自然语言编写一份交接简介，然后由副手（由一个更便宜的模型驱动）在自己的上下文中执行任务并向主导报告。主导审查结果并决定下一步行动。
为了弄清成本究竟花在了哪里，我们做了两件事。首先，我们解析了所有 3,000 次会话中的每一次 LLM 调用：哪个模型在说话、调用了什么工具、读写了多少 token、每次调用的成本是多少。其次，我们挑选了 40 个任务进行深入分析：包括那些 Fable 成本大幅低于 Opus 的任务、Opus 成本大幅低于 Fable 的任务，以及另外一组来自中间区域的随机样本。对于每个任务，我们并排分析了 Fable 主导的运行和 Opus 主导的运行，检查执行轨迹并观察资金流向。
Agent 的成本
以下是实验中主导模型与副手之间的成本分配情况：
主导 $ | 副手 $ | 总计 $/次运行 | 主导轮次/次运行 | 主导输入 token（累计） | |
|---|---|---|---|---|---|
Fable + 副手 | $1.28 | $0.58 | $1.86 | 11.5 | 545k tok |
Opus + 副手 | $1.73 | $0.31 | $2.04 | 26.5 | 1,679k tok |
Fable 在副手上的花费比 Opus 多 —— 每次运行多 $0.27。但它在 自身 上的花费少了 $0.45。Fable 的主导模型每次运行只执行 11.5 轮，而 Opus 是 26.5 轮；它输出的 token 是 Opus 的三分之一（6.1k vs 19.0k），输入的 token 也是三分之一。Fable 虽然每 token 显著更贵，但在上下文管理和轮次控制上胜出。
Fable 的 token 节省源于它直接避免了不必要的工作。有趣的是，在 81% 的 Fable 主导的运行中，主导模型从未亲自进行过任何代码编辑。对于 Opus，这一比例仅为 24%。在 13% 的 Fable 主导的运行中，主导模型甚至从未自己读取过仓库文件。
微观管理者带着实习生 vs 管理者带着工程师
以下数据揭示了差异的关键所在：两个主导模型委派的次数相同，每次运行约 3 次移交。每次调用的日志排除了“Fable 只是委派得更多”这个简单解释。真正的区别在于 何时 以及 委派什么。Fable 的第一次移交来得更早。Opus 常常在最后才进行移交，在此之前它会进行长时间的独立探索和实现；到那时，设计决策已经做出，重要文件已经加载到上下文中，昂贵的工作已经完成。
GIF
一个典型的 Fable 主导的运行流程是：先对仓库进行几次侦察操作，然后编写一份高度凝练的交接简介，将整个“实现 + 测试 + 代码检查”循环全部委派出去。接着通过一次 git show 来审查差异，最后提交代码。
而一个典型的 Opus 主导的运行则会经历 20–45 轮的独立探索、设计和实现，然后在最后进行一次委派，仅处理机械性的收尾工作。
有时 Fable 在会话中的 第一个动作 就是一次移交。面对同一个任务，两个主导模型的起始动作如下：
显而易见的修复办法是让 Opus 更多地委派探索工作，但强制这种行为往往会降低性能。判断一个调查任务是否安全到可以委派出去，或者是否必须亲自完成，这本身就是一个判断力问题。一个被强迫委派的模型并不能获得这种判断力；它只是委派了错误的事情。
两个模型的管理风格也体现在交接简介本身。当 Opus 委派实现任务时，它会下达指令，而 Fable 则编写一份设计文档：
委派不仅仅在转移成本；它还会改变工作的质量。上面的哈希任务就是一个鲜明的例子。任务要求哈希函数在指针长度上必须是 O(1) 复杂度。Opus 手动实现了它，但从未在任何地方记录这个要求。途中它忘记了约束条件，最终提交了一个线性时间的实现，得分为 25。相比之下，Fable 使用高层约束进行委派。它的简介中写道：“operator() 必须在指针长度上为 O(1)：禁止全 token 扫描。”副手成功实现了这一要求，得分为 94。
我们发现这种模式在任务中是普遍存在的。Fable 的交接中列举了约束条件、边界情况以及“完成”的定义，这既节省了自身的工作量，也让副手能够以低成本正确完成实现。
交接之后
另一部分是主导模型在接收到副手返回的工作后如何处理。两个主导模型通常会执行相同的廉价检查：两到三次 git diff/git show 调用。但 Opus 并不止步于此。它会将副手的文件拉回自己的上下文（频率是 Fable 的 2 倍），并以主导模型的价格进行 4 倍多的修正性编辑。在极端情况下，它会撤销副手的工作并亲自重写：
Opus 的不信任也并没有提高正确性。在某些评估任务中，Fable 仅通过对差异进行一次审查就发现了副手真正的 bug，并选择进行另一次廉价委派，而不是像 Opus 那样频繁地采用主导层级的重写。
当委派无济于事时
Fable 的委派策略并非普遍有效；当任务没有可以委派的组成部分时，它就会失效。以下几类任务似乎难以分解：
- 短任务：仅包含少量主导模型轮次，从决策到交付之间没有需要委派的内容。
- 串行调试任务：根本原因排查是一长串连续的判断过程。在此类任务中，累积的上下文本身就是工作。
值得注意的是，在这些任务上 Fable 几乎不进行委派。那些能写出优秀简介的判断力，也同样知道何时不该写简介。但当任务没有值得委派的内容时，委派对成本就没有任何杠杆作用。
在生产环境中，Fusion 在另一个层面处理这个问题：委派控制昂贵模型承担哪些工作，而路由则决定昂贵模型是否介入。
结语
我们开始这个实验时，预期的结果是测量 Fable 的两倍价格溢价会增加多少成本。但我们惊讶地发现，Fable 的高效委派实际上在总体上降低了成本。它通过明确约束和预期结果，而不是手把手地写出实现细节；它通过提供反馈而不是亲自修复；在大多数情况下它甚至从未碰过代码。这些正是一个优秀管理者的习惯。
随着副手模型越来越便宜、越来越强大，越来越多的工作可以交给它们来做。那么，真正值得前沿价格的就是判断力：决定做什么、设定什么约束、以及由谁来完成。
