Como tornar o Fable mais barato do que o Opus: reestruturar os custos do agente com reescrita por delegação

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 的成本，主要取決於主導模型走了多少回合、拖著多少上下文一起走，以及最重要的——它決定「não」自己做哪些事。差別歸結到管理風格：Opus 表現得像個帶著實習生的微觀管理者；Fable 則像個帶著能幹工程師的經理。

實驗設定

快速複習一下 Fusion 的副手架構如何運作。主導 agent 擁有整個工作階段：它和使用者對話、規劃、審查工作，並提交(commit)。它還有一個常駐的副手子 agent 用來委派任務。主導模型用白話寫下一份交接簡報，而由一個便宜得多的模型驅動的子 agent，在它自己的上下文裡執行，並回報結果。主導模型審查結果，決定接下來怎麼做。

為了找出成本流向哪裡，我們做了兩件事。第一，我們解析了全部 3,000 場工作階段裡的每一次 LLM 呼叫：是哪個模型在說話、它呼叫了什麼工具、讀寫了多少 token，以及每次呼叫花了多少錢。第二，我們挑了 40 個任務做更近距離的觀察：Fable 明顯更便宜的那些、Opus 明顯更便宜的那些，以及另一批來自中間地帶的隨機樣本。對每一個，我們把 Fable 主導的執行和 Opus 主導的執行並排分析，檢視它們的軌跡，觀察錢花到哪裡去了。

O custo de um agent

Abaixo está como o custo foi distribuído entre o modelo principal e o adjunto, na nossa experiência:

| | | --- | Modelo principal $ | Adjunto $ | Custo total por execução $ | Número de voltas do modelo principal | Tokens de entrada do modelo principal(acumulados) | | --- | --- | --- | --- | --- | | Fable + adjunto | $1.28 | $0.58 | $1.86 | 11.5 | 545k tok | | Opus + adjunto | $1.73 | $0.31 | $2.04 | 26.5 | 1，679k tok |

Fable gasta mais dinheiro no adjunto do que a Opus — mais $0.27 por execução. Mas gasta menos $0.45 no próprio modelo. A execução principal da Fable faz 11.5 voltas, contra 26.5 da Opus; os output tokens escritos são apenas um terço(6.1k vs 19.0k), e os input tokens consumidos também ficam em apenas um terço. Embora a Fable seja claramente mais cara por token, ganha em gestão de contexto e em número de voltas.

A economia de tokens da Fable vem de evitar simplesmente o trabalho. Curiosamente, em 81% das execuções lideradas pela Fable, o modelo principal não fez qualquer edição de código do início ao fim. Para a Opus, apenas 24% das execuções são assim. Em 13% das execuções lideradas pela Fable, o modelo principal sequer chegou a ler um ficheiro de qualquer repositório (repo).

Gestor de microgestão com estagiário vs gestor com engenheiro sénior

O que torna esta discrepância interessante é que os dois modelos principais delegam um número semelhante de vezes: cerca de 3 passagens de entrega por execução. Os logs de chamadas em sequência refutam a explicação simplista de que «a Fable delega só mais». A diferença real é o «quando» delegam e «o que» delegam. A primeira passagem de entrega da Fable chega muito cedo.

A Opus, pelo contrário, delega frequentemente muito tarde, após uma longa fase de exploração e implementação autónoma; nessa altura, as decisões de desenho já estão tomadas, os ficheiros importantes já entraram no seu contexto, e o trabalho caro já foi feito.

Uma execução típica liderada pela Fable começa por fazer algumas ações de reconhecimento no repo e, em seguida, escreve um brief ao nível de especificação, delegando de uma vez todo o ciclo «implementação + testes + lint». Depois vem um git show para rever o diff e, por fim, o commit.

Uma execução típica liderada pela Opus passa por 20 a 45 voltas de exploração, desenho e implementação autónomas, e ainda por uma passagem de entrega que só acontece muito tarde e que delega apenas um encerramento mecânico.

Às vezes, a primeira ação numa sessão de trabalho, por parte da Fable, é a própria entrega. Para a mesma tarefa, a abertura de dois modelos principais é assim:

A alteração óbvia seria forçar a Opus a delegar mais explorações, mas impor esse comportamento tende a piorar o desempenho. Saber quando uma investigação pode ser delegada com segurança e quando é algo que tens de fazer tu próprio é, por si só, um tipo de juízo. Um modelo forçado a delegar não desenvolve esse juízo; apenas delega coisas que não deveria.

O estilo de gestão de cada modelo também se revela no próprio brief de entrega. Quando a Opus delega implementação, dá instruções; a Fable, por sua vez, escreve um documento de desenho:

Delegar não serve apenas para redistribuir custos; também altera a qualidade do trabalho. A tarefa de hashing acima é um exemplo claro. A especificação da tarefa exige que uma função de hash seja O(1) em comprimento de pointer. A Opus implementa-a à mão, mas nunca escreve essa exigência em lugar algum. Em algum passo, ela esquece a restrição e entrega uma implementação com tempo linear, recebendo 25 pontos. Em contraste, a Fable delega com uma restrição de alto nível: o seu brief diz «operator() deve ser O(1) em comprimento de pointer: não fazer varrimento completo de tokens». O adjunto implementa com sucesso e obtém 94 pontos.

Constatámos que este padrão é transponível entre tarefas. As entregas da Fable enumeram várias restrições e casos-limite, e incluem uma definição do que significa «concluído»; assim, poupa esforço para si própria e permite que o adjunto execute a implementação de forma barata e correta.

Depois da entrega

A outra metade é o que o modelo principal faz com o resultado devolvido pelo adjunto. Ambos os modelos principais fazem frequentemente as mesmas verificações baratas: duas ou três chamadas a git diff / git show. Mas a Opus não fica por aí. Ela puxa os ficheiros do adjunto para o seu próprio contexto com uma frequência 2x maior e faz até 4x mais edições corretivas ao preço do modelo principal. No caso mais extremo, ela anula completamente o que o adjunto entregou, reescrevendo tudo à mão:

E a falta de confiança da Opus, por sua vez, não aumenta a correção. Em algumas tarefas de avaliação, a Fable captura um bug real do adjunto apenas numa única revisão de diff e decide fazer uma segunda entrega barata, em vez de apelar tão frequentemente a reescritas ao nível do modelo principal, como a Opus faz.

Quando delegar não ajuda

A estratégia de delegação da Fable não é universal; quando não há partes do trabalho que possam ser delegadas, ela falha. Estas categorias de tarefas parecem difíceis de decompor:

• Tarefas curtas que envolvem apenas poucas voltas do modelo principal, sem nada para delegar entre a «decisão» e a «entrega».
• Tarefas de debug sequenciais, cuja causa raiz é uma longa cadeia de julgamentos consecutivos. Aqui, o contexto acumulado por si só é o trabalho.

Note-se que, nestas tarefas, a Fable quase não delega. O mesmo tipo de juízo que consegue escrever bons briefs sabe também quando não deve escrever. Mas quando um trabalho não tem nada digno de ser delegado, delegar não tem onde «ganhar tracção» em termos de custo.

Em produção, o Fusion trata isto num outro nível: a delegação decide quais trabalhos ficam com o modelo caro, e o routing decide se o modelo caro deve ou não ser envolvido.

Conclusão

Quando começámos esta experiência, esperávamos medir quanto é que o sobrepreço de 2x da Fable aumentaria os custos. Ficámos surpreendidos ao descobrir que a delegação eficiente da Fable, na prática, diminuiu o custo total. Ela indica restrições e resultados, em vez de escrever a implementação passo a passo; dá feedback em vez de consertar ela própria; e na maioria dos casos, nem sequer toca no código. Tudo isto são hábitos de um bom gestor.

À medida que o modelo adjunto fica mais barato e melhor, mais trabalho pode ser entregue a eles. E o que ainda vale a pena pagar a preço de ponta será o juízo: o que fazer, que restrições impor e quem deve escrever.