十种毛病，按你看到的现象排成一份索引
一个跑了两小时的 Agent 任务，在还剩三件活的时候停下来问「要不要我继续」；另一段存了几个月的对话，只因为系统提示词改了一句，再发回去就直接报 400 错误。这两种卡法，Anthropic 给 Claude Fable 5.2 的官方提示指南里各有一节，连可以直接复制的系统提示词都写好了。
指南跟模型一起放进开发者文档，按你看到的现象组织，一共十种：活没干完就收工、长任务一声不吭、子 Agent 开太多、动不动要批准、把旧提示词直接带进新模型，都在里面。每种都给了解法，有的调档位，有的加一段话，有的删掉几句旧句子。同一个底层模型的 Claude Mythos 5.2 也适用这套办法。
通读下来反复出现的是同一件事：提示词里写明的规则，5.2 会按字面执行。告诉它「这个代码库是你的」，它在约一半的尝试里主动合并重复代码；记忆里带着一句「永远不要重试」，工具忙时它的重试比例就从几乎每次降到约四成。反过来，笼统的放权和另起一行的例外都压不过一条写死的「永远不要」，叫它少想的那句「直接回答，别琢磨」在 medium 及以上干脆不管用。所以这份指南有相当篇幅在教删。
指南之外，同一天公布的还有模型的几项事实：价格从每百万 token 输入 10 美元、输出 50 美元降到 8 美元和 40 美元，输出速度比 Fable 5.1 最多快 30%。在 Remote Labor Index（看 AI 能做完多少真实远程外包项目）上开 high 档得 41.3%，Fable 5.1 开到最高档只有 17.9%。官方建议多数编程和知识工作先用 Opus 5.5，碰到最难、最开放的技术活再换过来。
下面每一组比例都来自 Anthropic 自己的测试，是约数，各条在不同任务上测得，彼此不能直接比。换到你的任务上，值得自己再量一遍。
改提示词只在新对话里做：前缀检查会拦住旧对话
指南里几乎每一节都建议往系统提示词里加几句、删几句，或者改一个工具的描述。这些改动，指南都安排在新开的对话里做。
原因是 5.2 的「保留思考」（preserved thinking）：模型每一轮的思考块，都跟它前面的全部内容绑在一起，包括系统提示词、工具定义和之前的每条消息。API 对所有账号强制做前缀检查，system、tools 或更早的某条消息一变，你再把后面的思考块发回去，请求就可能直接返回 400 错误。
- 回头改前面：Messages API 默认拒绝这个请求（400），Message Batches API 会把这些思考块丢掉。
- 只往后加：前面的内容原样保留，思考都有效，提示词缓存也照样命中。
中途要换指令，指南给了两条路：把新指令放进最新一轮，或者平台支持「对话中途的系统消息」时，往对话里追加一条系统消息。前面一个字不动，思考链都有效，缓存也不必重建。
effort 从 high 起步，五档各接什么活
effort 是控制模型想多久的档位，决定一轮花多少时间、多少 token，也会改变它思考的方式和调用工具的次数。Claude API 的默认值是 high，Claude 应用和 Claude Code 的默认值是 medium。指南建议从 high 开始，再分别用 medium 和 xhigh 各跑一遍自己的评测（evals，一套固定的测试题）。
档位的顺序在各个 Claude 模型上一样，同一档背后的思考量却不一样。换到 5.2 要把档位重新扫一遍，别把在 Fable 5.1 或 Opus 5.5 上调好的设置直接搬过来。
选档时指南点了三种行为，都容易踩。
- 档位越低越容易提前收工。在 low 或 medium 上跑 Agent，要配上下一节那段「把活干完」的话。
- high 及以上几乎每次回复前都要想一想，回一句「你好」也是。简单请求嫌慢嫌贵，就把这类轮次降到低档；提示词里写「直接回答，不要斟酌」不拦这件事。
- effort 几乎不改变回复的长短。想要更短或换语气，得靠提示词写清楚。
同一个工作流里可以混着用。先用 medium 做计划、反复改，再把长时间无人值守的那一段调高。想在一段对话里换档又不丢缓存，用「按消息改 effort」（测试版，请求头 mid-conversation-output-config-2026-07-01）；不支持的平台只能在下一个请求里重设顶层 effort，缓存从头开始。
活没干完就收工：把障碍分成两堆
在又长又多步的任务上，5.2 有时会在活没干完时结束这一轮。收尾的样子有三种：列一张还剩什么的清单，问你要不要继续，或者在超时这类普通障碍前停住。档位开在 low 和 medium 时更常见。
指南建议往系统提示词里加一段「把活干完」的话，核心是把障碍分成两堆：普通障碍它自己过，有人故意设的阻碍留着不碰。写法如下，可以整段放进系统提示词。
# 把活干完
用户交代的活还没做完时，请不要停下。要有韧性，非必要不停。欢迎你写进度说明，也欢迎就悬而未决的决定向用户确认；但不依赖用户回答的那部分工作，请继续做下去，不要无谓地停下。
如果你发现自己正在请用户给你换方向，或者提出先等一等，那就改为直接做任务的下一部分。你可能会碰到普通的障碍，比如报错、超时、文件被锁、结果为空、工具失败。先诊断；如果它们不是真正的阻碍，就用你手上已有的权限把它们解决掉（等一会儿再试、修正请求、换一个工具或来源），而不是无谓地停下。
如果有人明确把某件事定为硬性阻碍，比如标了不许碰的文件、有意不给的权限、安全护栏，那就别碰它，直接说清你发现了什么，再找别的安全办法完成任务。任务没做完就停下，极少是合理的：只有在没有用户输入就推进不了，或者阻碍是有意设置、不该绕过的时候才停。这一条不取代危险或破坏性操作需要先确认的要求。
这段话把两类障碍分得很清楚。报错、超时、文件被锁、结果为空、工具失败属于普通障碍，先诊断再想办法过去；标了不许碰的文件、有意不给的权限、安全护栏属于有人设的阻碍，留着不碰并报告出来。它问得少了，你自己那道确认关更要留着。
Anthropic 拿一款 Agent 编程产品里录下来的会话，在 medium 档上重放。加了这段之后：
- 结尾问「这一步需要你点头，我再接着改？」：大多没了。
- 结尾问「要不要我继续把剩下的测试也修了？」：大多没了。
- 结尾列出「还剩三件没做：A、B、C」再停下：还在。
- 还剩能做的活就结束的会话：约减半。
- 代价：输出 token 约多 30%。
批准要说清动作，规则写宽了它就照拦
让它接着干的时候，说清楚你要它做什么。本来你会回一句「go」或者点个赞，改成回「好，在 staging 数据库上跑迁移」，动作、对象、范围都在一句话里。
系统提示词里写审批规则的，要写明规则管的是哪些具体动作，因为模型按字面执行。Anthropic 在没人负责批准的模拟任务上测过：一条规则把「给本对话以外的人发消息」列为需要批准的步骤，结果它找同事和其他团队的常规请求，大约一半压着没发。
写规则的人可能只想管发给客户的消息，这条规则写宽了。模型照字面读规则，写宽的部分也会原样生效。
代码归谁：一句话，把合并率从一成推到一半
Fable 5.2 对提示词里「代码归谁」的说法很敏感。Anthropic 在小型编程任务上测过：提示词不提归属，或者把代码库说成别人的，它倾向于在现有结构上往上加，哪怕这样会重复已有的代码；看到旁边的问题，也倾向于只报告、不动手。
想让它边干活边收拾结构，就把归属写明白，一句话就够。
这个代码库是你的：它拿来做什么、怎么搭，由你决定，之后也由你接着往下建。
效果是直接的。同一批小型编程任务里，加了这句，它在大约一半的尝试里合并了重复代码；不加，不到十分之一。这句放进一份很长的系统提示词里照样有效，要做的那个功能几乎每次都做成了，加不加都一样。
代价同时出现。输出 token 约为原来的 1.5 倍，还多了好几处没人要求的改动，很多是新加的测试和文档；除去修 bug，每 6 到 10 次尝试里就有 1 次改了某个已有功能的行为，档位越高越常见。它最后的总结只写大的改动，比如合并三处 formatMoney、加了导出、补了导出的测试。diff（逐行的改动记录）里还补了空值判断、给 README 加了一段说明、把金额改成四舍五入到分，最后一条已经改了原有行为。总结会漏掉小的改动，验收要看 diff。
什么时候别加：代码是用户的，而且用户希望改得越少越好。一条限制范围的规则压不住这句话，同一份提示词前面已经写了「不许顺手重构、改名或清理」，它照样在约三分之一的尝试里合并了重复代码。想让它少动，这句就不要写。
长任务一声不吭：先查 thinking.display，再补三句话
5.2 在一长串工具调用里，有时写给用户看的文字很少；第一次调工具之前，也可能不先说一声要干什么。问题常出在客户端。它在两次工具调用之间写的进度更新，是以 thinking 块（模型在工具调用之间写下的思考内容）的形式返回的，内容是发现了什么、下一步做什么。thinking.display 的默认值是 "omitted"，这时这些块的文字是空的。只渲染 text 块的界面，看起来就是卡住了。
设成 "updates"（测试版，请求头 thinking-display-updates-2026-08-18）或 "summarized"，再把工具调用之间非空的 thinking 块渲染出来，界面才会说话。前者每条进度给一句短摘要，后者在进度之外再给一段推理摘要。
用户在盯着看，更新还是太少的话，指南给了三个办法，可以叠着用。能改 harness（包在模型外面、负责调工具和管对话的那层程序）的，装一个沉默计数器：数一数连续多少步没给用户留下任何能读的东西。连续几步都这样，就把提醒追加在最新的工具结果后面，作为只在本轮有效的系统消息（clear_at: "next_user_message"，测试版请求头 mid-conversation-system-clear-at-2026-08-21）。这需要平台支持对话中途的系统消息。多轮编程任务测下来，提醒让最长的一段沉默大约减半，token 和耗时没有明显增加。
有真人在旁边看的场景，比如交互式编程，往系统提示词里加一段：开始之前用一行说说你要做什么，干活时简短更新，最后用一段能独立看懂的回顾收尾。编程任务上它每次都在第一次调工具前先开了口，代价是每个任务的输出 token 多约 20%。改不了 harness，或者平台不支持中途系统消息，就加一句「每隔几次工具调用，用一行话告诉用户现在进展到哪了」，流程自动化任务上大部分长时间沉默就没了。
提醒发出去以后，后面的请求里都要原样留在 messages 里。删掉或改写一条，等于改了更早的一轮，它后面的思考块全部作废。反过来说，那种用户过一阵回来看结果的异步任务，更新稀一点影响不大。
子 Agent 开太多、越来越畏手畏脚：先审它带着的规矩
5.2 把多少活分给子 Agent，取决于你的 harness 和任务。两种极端都测到过：短任务、只给一个最简单的「开子 Agent」工具，它很少开；在一款提示词本身就鼓励委派的 Agent 编程产品里，它开得很勤快。
所以先审上下文：系统提示词、技能文件、Agent 配置文件里凡是叫它委派的句子，先读一遍。删完以后还是开得比任务需要的多，再改「开子 Agent」那个工具的描述。新描述写三件事：开一个子 Agent 会给这次会话增加多少成本、什么时候值得委派、开的时候怎么交代任务，成本放在最前面。这套写法适合两种情况同时成立：harness 本来就鼓励委派，子 Agent 又占了 token 用量的一大块。
谨慎也会越攒越多，凡是「上下文会被带过去」的地方都算：记忆、笔记、指令文件、Agent 之间传的消息。5.2 严格照办，于是可能去要它不需要的批准，或者把常规的活压着不做。少数早期测试者见过这种情况，大多是在几个 Agent 一起干活的时候；以前的模型也照办，但在一组对比设置里，只有 5.2 缩手了。
一组常被引用的例子是十二条旧笔记：每次会话往记忆里添一条、没人回头删，其中一条写着「永远不要重试」。工具返回「忙，请稍后再试」时，不带这些笔记它几乎每次都重试，带着这些笔记重试降到约 4/10。
清理从四个地方入手：删掉不再需要的笔记；写明哪些步骤不需要批准；查查审查 Agent 附带了什么条件；把例外写进规则本身，让规则说清「做之前先拿到同意」。危险或不可逆的操作，自己那道确认环节要留着。
三组的共同点是它只认规则里白纸黑字写明的东西。笼统的放权、另起一行的例外，都压不过一条写死的「永远不要」；把规则改写成「做之前先拿到同意」，它才在约十分之九的尝试里做了那一步。
写给旧模型的句子，七类该删
迁移时要把提示词过一遍。Anthropic 测到有些为旧模型写的指令，在 5.2 上会抬高成本、带来副作用，或者干脆不灵了，一共分了七类。
- 「能分给子 Agent 的就分出去」这类常驻委派指令，常藏在系统提示词、技能和 Agent 文件里，子 Agent 可能开得比需要的多。先读再测，测出来开多了，删掉不再需要的那几行。
- 写进提示词的 token 预算，比如「本任务可用 X token，还剩 Y」。预算写多大，会影响它花多少；在 high 和 xhigh 的编程任务上，去掉一个大预算，成本降了，效果相当。不写预算跑一遍你的任务再决定；这里说的是提示词里的文字，API 的 task budgets 这次没测。
- 每次请求前改系统提示词的 harness 代码。改动点之后的思考块全部作废，Messages API 默认拒绝请求，Message Batches API 丢掉这些块。改成只往后加，缩短历史用 context editing（删改早前的上下文），或者用总结后不保留更早轮次的 compaction（压缩）。
- 「把答过的当定论」那两句，是从 Opus 5.5 指南带过来的。high 档上 5.2 被追问时想得少了，指出自己之前答错的可能性也大大降低。希望它继续复查旧答案的场景别加，其他场景先测它还会不会指出自己的错。
- 「直接回答，不要斟酌」。Fable 5.1 通常照做，5.2 在 medium 及以上照样思考，这句删掉，改为调低 effort。
- 写作风格的硬规则，比如「每句只写一条指令，不超过 20 个词」。它照得很严，文字变得一顿一顿。删掉不需要的，删完再加「报告」那一节那段话。
- 越攒越多的「永远不要」。删掉理由已不成立的，绝对规则改写成写明范围和理由，已经卡住的系统删减记忆和笔记后重启，原件留一份。
第三类想缓和一点，可以把 thinking.block_binding 下的 prefix_mismatch_behavior 设成 "drop_block"（测试版，请求头 thinking-binding-controls-2026-08-01），让 Messages API 像批处理那样丢掉作废的思考块。Anthropic 测试里，每一轮都丢掉之前的思考，模型会重新想一遍，输出 token 变多；实际多多少，看你的 harness 多久改一次前面的轮次。用之前先在自己的任务上量 token。除了 compaction 和 context editing，历史保持只追加，缓存命中率高，也没有思考被丢掉。
跑完之后的报告，要能一个人看懂
长时间的 Agent 任务跑完，读最终报告的人通常没看过背后的工具调用和文件，报告得自己就能讲明白。
指南给了一段可以直接加的写法，核心是写给一个聪明但缺少上下文的读者：要点放在头几句，句子顺序循序渐进，第 1 行不用要读到第 12 行才明白的指代。它要求不用干活过程中自己造的术语和缩写，大体按 ASD-STE100（航空航天业给维修手册定的简化技术英语规范）的风格写：句子短、一句一个意思、主动语态、同一个东西始终用同一个词。意思相连的地方写成连贯段落，彼此独立的条目才用列表。
测出来的变化是：Agent 任务上最终报告没那么密了，分号也少了，流程自动化任务上句子也变短了。这跟上一节「写作风格的硬规则会让文字一顿一顿」不冲突，它也要短句，只是用「大体按」这种软要求，还明说意思相连处要写成段落。顺序上先删旧的硬规则，再加这段。
同一份收尾报告，两种写法差得很远。只给干活的人看的那种是「按方案 B 处理了；T3 那个不稳定用例已修；v2 的临时补丁回滚了；剩 2 个待办，详见上面；导出现在应该没问题了」。给没看过过程的人看的那种是「导出 CSV 修好了，全部测试通过。原因是日期在不同时区下被算成了不同的天。我改了处理日期的那个函数，并加了两个跨时区的测试。还有一件事要你决定：旧数据里已经存错的日期，要不要批量改正」。
被拒的时候，看 stop_details.category
5.2 运行着几个安全分类器，可能拒绝一个请求。被拒时返回 stop_reason: "refusal"，stop_details.category 写着是哪一类。
- cyber：请求可能促成网络危害，比如开发恶意软件或漏洞利用。
- bio：请求可能促成生物危害，比如危险的实验室方法。
- frontier_llm：请求可能帮着开发与之竞争的模型。
- reasoning_extraction：请求要它把内部推理写进正文。
- general_harms：落在使用政策的其他领域。
reasoning_extraction 这类多半是提示词自己招来的：技能或工具描述里叫它「把推理写在回复里」，删掉这条要求就行。想看它怎么推理，把 display 设成 "summarized"，去读 thinking 块。
正当的网络安全和生命科学工作也可能触发 cyber 和 bio。挡住正经工作的机构，可以申请 Anthropic 的网络安全验证计划和生命科学验证计划；Mythos 5.2 能力相同，只开放给通过这两个计划验证的机构。被拒的请求想换模型重试，指南指向《What's new in Claude Fable 5.2》里讲拒绝、回退和计费的那一节。
迁移顺序：四步，每一步都带着价钱
指南最后给了一个四步顺序，照着走能把上面十几条改动落到自己的系统上。
- 把 effort 明确设成 high，再用 medium 和 xhigh 各跑一遍你的评测。
- 把带过来的文字全读一遍：系统提示词、技能、Agent 文件、记忆文件、笔记、harness 里的文字。七类旧句子，该删的删，该测的测。
- 跑你最长的 Agent 任务，记下五种情况出现在哪：提前收工、要不必要的批准、一声不吭、委派得比需要的多、该重构的地方只往上加。
- 一次只改一处。针对看到的每种情况套用对应那一节的办法，在自己的任务上量效果，也量 token 成本。
回头看，几乎每个办法后面都跟着一个价钱：把活干完多 30% 输出 token，开头和收尾多 20%，代码归你多一半。它们都管用，代价也算得出来。
整份指南翻来覆去讲的是同一件事：5.2 会照你写的去做，而且做得比以前的模型更彻底。写进去之前想清楚要不要它照做，写进去之后测一下它做成了什么样；那些已经不想让它照做的旧句子，先删掉。
