代码里的 TODO 如何让智能体跑偏

Google Developers Blog#编码智能体#成本优化#任务边界

Editor brief · 编辑速览

对逾 91.3 万次编码智能体会话的分析发现，遇到指定格式 TODO 注释时，6% 会采取行动，其中 83% 未获开发者要求。这类偏离伴随步骤增加 70%、令牌增加 77%、等待时间增加 105%，提示团队清理过期注释并约束任务范围。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

代码里一条早已失效的 TODO，人类可能扫一眼就过去，AI 编程代理却可能把它当成待办任务，查工单、搜历史，甚至顺手改代码。Google Developers Blog 的这篇文章讨论的，就是这些遗留注释如何让代理偏离用户交代的工作。

作者基于大规模代理交互记录发现，干扰不只来自过期信息：仍然有效、但用户没有要求处理的问题，也会诱发任务越界。对日常使用 AI 编程的团队来说，代码库清理因此多了一笔需要重新计算的收益。

代理在规划和调查阶段会读取文件，代码、注释和文档都会进入上下文。人类通常能区分「历史遗留提醒」和「眼下必须处理的任务」，代理却可能把遇到的问题直接理解为行动线索。

工具和技能越多，这种偏移越容易继续扩大。看到一个 bug 编号之后，代理可以查询工单、搜索代码、检索内部知识，再进入修改流程。一次看似积极的探索，就可能变成用户没有安排的支线任务。

代码库里存在一个问题，不等于当前任务授权代理处理它。

作者选择行内 TODO(bug/...) 和 FIXME(bug/...) 作为观察入口。原因很实际：注释可能多年没有更新，关联工单却有相对明确的状态记录。把代理遇到的注释、工单状态和用户提示词交叉检查，就能识别一部分无效调查与任务越界。

这是一种可规模化的代理指标，但它覆盖的是带 bug 引用的注释，不能直接代表所有文档和代码对代理造成的干扰。

分析覆盖数千名工程师、数亿个代理步骤；在数百万次读取文件的会话中，13% 的会话让代理接触到了上述 bug 引用，接近七分之一。

接触之后，大多数代理没有继续行动：94% 的遇见被忽略，6% 触发了针对该 bug ID 的后续动作。在这些触发动作的会话中，83% 没有得到开发者的明确要求。

因此，不能把 83% 理解成「所有 AI 编程任务都会跑偏」。它描述的是已经发生后续动作的那部分会话。

对未经要求的支线调查，作者又按工单状态做了拆分：

这里有两种不同的失败。追查已关闭问题，主要浪费调查成本；主动处理仍开放的问题，则可能扩大改动范围，增加审核负担。后者即使修得正确，也未必符合用户当前的优先级。

作者还用多向固定效应回归，控制开发者、代码库复杂度、任务类型、模型档位、读取文件数、初始提示词长度，以及 bug 引用出现的步骤，并按开发者聚类计算标准误。文中称额外开销在统计上显著，均为 p<0.0001。

但提供的原文在「每次会话」之后没有列出具体开销数值。我们无法据此知道平均多花多少 token、步骤或时间，也不能仅凭显著性判断影响有多大。

第一个案例发生在一次无关 bug 的调查中。代理读取 SurfaceControlTest.java，遇到了这样的注释：

// TODO(bug/XXX)

要注意的是 bug/XXX：它关联的问题在 2023 年已经修复，注释却仍然把代理引向了额外调查。

第二个案例里，代理遇到 TODO 后，主动执行了多次 Code Search 和内部知识查询，最终修改了 ModelDownloaderV1。直到人类质疑范围扩大，模型才承认这次扩展不合适。作者将两个案例都描述为轻微绕路，但它们确实消耗了时间、token 和人工干预。

他们团队随后用代理扫描代码库，寻找已修复或过时的 bug 引用。不过，工单关闭只是筛选条件，不能直接作为删除依据。

一条 TODO 可能仍然解释着某段特殊实现，或者记录着必须保留的限制。清理代理还要检查工单历史、文件历史和代码变更，有时需要回溯多年。只有确认注释及其背后的意图都已过时，才提交删除变更供人审核。

按作者报告，这套流程在过去 6 个月清除了数千条实际过时的引用，人工审核接受率超过 95%。这个数字支持清理方案具有可用性，但不能直接换算成编程代理的效率提升。

我认同作者对维护成本的重新估算。过去，一条过期注释可能只是阅读噪声；代理能够调用工具之后，它还可能引出搜索、修改和审核。代码库是否适合代理工作，确实不能只看主流程代码是否整洁。

不过，这项观察研究仍有边界。固定效应回归控制了多种因素，却不等于随机对照实验；原文也没有交代具体模型、完整识别规则，以及如何判断某次 bug 调查确实不属于用户需求。把这些比例直接套到一般前端团队，依据还不够。

清理历史信息与约束代理范围，也应该一起做。前者减少误导来源，后者处理「问题有效，但当前不该做」的情况。只删除过期 TODO，解决不了那 57% 指向开放工单的支线调查。

相比人工顺手维护，自动扫描更适合大规模代码库；相比按工单状态批量删除，作者增加历史核查和人工审核的做法更稳妥。但原文没有给出这些替代方案的成本与效果对照，不能据此宣布哪一种投入产出最高。