Opus 5.5：AI没偷懒，喊停的是你的代码！

当你指派AI代理连夜完成代码库迁移任务，第二天清晨打开终端，却只看到一行进度汇报：已完成3个接口迁移，接下来将处理剩余两个端点并补上测试。随后程序便陷入停滞，只有手动输入“继续”才能让它继续工作——这并非个例，而是很多开发者在升级到Opus 5.5后遇到的普遍问题。

Opus 5.5的“主动”陷阱

Opus 5.5发布后，不少运行AI代理的开发者发现，模型能力确实有所提升，但却频繁在任务中途停下，不主动催促就不会继续工作。就连模型的研发方也注意到了这个问题，发布仅数日就推出了配套的提示词指南，专门针对这类停工问题提供修复方案。

官方在开篇的排查清单中直接点名了这种“半路溜号”的情况：无人值守的代理在汇报完进度后直接停在半路。背后的原因或许出人意料：Opus 5.5过于主动地进行进度汇报。在执行长任务时，模型会主动同步当前进度，但部分汇报发送后，模型就不再继续操作，API返回的信号是end_turn，意为“本轮对话结束”。而不少沿用旧逻辑的AI代理程序有一个僵化的规则：只要模型不再调用工具，就视为任务已经完成。一份简单的进度汇报，就这样被错误地当成了任务完成的凭证，导致代理提前“下班”。

四类“优等生”式停工场景

颇具讽刺意味的是，“沟通更主动、总结更清晰”正是Opus 5.5的核心宣传卖点。这些原本被视为优等生的好习惯，放到旧的无人值守代理程序中，反而成了导致任务停滞的诱因。官方将这类中途停工的情况归纳为四类，几乎每个运行过AI代理的开发者都遇到过：

第一种是纸上谈兵：模型输出长篇总结，宣布下一步计划，但并未实际调用任何工具，后续操作始终停留在口头层面。

第二种是过分礼貌：执行任务中途突然询问“如果您允许，我将继续处理某某任务”，随后直接挂机，等待不在电脑前的用户回复。

第三种是假装请示：列出一堆需要用户拍板的决策项，但实际上这些决策并不会影响后续任务的推进。

第四种是汇报强迫症：模型认为当前对话回合字数足够，或是刚完成一个小阶段，就必须停下来向用户做一次总结。

官方三大优化方案

针对这些问题，官方给出了三大优化方案，同时配合调整提示词，就能让代理顺利完成任务而不会陷入无限循环。

第一个方案是任务清单法：将大任务拆分为多个细项，通过待办工具或文本进行维护，让模型在执行过程中逐一勾选。当对话回合结束时，如果清单中仍有未完成的任务，且模型未说明停滞原因，应用就应该自动发送消息，提醒模型继续执行。官方给出的示例提示为：“你的任务清单还有未完成项：迁移剩余两个端点并更新它们的测试。继续执行。如果遇到阻碍，请说明具体卡点。”

第二个方案是铁面验收员：提前设定明确的任务完成标准，每次对话回合结束后，交由一个轻量模型对照标准进行检查。如果未达标，就将未达标的原因作为新的对话内容发送给模型，让其返工修正。

第三个方案是硬刹车机制：如果同一个任务自动续跑两三次仍停滞不前，必须强制暂停任务并交由人工复查，避免无效消耗API额度。

除了上述三个方案，提示词的调整也必不可少。官方还提供了可直接复用的系统提示词模板，核心是双向约束：既要明确禁止上述四类停工行为，也要清晰定义允许模型停止任务的场景，比如脱离用户输入后无法继续推进，或是遇到了受保护的核心资源。

API迁移的四大致命坑

除了中途停工的问题，从Opus 5升级到Opus 5.5还存在不少容易触发400错误的API改动，未做调整的旧请求会被直接拒绝：

第一，thinking参数无法关闭：如果将thinking设为disabled，或是手动指定budget_tokens，系统会直接拒绝请求。要么不传递thinking字段，要么将其设为adaptive，通过effort参数控制思考深度。

第二，无法强制指定tool_choice：将tool_choice设为any或指定具体工具，都会触发400错误。官方建议使用auto模式，配合严格工具调用或结构化输出，并在提示词中明确不同场景下应使用的工具。

第三，thinking块与模型及上下文绑定：2026年8月31日后创建的账户，如果中途修改了系统提示词、工具或历史消息，再回放旧的thinking块，默认会直接报错。仅追加内容而不修改的场景不受影响。

第四，旧版电脑操作工具下线：在Claude API和Google Cloud平台上，需要更换为computer_toolset_20260801；在Amazon Bedrock上，旧的computer_20251124仍可正常使用。

容易被忽略的隐性暗坑

除了直接触发400错误的API改动，还有一些不会报错但同样影响使用的隐性问题：

第一个是看不见任务进度：在Opus 5中，模型在两次工具调用之间输出的进度文字属于普通正文块；但在Opus 5.5中，这些文字被移入了thinking块，而thinking块默认设置为不显示内容，返回结果为空。如果应用界面仅显示正文，长任务运行时用户会看到一片安静，误以为模型卡死，但实际上请求并未失败。解决方法是将display参数设为updates（beta）仅获取进度摘要，或是设为summarized同时返回进度和推理摘要。

第二个是回答被截断：max_tokens参数现在管控的是思考内容加正文的总长度。过去在关闭思考功能时设定的上限，在Opus 5.5中可能不足以支撑完整输出，导致回答写到一半被截断。

第三个是隐身的token消耗：即使思考内容没有返回给用户，模型仍会按照输出token进行计费。

同时，处理返回结果的代码也需要调整两处：一是读取结果时要区分内容类型，模型返回的思考内容和正文是分开的，不能想当然地将第一段内容当作最终回答；二是在来回调用工具时，必须原封不动地传递模型的思考记录，删除、修改或调整思考记录的顺序都会导致请求被拒绝。

需要注意的是，以上清单主要针对直接调用Messages API开发的开发者，使用Claude Managed Agents的用户仅需更换模型名称即可。

档位调整：medium档的新定位

由于thinking参数无法关闭，effort参数成为调控成本的唯一旋钮。Opus 5.5提供了从low到max共五个档位，官方表示，使用medium档位就能追平甚至超越Opus 5的high档位，而使用low档位处理简单任务时，成本会大幅降低。

不过官方也提醒，在同一档位下，Opus 5.5每轮对话的思考量比Opus 5大得多，尤其是高档位。如果直接将旧项目的high档位设置照搬过来，不仅对话回合会变长，输出的token数量也会大幅增加。即使同样名为high档位，模型的思考逻辑已经发生了彻底变化。因此建议从medium档位起步，使用自身业务数据进行测试，确实需要提升性能时再向上调整档位；如果希望减少模型的思考量，直接降低档位比在提示词中反复提醒“不要想太多”要有效得多。

消除AI界面感的实用技巧

官方指南中还提到了一个优化前端界面的实用技巧。如果不给模型明确的设计约束，它往往会生成千篇一律的标准化AI风格界面。如果仅在提示词中写“请避免通用的AI感”，模型只会在不同的AI模板之间切换，无法达到预期效果。真正有效的方法是直接列出禁止的样式清单，明确告知模型哪些元素不能使用。

官方示例中列出了五类需要避开的样式：不要奶油色或灰白背景、不要标题中的斜体强调词、不要01/02这类章节编号、不要等宽字体标签、不要胶囊形按钮。模型能够理解具体的“不要什么”，却无法领会抽象的“好看一点”这类模糊要求。

最终的思考

翻阅这份官方指南不难发现，AI模型的能力在快速迭代，但不少应用的底层逻辑还停留在上一代。过去开发者担心模型不动脑，会逼迫它一步步写出推理过程；如今却需要引导模型减少不必要的思考。过去费尽心思让模型按时汇报进度，如今却因为汇报过于频繁导致任务停滞。

一个AI代理能否顺利完成任务，模型能力只占一半，另一半则取决于开发者如何定义“任务完成”、如何保存上下文，以及如何分配推理预算。下次再遇到代理中途停工的情况，别急着责怪模型偷懒，不妨先回头检查一下自己编写的程序逻辑。