北京
周三下午三點(diǎn)半，一位谷歌工程師第三次收到沙箱超時報警。前兩次他修復(fù)了broker配置和網(wǎng)絡(luò)隔離，但這次看似無關(guān)的錯誤再次連成一串。把它們單獨(dú)錄入缺陷系統(tǒng)，每個都只是孤立任務(wù)；可一旦合起來看，它們?nèi)贾赶蛲粋€底層目標(biāo)：加固沙箱執(zhí)行可靠性。
這正是當(dāng)下AI編碼智能體面臨的根本性轉(zhuǎn)變——從完成明確定義的任務(wù)，轉(zhuǎn)向主動圍繞“目標(biāo)”工作。過去幾年，我們習(xí)慣讓智能體被動響應(yīng)指令，比如修復(fù)一個具體Bug或補(bǔ)一個函數(shù)缺口，流行的SWE-Bench基準(zhǔn)正是這樣檢驗它的能力。但真實(shí)的軟件工程很少會這么工整地遞上單點(diǎn)任務(wù)；工程師真正面對的，是一連串看起來離散、實(shí)則圍繞同一個工程目標(biāo)旋轉(zhuǎn)的線索。此時智能體需要的就不再是單純的自主完成任務(wù)，而是能提前嗅出風(fēng)險、從代碼倉中自行找出關(guān)聯(lián)，并在合適時刻給出診斷性觀察。
谷歌最新論文《編碼智能體需要主動性，而不只是自主性》正是針對這一缺口發(fā)聲。論文斷言，要衡量一個主動型智能體，就必須評估它的“洞察策略”——即它基于流動的上下文，如何判斷什么事重要、什么證據(jù)支撐、什么時機(jī)應(yīng)該通知開發(fā)者、提出問題、起草一份替代方案，或者干脆保持沉默。論文配圖清晰勾勒出這套洞察引擎：上下文持續(xù)涌流，內(nèi)部維護(hù)著開發(fā)狀態(tài)與開發(fā)者模型，然后觸發(fā)四種動作之一——通知、提問、草案、沉默——再從人類反饋中迭代學(xué)習(xí)。
這讓一個核心難題浮出水面：怎樣為“會不會洞察”建立可量化的根基事實(shí)？谷歌實(shí)驗室基于內(nèi)部持續(xù)AI系統(tǒng)的經(jīng)驗，提出一種取巧又踏實(shí)的路線——往回看真實(shí)團(tuán)隊的Bug修復(fù)歷史，用“時間接近性”和“語義相似性”兩條啟發(fā)式去還原工程師心中那個未寫明的目標(biāo)。團(tuán)隊假設(shè)，當(dāng)幾個相關(guān)Bug在短時期內(nèi)被同一批人提交和消除時，它們通常只是同一場工程會戰(zhàn)的癥狀。就像沙箱超時、broker配置失敗、網(wǎng)絡(luò)隔離不一致測試，單獨(dú)看都太瑣碎，聚在一起才暴露那個更高階的意圖。
為驗證這套假設(shè)，團(tuán)隊調(diào)取了源自Google內(nèi)部代碼倉的705個缺陷和1178次代碼提交，搭建了一個初步基準(zhǔn)，具體做法極具“還原視角”：先將Bug聚類，從中提煉開發(fā)者實(shí)際上在趕赴的“期望目標(biāo)”；然后把每個Bug集群中的個體Bug設(shè)為目標(biāo)事實(shí)，再把代碼倉精確回滾到人類工程師接手前的狀態(tài)；允許智能體進(jìn)行至多三輪調(diào)查——作為它的探索預(yù)算；此后讓它生成最終洞察，并用一個大語言模型（LLM）對這些洞察從1分（毫不相關(guān)）到5分（完美命中事實(shí)）進(jìn)行評判。與此同時，團(tuán)隊持續(xù)追蹤智能體的平均最高分?jǐn)?shù)以及它給出高精確匹配的頻率。
初步測試結(jié)果讓團(tuán)隊頗為振奮，但原因并不花哨：核心診斷邏輯行得通。僅一輪探索下，智能體就能穩(wěn)定給出有效洞察，不再被“這只是一個任務(wù)”的框子堵死感知。這意味著，替主動智能體定一個洞察品質(zhì)的標(biāo)尺，或許已不再是空洞的想象。至于更細(xì)致的命中率與場景對比，論文僅預(yù)告這兩個關(guān)鍵結(jié)論背后還有更深層的分析尚未公開，但單是“洞察策略可被評估”這件事，已經(jīng)為下一階段的AI編程工具劃出了一條和以往完全不同的評價基準(zhǔn)線。
特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務(wù)。
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.
