Google Developers Blog 在 2026 年 6 月 22 日发布「Measuring What Matters with Jules」，讨论 AI coding agents 的下一个评估问题。文章指出，coding agent 正由被动完成任务的助手，转向可以持续吸收上下文、发现风险、提出诊断洞察的 proactive engine。这代表评估标准也要改变。
现时不少 benchmark 例如 SWE-Bench，主要测试 agent 能否修好一个清楚定义的 bug。但 Google Labs 的观点是，真正主动的 agent 要面对的是 goal，而不是单一 task。它需要探索 codebase、判断哪些讯号重要、知道何时打扰开发者、何时提出草稿、何时追问、何时保持沉默。这种能力在文章中被称为 insight policy。
为了建立评估基础，Google 团队提出用真实 bug-fixing history 作为 ground truth。他们观察到，工程师在短时间内提交和修复多个相关 bug 时，这些 bug 往往指向同一个更高层次工程目标。例如多个 sandbox timeout、broker config 和 network isolation 问题，可能共同指向「提升 sandbox 执行可靠性」这类 aspirational goal。
在初步 benchmark 中，团队使用 705 个 bugs 和 1,178 个 CLs，将历史 bug 聚类为较高层次目标，然后把 codebase 回复到修复前状态，让 agent 在有限探索轮数内提出 final insights。之后再用 LLM judge 把 agent 的洞察与 ground truth 对照，按相关程度和 Hit@K 衡量表现。
初步结果显示，单轮探索已能产生平均 4.5/5 的高相关洞察，对简单问题能抓住主要讯号。但对复杂、多面向问题，探索预算很重要。文章提到将 exploration budget 由两轮提升至三轮后，Hit@5 由 33% 回升到 57%，说明 agent 需要足够时间和上下文去发现次要但关键的讯号。
这项研究的价值不只是为 Jules 建立指标，而是指出 AI coding agent 的产品方向。未来 agent 不一定只是在 issue 被指派后执行任务，它可能在开发过程中主动找出模式、风险和改进目标。但这也带来新的 UX 问题：如果 agent 太常提醒，会打扰开发者；如果太安静，又失去主动价值。
对工程管理来说，这篇文章提供了一个更成熟的评估框架。评估 coding agent 不应只看 pass rate 或 patch 是否通过测试，也要看它是否能找到真正值得人类注意的工程讯号，是否有证据支持，是否在合适时间介入。AI coding 的竞争正由「会不会写 code」走向「是否懂得何时提出有用判断」。
