Fable 像帶著资深工程師的经理，早早交派、寫清楚規格、少親自动手；Opus 則像帶实習生的微觀管理者。本文源自 Joon Lee X 文章，用 3,000 场評測拆解背后的成本結構。 （前情提要：Anthropic 推出「Claude for Small Business」：瞄準中小企业 AI 自动化工作，幫你催发票、算薪水..） （背景補充：Anthropic 要求实名 KYC 验证！Claude 部分功能將需上傳身分证件，合規壓力擴大）
本文目錄
Toggle
我們把 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 主導的執行並排分析，檢視它們的軌跡，觀察钱花到哪裡去了。
以下是在我們的实验中，成本如何在主導模型与副手之间分配：
| | | --- | 主導 $ | 副手 $ | 每次總成本 $ | 主導每次回合數 | 主導输入 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 檔案。
让这个落差變得有趣的地方在於：两个主導模型委派的次數一樣多，每次執行大约 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 有效的委派实际上让整體成本下降了。它指明限制与結果，而不是把实作一步步寫死；它給出回饋，而不是自己动手修；而且在大多數情況下，它根本从未碰过程式碼。这些，都是一个好经理的習慣。
随著副手模型變得更便宜、更好，更多的工作可以交給它們。而未来仍值得付前沿价格的，將是判斷力：要做什麼、要限制什麼，以及該由誰来寫。
134.12万 热度
76.91万 热度
26.79万 热度
105.42万 热度
2914.84万 热度
如何让 Fable 比 Opus 更便宜：用委派改写 Agent 的成本结构
Fable 像帶著资深工程師的经理，早早交派、寫清楚規格、少親自动手；Opus 則像帶实習生的微觀管理者。本文源自 Joon Lee X 文章，用 3,000 场評測拆解背后的成本結構。
（前情提要：Anthropic 推出「Claude for Small Business」：瞄準中小企业 AI 自动化工作，幫你催发票、算薪水..）
（背景補充：Anthropic 要求实名 KYC 验证！Claude 部分功能將需上傳身分证件，合規壓力擴大）
本文目錄
Toggle
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 有效的委派实际上让整體成本下降了。它指明限制与結果，而不是把实作一步步寫死；它給出回饋，而不是自己动手修；而且在大多數情況下，它根本从未碰过程式碼。这些，都是一个好经理的習慣。
随著副手模型變得更便宜、更好，更多的工作可以交給它們。而未来仍值得付前沿价格的，將是判斷力：要做什麼、要限制什麼，以及該由誰来寫。