2026年11月8日
那个早已关闭的缺陷，为什么又被AI工程师翻了出来
一位工程师请编码智能体定位当前模块的异常，智能体开始浏览文件、阅读调用链、搜集测试记录。代码里留下的一句TODO(bug/...)原本只是多年前一位开发者给同事的提醒，当时对应的问题已修复，工单也已经关闭。人类工程师看见这种注释，往往扫一眼就跳过去；模型却很容易把它纳入当前计划，沿着缺陷编号查资料、翻历史提交，甚至试图再次修改代码。等到工具调用和Token消耗了一大轮，最初的任务进度反而没有推进多少。这个场景并非凭空构想。Google开发者博客11月6日刊发由Sam Saccone和Madhuri Garikapati撰写的《Agent Distraction》，正是通过内部智能体工作轨迹把这类现象系统量化。过去讨论Agent效率时，业界大量比较模型排行、上下文窗口和工具调用速度，而这份研究把关注点推向一个多年被当作普通软件维护问题的角落：代码仓库里的陈旧信息如何改变智能体的行动。
Google并没有只列举几个看起来离谱的案例。它利用分布式追踪记录、代码里的缺陷引用以及工单系统中的状态，对大量会话建立对应关系。在相关文件读取会话中，约13%会遇到包含缺陷编号的TODO或FIXME注释；在这些遭遇中，智能体有大约6%的机会对相关缺陷展开后续行动，而触发行动的情况里约83%并非开发者提出的任务。跑题也不只发生在已经解决的旧问题上。Google把未经要求的行动与实时缺陷状态关联后发现，其中很大一部分指向仍处于打开状态、却不属于用户本次需求的缺陷。对于有工具权限的智能体，当前环境里存在的信息既可能是证据，也可能被误读为指令；工单真实有效，并不意味着应该在当前任务中处理。
成本不只是多读几段代码，而是工作范围被悄悄改变
脱轨会话的成本已有具体测量。Google在控制开发者、仓库复杂度、任务种类、模型层级、读取文件数量、初始提示词长度以及缺陷引用出现位置等因素后，估计未经要求的缺陷支线会带来约70%的额外步骤、77%的额外Token和105%的额外等待时间。这里的增量来自Google内部样本中的统计关联，不能直接套到所有企业的财务预算里，但它提供了此前缺乏的一类成本证据：智能体即使没有明显的功能错误，也可能因为错误任务选择产生大量真实费用。开发者最终拿到一段看似完整的答复，计费记录、长任务轨迹和人工复核时间却已经比正常情况高出很多。
通常人们把Agent成本拆成输入Token、输出Token、模型价格和GPU推理时延，很容易漏掉“任务路径”这一项。一个智能体可能先调用代码搜索、再翻缺陷追踪系统、读取历史提交、启动测试脚本、召唤子代理，最后再回到最初的问题。单次工具调用的费用并不高，但整个执行链会放大查询次数和对话状态。若企业按每个工程师配置多个并行智能体，浪费甚至会跨Agent放大：A代理把旧TODO识别为待解决事项，B代理阅读A的摘要后继续调查，C代理据此生成测试用例。最终的成本不仅是77%的Token，还可能包含CI流水线排队、代码审核和错误修改带来的返工。智能体系统的可观测性应该把“何时开始处理原任务以外的工作”单独列为指标，而不是仅统计模型请求是否成功。
代码注释正在变成一种不受控的任务入口
传统软件工程把代码、注释、README和工单看作开发者参考信息。Agent读取这些材料时，往往把它们压缩成短期工作记忆，并据此自主规划。它的优势是可以把庞杂的代码仓库和文档快速串起来，弱点则在于缺少天然的“来源权威等级”判断。用户提出的任务、仓库注释、测试日志和第三方依赖说明，可能在模型生成下一步计划时被放到接近的地位。Google案例里的TODO本身并没有恶意，所以问题更具普遍性：即使没有攻击者，也会发生类似提示注入的行动偏移。若把它放进企业研发体系，老版本技术方案、废弃需求说明、未关闭的临时工单、重复的设计文档，都会成为潜在的错误规划材料。
工业软件开发还要考虑更长的设备和代码生命周期。PLM扩展、MES接口、PLC通信程序、仿真脚本和历史设备驱动往往拥有十年以上生命周期，同一套系统经历多次外包、版本升级和现场定制。某个注释写着“待处理某型号设备异常”，可能早已被现场临时方案取代，智能体若按这句话直接修改采集逻辑，就可能影响实时系统的行为。工程代码不能只靠一般性的“不要听信文档指令”提醒解决问题，而应给工单系统、产品需求基线、已批准设计变更和工程师当前指令建立明确的权威顺序。智能体可以提出发现了旧缺陷，但在未经授权之前，不应把它自动升级为当前开发任务。
清理旧注释：先核实工单，再由人审核
Google没有采取“一律删除TODO”的激进办法，而是建立了清理型智能体。它识别代码仓库中的缺陷引用，再读取真实工单状态、代码变更历史和长期维护记录，判断某条注释是否已经失去工程价值；只有在证据足够时才发出删除建议，交由人类审核。Google称，过去六个月这类工具删除了数千条真正过时的记录，人工审核接受率超过95%。这个接受率表明清理流程具有较高可用性，但它并不等于所有潜在陈旧信息都已经识别，更不意味着系统可以不经审核自动改写生产代码。研究明确承认部分注释虽然关联已关闭的缺陷，却仍可能解释重要的历史决策，因此需要回溯版本和上下文。
从工程管理角度看，这种清理型Agent很值得借鉴。软件公司完全可以把仓库卫生整理作为独立工作流，定期对文档、注释、接口契约与测试记录进行交叉核对，输出“已失效”“待确认”“仍有效”三类状态。高风险改动必须保留审批；自动化适合做的是找到候选、聚合证据、生成最小修改建议与记录审核过程。与过去一次性大清理相比，这类持续运行的服务更贴合快节奏开发团队，也能够与每次提交的预检查结合，让旧信息减少重新沉积。清理任务与编码任务分开后，团队才能比较两者的投入产出。
为什么能力更强的模型，反而可能更容易花钱跑题
Google的技术文章特别指出，高能力模型的分心问题值得警惕。直觉上，人们会以为能力越强、推理越充分，模型越能识别哪些注释可以忽略。但复杂Agent不仅理解信息，也主动采取行动；它更有能力阅读远程文档、检索关联工单、构建测试并尝试修复。面对一个尚未处理的Bug，它可能确实有能力解决，只是这件事与当前用户指令无关。模型能力提升提高了“能做什么”的上限，却没有自动改变“该做什么”的授权规则。把主动性与任务边界混为一谈，会导致新版本模型上线后产生意料外的工具调用和代码修改。
这里涉及两个不同评价维度：目标完成率和授权一致性。研发团队不仅要问“Agent有没有完成用户任务”，还应问“它在完成任务之前做了多少未获准的工作”。测评设计可以放入带有已关闭缺陷、过时API说明和错误示例的测试仓库，观察Agent是否打开无关的维护工单、修改无关文件或重复执行高成本工具。进一步可使用同一任务对比不同模型、不同权限策略以及不同仓库清洁程度，让评价从单一Pass@1转为任务成功、范围偏移、工具调用成本与审计可解释性的组合指标。对工业客户而言，这类指标比华丽的编程演示更接近采购价值。
长任务越长，旧信息造成的路径偏移越贵
随着编程智能体从几分钟的代码补全走向持续数小时、数天的仓库维护，一次错误转向会影响后续所有决策。长上下文可以携带更多历史，但并不会自动识别哪些历史已经失效；上下文压缩如果保留了错误目标，反而可能把未经授权的支线固化为“已确认计划”。相比持续向模型添加背景材料，一个更稳妥的工程办法是把可信工作状态放在外部：明确主任务ID、已获批变更范围、允许触碰的模块、测试验收条件以及需要人工确认的动作。每次Agent重新启动或压缩上下文时，从这些权威状态恢复，而不是仅依赖它此前生成的自我总结。
仓库知识库也需要分层。官方需求和现行接口规范应与历史说明、会议纪要及待验证假设分开；搜索结果最好附上文档版本、适用产品、有效日期和确认状态。给模型提供的不是无差别堆积的“全部知识”，而是当前任务所需的最少可靠证据。工具接口也应尽量收敛，例如查询缺陷可以开放，但关闭缺陷、修改安全配置和提交合并请求要分别授权。这样一来，即便某条旧TODO引起模型兴趣，它也只能先作为发现事项记录，不能直接改变已批准的工程目标。
真正的效率提升，要从计费记录走到工程组织设计
企业采购Agent平台时，常见试点方式是选择若干高频开发任务，让模型生成代码和测试，再和人工工时比较。这种方法可以判断短期可行性，却不容易衡量真实环境的长期成本。规模化以后，版本仓库的治理、权限与审计、流水线容量、异常恢复和审批等待，都会成为总成本的重要组成部分。Google的研究提示管理者，把任务外调用率、人工拒绝率和历史信息误导率纳入平台看板，再与每次提交的质量指标交叉分析，才能看见智能体“工作量增加、有效产出没有同步增长”的情况。
面向Agent的代码与知识环境维护，正在成为软件企业的日常工作。它与传统软件配置管理、技术文档管理类似，却更强调对机器决策的直接影响。工程主管可以挑选一批典型老项目试点，先标注权威需求，再把过期工单与注释进行自动核对，最后对比Agent任务路径和成本。若改进有效，再把规则扩展到研发规范、CI检查与项目移交。这样做并不需要等待通用大模型下一次巨大升级，却能立即回应智能体在实际生产中的痛点。
建立一份面向智能体的可执行工程基线
一个可落地的改进方法，是由项目负责人整理一份随版本更新的工程基线文件：包括当前任务工单、允许修改的目录、有效需求文档、关键接口版本、测试入口与审批人。Agent开始工作前先读取这些受控材料，再使用按需搜索去找补充证据；读到历史注释时，仅将其记录为可能相关的背景，不主动扩展工作范围。企业还可定期使用批量脚本或智能体扫描无效工单引用，但删除建议必须带上对应的工单状态、最近一次代码修改和责任人审核记录。实施几周后，将有基线和没有基线的任务对照，观察任务外工具调用和人工复核次数变化，便能衡量治理投入是否值得长期持续。
参考资料
- Google Developers Blog，Sam Saccone、Madhuri Garikapati，Agent Distraction，2026-11-06： https://developers.googleblog.com/en/agent-distraction/
- Google Developers Blog主页，2026-11-06更新条目，进一步说明研究范围： https://developers.googleblog.com/
- 本文对软件工程、工业研发流程与智能体治理的建议属于编辑部分析，不是Google公布的额外实验结果。