# Claude Opus 5.5 速度提升三成，却可能提前结束任务

**Summary:** Anthropic 称 Opus 5.5 速度提升超 30%，但无人值守运行可能在工作未完成时就结束回合。我会将完成状态设为明确的控制框架状态，而非从 end_turn 推断。

- Canonical: https://markhuang.ai/zh/news/claude-opus-5-5-end-turn-is-not-done
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-09-28
- Section: News
- Tags: Claude Opus 5.5, AI 智能体, 智能体控制框架
- Source: [Claude Platform Docs](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5-5)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![机械臂仍在搭建发光的电路桥，但琥珀色的闸门已经拦住了未完工的路](https://cdn.markhuang.ai/news/claude-opus-5-5-end-turn-is-not-done/hero.webp)

*机器还能继续干活，但控制循环已经判定这一轮结束了。*

Anthropic 说 Claude Opus 5.5 的输出速度比 Opus 5 快了 30% 以上。但他们新的[提示指南](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5-5)也提了个醒：没人盯着的智能体可能在任务还没做完的时候就结束回合、丢出一份进度报告，而 API 照样返回 `stop_reason: "end_turn"`。

如果是我做升级审查，这一点会排在最前面。Opus 5.5 确实更快、更高效，但直接对接 API 的集成很容易把模型的对话暂停当成任务完成。控制框架一旦关了任务、释放了资源、告诉用户"搞定了"，模型再强也补不回漏掉的步骤。

在我看来，这其实不是提示工程的问题，而是完成契约的问题。生产环境里的智能体得自己维护一份"还剩什么、什么算做完、什么时候可以安全进入下一轮"的账本。模型返回的停止原因只是其中一个参考信号。

## 更便宜的模型依然改变了契约

先看价格。[Anthropic 给 Opus 5.5 的定价是每百万输入 token 4 美元、每百万输出 token 20 美元](https://www.anthropic.com/claude-opus-5-5)，比 Opus 5 的 5 美元和 25 美元都低了一档。官方估计典型默认工作负载下成本能降 40%——不光单价便宜了，新模型每个任务用的 token 也更少。Anthropic 另外写了一篇[成本拆解](https://claude.dev/blog/what-a-task-costs-on-opus-5-5/)，说得很清楚：光降价部分就让示例会话省了约 31%，剩下能省多少得看具体任务。

配置也不是直接搬过来的。Opus 5.5 默认 effort 是 `medium`，不是 Opus 5 的 `high`，而且 adaptive thinking 始终开启。[迁移指南](https://platform.claude.com/docs/en/models/opus-5-5/migration-guide)说得很明确：直接用 Messages API 的客户端要按类型读响应块、在工具循环里保留 thinking 块、去掉不支持的强制工具选择、重新检查 token 上限。Anthropic 说托管智能体只改模型名就行，所以这些麻烦主要落在自己写循环的团队头上。

## `end_turn` 不是完成证书

Anthropic 描述了一种很具体的翻车方式：长任务跑到一半，Opus 5.5 可能吐一段进度报告就直接结束回合，活还没干完。如果你的循环把任何纯文本的 `end_turn` 等同于"成功了"，那就停在这儿了。指南的建议是把任务拆成清单，还有未完成项、也没报阻塞就继续推，自动续接两到三次之后如果同一个任务还是做不完，就停下来等人看。

```mermaid

flowchart TD
    A[模型返回 end_turn] --> B{必需项已完成？}
    B -->|是| C[标记任务完成]
    B -->|否| D{已声明阻塞？}
    D -->|是| E[显示阻塞]
    D -->|否| F[继续处理未完成项]
    F --> G{达到续接上限？}
    G -->|否| A
    G -->|是| H[停止以供审查]
```

> **Warning:**
>
> 我会把 `stop_reason` 当成通信层面的结果。任务算不算完，得看它声明的输出和校验是不是都到位了。

这个区分很关键，因为 `end_turn` 本身没有错——模型确实结束了它的回合。出问题的是控制框架把这个信号解读成了比 API 实际承诺的更强的含义。

## 清单让循环有据可查

我的做法是把完成状态放到模型外面去维护。控制框架记下要交付的东西和必须过的检查项，每轮结束后拿实际产出和工具结果跟这份记录对。还有活没干完的话，下一条消息就把未完成项点名列出来，别含糊地跟模型说"你继续"。

Anthropic 还建议拿一个更小的模型来审视对话，在工作不完整时给出原因。这招可能有用，但我不会让第二个模型当唯一裁判。测试、预期文件、结构化的任务状态、明确的审批——这些证据更硬。小模型能帮你抓出不一致的地方，但它没办法把一份模糊的需求变成一条客观的终点线。

续接上限也不能忽视。自动推一把可以把过早停下来的任务救回来，但不设上限的话，卡住的智能体会一边重复一边烧 token。重试两到三次、然后抛出一个可以人工审查的阻塞，这是比较合理的默认策略。高风险或不可逆的操作仍然需要单独的确认关卡。

## 界面也可能把进度藏起来

Opus 5.5 改了进度更新出现的位置。工具调用之间的文本现在放在 `thinking` 块里，默认显示模式会把这些内容留空。只渲染普通文本的客户端在长任务期间可能看起来一片死寂，哪怕智能体其实在干活。Anthropic 说开发者可以请求摘要模式或只展示更新内容的 thinking 显示，然后在每次工具调用前把非空的块渲染出来。

这事跟完成状态是两码事，但两种故障会互相叠加。用户先看到一片安静，然后收到一份打磨过的进度报告。控制框架看到 `end_turn`。就算清单上还有未完成项，表面上也像是一个自然的收尾。

我在[Fable 5.1 把思考历史改成只追加](https://markhuang.ai/news/claude-fable-51-thinking-history-append-only)那篇里也说过类似的观点：模型升级越来越多地在改变模型周围的对话契约。光看最后的文本已经不够了，没法正确地驱动循环。

## 公开测试没有覆盖这个边界

有个详细的[Reddit 评估](https://www.reddit.com/r/ClaudeAI/comments/1woicc1/opus_55_is_the_real_deal_same_accuracy_as_fable/)跑了 23 个任务，说 Opus 5.5、Opus 5、Sonnet 5 和 Fable 5.1 在默认配置下全都通过了。10 个独立的工作类任务里，Opus 5.5 在低 effort 和高 effort 下每次都过，低 effort 还更省钱。作者也指出了样本量小、任务都是同一个人写的、用的是 Claude Code 控制框架这些局限。

[Hacker News 上有人抱怨](https://news.ycombinator.com/item?id=49821657)说 Opus 5.5 做代码审查时因为推理相关的原因拒绝了请求，而老模型对同样的提示是接受的。这是一个没经过验证的报告，不能说明普遍问题。但它确实说明控制框架必须分清成功、拒绝、明确阻塞、未完成的进度报告——这些都是不同的状态，哪怕它们都以结束回合收场。

## 先升级状态机再说

在把生产流量切过去之前，我会拿需要多轮工具交互的长任务重跑一遍，其中一些故意埋个阻塞。我要看循环能不能把没做完的活捡起来、把真正的阻塞报出来、在续接上限处停下来、审批关卡还在不在。我也会算每个被接受任务的成本——模型便宜了，但如果多了不少可以避免的续接回合，省下来的钱可能又吐回去一部分。

然后我会盯着基准图里通常不画的那条失败曲线：报称完成、但其实还有必要项没做完的任务。在无人值守的工作流拿到更多权限之前，这个数字应该是零。

Opus 5.5 确实可能在更短的时间里干更多的活。但我仍然不会让 `end_turn` 来关工单。控制框架得证明的是任务本身做完了，而不只是这一轮结束了。