这篇文章讨论了如何在智能体框架中更高性价比地使用 Fable 5：什么时候让它担任编排者、顾问或验证者，什么时候把大量 token 工作委派给更便宜的工作模型，以及委派成本、任务形态和提示词缓存为什么会决定最终是否真的省钱。
原文来源：https://x.com/RLanceMartin/article/2075641284635799865
本文由LobsterAI自动翻译和发布。
人们对如何高性价比地使用 Fable 5 非常感兴趣。智能体框架会越来越擅长判断：究竟应该在什么时候调用前沿智能模型。
我想分享一些自己做过的测试，以便更深入地理解应该在什么情况下、以什么方式使用 Fable 5。
任务的形态
很多任务在不同 token 阶段所需要的智能水平并不对称。智能体框架可以识别这种差异，然后决定什么时候使用 Fable 5。
目前已经出现了几种模式，未来很可能还会出现更多：
- 将 Fable 5 用作编排者，把任务委派给成本更低的工作模型。
- 将 Fable 5 用作顾问，让成本更低的执行模型在需要时向它请教。
- 将 Fable 5 用作验证者，检查其他模型完成的工作，例如放在
/goal或 Outcomes 循环中。
例如，@mitchellh 提到过一种“编排者—验证者”方案：
我让 Fable xhigh 充当规划者和架构师，让 GPT 5.5 xhigh（订阅版）负责编码，然后再让 Fable xhigh 充当评审。
按照 API 定价计算，规划和评审的成本大概只有几美元，而一次典型的、完全由 Fable 完成的往返通常要花费 50 美元以上。
我也见过有人使用更笨、更便宜的编码模型，但即使开启 xhigh，GPT 5.5 与 Fable 5 相比仍然非常便宜、非常快。而且 GPT 5.5 确实……真的很强。
这种方案重新流行还不到 24 小时，所以它能否长期有效仍不确定，但到目前为止表现一直非常好。
我在 Parameter Golf 上研究了这种方案。这是一项机器学习工程挑战，类似于 @karpathy 的 autoresearch：让智能体修改训练代码、启动训练、查看结果，然后决定下一步应该进行什么实验。
目标是在 8 张 H100 GPU 上、不到 10 分钟的时间内，训练出能够塞进一个 16MB 制品中的最佳模型。
我之前已经证明，Fable 5 很擅长完成这类任务。因此，我想看看能否只让 Fable 5 负责实验设计，再让 Sonnet 5 作为工作模型，承担实现过程中产生的大量 token。
我使用 Claude Managed Agents 搭建了这个系统。它可以访问一个托管在 Modal 上、配备 8 张 H100 的自建沙箱，并包含一个能够调用 Fable 5 的 Sonnet 5 执行器。
我要求 Sonnet 5：
- 在制定初始计划时向 Fable 5 咨询。
- 在总共 20 次实验的执行过程中，再选择两个检查点向 Fable 5 咨询。
下面的结果展示了三种配置下的验证损失，以“每字节比特数”衡量，数值越低越好。
Fable 5 与 Sonnet 5 组合完成的改进幅度，达到了 Fable 5 单独执行时的约 90%，但 token 成本只有后者的约 34%。
事前咨询并不是主要收益来源。事实上，Fable 5 最初给出的方案排名与最终真正有效的结果呈负相关。
真正的价值来自执行过程中的咨询检查点。
Sonnet 5 很容易陷入局部爬坡：持续追逐微小收益，却不会主动后退一步，对所有方向重新排序。Fable 5 在检查点提供的建议，则可以纠正方向并重新排列优先级。
在这个案例中，重要的是判断力在整个任务中的分布方式。
仅仅在开始时制定计划还不够；在任务执行过程中，于固定节点插入 Fable 5 作为顾问，更有助于把任务引导到前景更好的方向。
事后来看，这与任务本身的形态完全吻合：这类实验具有探索性，每一次实验结果都会改变下一步最值得尝试的方向。因此，判断力必须分散在整个执行过程中，而不能全部集中在任务开始之前。
委派的成本
即使一个任务确实存在可以被智能体框架利用的“智能需求不对称”，把任务卸载给其他模型也不一定划算。
有时候我们宁愿亲自完成某项工作，就是因为委派本身存在协调成本。
@brada 和我在使用 BrowseComp 测试 Fable 5 时就观察到了这一点。
BrowseComp 是一项多约束网页搜索评测。它非常适合让 Fable 5 负责规划并把任务委派给 Sonnet 5 工作模型，由后者搜索、打开页面、进行交叉核对，直到所有约束共同锁定唯一答案。
在 BrowseComp200 这个较简单的子集上，每道题大约需要阅读 37 万个 token。结果表明，单独使用 Fable 5，反而比混合使用 Fable 5 和 Sonnet 5 更便宜。
编排机制使成本增加了 60%，性能却没有得到任何提升。
但在完整的 BrowseComp 评测集上，每道题大约需要阅读 3100 万个 token，此时编排就开始产生收益：
- Fable 5 充当编排者。
- Sonnet 5 充当工作模型。
- 最终取得了 Fable 5 单独执行时 96% 的成绩。
- 成本只有后者的 46%。
通过把任务委派给工作模型而获得的 token 成本套利，必须足以抵消由此产生的协调成本。
在这个案例中，协调成本主要包括：
- 边界重复：模型之间每传递一个 token，至少会被计费两次。主模型写出任务说明，工作模型要读取它；工作模型写出报告，主模型又要读取它。
- 并行重叠：在很多智能体框架中，不同工作模型之间不会相互沟通，因此它们的研究内容经常出现部分重叠。@walden_yan 去年写过一篇很好的文章讨论这个问题。
这意味着，使用廉价工作模型获得的成本收益，必须抵消每次交接都会产生、且大致固定的协调成本。
在这个案例中，工作模型带来的收益会随着每个工作模型所吸收的 token 数量一起增长。任务体量越大，委派越容易变得划算。
高性价比的智能体框架
下面是我在让 Fable 5 为不同任务编写高性价比智能体框架时，经常提供给它的指导原则。
只要提供其中一些指导，Fable 5 就很擅长理解应该在何时、以什么方式使用自己的智能。
分析任务形态。
评估任务各个阶段需要什么水平的智能。
如果判断力需要分散在整个任务过程中，就像 Parameter Golf 一样，可以采用“廉价执行器 + Fable 5 顾问”的组合。
如果判断力主要集中在任务开始前，或者主要用于检查最终结果，则更适合让 Fable 5 充当编排者或验证者。
使用委派启发式规则。
有时我们可以预先向 Claude 提供有关工作模型委派的先验信息。
@theo 在这个例子中，按照“品味”和“智能水平”对不同模型进行了排名。
这些信息能够帮助智能体框架判断应该在什么时候引入哪一个模型。
评估协调成本。
委派本身是有成本的。
正如我在 BrowseComp 测试中观察到的，必须确保被委派出去的 token 数量足够大，能够抵消协调成本。
Fable 5 的单 token 价格虽然更高，但它可能比价格更低的模型具有更高的 token 效率。因此，不能只根据每 token 的美元价格判断委派是否划算。
确保正确使用提示词缓存。
每个模型都会维护自己的提示词缓存，而错误地处理这一点，很容易让委派成本彻底失控。
正如 Cognition 在这里指出的，子智能体应当在多次调用之间持续维护自己的提示词缓存。
后续请求应该被路由到同一个工作模型实例，让它的缓存不断积累，而不是每次请求都启动一个全新的工作模型，并反复为上下文写入付费。
在我的实验中，Claude Managed Agents 的子智能体原生支持这种机制。
但我也见过一些案例：由于提示词缓存命中率太低，最终完全抵消了使用低价工作模型所获得的成本优势。
正如 @trq212 在这里分享的，Claude 可以根据当前任务，即时编写自己的智能体框架。
本文讨论的这些因素，可以帮助 Claude 构建更具成本效益的智能体框架，只在真正需要的阶段选择性地调用前沿智能。