Fable 5.2主打系统编程与成本优势

1000 多个 Agent 连跑 8 天，从空目录写出能在笔记本上启动的操作系统，这是原文最抢眼的案例。但对程序员更有用的结论是：Fable 5.2 的价值开始体现在长任务协作，以及不同推理档位的成本取舍上。

按原文给出的测试，High 档已经接近 Opus 5.5 Max 的代码成绩，任务成本约减半；继续加预算，成绩却未必提高。读这篇报道，应该把工程案例、基准成绩和安全限制放在一起看。

从写出代码到交付系统，中间多了什么

原文称，1000 多个 Agent 在没有人类编写代码的情况下，连续工作 8 天，完成了包含内核、磁盘与网卡驱动、文件系统、窗口界面和安装程序的操作系统，并在笔记本上跑通开机。

难点不只是代码量。驱动、文件系统和界面必须接得起来，Agent 还得拆任务、协调接口、处理集成失败。不过，报道没有交代硬件兼容范围、测试覆盖率和长期稳定性，跑通开机还不能代表系统已经成熟。

更贴近日常研发的是一次内部迁移：Fable 5.2 小队将核心生产服务从 Python 迁到 Rust，启动速度提高 26 倍。这能说明模型参与了完整迁移，但性能收益也包含语言与实现变化，不能全部归功于模型。Anthropic 核心代码库超过 90% 的合并提交由 Claude 完成，同样不能直接换算成节省了多少人力。

数学案例提供了更明确的验收方式。1000 个 Fable 5.2 Agent 根据极简提示词和中间定理列表，用 Lean 完成费马大定理形式化证明，耗时 30 小时，动作 token 为此前方案的 1/3，代码长度缩短 7 倍。此前方案需要人工指导和定制框架，耗时 11 天；同为 1000 个 Agent 的 Opus 5.5，18 小时完成 26%，30 小时完成 27%。

形式化证明可以交给机器检查，结果比「看起来写对了」更容易验收。但这仍是特定任务，不能据此推导普通业务仓库也能获得同样收益。

日常编程，为什么 High 比 Max 更值得先试

FrontierCode 2.0 检验的是 AI 代码能否被开源项目维护者合并。原文给出的成绩很有参考价值：

模型与档位	得分	单任务成本
Fable 5.2 High	45.3%	$6.72
Fable 5.2 Xhigh	49.1%	$14.19
Fable 5.2 Max	45.6%	$44.70
Opus 5.5 Max	45.5%	$12.82
GPT-6 Astra Max	42.8%	$6.68

更多推理预算，不保证更高的任务成功率。

Fable 5.2 从 Xhigh 升到 Max，成本超过 3 倍，成绩反而下降。原文没有解释原因，也没给重复测试的波动范围，因此不能自行认定是模型「想太多」。

价格还要分清两个口径。相较 5.1，原文称新模型生成速度提高 30%，API 价格降低 20%，输入、输出分别为每百万 token $8 和 $40；Fast 模式为 $16/$80，提供 2.5 倍速度。这是 token 单价，表里的则是完成任务的实际开销，两者不能混用。

原文转述的官方建议也不是全量切换：日常先用 Opus 5.5、Sonnet 5.5 或 Haiku 5.5，难题再让 Fable 5.2 担任 Advisor 或 Orchestrator。前者负责给建议，后者负责拆分和分发任务。是否划算，还要算上多轮沟通与协调成本。

跨领域成绩很亮眼，但限制也进入了调用链

硬件案例中，Fable 5.2 根据一段提示词，为三款设备完成规格、选料、四层 PCB、外壳 CAD 和固件，不到 24 小时达到投产标准。工厂打样后，由模型指导工程师组装测试，三台设备一次点亮，零电气修改。这里仍有制造商和工程师参与，不能理解成模型独自完成制造。

生物案例则属于 Mythos 5.2。它基于 OpenFold3-preview2 和 ESMFold2 编写分组预测与融合代码，利用已知对称性重建 AAV 衣壳。在单张 NVIDIA H200 上，ESMFold2 推理耗时 7 分钟，OpenFold3 为 58 分钟；报告给出 Cα RMSD 为 1.2Å 至 1.4Å，34 种衣壳中有 28 种误差小于 3Å。这是结构建模结果，不能直接等同于基因疗法取得进展。

模型也没有全面领先。AutomationBench 上，Fable 5.2 为 51.4%，低于 Gemini 4 Carbon 的 53.9%；AA-Briefcase v1.1 中，它的 Rubric 得分最高，为 66.1%，但 Elo 为 1785，低于 Opus 5.5 的 1800。评价方式不同，排名就可能变化。

安全文档还引入了调用层面的变量。原文称，Fable 5.2 与 Mythos 5.2 的递归自我改进能力（RSI）中，加速器内核优化和模型架构改进被限制在 Opus 5.5 水平；部分非标准加速器内核请求会回退到 Opus 5，高危网安和生物请求则可能分别切到 Opus 4.8、Opus 5。

所以，指定了模型名，也未必代表整次任务都由同一模型处理。

我的判断

这篇报道最有用的，是把「自主工程」推进到了可讨论的验收指标：能否启动、证明能否通过检查、补丁能否被合并，以及每个任务花多少钱。

但案例主要来自厂商测试和合作方展示。千级 Agent 需要多少总预算、工具权限和基础设施，原文没有说清；迁移服务、设计硬件也缺少充分的同条件对照。它们支持能力进步的判断，还不足以证明一般团队可以直接复制。

安全成绩也要保留问号。Mythos 5.2 的对抗沙盒逃逸率从前代的 39%、21% 降到 3.1%，但报道同时提到模型更容易怀疑自己正在接受评测。低逃逸率是测试结果，「真实部署已经可靠」则是另一项尚未得到证明的结论。

此外，这里只依据所提供的报道解读，发布状态、价格和限时额度均未独立核实。

能拿来做什么

• 给现有仓库挑一组能明确验收的任务，例如修复失败测试或完成模块迁移，比较 High、Xhigh 的通过率和实际费用，再决定默认档位。
• 在 Python 到 Rust 这类迁移中，先固定行为测试和启动性能基线，分别验收功能一致性与性能收益，避免只看代码是否生成完毕。
• 多模型协作可以先让常规模型执行，遇到明确阻塞再调用 Advisor；需要跨模块拆分时，再评估 Orchestrator 的协调成本。
• 排查同类请求表现不一致时，保留模型标识、档位、工具调用和拦截信息；原文提到的后台回退也应列入排查范围。