Google Labs 提出用“洞察策略”评估 AI 编码智能体的主动性

Measuring What Matters with Jules 1.0

AI 编程智能体正迅速从被动式助手——即在收到提示后才完成任务——转变为主动式引擎：持续吸收上下文、发现新出现的风险，并在开发者开口询问之前就呈现诊断洞察。这一演进的核心，是从定义明确的任务转向目标，后者要求智能体探索代码库、发现相关内容，并呈现有助于引导开发者迈向更高层目标的诊断观察结果。

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

overview-abstract

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

利用真实 bug 修复作为“真值”

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

我们的假设很简单：当工程师在短时间内提交并修复多个相关 bug 时，这些 bug 往往是同一项底层工程工作的症状。围绕“沙箱超时错误”、“broker 配置失败”和“网络隔离不稳定测试”聚集的一批 bug，都指向一个共同的愿景目标，例如“增强沙箱执行可靠性”。单独来看，每个 bug 都过于任务特定，无法作为目标。它们合在一起，则揭示了更高层次的目标。

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

为了构建我们的初步基准并检验我们的假设，我们使用了来自 Google 内部代码库的 705 个 bug（1,178 个 CL），以：

对相关的历史 bug 进行聚类，以揭示开发者实际正在努力实现的更高层次“愿景目标”。
将每个聚类中的各个 bug 设为我们的“基准真相”目标，并将代码库回退到其修复前的确切状态，使智能体从人类工程师起步的同一位置开始。
允许智能体在生成最终洞察之前，对代码库进行最多三轮的探查（即其“探索预算”，或称 N）。
使用一个 LLM 来评判智能体预测的洞察，对照我们的“真实基准”目标，从 1（不相关）到 5（完全匹配）进行打分。
通过追踪智能体的平均最高分以及它成功产出高度准确匹配的频率（Hit@K）来衡量成功与否。

初步结果与我们的收获

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

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

探索预算很重要：复杂、多维度的问题自然更难，但给智能体更多资源去探查会带来回报。将探索预算从两轮增加到三轮后，智能体的 Hit@5 准确率（定义为正确的诊断洞察出现在其前 5 条推荐中的比率）从 33% 显著回升至 57%。这证明额外的探查轮次能直接帮助智能体发现它最初遗漏的次要信号。

下一步

这些是在初始样本上得出的初步结果，我们正在多个方向上积极扩大覆盖范围。首先，我们正在将这一评估扩展到公开的 GitHub 数据（issue 和已解决的 PR），以使该方法论能够广泛适用于更广大的 AI 社区。我们还在探索如何引入更丰富的上下文流，例如 issue 跟踪器、对话和设计文档，而不仅仅局限于代码库。

在此处阅读完整论文，如果你有兴趣进一步了解我们在 Google Labs 关于编程未来的工作，欢迎在labs.google/code关注我们。