Fable 5.1 实战：Theo 谈成本、代理工作流与 PR 质量

Fable 5.1 来了，经过一天的高强度使用，我印象深刻。它相比 Fable 5 有明显进步，不过价格和遵循指令的表现都有细节需要注意。我的团队在使用它的 24 小时内合并了 89 个 PR；这段经历影响了我的评价，但并非受控基准测试。

Anthropic 表示，Claude Fable 5.1 和 Mythos 5.1 是同一个底层模型，只是安全防护不同。Fable 普遍开放，Mythos 则限于可信访问计划，用于包括网络安全和生命科学在内的工作。我也发现新模型的回答更易读，少了一些套话和技术黑话。

发布时，Anthropic 估计按 token 计费的典型工作负载比 Fable 5 便宜 25%，高度代理化的工作最高可节省 45%，主要因为缓存读取价格下降了 75%。标准价格仍是每百万输入 token 10 美元、每百万输出 token 50 美元，缓存读取为每百万 0.25 美元。这些是发布时的数字；实际成本取决于用量，价格也可能变化。

代理反复调用工具时，缓存很重要。每次工具结果都会带着之前的上下文继续对话，缓存前缀可以避免每次都按全价重新处理所有输入。在我的一份用量统计中，大部分输入 token 都是缓存读取，但这不意味着每次重复读取都是新的文本。

缓存写入是另一项费用。画面中的例子里，它占估算账单近 60%，约为 1963 美元中的 1171 美元；缓存读取约 264 美元，输出约 523 美元。我的订阅用量并不等同于实际支付这笔 API 账单。对于工具调用很少、默认缓存仅持续五分钟的短对话，节省情况可能完全不同。

Anthropic 还介绍了 Enterprise Frontier Safeguards，旨在让数据保留在客户控制的基础设施中，同时应用安全检查。可用范围和条款取决于具体企业产品。公司称误报减少了 60%；我自己的高强度使用中只遇到一次安全防护标记。两者都不能证明误报或安全风险已经消失。

在 Terminal-Bench Science 和终端编程测试中，发布图表显示新模型在多个推理强度下比前代得分更高。图表也显示 Fable 和 Mythos 有差距；Anthropic 将其归因于 Fable 的安全防护有时会回退到 Opus。底层模型相同，并不意味着系统在每项评估中的行为都完全一致。

Cursor 的编码基准也报告了展示的运行中更高的分数和更低的成本。我注意到，高推理强度往往是有用的设置，而继续提高不一定能带来成比例的改善。Fable 5.1 可能比前代生成更多输出，因此 token 效率和工作成果是否有用都很重要。

Anthropic 展示了蛋白质结合体设计、利用金星雷达数据制图，以及计算生物学内核优化等科学案例。报告的结果是研究辅助的积极例子，并不能证明模型独立解决了医学问题。公司安全评估也报告多个指标的行为有所改善，但结论适用于它所描述的测试。

对话历史的一项变化会影响基于 API 构建产品的开发者：Anthropic 将仅追加历史作为反蒸馏措施的一部分。编辑先前上下文可能影响对话续接和保留的推理，因此有分支历史的客户端可能需要调整。视频讨论的开放过程是逐步进行的，具体规则具有时效性。

Artificial Analysis 报告称，新模型在其指数上得分更高，但在该评估中，Fable 5.1 的最高推理强度每项任务成本约为 3.76 美元，比 Fable 5 高约 20%，部分原因是生成了更多输出。经常重复使用缓存上下文时，缓存读取降价可以省钱；这不保证每项基准或工作负载都变便宜。

我还比较了物理推理基准和一项惩罚自信错误回答的测量。一个图表中 Sol 领先，另一个图表中 Anthropic 模型表现更好。我认为实验室可能重视不同的行为，但这只是解读，不能证明它们的训练目标，也不是对分数差异的因果解释。

在前端设计方面，Which-AI 使用 Anthropic 设计 skill 的例子展示了动画和独特落地页，我比 Fable 5 的版本更喜欢它们。在这些例子中，设计 skill 帮助很大。我自己还没有用新模型做大量前端工作，因此把这些看作演示，而不是完整评估。

我重建的 2D Fish Slop 中，鱼转向时会倾斜，潜艇后面有气泡轨迹，不同动作也有不同声音。一些素材来自早期版本，但模型很好地使用了它们。让我印象深刻的是移动和动画曲线结合起来后，整体体验更协调。

3D 版本用 Blender 制作了部分模型，生成了可以辨认的鱼、珊瑚和岩石。我喜欢移动手感和鼠标加速度，不过有些控制方式与预期不同，怪物也没有完整动画。不同模型产生的效果相似，让我猜测它们可能使用了相似数据，但这只是猜测。

Anthropic 的提示指南建议从高推理强度开始，再用自己的评估测试其他设置。低和中等强度已经帮我完成很多任务，但可能漏掉隐蔽的复杂问题；更高强度也不能保证不出错。我还建议重新检查旧指令文件，移除不再符合模型行为的规则，再按需要加回。

一个有文档说明的变化是，模型在长时间调用工具期间默认提供更少进度更新。我曾尝试让它修复损坏的音频，虽然没有成功，却看到它运行超过 24 分钟、调用工具 60 多次，中间有很长时间没有文字更新。如果你需要更新，指南建议直接提出，并移除旧的压制更新的指令。

指南还讨论了更紧密的行文、更少的默认项目符号和粗体，以及可能未标注引用就复述来源段落的问题。必要时可以给出明确的写作指令和示例。它也建议给自主任务设定清晰终点、说明上下文压缩应保留什么，并在模型增加无关修改或测试时明确限制范围。

在实际工作中，我让模型审查 T3 Code 如何把 PR 关联到线程。它的第一份报告错误地说没有任何自动关联；我指出分支查找提供了我所说的行为后，它承认了这个区别。这个例子说明，即使代理很有用，也需要检查并澄清它的说法。

对于停滞的 PR，我使用一条接手机制：在 worktree 中检出分支，并负责把修改推进到可合并状态。Fable 5.1 接手后，几个此前陷入重复审查循环的修改最终合并，包括 skill 选择和流式处理方面的工作。这是我对这些任务的体验，并不证明每次接手都会成功。

我让它审查 Lakebed 中杂乱的代码，检查它提出的顺序后，再让子代理并行清理。因为项目不会自动部署到生产环境，我允许简单修改直接合并。它报告合并了十个 PR，检查通过，并在 340 个文件中净减少约 1.3 万行。自动审查和 CI 是有用的信号，但不能证明修改没有缺陷。

第二次质量审查带来了更多并行 PR，由另一个代理监控并合并。我没有逐行阅读，但确实通过基准测试检查了结果；在一些困难场景中，我观察到 85% 至 90% 的性能改善。这些测量针对我的项目和选定场景，并非模型带来的普遍加速。

模型还帮我在 T3 Code 中找出值得审查和合并的贡献者 PR。我越来越常让它合并自己认为准备好的修改，尤其是范围明确的修复，同时也认识到这有风险，将来可能出现坏结果。这是在我的项目工作流下做出的个人选择，并不是建议所有团队取消人工监督。

为了比较模型，我请它分析 T3 Code 和 Lakebed 的 PR：将 Fable 5.1 的前 24 小时与 Fable 5、Sol 所选的高活跃日比较。这些组的任务、审查条件和人工参与程度不同，因此观察性比较不能证明因果关系，也不能给出普遍排名。

报告显示 Fable 5.1 组有 13 个 PR，中位数为新增 489 行，涉及 11 个文件和四个包。报告称，每千行代码中，审查机器人给 Fable 5.1 留下 0.4 个高严重度问题，Fable 5 为 2.06，Sol 为 1.02。机器人发现的问题只是有限的质量信号，样本少且经过选择，直接比较有不确定性。

展示的报告给出 PR 提交到合并的中位时间：Fable 5.1 约 50 分钟，Fable 5 约 47 分钟，Sol 约 30 分钟。我还讨论了所选样本中更少的后续提交。这些数字对应不同任务和工作流；合并更快或修改行数更多，本身都不能证明软件更好。

我感受到的变化，是可以委托的工作层级越来越高。我从自动补全，发展到指定已知文件让代理编辑，再到审查 PR、让代理寻找和审查候选 PR，如今有时还让它修复并合并范围明确的修改。更强的代理也可能消耗更多额度，因为我让它做更多事情、协调更多子代理。

对我来说，Fable 5.1 是一次有意义的进步，让我能把更多时间放在更高层次的决策上。这不能证明模型的每个输出都正确，也不意味着所有团队都应该采用相同的自主程度。我对这次更新很兴奋，也想继续测试它的长处和局限。