AI HOT 精选

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

8.5内容质量
Google Labs 提出用"洞察策略"评估 AI 编码智能体的主动性

TL;DR · AI 摘要

Google Labs 提出用“洞察策略”评估 AI 编码智能体的主动性，而非仅按任务完成度打分，实验显示探索预算增加可显著提升准确率。

核心要点

  • 探索预算从两轮增至三轮时，Hit@5 准确率从 33% 升至 57%。
  • Google 使用 705 个 bug（1178 个 CL）构建评估集，基于时间邻近性和语义相似性聚类。
  • Jules 在单轮探索下洞察相关性评分平均 4.5/5。

结构提纲

按章节快速跳转。

  1. §引言

    AI 编码智能体正从被动助手转向主动引擎，需要新的评估方法。

  2. ·洞察策略的提出

    Google Labs 提出以“洞察策略”评估 AI 编码智能体的主动性，而非仅按任务完成度打分。

  3. ›构建“基准真相”的方法

    基于时间邻近性和语义相似性聚类，分析真实 bug 修复历史以构建“基准真相”。

  4. ·构建并测试初步评估集

    使用 Google 内部代码库的 705 个 bug 构建评估集，并测试智能体的洞察能力。

  5. ›探索预算的影响

    探索预算从两轮增至三轮时，Hit@5 准确率显著提升。

  6. ·下一步计划

    Google 正在将评估方法扩展至公开 GitHub 数据，并探索纳入更多上下文。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • 洞察策略评估 AI 编码智能体
    • 评估方法
      • 基于真实 bug 修复历史
      • 时间邻近性与语义相似性聚类
      • 探索预算影响
    • 实验结果
      • 单轮探索得分 4.5/5
      • 三轮探索提升 Hit@5 准确率至 57%
    • 下一步计划
      • 扩展至 GitHub 数据
      • 纳入更多上下文

金句 / Highlights

值得收藏与分享的关键句。

#AI#编码智能体#评估方法#Google Labs
打开原文

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

← 返回

Google Developers Blog（RSS）

精选

61

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

2026-06-23 00:08

·

2小时前

精选理由

AI 编码代理的评估从任务修复转向目标洞察，Google 这个思路让评估更接近真实开发场景，但实验还是内部数据，等公开 GitHub 版本再看落地效果。

AI 摘要

Google Labs 提出以“洞察策略”评估 AI 编码智能体的主动性，而非仅按任务完成度打分。团队基于 Google 内部代码库 705 个 bug（1178 个 CL），通过时空近邻与语义相似度聚类还原开发者实际的高层级目标。初步实验显示：Jules 在单轮探索下洞察相关性评分平均 4.5/5；探索预算从两轮增至三轮时，Hit@5 准确率从 33% 升至 57%。团队正将评估方法扩展至公开 GitHub 数据，并探索纳入问题追踪器、对话等更丰富的上下文。

AI 翻译 · 中文

显示原文

用 Jules 衡量真正重要的事

2026 年 6 月 22 日

Nghi Bui，研究科学家

Georgios Evangelopoulos，研究科学家

Zack Elliott，软件工程师

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

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

上图展示了一个主动型 AI 编码引擎的设计。上下文流入引擎，引擎维持开发状态和开发者模型，输出洞察（通知、提问、草稿、保持沉默），并根据响应进行学习。

利用真实 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。

发布在：

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

上一页

下一页