当你的 AI Agent 在凌晨悄悄停止工作，只留下一句「我接下来将处理剩余两个端点」的承诺，然后陷入沉默时，你可能会怀疑它是不是学会了人类的摸鱼哲学。然而，Anthropic 刚刚发布的官方提示词指南揭开了真相：模型并没有偷懒，是你的程序代码替它打了下班卡。
这个看似荒诞的现象，正在成为所有 AI 开发者与重度用户必须面对的新课题。尤其当你满怀期待地打开终端，发现模型在关键节点上戛然而止，那种感觉就像追剧追到一半被掐断，不得不手动输入「继续」才能让进度条重新走动。对于长期依赖自动化的团队来说，这已经不是一个效率问题，而是一个会导致整个工作流断裂的Bug级痛点。
现象的背面：汇报强迫症如何变成停工元凶
Opus 5.5 发布后，开发者社区很快就发现了它的独特「性格」——能力确实大幅增强，但干起活来总爱时不时停下来向你汇报进度。表面上看，这是模型变得更负责任的表现，但当这些汇报出现在无人值守的 Agent 流程里，事情就变味了。
Anthropic 官方指南在开篇就点明了这个核心问题：无人值守的 Agent 在汇报完进度后，直接停在了半路，不再调用任何工具。官方给出的原因令人啼笑皆非——Opus 5.5 实在太爱汇报了。在长任务执行过程中，它会主动同步进展，而这些汇报结束时的 API 信号是 `end_turn`，代表「这一轮我说完了」。
然而，许多沿用旧逻辑的 Agent 程序并不能区分「汇报」和「完成任务」。这些程序只认一条死规矩：模型不再调用工具，默认即为任务完成。于是，一份普通的进度汇报就被误判成了交差凭证，整个流程随之终止。
官方指南强调得非常明确：纯文本的回合结束应视为一份汇报，绝不能当作任务完成的凭据。这一提醒背后，折射出的是下一代大模型训练成果与老旧应用逻辑之间的深刻错位。模型变了，应用逻辑却没跟上，最终让用户体验变得支离破碎。
更讽刺的是，Opus 5.5 在官方宣传中恰恰把「沟通更主动、总结更清楚」当做了核心卖点，结果这些优等生般的好习惯，放进预设了「不调用工具就算结束」的程序里，反而成了最大的减分项。
四种典型半路停工场景解析
官方指南将这种半路停工归纳为四种典型场景，每一个都能在真实开发中找到对应案例。理解这些场景，是避开此类雷区的第一步。
第一种叫「纸上谈兵」。模型写出一大篇总结，末尾宣布下一步要处理某件事，但实际上它从头到尾没有调用任何工具，也没有任何执行动作，所谓的「下一步」永远停留在文字里。这种模式最常见于复杂任务拆解过程中——模型试图展示自己的规划能力，却忽略了执行本身。
第二种叫「过分礼貌」。在执行过程中，模型突然停下并询问：「如果您不介意，我接下来继续处理某某事项，可以吗？」然后原地挂机，等待一个根本不在设备前的用户回复。这种对话式的礼貌放在真人交互中并无不妥，但在自动化流程里就成了无限期阻塞。
第三种叫「假装请示」。模型列出大串需要用户拍板的决策项，但根据它自己的描述，这些决策实际上根本不会影响它继续处理剩余工作。它只是把「汇报」变成了一种惯性动作，仿佛在等待一个并不必要的批准。
第四种叫「汇报强迫症」。当模型认为当前回合的字数已经足够多，或刚好完成一个小阶段时，它会主动停下来向你做总结。这种按耐不住的汇报欲，在长任务执行中会被反复触发，导致整个 Agent 流程千疮百孔。
如果你曾经被这类行为困扰过，不妨回想一下自己的代码逻辑：是否把「回合结束」等同于「任务完成」？如果你的应用仍使用这套判断标准，那么无论模型多么优秀，最终只会得到一个频繁摸鱼的 Agent。现在，AI Agent技术正在快速迭代，而开发者的应用架构却还在用旧时代的思维度量着新模型的每一次呼吸。
官方三招：把验收权从 AI 手中夺回
面对半路停工问题，Anthropic 给出了三招治本方案，核心思路完全一致：将验收权从模型手里夺回来，交给程序和流程去把控。
第一招是任务清单法。将大任务拆解为细项，通过待办工具或文本形式由模型逐项勾选。每次回合结束时，应用主动检查清单——如果仍有未完成任务且模型没有说明卡住原因，系统应自动发送一条续跑消息点名让模型继续。官方甚至给出了可直接使用的续跑示例：「你的任务清单还有未完成项：迁移剩下两个端点，并更新它们的测试。继续做。如果哪项被卡住，说明卡在哪里。」这种方法能够有效打破「汇报即停工」的循环，让 Agent 始终围绕未完成项转动。
第二招是铁面验收员机制。事先定义清晰的完成标准，每当回合结束，让一个更小、更便宜的模型对照标准检查输出结果。如果未达标，将未达标的原因作为下一条消息再塞回主模型，强制它返工。通过引入独立验收环节，彻底绕开了模型自我评估的盲区。
第三招是硬刹车。当同一个任务自动续跑两三次仍然卡在原地时，系统必须强制停止，将任务交给人来复查。这一策略的核心价值在于防止 API 额度在无解任务上空转烧光。毕竟，对一个真正死锁的任务，无限重试只会造成不必要的损失。
这三招并不是相互排斥的，完全可以组合使用。任务清单负责方向牵引，验收员负责质量把关，硬刹车负责止损兜底。对于正在企业数字化转型过程中搭建自动化流程的团队来说，这套方法论具有极高的参考价值。无用质疑的，要想让AI工具真正成为生产力引擎，就必须为它设计好一套完整的控制机制。
迁移陷阱：从 Opus 5 到 Opus 5.5 的四个 API 改动
如果说半路停工只是让效率打折，那么从 Opus 5 切换到 Opus 5.5 时的 API 改动，则会让直接沿用旧代码的程序直接崩溃。官方迁移指南列出了四个必须注意的改动点，任何一处忽略都会导致请求被拒绝，返回 400 错误。
第一处改动是 thinking 参数不能再关闭了。如果开发者继续将 thinking 设为 disabled，或者手动指定 budget_tokens，系统会直接拒绝请求。正确做法是干脆不传 thinking 字段，或将其设为 adaptive，通过 effort 参数来控制思考深度。
第二处改动是 tool_choice 不能强制调用工具。将 tool_choice 设为 any 或指定某一把工具都会报错。官方建议使用 auto，配合严格工具调用或结构化输出，并在提示词中详细说明何时该用哪把工具。这本质上是将工具选择的决策权交还给模型，而不是预先硬编码。
第三处改动涉及 thinking 块与模型及上下文的绑定关系。2026 年 8 月 31 日之后创建的账户，如果在中途修改了系统提示词、工具或历史消息，再回放旧的 thinking 块时默认会报错。唯一不受影响的就是只追加而不改写的用法。这一变化意味着，旧有的上下文编辑方式在新模型上不再安全。
第四处改动是旧版电脑操作工具下线。在 Claude API 和 Google Cloud 上，必须更换为 computer_toolset_20260801 才能正常工作。Amazon Bedrock 上旧的 computer_20251124 依然可用，但这只是暂时的兼容性。
除了这些直接报错的问题，还有一些不报错的暗坑更为隐蔽。例如，Opus 5.5 把两次工具调用之间的进度文字从普通正文挪进了思考块，而思考块默认不显示内容，导致你的用户界面一片安静，看起来就像模型死掉了一样。解决方法是设置 display 为 updates 或 summarized，让进度摘要可见。
另一个暗坑是 max_tokens 的分配。现在它同时管思考量和正文量，过去关掉思考时定下的上限可能不再够用，结果就是回答写到一半被截断。更重要的是，思考内容就算不显示，也会照常按输出 token 计费。对于需要精细管理成本的团队来说，这些都是必须重新审视的变量。
如果你是自己直接调用 Messages API 的开发者，这些改动几乎每一项都需要动手修改代码。而如果你使用的是 Claude Managed Agents，只需要把模型名改过来即可，其余逻辑早已内置处理。
从 high 档到 medium 档：重新校准你的思考预算
既然思考机制已经无法关闭，那么 effort 参数就成了调控成本的核心旋钮。Opus 5.5 支持从 low 到 max 共五档思考强度设置。官方声称，现在开启 medium 档就能追平甚至超越以前 Opus 5 的 high 档效果，而 low 档处理简单任务时成本极低。
听起来像是一项白捡的福利，但官方紧接着提醒：在相同的档位下，Opus 5.5 每回合的思考量远大于 Opus 5，尤其是在高档位。换句话说，如果你把旧项目的 high 档原封不动搬到新模型上，不仅回合时间变长，输出 token 数也会飙升。同样叫 high，背后的思考投入已经完全不同了。
一个务实的建议是：新项目从 medium 档起步，用自己的真实数据测试，确实需要更高智力水平的地方再逐步上调。如果想让它少想一点，直接降低档位比在提示词里反复强调「别想太多」要有效得多。这些都是最新科技产品使用中的实践心得，也是AI工具箱中真正能见效的调参技巧。
对于性能极为敏感的场景，你还可以尝试在运行时动态调整 effort 档位。比如，在数据清洗类任务中使用 low，在代码重构中切换到 medium，而在需要深层推理的数学问题上才启用 high。这种灵活配置往往能实现效果与成本的双赢。
消除「AI味」：从抽象审美到具体黑名单
最后，这份指南还意外地贡献了一个前端设计领域的实用技巧。如果你不给模型明确的设计方向，让它自己发挥，最终往往会得到一个千篇一律的「AI 风格」界面。通常的解决办法是在提示词里写「请避免通用的 AI 感」，但官方指出，这样做只会让模型从一套 AI 模板跳到另一套 AI 模板，毫无意义。
真正有效的方法，是直接拉出黑名单。官方示范的提示词中列出了五种要明确禁止的具体样式：不要奶油色或灰白背景，不要标题里的斜体强调词，不要 01/02 这种章节编号，不要等宽字体标签，不要胶囊形按钮。模型能够精准理解「我不要什么」，但很难理解抽象的「我要好看一点」。这背后的道理，与我们教育年轻人一样：给出具体的边界，比空谈理念更可执行。
同理，如果你想使用AI画图工具来设计界面或者配图，也可以采用同样的策略——直接告诉工具哪些具体元素不要出现，往往比反复强调「我要高端大气」更有效。这种清单式的反向约束，正在成为一项重要的工程实践。
翻完这份官方指南，最大的感触是：模型的能力正在一路狂奔，而很多应用的脚手架却还停留在上一代。过去开发者生怕模型想得不够多，费尽心思逼着它把推理过程写出来；如今却要反过来劝它少琢磨点。过去大家费力让它定时汇报，如今它汇报得太勤快，真正的活儿反倒干不完。
一个 Agent 能不能把活干完，模型能力只占一半。另一半，掌握在你的手里——取决于你怎么定义「完成」，怎么保存上下文，怎么分配推理预算。下次你的 Agent 再干一半就溜号，别急着骂它偷懒，先回头翻翻你自己写的那段循环，说不定，它停下的理由就写在你发给它的提示词里。