Opus 5.5 跑长任务总是半路停下？官方提示词指南的中文解读和可抄模板

摘要： 本文解读 Anthropic 官方《为 Claude Opus 5.5 编写提示》中关于“无人值守 Agent 半路停下”的部分，并给出可以直接复制的中文模板和一个可运行的外层循环脚本。最重要的结论是：Opus 5.5 半路停下，多数时候不是模型偷懒或出了故障，而是它在长任务中会主动发“进度报告”，其中一些报告以普通文本结束本轮回复，而很多 Agent 循环把这种结束误当成了“任务完成”。解决办法分两层：外层程序不再把文本结束当作完成，而是对照任务清单自动续跑；系统提示里点名说清楚“哪几种停法我不要”。本文适合用 Opus 5.5 跑代码迁移、批量处理、夜间长任务的开发者和 Agent 搭建者。读完本文，你能看懂停下的原因，改好自己的循环逻辑，并用附带的模板和脚本把长任务稳定跑完。

配套项目源码：下载 长任务循环脚本与中文提示词模板（ZIP）。解压后按 README.md 使用脚本与提示词模板。

核心结论

Opus 5.5 跑长任务半路停下是可以解决的，而且官方已经给出了明确的做法：改外层循环，再补系统提示。

• 停下的真正原因：官方指南说明，在包含多个部分的长任务中，Opus 5.5 会边做边向用户通报进展，其中一些更新以文本而不是工具调用结束本轮（stop_reason 为 end_turn）。如果无人值守的循环把这样的轮次当作任务结束，运行就会停在那里。
• 第一层：改外层循环。官方建议把仅含文本的轮次结束看作一份报告，而不是完成的证明；让模型在清单里维护任务进度，如果轮次结束时还有未完成事项又没说明阻碍，就发一条简短消息列出这些事项让它继续。自动续跑两到三次后应停下交人工审查，避免无限循环。
• 第二层：补系统提示。官方指出，对于点名具体过早停止方式的指令，Opus 5.5 响应很好，例如“用宣布下一步的总结结束回复，却不去执行”；同时说明你确实希望它停下的情况，效果更好。
• 别只盯着停下：官方同时提醒，Opus 5.5 的默认 effort 是 medium，思考始终开启，max_tokens 设得太小可能截断回复；在工具调用之间写的进度说明默认以空文本返回，只渲染文本块的客户端会“看起来没有任何输出”。
• 附带工具：本文的 long-run-harness 用 Python 标准库实现了续跑、次数上限、沉默提醒和时间预算，6 个离线场景测试全部通过。

背景与主要变化

Opus 5.5 发布后，开发者很快发现一个反差：模型能力明显变强，但跑 Agent 时经常干到一半就停，不催就不动。新浪 AI 热点报道称，Anthropic 在发布后几天就挂出了配套提示词指南，专门处理这类问题（第三方报道）。这份指南目前已有官方简体中文版。

先看官方描述的能力变化。指南说明，Opus 5.5 生成输出令牌的速度比 Opus 5 快 30% 以上，往往用更少令牌完成同样任务；它更能维持长时间的自主工作，例如借助并行子智能体、在很少监督下完成数小时的大型代码库审计和迁移。它关于智能体工作的报告，也会更清楚地说明做了什么、发现了什么、需要你提供什么。

问题恰恰出在“更会汇报”这一点上。下表对比了人机协同和无人值守两种场景下，同一个行为的不同后果（编辑判断）：

场景	模型行为	旧循环的处理	结果
人机协同（有人看着）	做完一部分，用文本汇报进展	把控制权交还给人	人看完回复“继续”，体验很好
无人值守（夜间跑）	做完一部分，用文本汇报进展	判定为任务结束，退出循环	早上只看到“已完成三个接口”
无人值守 + 本文改法	做完一部分，用文本汇报进展	对照清单发现未完成，自动续跑	继续做完剩余部分
无人值守 + 真的卡住	反复汇报但没有进展	续跑两到三次后停止	留给人工审查，不空转

还有几项与长任务直接相关的变化需要一并了解。官方指南说明，Opus 5.5 的默认 effort 从 Opus 5 的 high 改为 medium，并且在 Anthropic 的测试中，medium 在编码和知识工作评估上达到或超过 Opus 5 在 high 下的表现。思考始终开启，Opus 5.5 不再接受禁用思考的设置。指南建议把 max_tokens 设得足够高，因为即使思考内容没有返回，也会计入 max_tokens；对于智能体编码的长轮次，官方测试中设为该模型的最大值 128,000 效果良好。

核心功能拆解

官方针对长任务给出的做法可以拆成四个机制：清单续跑、系统提示补充、进度可见性、时间信号。前两个解决“停下”，后两个解决“看不见”和“跑太久”。

机制一：清单续跑

这是官方给出的核心 harness 改法。要点有四个：

1. 把文本结束当报告。end_turn 不等于完成，是否完成由任务清单决定。
2. 让模型维护清单。官方建议把任务的各个部分放在由模型更新的清单里，可以是待办事项工具，也可以是一个文件。
3. 两种续跑触发方式。一是清单仍有未完成项且模型没说明阻碍时，发一条简短消息列出剩余事项；二是预先写好完成条件，让一个单独的、较小的模型在每轮结束时检查对话，条件未满足就把理由作为下一条消息发回。
4. 设次数上限。同一任务自动继续两到三次后停止，让真正卡住的运行结束并等待审查。

官方还特别提醒一个容易漏掉的情况：如果模型启动的后台命令或子智能体还在运行，不要把任务视为完成，要等它结束，再把输出发回给模型。

机制二：系统提示点名具体停法

官方给出了一段示例系统提示（英文原文见文末官方链接），核心思想是把四种“工作没做完却结束回复”的方式逐一点名：写完总结宣布下一步却不执行；问“要不要继续”然后等待；列出一串其实不阻碍工作的决策问题；觉得这一轮够长或刚完成一个阶段就停下汇报。同时说清楚允许停下的情况：没有用户就无法推进，或者挡路的东西是被有意保护起来的。

使用这段提示有三条官方注意事项：从会话第一条请求起就放在系统提示末尾，中途加入会使之前的思考块失效；为有风险或不可逆的操作保留自己的确认步骤；不要在有人负责回应的人机协同应用里使用。官方还提示，加入后每个任务的工具调用和输出令牌预计会增加。

机制三：进度可见性

很多人以为模型“停了”，其实它在工作，只是你看不到。官方说明，Opus 5.5 在工具调用之间写的进度说明以思考块而非文本块返回，默认显示设置下其文本为空，只渲染文本块的客户端会在长轮次中看起来毫无输出。设置 display: "updates"（beta 功能）可以收到每条说明的简短摘要。

如果长轮次仍然沉默太久，官方建议由 harness 主动请求更新：统计连续没有任何可读内容的工具步骤，达到若干次（例如五次）后追加一条简短提醒，发送两到三次后停止。官方称，在 Anthropic 针对智能体编码任务的测试中，这使出现长时间沉默的任务比例大约减少一半，成本没有可测量的变化。

机制四：时间信号

对于多智能体设置，官方建议 harness 在每条发回模型的消息末尾加一行已用时间与预算，例如 elapsed 340s / 1200s。模型会据此调整节奏并更多地并行工作。官方同时强调，预算只是参考，到达上限时没有任何机制会阻止模型，需要硬性停止就要保留自己的超时设置。

适用人群与使用场景

这篇文章最适合“自己写 Agent 循环、让模型在无人看管时连续工作”的人。如果你只是在聊天界面里和模型对话，每轮都会亲自回复，那么“半路停下”对你来说只是正常的汇报，不需要改什么。

以下几类用户建议优先处理（实施建议，非官方数据）：

• 跑夜间代码迁移、批量重构的开发者：这是最典型的受害场景，一次停下就浪费一整晚。建议同时实现清单续跑和次数上限。
• 用 Agent SDK 或自研框架搭建自动化的团队：检查你的循环是否把 end_turn 直接当作结束条件，这是最常见的根源。站内的 AI Agent 相关教程 有更多框架介绍。
• 做批量数据处理、报告生成的知识工作者：清单可以直接用一个文本文件，每处理完一批就让模型勾掉一项。
• 运行多智能体团队的人：时间信号和并行化建议对你最有价值，但一定要配合硬超时。
• 从 Opus 5 迁移过来的用户：除了停下问题，还要按官方迁移指南检查 effort、max_tokens、禁用思考和按块类型读取响应等变化，否则可能遇到请求报错或回复被截断。

不适合的情况也要说清楚：客服、陪练、需要逐步确认的人机协同应用，不要加“不要停下来问我”这类系统提示，官方明确不建议这样做。

安装、配置或使用步骤

下面分两部分：先改你自己的循环和提示，再用附带的 long-run-harness 验证逻辑。

1. 找到循环的结束判断。在你的 Agent 代码里搜索判断 stop_reason 的位置。如果写法是“只要不是 tool_use 就退出”，这就是半路停下的根源。
2. 加一个任务清单。最简单的做法是提供一个 update_checklist 工具，让模型在完成每一项后标记；也可以让它维护一个 Markdown 待办文件。任务开始时由你写好初始清单。
3. 改写结束判断。遇到 end_turn 时：若回复中声明了阻碍，停止并交给人；若清单全部完成，正常结束；否则发送续跑消息，并累加续跑次数，超过 3 次就停止等待审查。附带脚本中对应的核心逻辑如下：

        # end_turn：只当作报告
        text = reply.get("text", "")
        if BLOCKED_MARK in text:
            return "blocked", messages
        open_items = checklist.open_items()
        if not open_items:
            return "done", messages
        if continues >= MAX_CONTINUES:
            return "needs_review", messages
        continues += 1
        log(f"[harness] 第 {continues} 次自动续跑，未完成：{open_items}")
        messages.append({"role": "user", "content": stamp(CONTINUE_TMPL.format(items="、".join(open_items)))})

4. 在系统提示末尾加入常驻指令。从会话第一条请求就加，不要中途追加。本站根据官方思路改写了中文版，措辞为原创，模型能很好地理解中文：

关于你如何结束一轮回复，这是我的长期要求：只要回复里没有工具调用，工作就会停住，直到有人叫你继续。
在我交代的工作还没做完时，请不要用下面四种方式结束回复：
一、写一大段总结，最后说“接下来我会做某事”，却没有真的调用工具去做；
二、问我“要不要继续”，停下来等一个我不会给的回答；
三、列出一串需要我决定的问题，但按你自己的判断，这些问题并不妨碍其余工作；
四、因为这一轮已经很长、或者刚完成一个阶段，就觉得适合停下来汇报。
进度说明和建议都欢迎，但请把它们和下一次工具调用放在同一条消息里，然后继续做不依赖我回答的部分。
只有两种情况可以停：没有我就完全推进不了；或者挡住你的东西是被有意保护起来的。
有风险或不可逆的操作，仍然必须先征得我确认。

5. 约定阻碍的写法。让模型在真正被卡住时单独写一行以 BLOCKED: 开头的说明，循环据此立即停止，而不是继续续跑。这个约定对应模板包中的第 5 段。
6. 检查 max_tokens 和 effort。按官方建议显式设置 effort，长轮次把 max_tokens 设得足够高；参数的具体写法以官方 effort 文档为准。
7. 处理进度显示。如果你的界面只渲染文本块，要么按官方文档开启 display: "updates"，要么至少在日志里记录工具调用，避免误以为模型停了。
8. 离线验证循环逻辑。解压 long-run-harness 后运行测试，确认续跑、上限、阻碍、提醒、超时这几条路径都按预期工作，再接入真实 API：

cd long-run-harness
python3 test_harness.py

实际工作流示例

以“夜间迁移 3 个接口并更新测试”为例，看改造后的循环如何处理各种情况。

场景一：汇报后停下 → 自动续跑 → 完成

模型迁移完接口 A，在清单里勾掉它，然后写了一句“接口 A 已完成，下一步我会迁移接口 B”并结束本轮。旧循环会在这里退出；改造后的循环检查清单，发现接口 B 和更新测试还没完成，自动发送续跑消息，列出这两项。模型继续工作，全部勾完后再结束，循环判定完成。

场景二：真的卡住 → 续跑 3 次后交人工

如果模型每次都只是汇报进度、清单没有任何变化，循环在第 3 次续跑后仍未完成，就停止并返回“需要审查”。这对应官方“自动继续两到三次后停止”的建议，避免一个卡住的任务空转一整夜、白白消耗额度。

场景三：缺权限 → 立即停止

模型发现需要数据库只读账号才能验证迁移结果，写出一行“BLOCKED: 缺少数据库只读账号”。循环识别到阻碍标记，立即停止，而不是继续发续跑消息逼它硬做。

场景四：长时间沉默 → 有上限的提醒

模型连续多个工具步骤都没有任何可读更新时，循环在第 5 个沉默步骤后附上一条简短提醒。附带脚本把提醒次数限制为 3 次，之后不再发送。需要说明的是，官方推荐以“轮次范围的系统消息”（beta）追加提醒，本脚本为了保持简单，把提醒文字附在工具结果之后，接入生产环境时建议按官方文档改用正式方式。

离线测试结果

我们用脚本化的假模型复现了 6 个场景，全部通过：半路停下后自动续跑直至完成，且只发了 1 次续跑消息；连续只汇报不干活时在 3 次续跑后返回“需要审查”；声明阻碍后立即停止；30 个连续沉默步骤中只提醒了 3 次；每条回传消息都带有已用时间与预算，到达硬超时后停止；工具抛出异常或调用了不存在的工具时，错误作为结果返回给模型，循环不会崩溃。接真实 API 的适配器只做了语法检查，没有在真实账号上长期验证。

成本估算

以下为示例计算，非官方数据。续跑本身几乎不花钱：一条续跑消息只有几十个字，最多发 3 次。真正的成本差异在“停下的代价”。假设一个夜间迁移任务需要 4 小时，旧循环在第 1 小时后停下，第二天发现后重新启动：浪费的是一整晚的等待时间，外加重新加载上下文的输入令牌。改造后，同样的任务在无人值守下自动续跑完成。官方也提示，加入常驻指令后每个任务的工具调用和输出令牌会有所增加，建议用自己的任务样本对比一下改造前后的单任务令牌消耗。

对比与选型建议

官方给出的几种做法可以组合使用，关键是按场景挑选，而不是全部堆上去。

做法	解决什么	成本	建议使用场景
清单续跑 + 次数上限	被误判为完成	很低	所有无人值守任务，必做
小模型检查完成条件	清单难以细化的任务	每轮一次小模型调用	完成标准复杂、难以拆清单时
系统提示点名四种停法	减少过早停止的频率	工具调用和输出令牌增加	完全无人值守的任务
display: "updates" + 沉默提醒	“看起来没反应”	几乎无额外成本	有界面展示进度的应用
时间预算行	多智能体跑太久	很低	多智能体团队，配合硬超时

几条选型建议（编辑判断，不代表官方结论）：

• 先改循环，再改提示。循环的误判是根源，提示只能降低停下频率，不能替代正确的结束判断。
• 人机协同应用只做可见性。有人盯着的产品里，模型汇报后停下是好事，只需要让用户看得到进度。
• 给每个长任务都设硬超时。时间预算是建议，硬超时才是保险。
• 跨多个应用的自动化，加一句“先探索再动手”。官方称这让多应用任务正确完成的比例明显上升，但要确保它搜索的记录里没有不受信任的内容。站内的 提示词专题 收录了更多写法。

风险、限制与注意事项

让 Agent 更“执着”地做完任务，同时也放大了它犯错时的影响范围。下面这些风险要一并处理。

不可逆操作必须保留确认。 官方明确说明，加入常驻指令后，模型会在原本会停下来确认的地方继续工作，因此要为有风险或不可逆的操作保留你自己的确认步骤。删除文件、强制推送、付款、对外发布、发送邮件和消息、修改权限、操作生产数据库，这些步骤都不要交给无人值守的循环自动完成。站内的 Agent 安全自查教程 介绍了如何用钩子拦截高危操作。

无限续跑与额度消耗。 没有次数上限的续跑，会让真正卡住的任务一直空转。本文脚本默认上限为 3 次，官方建议两到三次。

重试与幂等。 续跑后模型可能重复执行已经做过的步骤。清单要由模型实时更新，工具要设计成重复执行也不出错，例如写文件前先检查是否已存在。

后台任务未结束就判定完成。 官方提醒，模型启动的后台命令或子智能体还在运行时，不能把任务视为完成。自己的 harness 要跟踪这些进程，等它们结束后把输出发回。

中途修改系统提示的副作用。 官方说明，中途加入常驻指令会更改系统提示，使对话中较早的思考块失效；中途新增工具也会产生类似影响。正确做法是从第一条请求就把指令和工具都放好。

Prompt Injection。 长任务会读取大量文件、网页和工具结果，官方称 Opus 5.5 抵御间接提示注入的能力优于早期 Opus 模型，但也建议用标签标记用户粘贴的外部文本，并与其他防护措施并用，因为标签本身可以被模仿。

预算不是硬上限。 官方强调时间预算只是参考，并提示在时间压力下模型的搜索和验证可能略有减少。需要硬性停止时保留超时，并检查结果质量。

API 变更与版本差异。 官方迁移指南列出了从 Opus 5 迁移时的四项破坏性 API 变更，beta 功能也可能调整。本文涉及的参数写法以官方最新文档为准。

事实依据与来源

本文信息按可信度分级如下：

• 官方已确认：长任务中以文本结束轮次导致循环误停的原因；把文本结束视为报告、模型维护清单、发送续跑消息、小模型检查完成条件、自动续跑两到三次后停止、等待后台任务的建议；系统提示点名具体停法及其三条注意事项；进度说明以思考块返回、display: "updates"、沉默五步后提醒、提醒两到三次后停止以及测试中长时间沉默任务约减半；时间预算行与硬超时建议；默认 effort 为 medium、思考始终开启、max_tokens 最大 128,000；输出速度快 30% 以上；多应用先探索、标记粘贴文本等内容，均来自 Anthropic 官方《为 Claude Opus 5.5 编写提示》简体中文版。
• 第三方报道：开发者发现 Opus 5.5 跑 Agent 时爱中途停下、Anthropic 发布后几天挂出配套指南，来自新浪 AI 热点报道。
• 实测结果：long-run-harness 的 6 个离线场景测试为本文写作时实际运行所得；接真实 API 的适配器只做了语法检查，未在真实账号上验证。
• 编辑判断与示例计算：场景对照表、人群建议、做法选型为本站编辑判断；成本分析为示例计算，非官方数据。文中中文提示词模板为本站根据官方思路原创改写，官方英文原文请以官方页面为准。

内容核验日期为 2026 年 9 月 28 日。

FAQ

Opus 5.5 半路停下是 bug 吗？

不是 bug。官方指南说明，它在长任务中会主动发进度更新，其中一些以文本结束本轮；问题在于无人值守的循环把这种结束误当成了任务完成。

只改提示词能解决吗？

只能减少，不能根治。官方建议先改外层循环，把文本结束视为报告并对照清单续跑；系统提示点名具体停法可以进一步降低停下频率，两者配合效果最好。

自动续跑应该设几次？

建议两到三次。官方建议在同一任务上自动继续两到三次后停止，让真正卡住的运行结束并交人工审查，本文脚本默认上限为 3 次。

为什么模型明明在工作，界面却没有任何输出？

因为进度说明默认不以文本返回。官方说明，Opus 5.5 在工具调用之间的进度说明以思考块形式返回，默认显示设置下文本为空；开启 display: "updates"（beta）可以收到摘要。

常驻指令可以在对话中途加吗？

不建议中途加入。官方说明，中途加入会更改系统提示，并使对话中较早的思考块失效，应从会话第一条请求起就放在系统提示末尾。

人机协同的应用也要加这些改动吗？

不需要加常驻指令。官方明确不建议在有人负责回应的人机协同应用中使用它；这类应用只需要处理好进度可见性。

从 Opus 5 迁移过来还要注意什么？

重点检查 effort、max_tokens 和思考设置。Opus 5.5 默认 effort 为 medium，思考始终开启且不能禁用，max_tokens 过小可能截断回复；完整变更请看官方迁移指南。

参考来源

• Anthropic 官方：为 Claude Opus 5.5 编写提示（简体中文）
• Anthropic 官方：Prompting Claude Opus 5.5（英文原版）
• Anthropic 官方：为 Claude Opus 5 编写提示
• 新浪 AI 热点：Opus 5.5 干一半就停的原因（第三方报道）
• KuCoin News：Opus 5.5 中途停止的官方解法（第三方报道）

内容核验日期：2026 年 09 月 28 日

工具评测文章

工具选型与提示词资料

适合阅读工具评测、工具推荐、对比测评类文章后继续转化。

工具选型表 按场景、价格、上手难度和核心能力筛选合适的 AI 工具。 查看资料包 提示词模板包 提供写作、运营、编程、图片和视频生成常用提示词模板。 查看资料包