Claude Fable 5.1 长任务怎么跑？Agent 工作流设计与提示词实践指南

用 Claude Fable 5.1 跑长任务的人，大概率撞上过三件事：任务跑到一半，模型停下来问“要我继续吗”；agent 跑了两小时突然没声音，分不清是卡死还是在干活；任务总算跑完，账单比预期翻了一倍。这三个问题分别对应提示词写法、进度可见性机制和成本组织方式，官方在 5.1 的文档里都给了明确解法，只是散落在提示词指南、工具说明和定价页好几处。本文把它们串成一条可执行的路径，按两个典型场景展开：大型代码库迁移/重构（详写），多步骤研究与知识工作（简写）。文中提示词写法均按官方文档整理，关键指令附原文，价格口径为 2026 年 9 月 2 日查询的官方信息。顺带一句：同日发布的 Claude Mythos 5.1 目前仅限 Project Glasswing 邀请制，本文不涉及。

跑长任务前，先确认 Fable 5.1 适不适合你的活

官方对 Fable 5.1 的定位是 demanding reasoning 和长程 agentic 工作，并明确建议多数负载从 Opus 5 起步，Opus 5 开到高 effort 仍不达标时再上 Fable 5.1。如果你的任务是几分钟内能完成的问答或单文件小改动，用 5.1 跑长任务编排是浪费。

与长任务直接相关的规格：1M 上下文、128K 输出、adaptive thinking 常开、默认 effort 为 high，API 模型 ID 是 claude-fable-5-1。一个容易踩的坑是平台默认档位不一致：Claude Code 默认 High，Claude Cowork 和 claude.ai 默认 Medium。你在客户端看到的行为和 API 直调可能不同，先确认自己处在哪个默认下。

场景一：大型代码库迁移/重构，任务拆到什么粒度、怎么协作

拆解的判断标准。 官方没有给出“每多少行代码拆一个子任务”之类的硬性数字，更可靠的判断标准是两条：子任务能否被独立验证（有明确的完成判据，比如一组测试通过）；子任务的上下文能否隔离（不需要读全库才能干）。满足这两条的交给子代理，需要跨文件全局判断的部分留在主代理（lead）手里。

子代理用异步模式，别干等。 5.1 的提示词文档专门给了一个异步子代理模式：启动子代理的工具调用立即返回，子代理的结果在后续的 user 消息里回传，同时给 lead 配一个单独的 wait 工具，让它想等的时候再等。官方的说法是这种模式在质量、token 用量和成本相近的情况下，降低平均完成时间。直觉上也好理解：lead 派出三个子代理后继续干自己那部分，比串行等待快得多。

客户端要按“跑很久”来设计。 官方文档明确，困难任务的单次请求可能跑很多分钟，自主运行可以延续数小时。这意味着同步阻塞式的调用方式不适用，官方建议调整客户端超时、开流式、用异步检查（比如定时任务轮询状态）代替一直挂着等。

历史必须 append-only。 5.1 的 thinking block 与原会话绑定：2026 年 8 月 31 日之后新建的账号，修改历史前缀会直接返回 400，或者 thinking block 被丢弃。8 月 31 日之前的老账号不受绑定强制，但编辑历史同样会使 thinking blocks 失效。跑长任务时把历史当成只追加的日志来对待，是最稳妥的做法。

防止 lead 过度规划。 长任务开头模型容易花大量回合做计划而不动手。官方给了一句提示词：“When you have enough information to act, act…”，意思是信息够用就动手，边做边修正。

场景一的提示词怎么写：三个官方写法直接复用

第一个：解决“跑到一半停下来问你要不要继续”。 这是长任务最常见的失败模式，模型输出“Next, I'll…”或者“Shall I…?”然后停住。5.1 提示词文档给了两段系统提示词，一段讲自主运行（不要中途确认，按自己的判断推进），一段讲交付（完成全部工作再收尾，交付完整的成果而非半成品）。官方特别注明：开头第一句承载了大部分效果，保持原样别改。你可以在官方文档里找到这两段的完整原文，直接放进系统提示词即可。

第二个：解决“一轮只调一个工具”。 5.1 在编码和 computer use 的工具循环中，可能每轮只发起一个工具调用，长任务里这会显著拉长耗时。官方的纠正提示词是一句话，可直接复用：

First privately list what you need next; then request every item that doesn't depend on another's result in this one response.

意思是先在心里列出接下来需要什么，然后把其中不依赖其他结果的项目在这一轮全部请求掉。

第三个：长输出别让模型在思考里打草稿。 xhigh 和 max 档位下，模型思考时间明显增加，长交付物可能出现“思考里写了一遍、正文又重写一遍”的情况，白白消耗输出额度。官方的建议是给 max_tokens 留足余量，并用官方提供的提示词片段告诉模型不要在思考中起草再誊写。这一条在跑 xhigh 长任务前值得先配上。

另外提一句 5.1 的提示词范式：简短、直接的指令优于长篇枚举规则。从旧模型迁移来的用户容易把提示词写成几十条 do 和 don't，在 5.1 上反而稀释效果。

场景二：多步骤研究与知识工作，重点是记忆和压缩

跨会话的研究任务和代码迁移不同：它的产出是逐渐积累的认知，最怕的是压缩或换会话后“忘了自己学到什么”。

记忆系统。 官方推荐的模式是用 Markdown 文件做教训库：一个文件记一条教训，文件开头一行摘要。会话开始时用一段 bootstrap 提示词让模型回顾之前的会话并更新记忆文件。需要说明出处：这套 memory system 的具体做法写在 Fable 5 的提示词文档里，5.1 的专属文档开篇声明“现有的 Fable 5 提示词在 5.1 上无需修改即可表现良好”，因此可以延续使用。

压缩时保留什么。 5.1 文档给了一份压缩摘要的保留清单，客户端自己做上下文压缩时照着留，共六项：遇到的困难和解法；被放弃的方案及放弃原因；关键决定和约束的原文；当前进度；未决事项；难以重建的细节。研究类任务里最值钱的是第二项和第六项，被放弃的搜索方向不记下来，模型压缩后很可能原路再走一遍。

中途交付。 研究任务跑几小时，阶段性结论应该及时交出来而不是憋到最后，这正是 send_to_user 的用武之地，下一节展开。

agent 跑着跑着没声音了？进度可见和结果交付是两件事

很多人把“agent 失声”当成一个问题，其实是两个：你想看到它在干什么（进度可见性），和它该把成果交给你（结果交付）。解法不同，混着用会两头都不对。

进度可见性。 5.1 默认比 Fable 5 输出更少的用户可见进度更新，长工具链里模型可能安静干活很久。官方的解法分两步：先检查并删掉旧提示词里“hold findings for final response”（把发现留到最终回复再说）这类指令，它们会主动压制中途输出；然后开启进度更新显示，设置 thinking 的 display 为 updates，这是一个 beta 功能，需要带上对应的 beta 请求头（thinking-display-updates-2026-08-18）。开启后你会收到模型的状态行，知道它是在跑还是卡住了。

结果交付。 send_to_user 是官方定义的工具，让模型在长任务中途主动把阶段性成果发给用户。它的定义包含完整的 JSON schema 和配套的系统提示词，写在前代 Fable 5 的提示词文档中，按 5.1 的延续声明可直接使用。这个工具有个关键特性：tool inputs 永远不会被摘要压缩。也就是说你通过它收到的内容，不会在后续上下文压缩时丢失，适合承载必须留存的中间结论。反过来，官方也明确提醒不要用它跑叙事性内容：模型的过程叙述应该走 thinking 和进度更新，send_to_user 留给真正要交付给你的东西。

每轮提醒的新做法。 长工具循环里经常需要每轮提醒模型某些约束，塞在正常消息里会污染上下文。5.1 提供了 turn-scoped system messages（beta）：发一条 role 为 system 的消息并设置 clear_at 为 next_user_message，它在下一条 user 消息前自动清除，清除后不计入输入 token。对应的 beta 请求头是 mid-conversation-system-clear-at-2026-08-21。既省 token 又不弄脏历史。

长任务成本怎么控：缓存读降价后，账要重新算

先看价格。 2026 年 9 月 2 日查询的官方定价：输入 $10/MTok，输出 $50/MTok，缓存读 $0.25/MTok。缓存读指请求命中提示缓存后、读取已缓存前缀时的输入计费，长任务里同一段系统提示词和工具定义会被反复读取，缓存读的单价直接决定这类任务的账单底数。缓存读从上一代的 $1 降了 75%，这是 5.1 成本结构最大的变化。Anthropic 在发布公告中称，相对 Fable 5，典型负载成本约降 25%，复杂编码和高 agentic 任务最高可降约 45%。注意这是官方口径的“up to around”，你的实际数字取决于自身负载结构，务必用自己的任务跑 benchmark 再做预算决策。

档位策略。 effort 是控制模型思考量的参数，官方将其定位为质量、延迟与成本的主控制杆，共五档：low、medium、high、xhigh、max，API 默认 high。官方建议从 high 起步，在自己的评测集上验证质量保持后，再降到 medium 或 low。xhigh 的官方定位是 30 分钟以上、token 预算百万级的长程 agentic 和编码任务，正是长任务的主战场；low 的定位包含子代理这类简单分工，但要注意低档位下模型更少主动调用搜索工具。一个可用的分工：迁移主线跑 high 或 xhigh，子代理跑 low，常规步骤降档。

会中换档不破坏缓存。 5.1 新增了会中调整 effort 的能力（beta）：通过 output_config 修改 effort，请求头为 mid-conversation-output-config-2026-07-01。官方明确这个操作不破坏 prompt cache，且建议“难步骤升档、常规步骤降档”。这让长任务可以在一次运行内按步骤精细控制成本，而不是全程锁死一个档位。

上下文组织。 缓存读降到 $0.25 之后，官方对压缩时点的态度变了：提前压缩省下的钱变少了，为省钱而激进 compact 未必还是正确的权衡，建议实验更晚的压缩点。组织上下文时的几个要点：保持系统提示词和工具定义等前缀稳定，别在中段插入会打掉缓存的内容；让子代理活得久一点，长命的子代理反复命中自己的缓存；用上一节的 turn-scoped 消息做每轮提醒，清除后不计输入 token。缓存写比输入略贵（5 分钟缓存写 $12.50/MTok），但一次写入、多次 $0.25 读取，在重复读取次数多的长任务里通常是划算的。

跑长任务前必须知道的几条硬规则

以下是长任务视角下最容易踩中的变更，按“旧写法 → 5.1 正确写法”列出：

• 强制工具调用（tool_choice 设为 any 或 tool）会返回 400。改用 auto 加 strict: true。
• thinking 设为 disabled 在任何档位都返回 400。5.1 的 adaptive thinking 常开，不能关闭，只能通过 effort 调节思考量。
• prefill（预填 assistant 回复）返回 400，这个技巧在 5.1 上不可用。
• 旧模型读不了 5.1 的 thinking blocks，跨模型处理历史时注意剥离。

计费方面：模型可能返回 stop_reason 为 refusal 的拒答，输出发生前的拒答不计费；配置 fallbacks 为 default（beta）可以在拒答等情况下回退到其他模型，且 fallback credit 会退还切换模型产生的缓存成本。长任务的费用核算里要把这两条算进去。

以上是长任务会踩中的部分。迁移层面的完整变更清单，包括请求参数和响应结构的逐条差异，我们在另一篇《升级到 Claude Fable 5.1：Breaking Changes 清单》里拆过，此处不重复。

常见问题

从 Fable 5 迁移过来，长任务的提示词要重写吗？ 不用。官方明确 Fable 5 的提示词在 5.1 上无需修改即可表现良好。但几个行为差异要对症处理：进度输出默认变少、工具调用可能一轮一个、低 effort 少调搜索，对应上文各节的解法即可。

长任务用哪个 effort 档位起步？ 默认和官方建议都是 high。在自己的评测集上确认质量保持后降到 medium 或 low；30 分钟以上、百万 token 级预算的任务考虑 xhigh；配合会中换档，难步骤升、常规步骤降。

模型拒答了长任务怎么算钱？ 输出发生前的拒答不计费。担心拒答中断长任务的话，配置 fallbacks 回退，fallback credit 会退还切换模型的缓存成本。

缓存写比输入还贵，还值得写缓存吗？ 5 分钟缓存写 $12.50，比输入的 $10 贵四分之一，但缓存读只要 $0.25。长任务里同一段前缀会被反复读取，一次写入多次读取通常划算，要避免的是频繁打掉缓存的重写。

下一步：拿一个真实任务做试点

判断 5.1 值不值得为你的长任务买单，最可靠的办法不是对照参数表，而是拿一个真实的中等长度任务（一两个小时量级）做试点：配上 Finish the whole task 系统提示词和异步子代理，开启进度更新，从 high 档起步，跑完记录成本和质量，再决定降档点和压缩时点。官方的 25% 和 45% 是参考起点，你自己的 benchmark 才是预算依据。