让一个 Agent 连夜迁移代码库,第二天早上一看终端,只有一句话:“已完成 3 个接口迁移,接下来我将处理剩余两个端点,并补上测试。”然后就没有下文了,想让它干完,你还得再敲两个字:继续。
这是 Opus 5.5 上线后最集中的一类吐槽。我们 9 月 23 日那篇 Opus 5.5 的换模型账算的是价格和该不该换,今天这篇不重复价格结论,只讲一件事:它为什么干一半会停、怎么让它接着干、从 Opus 5 迁移过去哪里会直接被拒。
先给结论:模型没变懒,停下不等于干完,而把一次进度汇报判成“交差”的那行代码,在你自己写的循环里。
一、先把传闻和实锤分开
- 传闻:“Opus 5.5 降智了、变懒了”——错。官方指南的说法很具体:它在长任务里会边做边同步进度,而其中一部分汇报以纯文本结束当前回合,API 返回的信号是
stop_reason: "end_turn",意思是“这一轮我说完了”;不少沿用旧逻辑的 Agent 循环只认一条死规矩——模型不再调用工具就算任务完成。一份进度汇报就这样被当成了交差。 - 传闻:“官方承认这是个 bug”——半对。官方没有给触发频率,也没把它定性为缺陷,而是把“无人值守的 Agent 汇报完进度后,停在了任务中途”列进指南开篇的问题清单;同一时间,官方 playbook 也写了同一件事,并给出了 CLAUDE.md 里的规则写法。更准确的定性是行为变化,不是坏掉。
- 实锤:官方指南给出了三样可以直接照做的东西——连续续跑的消息示例、“同一个任务自动续跑两三次就该停”的上限建议,以及一段针对完全无人值守场景的完整系统提示词。
- 实锤:“沟通更主动、总结更清楚”本来就写在 Opus 5.5 的官方宣传里。也就是说,这次的停工是优等生习惯撞上旧脚手架,不是能力倒退。这一点在中文圈被反复讨论,可参考 AGIHunt 的万字整理与新智元的解读。
- 一个诚实说明:官方文档页对我们所在地区的直连会跳到区域提示,上面这些细节以官方 playbook 原文与中文整理版为准,英文关键句我保留了原文,方便你对照核对。
二、它停下来的四种样子
官方把“半路停工”拆成了四种具体形态,只要跑过无人值守任务,大概率都见过:
| 停法 | 现场表现 | 为什么会发生 |
|---|---|---|
| 纸上谈兵 | 写了一大段总结,结尾宣布下一步要做什么,却没有任何工具调用 | 该回合直接 end_turn,下一步永远停在口头上 |
| 过分礼貌 | 中断下来问“如果您不介意,我接下来继续处理某某”,然后原地挂机 | 它在等一个本来就不会有人给的回答 |
| 假装请示 | 列出一长串需要你拍板的决策项 | 按它自己的判断,这些决策没有一项阻塞剩余工作 |
| 汇报强迫症 | 觉得当前回合已经够长,或者刚好做完一个阶段,就停下来做总结 | “阶段完成”被它当成了“可以汇报”的信号 |
四种形态对应同一根机制:回合以纯文本结束,只说明这一轮讲完了,不构成任务完成的凭证。旧循环把它当成交差,工作就停在那里。
三、官方三招:把“验收权”从模型手里拿回来
- 第一招,任务清单续跑。把大任务拆成细项,交给待办工具或一个文件去维护,让模型边做边勾选;回合结束时如果清单上还有未完成的项,而模型又没有说明被什么卡住,你的程序就自动发一条简短的用户消息,把剩下的项列出来。官方给的示例是:“你的任务清单里还有未完成的项:迁移剩下的两个接口,并更新它们的测试。请继续完成。如果其中某项受阻,请说明是什么阻碍了它。”官方 playbook 里更推荐把清单落在文件里(比如维护一个 TASKS.md),理由是长任务会把上下文塞满、旧回合被压缩,只有落在文件里的清单能活下来,也方便你随时看到还差什么。
- 第二招,小模型当验收员。开工前就把完成条件写清楚——比如“所有接口都换成新客户端、旧客户端删除、测试通过”;每个回合结束,拿一个更小的模型对照这些条件检查一遍,没达标就把不达标的原因作为下一条用户消息发回去让它返工。这一步的意义是把“干完了吗”从模型的自觉,变成程序的判定。
- 第三招,硬刹车。同一个任务自动续跑两三次还卡在原地,必须强制停下来交回人工复查。真卡死的任务不该让 API 额度空转,这是官方明写的上限。
- 还有一条最容易被漏掉:如果模型启动的东西还在运行(后台命令、subagent),不要判定任务已完成,而是等它跑完,再把输出作为下一条用户消息返回给模型。
四、提示词怎么写:把“不想要的停法”一条条点名
官方给了一段针对完全无人值守场景的系统提示词,核心是两头堵:一边把上面四种停法逐条点名(不能用“不要提前停下”这种笼统说法),一边写清楚什么时候才准停。原文里最关键的两句是:
“A message with no tool call in it ends your turn, and the work stops there until you are asked to continue. … The stops the user does want are the ones where nothing can move without them, or where the thing blocking you is deliberately protected from you.”
翻译过来:不含工具调用的消息会结束你的回合,工作就停在那里;用户真正希望你停下的情况只有两种——没有用户就无法推进,或者阻碍你的东西是被刻意保护的、不允许你碰的。它还额外要求模型把状态说明和待定建议放在与下一次工具调用同一条消息里,而不是单独发一条然后等回复。
三条使用注意,每条都是踩过才写的:
- 要放在系统提示词末尾,并且从会话的第一个请求就加上。中途加入等于修改了 system,会导致之前生成过的 thinking 块失效,轻则被丢弃、重则直接报 400。
- 加了它之后模型会继续往下做,不再主动请示,所以你自己对高风险、不可逆操作的确认步骤必须保留——删数据、强推代码这类动作前的拦截,不能指望这段提示词。
- 有人随时在旁边回答的 human-in-the-loop 场景不要加,否则它会把本该问你的东西自己决定掉。
如果不打算改程序,官方 playbook 给了个更轻的做法:在 CLAUDE.md 里写一条规则——“当某个步骤不需要我输入时,继续做;把状态说明和下一步动作放在同一条消息里;只有在你没法在没有我的情况下继续,或者要动破坏性操作(删数据、强推、改仓库之外的东西)时才停下来问我。”另外,凡是提示词里写着“回答问题前请仔细思考”这类句子,在 Opus 5.5 上应该删掉:它每次回复前都会思考,控制思考量靠 effort,不靠喊。
五、四个会直接报 400 的迁移坑
从 Opus 5 切到 Opus 5.5,给旧模型写的请求不改就发过去,会被直接拒绝:
| 项目 | Opus 5 上的写法 | 换成 Opus 5.5 之后 | 正确做法 |
|---|---|---|---|
| thinking 参数 | {"type": "disabled"} 关闭思考,或手填 budget_tokens | 两种都返回 400 | 不传 thinking 字段,或传 {"type": "adaptive"},思考量交给 effort |
| tool_choice | 设为 any 或指定某一个工具来强制调用 | 返回 400 | 只支持 auto 与 none;要严格符合 schema 的 JSON,用 strict: true 或结构化输出 |
| thinking 块的绑定 | 回放历史 thinking 块 | 2026 年 8 月 31 日及之后创建的账号默认校验,中途改过 system、tools 或历史消息再回放会报 400 | 对话只追加、不改写;需要丢弃时就带 beta header 让它 drop |
| 电脑操作工具 | 旧版 computer 工具 | Claude API 与 Google Cloud 上要换 computer_toolset_20260801 | Amazon Bedrock 上旧工具仍可继续使用 |
还有两个不报错、但会让线上表现变怪的坑,杀伤力比 400 更大:
- 进度看不到了。Opus 5 时代,模型在两次工具调用之间写的进度文字是正文(text 块);Opus 5.5 把它们移进了 thinking 块,而 thinking 块默认
display为omitted,返回时内容为空。如果你的界面只渲染正文,长任务跑起来就是一片安静——请求一个都没失败,用户却以为它卡死了。要看进度得设display: "updates"(beta),并带上对应 header。 - 回答被截断。
max_tokens管的是思考加正文的总量。以前关掉思考时定的上限,现在可能不够用,回答写到一半就断。官方在长回合的 Agent 编码任务上给的建议是直接给到 128,000。
顺带记一笔:思考内容即使不返回给你,也照样按输出 token 计费。处理返回值时还要按块类型分开读,不要想当然地把第一个内容块当成正文;把 thinking 记录原封不动传回去这件事也要做对,删一段、改几个字、调换顺序都会被拒。
六、成本这条线:关不掉思考之后,effort 是唯一的旋钮
thinking 在 Opus 5.5 上是始终开启的,于是 effort 成了在智能、延迟和成本之间唯一的调节参数,共五档 low / medium / high / xhigh / max,默认是 medium(Opus 5 的默认是 high)。
| 结论 | 依据与数字 |
|---|---|
| 从 medium 起步,别照搬旧设置 | 官方测试:medium 在编程与知识工作上打平甚至超过 Opus 5 的 high,而且步数更少、token 更少 |
| 同档位比以前更“想” | 同一档位下 Opus 5.5 每回合的思考量比 Opus 5 更多,xhigh 与 max 尤其明显;原样沿用旧的 high,回合会变长、输出 token 会变多 |
| 想少想,就降档,别写提示词 | 降低 effort 比在提示词里要求它“别想太多”可靠得多 |
| 换档会掉缓存 | 在请求之间修改顶层 effort 会让 prompt cache 失效;只想个别回合换档,用 per-message effort(beta),缓存不受影响 |
账单侧的数字沿用上一代对比:输入 $4 / 输出 $20 每百万 token(Opus 5 是 $5 / $25),5 分钟缓存写入 $5、1 小时缓存写入 $8、缓存读取 $0.20,Batch 批处理半价 $2 / $10。其中缓存读取从 $0.50 砍到 $0.20 这一项,对我们 9 月 13 日那篇 Fable 5.1 缓存降价里算过的长对话场景影响最大——缓存读取常年占长任务账单的大头。
一句提醒:省钱的顺序是先降 effort、再管缓存,两者都别指望靠“在提示词里喊它省着点”实现。
七、我的判断
- 该上:跑无人值守 Agent、Claude Code 重度使用的人。这次官方把“续跑”这件事讲到了可执行的粒度:清单落到文件、续跑消息照抄、验收交给小模型、两三次不前进就刹车。把这四条补齐,能省掉大量反复敲“继续”的时间。
- 再等等:自己写循环、还没做完成判定的团队。先把“什么算干完”写出来再迁移,否则换模型只是把老毛病换个地方重复,而且还会撞上第五、六节那些坑。
- 别碰:把续跑提示词直接挂到无人监督的高风险操作流水线上的做法。它减少的正是“主动请示”,删除、强推、改外部系统这类动作的确认环节必须自己兜住;另外 human-in-the-loop 的对话产品也不要加这段。
- 一句话:这次的事故不是模型偷懒,而是模型跑得比脚手架快。能力只占一半,另一半在于你怎么定义“完成”、怎么保存上下文、怎么分配推理预算。
顺带一提:让 Agent 跑长任务,上下文怎么准备、完成怎么定义,这篇把 AI 编码助手接进日常工作流是实操记录。
本文由拾光札记编辑部整理,勘误请联系我们。