AI 编码智能体正迅速从被动的响应式助手——在收到提示后完成任务——转变为主动引擎，持续吸收上下文、发现新出现的风险，并在开发者提问之前就呈现诊断性见解。这一演进的核心是从“明确定义的任务”转向“目标”，后者要求智能体探索代码库、发现相关线索，并呈现诊断性观察结果，从而引导开发者朝着更高级别的目标前进。

像 SWE-Bench 这样的公开评测基准测试的是智能体完成任务的能力，比如修复一个精确定义的 bug，但目前尚不存在针对“目标”的评测基准。在我们最新的论文《智能体编码需要主动性，而不仅仅是自主性》中，我们认为主动型智能体应当根据其“洞察策略”来评分——即判断什么重要、有什么证据支持、以及是否应当打断开发者还是保持沉默的能力。

利用真实 bug 修复作为“基准真相”

基于我们在 Google Labs 对连续 AI 系统的研究，我们发现要构建能够根据洞察策略对主动型智能体评分的评估体系，必须建立“基准真相”。构建这种“基准真相”的一种方法是，根据我们称之为时间邻近性和语义相似性的两个启发式指标，分析团队的真实 bug 修复历史。

我们的假设很简单：当工程师在短时间内提交并修复多个相关 bug 时，这些 bug 往往是单一底层工程工作的症状。围绕“沙箱超时错误”、“代理配置失败”和“网络隔离不稳定测试”等问题的一批 bug，都指向一个共同的期望目标，比如“增强沙箱执行可靠性”。单独来看，每个 bug 都太具体，不足以作为目标。而放在一起，它们揭示出了更高级别的目标。

构建并测试我们的初步评估集

为构建初步基准并验证我们的假设，我们使用了来自 Google 内部代码库的 705 个 bug（共 1,178 个变更列表），用于：

• 将相关的历史 bug 聚类，以揭示开发者实际在解决的更高层级的“愿景目标”。
• 将每个聚类中的单个 bug 设为我们的“真实结果”目标，并将代码库回滚到修复前的精确状态，使智能体从人类工程师的起点开始工作。
• 允许智能体在生成最终洞察之前，对代码库进行最多三轮的探索（即其“探索预算”，记为 N）。
• 使用大语言模型对智能体预测的洞察进行评分，从 1 分（不相关）到 5 分（完全匹配），对照我们的“真实结果”目标。
• 通过追踪智能体的平均最高得分以及它成功生成高精确匹配的频率（Hit@K）来衡量成功率。

初步结果与我们的发现

我们测试的初步结果令人振奋，主要有两个原因。

核心诊断逻辑有效：在单轮探索下，智能体始终能识别出高度相关的洞察（平均得分 4.5 / 5）。对于简单的工程问题，它成功捕捉到了主要信号。

探索预算至关重要：复杂、多层面的问题自然更难，但给予智能体更多资源进行探索是值得的。将探索预算从两轮增加到三轮后，智能体的 Hit@5 准确率（即正确诊断洞察出现在其前 5 条推荐中的比率）从 33% 显著回升至 57%。这证明额外的探索轮次直接帮助智能体发现了最初遗漏的次级信号。

下一步计划

这些是针对初始样本的初步结果，我们正在多个方向积极扩大覆盖范围。首先，我们正在将这一评估扩展到公开的 GitHub 数据（即 issue 及对应修复 PR），以使该方法适用于更广泛的 AI 社区。此外，我们也在探索如何摄入更丰富的上下文流，例如 issue 追踪器、讨论记录和设计文档，而不仅仅是代码库本身。

在此处阅读完整论文，如果您有兴趣了解更多关于 Google Labs 在编程未来的工作，请关注 labs.google/code。

• 网络
• 人工智能
• 案例研究
• 学习
• 影响力