BotOf Tech — 技术与植物养护笔记

Fable 5 发布后，最容易被传播的是“state-of-the-art on nearly all tested benchmarks”这类结论。

这个结论有价值，但不够指导工程决策。对 Agent 产品来说，真正重要的不是它在一张静态榜单上高多少，而是它能不能在一个长任务里持续做四件事：理解目标、选择工具、吸收反馈、停止在正确的位置。

所以读 Fable 5 的评测，不能只看分数，要看它把哪些原本分离的能力合到了一条工作流里。

公开材料里值得看的三类信号

信号	表面含义	更深一层的含义
长任务案例	能连续工作更久	模型在多轮状态、局部失败和目标保持上有进步
视觉任务案例	能只看画面完成游戏	视觉输入、状态记忆和动作选择形成闭环
安全 fallback	高风险请求转 Opus 4.8	最强模型不再是单 endpoint，而是路由系统的一部分
高 token 价格	input 10 美元、output 50 美元每百万 token	评测必须把成本纳入结果，而不是只算成功率
项目级案例	Stripe、Wharton、IMC 这类真实任务	能力正在从问答变成生产过程压缩

公开案例里更值得关注的，不只是传统 benchmark，还包括大型代码迁移、视觉通关、研究工具开发、金融分析评估等任务。这些任务的共同点是：它们不是一轮输出，而是有环境、有反馈、有中间状态的过程。

传统模型评测通常像考试：给题目，拿答案，算分数。Agent 评测更像审计一个工作过程：它有没有读对上下文，有没有调用正确工具，有没有改错文件，有没有知道何时停手。

一个强模型如果在 SWE-bench 上得分高，但在真实仓库里不断误判测试边界，仍然不适合自动化生产。反过来，一个模型单题分数不一定极致，但如果能稳定形成调查、修改、验证、复盘的闭环，在工程场景里价值会更高。

这个图里的每个节点都应该进入评测。只看最后答案，相当于只看交付物，不看施工日志。

Fable 5 的重点在第三层到第五层。它不是简单“更会答题”，而是能把更多复杂任务放进可执行循环里。但越是这样，越要记录过程。否则你只知道它完成了任务，不知道是靠稳定能力、幸运路径，还是过度消耗 token。

如果要评 Fable 5 是否适合自己的产品，不建议照搬公开榜单。更实际的是做一组自己的长任务 benchmark。

一个合格的 Fable 5 内部评测，至少应该保存这些产物：

这套东西比“某模型赢了某榜单”更能说明生产价值。

Fable 5 公开版的一个核心设计，是在网络安全、生物化学、模型蒸馏等敏感方向触发拒绝或转向 Opus 4.8。这个机制不是旁枝，而是产品架构的一部分。

对开发者来说，问题不是“有没有 guardrail”，而是：

这也是为什么 Fable 5 的评测应该把“路由透明度”单独列出来。强模型时代，endpoint 背后可能是一组策略，不是一台模型。

Fable 5 的真正信号不是某个数字，而是评测对象变了。

过去评模型，像评一个答题者；现在评 Fable 5，要评一个执行系统。模型能力、工具链、上下文、路由、安全、成本和人工验收必须放在一起看。

如果团队只是想知道“它聪不聪明”，公开 benchmark 足够。如果团队想知道“它能不能进生产”，就必须搭自己的长任务评测闭环。

未来强模型的竞争，很可能不是单点分数，而是：谁能在更长任务里，以更低成本、更透明路由、更少人工补救，交付可复现结果。