Claude Code 的“自动继续”功能：一次功能失误的剖析

Claude Code：剖析一个错误的功能目录"Mechanical egg timer" by Hustvedt 采用 CC BY-SA 3.0 许可。已填充至更宽的画框；本改编同样采用 CC BY-SA 3.0 许可。

2026年加拿大国庆日（7月1日），Anthropic 向 Claude Code 用户推送了一个令人惊讶的“彩蛋”：2.1.198 版本包含一个效率旁路，允许智能体在未收到人类指令时继续运行。

本质上，在 Claude Code 请求输入后，你会得到一个60秒的计时器。如果你错过了这个窗口，Claude Code 会“贴心”地自行判断并继续执行。效果如下：● Claude 询问：⎿ …● 60秒后无响应——未收到答案，继续执行● 用户走开了。

我将根据最佳判断继续。我的计划：注意：以上内容直接摘自笔者的一次 Claude 会话，问题部分已做删减。如果你觉得这种行为令人惊讶，你并不孤单。让我们考虑一下可能的后果：- 做三明治时，你是否必须把笔记本电脑带进厨房？

如果你在这60秒内离开怎么办？- 你同时运行多少个智能体？你能同时观察它们全部吗？如果两个或多个智能体在同一60秒窗口内请求你的输入怎么办？- 如果智能体做出了错误的选择怎么办？在此期间浪费了多少 token？

- 如果你使用智能体进行部署怎么办？

（是的，我知道，但万一呢）这些都是你在发布此功能时可能会考虑的合理问题，也许你会在更新日志中记录你的理由。但如果你根本没有在更新日志中提及新的默认行为呢？那岂不是更令人惊讶？（剧透：确实如此！

）这个故事有一个（某种意义上的）圆满结局。快速行动和打破常规并不一定意味着不能快速行动和修复问题。几天内，修复版本就发布了，但这让用户对该产品的信任度如何呢？我们学到了一些东西：- 理论上（和实践中），

Anthropic 可以每天向 Claude Code 推送令人惊讶的功能- 并非每个功能都一定会出现在更新日志中- 本不应成为默认设置的功能可能没有文档化的关闭开关- Claude Code 的自动更新功能感觉比我们早期怀疑的更接近“YOLO 模式”有几件事我不确定我们

是否学到了：- 人类在这个等式中扮演什么角色？- 这个功能是人类构思的吗？- 是人类编写（或让智能体编写）了这个功能吗？- 人类审查过这个功能吗？- 人类批准了这个功能吗？- 人类合并了这个功能吗？

- 是否有人选择不记录此功能或将其添加到更新日志中？- 是否有一位人类发布经理将本次发布与上次发布进行了对比，并在发布前给予了批准？

就我个人而言，我很难相信一个人在未问“这是个好主意吗？”的情况下就通过了所有这些步骤。如果你告诉我，实际上是 Claude Code 自己构建了该功能、发布了它、批准了它，然后认为它不值得记录，我更倾向于相信这一点，但我就是不知道。

也许是这两者的某种结合。也许很多事情都出了问题，但我认为很明显，这根本不应该发生。我这么说，是因为我至少经历过一次绩效评估，我的经理说：“嗯，你确实在生产环境中引入了一个严重错误。”我一直在思考这是如何发生的，以及公开记录中有哪些事后分析。

所以，我让 Claude Code 调查它自己。值得称赞的是，它似乎没有阻止自我反思的过滤器。所以，充分披露：以下内容主要是 Claude 的工作，请自行判断其价值，如果你依赖任何关键假设，最好单独验证它们。

Claude 的研究从这里开始。#时间线- 2026-06-29 — 2.1.196 发布；报告者称其为“最后一个正常工作的版本（我猜的）”- 2026-06-30 — 2.1.197 发布；

一条更新日志，关于 Sonnet 5 的发布- 2026-07-01 — 2.1.198 发布——报告者将此版本认定为回归的根源。没有公开的提交显示这一变更；

此版本的唯一公开痕迹是机器人提交的发布说明（75709ea），只修改了 CHANGELOG.md 和 feed.xml。

- 2026-07-02 02:54 UTC — Aleksey Nogin 提交了 issue #73125- 2026-07-02 03:45 UTC — 一位评论者揭示了逃生舱口：CLAUDE_AFK_TIMEOUT_MS。

在讨论串中直接交流，未指向任何发布说明- 2026-07-02 — 2.1.199 发布，包含24条更新条目，此时 issue 仍处于开放状态。仍未提及此功能- 2026-07-03 — 2.1.200 撤销了该行为；

同样，唯一的公开痕迹是发布说明提交（1322e9b）- 2026-07-04 18:04 UTC — issue 关闭- 该 issue 的反应/规模：384 👍，143 条评论——并非小众投诉- 报告者的环境：2.1.198，

“最后一个正常工作的版本 2.1.196（猜测）”，Opus，AWS Bedrock，VS Code 终端

git clone https://github.com/anthropics/claude-code.gitcd claude-code# 修复是在什么时候、哪个版本中发布的？

git log -1 --format='%h %ai' -S'no longer auto-continue by default' -- CHANGELOG.md# 1322e9ba 2026-07-03 16:52:

26 +0000# 包含 bug 的版本是什么时候发布的？git log -1 --format='%h %ai' -S'## 2.1.198' -- CHANGELOG.md# 75709eac 2026-07-01 20:45:

29 +0000#该错误功能AskUserQuestion 是 Claude Code 用于在任务中途停止并向人类提问的工具- 新行为：

在不活动60秒后，该工具自动返回“无论如何继续”的结果，而不是阻塞- 返回给模型的消息——这是模板，以60秒默认值渲染：// v2.1.198，逐字逐句。`Thl` 是压缩器的名称；文本是二进制文件自身的。

// 注意 "60s" 是插值得到的，不是文件中的字面量：

function Thl(e){return `No response after ${Math.round(e/1000)}s — the user may beaway from keyboard. Proceed using your best judgment b

ased on the context so far;you can re-ask this question later if it's still relevant. `}- “稍后重新询问”的逃生舱口是循环的：重新询问的问题会触发相同的超时。

Aleksey Nogin 在提交 issue 后几分钟内就在讨论串中指出了这一点- 记录行有两个变体——二进制文件根据你是否已经开始回答来选择：// v2.1.198，逐字逐句。

`a` 是压缩器对“存在一些答案”的命名//（`s=Object.entries(r)` 在答案上，`a=s.length>0`）；两个字符串值// 都是二进制文件自身的。let d=a?

"continued with the answers selected so far":"continued without an answer"- 因此，一个回答了一半的对话框不会丢弃部分输入——它会提交它。

回答三个问题中的第一个，然后离开，超时会提交你的一个答案以及模型为其他两个选择的任何答案- 两个字符串在 2.1.197 中都不存在，而在 2.1.198 中出现- 公平地说：屏幕上并非静默。

对话框会显示实时倒计时，按键会重新启动计时器。这是在运行时组装而非存储为单个字符串，因此这是渲染形式，而非直接的 grep 命中：// v2.1.198，逐字逐句——各个部分。`s` 是剩余秒数。

children:["auto-continue in ",s,"s \xB7 any key to stay"]// 渲染为：auto-continue in 12s · any key to stay- 但这并没有看起来那么有用。

倒计时只对正在看屏幕的人有效，而该功能的前提是你不在看屏幕：- 内部名称是 AFK；消息说“用户可能远离键盘”- 同时运行多个智能体时，“看屏幕”并不是一个地方——你需要的倒计时可能在另一个标签页上- 而且倒计时出现得很晚。

阈值默认为20秒（CLAUDE_AFK_COUNTDOWN_MS），并且它基于剩余时间而非已过时间——因此前40秒内，对话框看起来就像一个普通的阻塞问题。

它在屏幕上，但没有任何内容表明计时器正在运行：// v2.1.198 发布了这个压缩版本——局部变量被混淆了，但属性// 名称保留了下来，所以 `showCountdown` 和 `remainingSe