Google：智能体被旧 TODO 带偏，绕路会话多花 70% 步数

你仓库里有没有那种三年前留下的 TODO，后面跟着个 bug 编号，bug 早修完了，注释还在原地站岗？（谁家仓库没几条这样的）人扫一眼就过去了，智能体不会。

11 月 6 日，Google 开发者博客发了一篇讲“智能体分心”的研究，拿内部数以百万计的编程智能体会话算了一笔账：没人要求、智能体却自己跑去追 TODO 里那个 bug 的会话，每场多出 70% 的步数、77% 的 token 和 105% 的等待时间。我们 AI主线 的看法是，编程智能体会把代码库里残留的旧注释当成待办事项，每一次没人要求的绕路都有看得见的成本。旧注释不再只是看着碍眼的小毛病。

13% 的会话撞上旧注释，真正中招的到底多不多？

先说清楚这数怎么来的。Google 要在海量会话里找一个能自动判断的信号，挑中了代码里的 TODO(bug/...) 和 FIXME(bug/...)，因为注释常常在 bug 解决或放弃很久之后还留着，而对应的工单才是权威记录。把智能体读到的每条 TODO，跟工单状态和用户的提示词一对照，哪些是正经活、哪些是白跑一趟，机器就能分出来。

结果是：13% 的读文件会话碰到过这类注释；碰到之后，94% 的情况智能体视而不见，6% 会针对那个 bug 编号接着动手；动手的里面，83% 是开发者压根没提过这个 bug。

按这几个比例粗算，全部会话里中招的不到 1%。听着不多，对吧？可会话量是数以百万计，而且每次中招都是实打实的多花钱、多等人。就像新人翻交接文档，看见一句“这块还有坑”，老员工知道早填了，新人不知道，于是认认真真查了一下午。

追的是死胡同，还是没人让它碰的活儿？

这批无人要求的绕路，Google 又拿工单状态拆了一遍，出来两种完全不同的毛病。41% 追到的是已关闭的工单，其中 32% 早已修复验证，9% 是废弃或不修的死胡同。另外 57% 的工单还开着，智能体把活儿越干越大：61% 只是查了一圈，39% 动手改了代码。

39% 乘一下，五分之一出头的绕路改了开发者没让碰的代码。博客里的例子就是这样：智能体顺手去“修”了 ModelDownloaderV1，后来被人类质问越界，它自己也承认扩大了范围。

我觉得这两种毛病不能混着看。说到底，一个是仓库脏，一个是智能体手欠。前一种把过期注释删干净就能治；后一种就算注释写得再干净，只要还有开着的工单摆在眼前，它照样可能去接这个支线任务。Google 的清理方案对后一种基本使不上劲，这块更可能得靠任务边界和权限设置去管。

Google 自己怎么收拾：让智能体去删旧账

他们写了一批智能体，扫遍全部代码库，找出工单已标记为修复或废弃的 bug 引用。光扫出来还不够，因为 TODO 可能是“承重墙”，所以智能体还要回头翻 bug、文件和代码的历史，有时要追溯好几年，确认注释和它背后的意图都过期了，才提交修改请求交给人审核。

按 Google 自己的说法，这个清理器过去 6 个月删掉了数以千计的过期引用，人工审核的通过率超过 95%。这是 Google 内部自报的数，外部没法核对，但路子很清楚：让智能体去清理会把智能体带偏的旧账，再交给人把关。这类技术债以前没人排期，是因为看不出价值；现在有了绕路多花七成步数这笔账，优先级自然能往前挪。

这份数据能直接套到你的仓库吗？

得泼一点冷水。这些数字来自 Google 内部的工程环境，用的是内部代码搜索和内部工单系统，外部拿不到会话轨迹，没法复核。回归分析控制了开发者、代码复杂度、任务类型、模型档次等变量，统计显著性也很高，但那只能说明在 Google 的环境里这个效应站得住。换成你的仓库，比例肯定会变，方向我倾向于认为不会变。

往大了看，这篇和上下文工程那条线接得上。Anthropic 在 2025 年发布的上下文工程文章，把上下文当成有限资源，塞得越多回报越低，业内管这叫 context rot。Google 这篇补的是另一个角度：上下文里除了可能太长，还可能混着过期的内容。有的文章把后一种叫 context poisoning，跟前者是两码事。

对天天开着 Claude Code、Cursor、Codex 的开发者来说，自家仓库有多少这种雷，半小时就能摸个底：把带工单号的 TODO 捞出来，对着工单状态过一遍。负责选型和治理的技术负责人，也多了个新指标：Google 在博客里写的“对智能体友好的代码库”，看的是犄角旮旯干不干净，主路径写得好不好只是一半。

接下来我想盯两件事：这类扫描清理会不会变成提交前检查里的标配，还有各家编程智能体会不会在“没人让我碰的活儿”上学会踩刹车。