Fable 5.1 长任务怎么验收？跨仓库修改、失败恢复与费用
SandBase 用跨两个仓库升级账单客户端的示例，说明 Fable 5.1 长任务如何验收：兼容测试、工具超时后的检查、重试上限和实际完成一项任务的费用。
假设代码 Agent 跑了三个小时，告诉你“账单客户端升级完成”：客户端自己的测试通过了，另一个仓库的调用方却还在发送旧格式请求。这能算 Fable 5.1 做完了吗？不能，还要确认两边能一起工作。这篇 SandBase 文章面向准备验收代码修改的开发者，用这个假设任务说明要检查什么；它是评估设计，不是一轮已经完成的多小时实测。
先说结论
- Fable 5.1 面向多步骤编程和工具任务，但运行了几小时不等于任务完成。
- 客户端和调用方都要测试，不能为了通过而削弱原来的兼容性断言。
- 工具超时后，先确认写入是否完成，再决定是否重试。
- 比较费用时计入失败和重跑，不能只看缓存读取单价。
Anthropic 把 Fable 5.1 定位为适合运行数小时、跨越多个应用的模型，场景包括跨代码库改造、代码审查、浏览器操作和异步 Agent。版本变化与调用型号见 Claude Fable 5.1 介绍；本篇只回答更具体的问题：长任务必须交出哪些结果，你才能合并它的代码？
评估这次发布，应该看完整执行过程：
读取上下文 -> 规划 -> 修改 -> 测试 -> 检查 -> 恢复 -> 交付模型可能让这条链路更稳定，但链路本身仍然需要由你的系统设计来负责。
Anthropic 用不同推理档位展示了 Fable 5.1 的成绩与推理成本关系。
长任务为什么容易失败
长任务会放大小错误。第一轮计划漏掉一个约束，几轮之后就可能变成错误的文件修改；测试失败后，Agent 可能通过削弱断言来“修好”测试；工具超时可能被误判成写入成功；上下文压缩可能保留最新症状，却丢掉最初的验收标准。
Fable 5.1 的产品叙事正好针对这些问题。Anthropic 表示，它会尝试修复根因而不是症状，在步骤失败时恢复，并编写测试检查自己的工作。这些是有价值的行为倾向，但不是保证。生产 Agent 仍需要可观察状态和明确的停止条件。
给 Fable 5.1 配置工具、时限和验收规则
Harness 指管理模型工具调用、任务状态与测试的外围程序。可以为每个任务提供这样的配置示例：
{
"goal": "升级账单客户端",
"acceptance": ["测试通过", "保持 API 向后兼容"],
"budget": {"minutes": 45, "tool_calls": 80},
"artifacts": ["plan.md", "diff.patch", "test-report.json"]
}然后把五件事分开：
- 规划： 修改前必须先输出短计划。
- 变更： 只允许写入明确的工作区。
- 验证： 独立运行测试并检查生成物。
- 恢复： 把失败分类为代码、环境、工具或策略失败。
- 交付： 只有机器检查完验收标准后，才允许报告成功。
这样，“Agent 跑了三个小时”才会变成可审计的执行记录，也能让模型比较更公平：测量完成任务数、重试次数、工具调用和人工介入，而不是只比较一次提示词的输出观感。
发布案例真正展示了什么
GPU Kernel 案例说明，长任务的价值来自可执行验证，而不只是生成看起来正确的代码。
Anthropic 的客户案例值得注意，是因为它们描述的是完整流程。Millennium 表示，Fable 5.1 追踪了一次极罕见的崩溃，从 core dump（程序崩溃时保存的内存记录）一路查到外部供应商库；MongoDB 则表示，模型先研究大规模服务代码和文档，再给出可扩展设计，随后无人值守运行数小时，最后交付带证据的可视化演示。
这些是客户案例，不是独立复现实验。但它们说明了目标能力：跨阶段坚持、寻找外部证据，以及产出人类可以审阅的交接物。
你可以用类似结构做内部评估：加入隐藏回归、残缺文档、偶发工具故障，并要求最终提交报告。一个只能生成看似合理的补丁、却解释不了测试覆盖范围的模型，还不能算完成任务。
成本与延迟上升为系统问题
官方成本章节把缓存读取与其他 Token 分开计算，并分别给出普通任务和重度 Agent 任务的节省幅度。
长程 Agent 的花费不只在最终回答。上下文读取、重试、工具调用、截图、浏览器会话和评估器运行，都可能主导账单。Fable 5.1 的缓存读取价格是每百万 Token 0.25 美元，输入和输出分别为 10 美元与 50 美元；这些价格有参考价值，却不能单独预测一项任务的总成本。
至少应记录：每个验收通过任务的成本、从开始到结束的实际耗时中位数与第 95 百分位（P50/P95）、失败后重试次数、需要人工介入的运行比例，以及“报告成功”后发生回滚的比例。
真正应该比较的不是“每个 Token 哪个模型更便宜”，而是“哪个模型能以更少的总监督，把经过验证的变更送进生产”。
仍然需要哪些边界
不要因为 Agent 能处理错误，就给它无限制凭证。应使用短期 Token、隔离 checkout、网络白名单，以及针对部署和不可逆操作的审批闸门。还要记录工具的输入输出，让审阅者能在上下文压缩后重建执行过程。
如果实际执行工具是 Claude Code，可先按 Auto Mode 改回手动审批的步骤做一次临时文件演练，再交给它跨仓库任务。模型能力与工具的审批设置要分开检查。
同时要考虑安全路由。Anthropic 说明，大多数 Claude 应用会把被标记的网络安全与生物学请求转给其他 Claude 模型，直连 API 客户则需要配置 Fallback API（回退接口）。不能据此认定所有第三方接口都会自动重试。服务返回实际型号或回退信息时应一并记录；未返回时标记未知，不能只凭请求型号判断所有回答来自同一模型。
如果 Fable 5.1 确实让整条动作执行过程更可靠，它的工程价值就不在“一次回答更聪明”，而在“一个任务更可能完整交付”。下一步是给这项能力配上可检查的规划、失败、测试和交接机制。
与普通编码 Agent 的比较
| 工作流 | 短程编码助手 | Fable 5.1 式长程运行 | Harness 还需要补什么 |
|---|---|---|---|
| 小函数或解释 | 通常已经够用 | 往往没有必要 | 基础 lint 与单元测试 |
| 跨仓库改动 | 需要人频繁接管 | 面向更长的自主阶段 | 工作区快照与验收测试 |
| 罕见线上 Bug | 可能停在第一个合理原因 | 可以检查产物并继续追踪 | core dump、符号访问与证据日志 |
| 浏览器或多应用工作 | 需要手工衔接工具 | 可以协调多个应用 | 每个工具的权限与可重放记录 |
模型并不是每一行都自动更好。单文件修改通常更适合便宜、快速的模型；当上下文丢失、反复交接或漏掉根因的成本更高时，Fable 的额外推理投入才更有价值。
用一次跨仓库修改验收 Fable 5.1
下面是评估设计示例，不是已经完成的跑分。假设要升级账单客户端：调用方位于两个仓库，旧版接口仍需兼容。不要只要求“升级依赖并修好测试”，而应把旧接口样本、期望返回值和不可修改的测试先固定下来。
| 检查点 | 必须留下的结果 | 不能算通过的情况 |
|---|---|---|
| 修改前 | 两个仓库的提交号、现有失败测试、依赖版本 | 把原有失败算到新补丁头上 |
| 修改后 | 两侧补丁、旧接口兼容测试、构建退出码 | 只测试客户端，没有测试调用方 |
| 工具超时 | 原始错误、写入是否完成的检查结果 | 未确认状态就重复执行写入 |
| 交付时 | 在干净工作目录重新运行的命令与结果、未完成项 | 靠本机残留文件才通过，或修改断言掩盖错误 |
让候选模型使用相同工具、45 分钟时限和 80 次工具调用预算；这些数字只是示例，可按任务规模调整。达到上限仍未通过，就保存补丁与失败日志，交给人决定是否继续，而不是继续消耗到“看起来完成”。
如果要看已有运行记录，可先读同一道 3D 游戏题的 Astra 与 Fable 对比。它包含实际输出与费用，但只代表那组任务。通用的目标丢失原因另见代码 Agent 跑久了为什么会忘记目标，本篇重点是 Fable 长任务的验收方式。
FAQ
Fable 5.1 只是更贵的代码补全模型吗？
不是。它针对的是需要工具和验证的多阶段任务。不过对于小改动，额外能力未必值得增加的价格和延迟。
可以让它无人值守跑一夜吗？
只能在一次性或隔离工作区内，并配置短期凭证、网络限制、检查点以及部署审批闸门。“无人值守”应表示减少监督频率，而不是授予无限权限。
怎样和其他模型公平比较？
固定代码版本、提示词、工具列表、超时、采样设置和验收测试，同时报告首轮成功率、验收成功率、总 Token、重试、耗时和人工介入。Fable 直接回答与 Opus 回退回答必须分开记录。
工具失败后应该怎么做？
Agent 应分类失败、保留原始错误，只做有依据的最小修改，再运行相关检查。如果它无法区分环境失败和代码失败，就应该暂停并请求人工判断。
试跑前核对模型和账单
9 月 9 日核对的 SandBase Fable 5.1 模型页列出调用名 anthropic/claude-fable-5.1。开始前，在该页确认所选接口的请求格式。SandBase 提供模型接入；示例需要的代码仓库、浏览器、测试环境与部署权限，仍由你的程序提供。收到一条成功的 API 响应，不等于这些测试已经运行过。
把官方价格与实际账单分开记录。缓存读取为 0.25 美元/百万 Token，并不表示每个任务都省 75%；新输入、输出、缓存写入、工具费用和失败重跑都需要计算。接入服务未返回内部回退型号时，标记“未披露”，不要凭回答风格猜测。
来源（2026 年 9 月 9 日核对）：Claude Fable 产品页、Fable 5.1 / Mythos 5.1 发布页及客户证言、SandBase Fable 调用入口。本次补清评估场景和 API 的职责，没有新增长任务跑分。
