北京
周三下午三点半，一位谷歌工程师第三次收到沙箱超时报警。前两次他修复了broker配置和网络隔离，但这次看似无关的错误再次连成一串。把它们单独录入缺陷系统，每个都只是孤立任务；可一旦合起来看，它们全都指向同一个底层目标：加固沙箱执行可靠性。
这正是当下AI编码智能体面临的根本性转变——从完成明确定义的任务，转向主动围绕“目标”工作。过去几年，我们习惯让智能体被动响应指令，比如修复一个具体Bug或补一个函数缺口，流行的SWE-Bench基准正是这样检验它的能力。但真实的软件工程很少会这么工整地递上单点任务；工程师真正面对的，是一连串看起来离散、实则围绕同一个工程目标旋转的线索。此时智能体需要的就不再是单纯的自主完成任务，而是能提前嗅出风险、从代码仓中自行找出关联，并在合适时刻给出诊断性观察。
谷歌最新论文《编码智能体需要主动性，而不只是自主性》正是针对这一缺口发声。论文断言，要衡量一个主动型智能体，就必须评估它的“洞察策略”——即它基于流动的上下文，如何判断什么事重要、什么证据支撑、什么时机应该通知开发者、提出问题、起草一份替代方案，或者干脆保持沉默。论文配图清晰勾勒出这套洞察引擎：上下文持续涌流，内部维护着开发状态与开发者模型，然后触发四种动作之一——通知、提问、草案、沉默——再从人类反馈中迭代学习。
这让一个核心难题浮出水面：怎样为“会不会洞察”建立可量化的根基事实？谷歌实验室基于内部持续AI系统的经验，提出一种取巧又踏实的路线——往回看真实团队的Bug修复历史，用“时间接近性”和“语义相似性”两条启发式去还原工程师心中那个未写明的目标。团队假设，当几个相关Bug在短时期内被同一批人提交和消除时，它们通常只是同一场工程会战的症状。就像沙箱超时、broker配置失败、网络隔离不一致测试，单独看都太琐碎，聚在一起才暴露那个更高阶的意图。
为验证这套假设，团队调取了源自Google内部代码仓的705个缺陷和1178次代码提交，搭建了一个初步基准，具体做法极具“还原视角”：先将Bug聚类，从中提炼开发者实际上在赶赴的“期望目标”；然后把每个Bug集群中的个体Bug设为目标事实，再把代码仓精确回滚到人类工程师接手前的状态；允许智能体进行至多三轮调查——作为它的探索预算；此后让它生成最终洞察，并用一个大语言模型（LLM）对这些洞察从1分（毫不相关）到5分（完美命中事实）进行评判。与此同时，团队持续追踪智能体的平均最高分数以及它给出高精确匹配的频率。
初步测试结果让团队颇为振奋，但原因并不花哨：核心诊断逻辑行得通。仅一轮探索下，智能体就能稳定给出有效洞察，不再被“这只是一个任务”的框子堵死感知。这意味着，替主动智能体定一个洞察品质的标尺，或许已不再是空洞的想象。至于更细致的命中率与场景对比，论文仅预告这两个关键结论背后还有更深层的分析尚未公开，但单是“洞察策略可被评估”这件事，已经为下一阶段的AI编程工具划出了一条和以往完全不同的评价基准线。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
