Anthropic 在发布后不久推出了配套的提示词指南，专门给这类问题打补丁。官方排查清单直接点名了这种「半路溜号」：无人值守的智能体汇报完进度后，直接停在了中途。

根子出在「太爱汇报」

问题的根源在于 Opus 5.5 太爱汇报进度。处理长任务时，它会主动同步进展；但有些汇报发完，它就不再调用工具，API 返回的信号表示本回合结束（end_turn）。而不少沿用旧逻辑的程序只认一条死规矩：模型不再调用工具，就算任务完成。一份进度汇报，就这样被当成了交差。

官方指南说得很直白：纯文本的回合结束，应当视为一份汇报，绝不能当作任务完成的凭证。

四种典型停法

官方把中途停工归纳为四种情况：

• 纸上谈兵：写完长篇总结、宣布下一步要做什么，却没调用任何工具，下一步永远停在口头上。
• 过分礼貌：干到一半突然停下来问「如果您不介意，我接下来继续处理某事项」，然后原地挂机，等待根本不在电脑前的用户回复。
• 假装请示：列出一长串需要用户拍板的决策项，但按模型自己的说法，这些决策并不影响其继续干活。
• 汇报强迫症：模型觉得当前回合字数够多，或刚做完一个小阶段，非得停下来做个总结。

有意思的是，「沟通更主动、总结更清楚」恰恰是 Opus 5.5 官方宣传的核心卖点。这些「优等生」的好习惯，一旦放进旧的无人值守程序里，反而成了停工的诱因。

官方三招：把验收权从 AI 手里拿回来

第一招，任务清单。 把大任务拆成细项，交给待办工具或文本维护，让模型边做边勾选。回合结束时，若清单上还有未完成的任务、且模型未说明被什么卡住，应用就自动发一条消息点名让它续跑。官方示例：「你的任务清单还有未完成项：迁移剩下两个端点，并更新它们的测试。继续做。如果某项被卡住，说明卡在哪里。」

第二招，铁面验收员。 事先定好完成标准，每次回合结束交给一个更小的模型对照检查；不达标，就把原因作为下一条消息塞回去让它返工。

第三招，硬刹车。 同一任务若自动续跑两三次仍卡在原地，必须强制停下交人工复查，避免把 API 额度空转烧光。

此外，提示词也需要更新。官方给出了一段可直接套用的系统提示词，核心思路是「两头堵」：既要明说绝对不想要上述四种停法，也要说清何时才允许停止，例如离了用户真推不动，或碰到被刻意保护的核心资源。

从 Opus 5 到 5.5 的迁移陷阱

如果说干一半停工只是磨洋工，下面这些接口变动则会直接让程序崩溃。沿用给 Opus 5 写的请求、不改就发给新模型，会被直接拒绝并返回 400 错误，共有四处关键改动：

1. thinking 参数不能再关闭。若把 thinking 设为禁用，或手工指定思考预算，系统会直接拒绝请求。要么不传 thinking 字段，要么设为自适应模式，由 effort 参数控制思考深度。
2. tool_choice 不能再强制调用工具。把 tool_choice 设为任意或指定某个具体工具都会报 400。官方建议用自动模式，配合严格工具调用或结构化输出，并在提示词中说清何时用哪个工具。
3. thinking 块绑定了模型和上下文。2026 年 8 月 31 日之后创建的账户，中途修改系统提示词、工具或历史消息后再回放旧的 thinking 块，默认会直接报错；只追加、不改写的用法不受影响。
4. 旧版电脑操作工具下线。在 Claude API 和 Google Cloud 上需换用 computer_toolset_20260801；Amazon Bedrock 上旧的 computer_20251124 仍可继续使用。

对开发者而言，关键不是催促模型多干一点，而是把「任务是否真的完成」的判断权从模型手里收回到程序里——用可校验的清单和外部验收，替代模型自己写下的「我做完了」。