Cómo hacer que Fable sea más barato que Opus: reescribir la estructura de costos de agentes con delegación

Fable 像带着资深工程师的经理，早早交派、写清楚规格、少亲自动手；Opus 则像带实习生的微观管理者。本文源自 Joon Lee X 文章，用 3,000 场评测拆解背后的成本结构。
（前情提要：Anthropic 推出「Claude for Small Business」：瞄准中小企业 AI 自动化工作，帮你催发票、算薪水..）
（背景补充：Anthropic 要求实名 KYC 验证！Claude 部分功能将需上传身份证件，合规压力扩大）

本文目录

Toggle

• 引言
• 实验设置
• 一个 agent 的成本
• 带实习生的微观管理者 vs 带资深工程师的经理
• 交接之后
• 当委派帮不上忙时
• 结语

我们把 Opus 4.8 换成 Fable 5，而 Devin 的账单反而降低了。

Fable 5 每 token 的成本是 Opus 4.8 的两倍。但当我们用全新的 Fusion 架构，在 FrontierCode 1.1 上同时跑这两个模型时，Fable 反而更便宜。不意外地，它的分数也更高。这篇文章会解释为什么，以及这对「为 agentic 工作定价」意味着什么。

引言

每个跑程序 agent 的人都知道，更强的模型会给你更好的结果，但你得吞下成本。

当我们推出 Devin Fusion 时，我们展示了一条出路：让一个前沿模型坐镇指挥，让它把工作委派给一个更便宜、更快的副手，于是你能以低 35% 的成本，获得前沿等级的表现。

但一旦主导模型把大部分工作都委派出去，它每 token 的单价还会主宰整张账单吗?Fable 5 每 token 的成本比 Opus 4.8 贵两倍，所以由 Fable 主导的 agent 按理说应该更贵。为了找出答案，我们在 FrontierCode 1.1 上跑了 3,000 场评测工作阶段，横跨四种配置：Fable 与 Opus 各自坐上主导席，并各自在「有」与「没有」同一个便宜副手的情况下执行。

纯粹的执行(pure runs)表现完全如直觉所料：Fable 的分数胜过 Opus(60.8 对 55.4)，成本也更高。更好的模型，更大的账单。

有副手加持的执行，才是事情变得有趣的地方。

在给定同一个副手的情况下，成本排序反转了：Fable + 副手比 Opus + 副手更便宜($1.86 对 $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 的成本，主要取决于主导模型走了多少回合、拖着多少上下文一起走，以及最重要的——它决定「不」自己做哪些事。差别归结到管理风格：Opus 表现得像个带着实习生的微观管理者；Fable 则像个带着能干工程师的经理。

实验设置

快速复习一下 Fusion 的副手架构如何运作。主导 agent 拥有整个工作阶段：它和使用者对话、规划、审查工作，并提交(commit)。它还有一个常驻的副手子 agent 用来委派任务。主导模型用白话写下一份交接简报，而由一个便宜得多的模型驱动的子 agent，在它自己的上下文里执行，并回报结果。主导模型审查结果，决定接下来怎么做。

为了找出成本流向哪里，我们做了两件事。第一，我们解析了全部 3,000 场工作阶段里的每一次 LLM 调用：哪个模型在说话、它调用了什么工具、读写了多少 token，以及每次调用花了多少钱。第二，我们挑了 40 个任务做更近距离的观察：Fable 明显更便宜的那些、Opus 明显更便宜的那些，以及另一批来自中间地带的随机样本。对每一个，我们把 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 个；写出的 output token 只有三分之一(6.1k 对 19.0k)，消耗的 input token 也只有三分之一。Fable 每 token 明显更贵，却在上下文管理和回合数上胜出。

Fable 的 token 节省，来自于它干脆地避开了工作。有趣的是，在 81% 由 Fable 主导的执行里，主导模型从头到尾没有做过任何一次代码编辑。对 Opus 来说，只有 24% 的执行是如此。在 13% 由 Fable 主导的执行里，主导模型甚至从未亲自读取过任何一个 repo 文件。

带实习生的微观管理者 vs 带资深工程师的经理

让这个落差变得有趣的地方在于：两个主导模型委派的次数一样多，每次执行大约 3 次交接。逐次调用的日志，推翻了「Fable 只是单纯委派得比较多」这个简单解释。真正不同的，是它们「何时」委派、「委派什么」。Fable 的第一次交接来得很早。

Opus 则常常很晚才委派，在一长段独自探索与实现之后；到那时，设计决策都已做完、重要文件都已进了它的上下文，昂贵的工作也已经做完了。

一场典型的、由 Fable 主导的执行，会先对 repo 做几个侦察动作，然后写一份规格等级的简报，把整个「实现 + 测试 + lint」的循环一次委派出去。接着一個 git show 来审查 diff，然后提交。

一场典型的、由 Opus 主导的执行，则会历经 20 到 45 个回合的独自探索、设计与实现，再加上一次很晚才发生、只交派机械性收尾工作的交接。

有时候，Fable 在一个工作阶段里的第一个动作就是交接。在同一个任务上，两个主导模型的开场是这样的：

显而易见的修法，是强迫 Opus 多委派一些探索，但强加这种行为往往会降低表现。知道一项调查什么时候可以安全地交派出去、什么时候是你必须亲自做的，这本身就是一种判断。一个被胁迫着去委派的模型，并不会因此获得那种判断力；它只会把不该委派的东西委派出去。

每个模型的管理风格，也在交接简报本身里显露无遗。当 Opus 委派实现时，它是在下指令；而 Fable 则是在写一份设计文件：

委派不只是把成本挪来挪去；它也改变了工作的质量。上面那个哈希(hashing)任务就是个鲜明的例子。任务规格要求一个哈希函数在指标(pointer)长度上必须是 O(1)。Opus 亲手实现它，却从没把这条要求写在任何地方。过程中某一步，它忘了这条限制，交出了一個线性时间的实现，得分 25。相对地，Fable 用高层次的限制来委派。它的简报写着：「operator() 在指标长度上必须是 O(1)：不得做完整的 token 扫描。」副手成功地实现了它，拿下 94 分。

我们发现这个模式在各个任务间都能通用。Fable 的交接会列举出各种限制、边界情况，以及一份「何谓完成」的定义，既替自己省下力气，又让副手能便宜且正确地完成实现。

交接之后

另一半，是主导 agent 拿副手交回来的成果做了什么。两个主导模型常常都会跑同样的便宜检查：两三次 git diff / git show 调用。但 Opus 不会停在那里。它把副手的文件拉回自己的上下文的频率高出 2 倍，并以主导模型的价格做出多达 4 倍的修正性编辑。在最极端的情况下，它把副手的成果整个还原，亲手重写了一遍：

而 Opus 的不信任，也并没有让正确性提高。在某些评测任务里，Fable 单单一次的 diff 审查就抓到了副手真正的 bug，并选择再做一次便宜的交接，而不是 Opus 那么常诉诸的、主导模型等级的重写。

当委派帮不上忙时

Fable 的委派策略并非放诸四海皆有用；当任务没有可委派的组成部分时，它就会失效。以下这些类型的任务，似乎很难被拆解：

• 只包含少数几个主导模型回合的短任务，在「决定」与「交付」之间没有东西可以委派。
• 序列式的调试任务，其根因追查是一长串连续的判断。在这里，累计起来的上下文本身就是工作。

值得注意的是，在这些任务上，Fable 几乎完全不委派。那份能写出好简报的判断力，同样也知道什么时候不该写。但当一个任务没有任何值得交派的东西时，委派对成本就毫无施力点。

在正式生产环境里，Fusion 会在另一个层次处理这件事：委派决定哪些工作留在昂贵的模型手上，而路由(routing)则决定昂贵的模型到底要不要被牵涉进来。

结语

我们开始这个实验时，原本预期要衡量的是 Fable 那 2 倍的溢价会让成本增加多少。结果我们很惊讶地发现，Fable 有效的委派实际上让整体成本下降了。它指明限制与结果，而不是把实现一步步写死；它给出反馈，而不是自己动手修；而且在大多数情况下，它根本从未碰过代码。这些，都是一个好经理的习惯。

随着副手模型变得更便宜、更好，更多的工作可以交给它们。而未来仍值得付前沿价格的，将是判断力：要做什么、要限制什么，以及该由谁来写。