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

像 SWE-Bench 这样的公开基准测试衡量的是智能体完成任务的能力（例如修复一个明确定义的 bug），但目前还没有针对“目标”的基准测试。在我们最新的论文《Agentic Coding Needs Proactivity, Not Just Autonomy》中，我们认为主动式智能体必须根据其“洞察策略”来评分——即判断什么重要、有什么证据支持、以及是否应该打断开发者还是保持沉默的能力。

上图展示了主动式编程智能体引擎的设计。上下文流持续输入到一个引擎中，该引擎维护开发状态和开发者模型，输出洞察（通知、提问、草稿、保持沉默），并从响应中学习。

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

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

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

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

为构建初步基准并验证我们的假设，我们使用了来自 Google 内部代码库的 705 个缺陷（共 1178 个变更列表），以达成以下目标：

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

初步结果与我们的发现

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

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

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

下一步计划

这些是基于初始样本的初步结果，我们正在多个方面积极扩大覆盖范围。首先，我们正在将此评估扩展到公开的 GitHub 数据（问题报告及对应的修复拉取请求），以使该方法论能广泛适用于更广泛的 AI 社区。此外，我们也在探索如何引入更丰富的上下文流，例如问题追踪器、讨论记录以及代码库之外的设计文档。

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

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