寫一個(gè)函數(shù)，AI 幾乎無敵；但維護(hù)一個(gè)系統(tǒng)，為何 AI 開始崩潰？

目前，人工智能已經(jīng)進(jìn)入到“下半場”。隨著 AI 編程能力不斷提升，OpenClaw 等產(chǎn)品逐漸興起，“CLI everything”正在成為現(xiàn)實(shí)，即 AI 不需要操作電腦，而是將所有的接口改為命令行界面（CLI），一個(gè)個(gè)技能正轉(zhuǎn)變成一個(gè)個(gè)軟件功能。

現(xiàn)在，Agent 已不僅僅是執(zhí)行單次任務(wù)的對(duì)話工具，而是正在向長期運(yùn)營、與真實(shí)世界交互、執(zhí)行復(fù)雜任務(wù)的系統(tǒng)發(fā)展。然而，一個(gè)新的問題出現(xiàn)了：在持續(xù)演進(jìn)的過程中，AI 能不斷適應(yīng)新環(huán)境并保持開發(fā)能力穩(wěn)定嗎？

騰訊“CEO/總裁辦公室”首席 AI 科學(xué)家姚順雨曾在一篇題為“The Second Half”的博客中提到，真實(shí)編程任務(wù)是連續(xù)依賴的，不是獨(dú)立并行的，但當(dāng)下學(xué)界沒有這樣的基準(zhǔn)來評(píng)估 AI 在該場景下所需要的能力，甚至缺乏勇氣打破任務(wù)間相互獨(dú)立的假設(shè)——長久以來被廣泛接受，用于簡化問題。

近期，美國南加州大學(xué)、加利福尼亞大學(xué)河濱分校、斯坦福大學(xué)、普林斯頓大學(xué)、OpenHands 等聯(lián)合團(tuán)隊(duì)發(fā)布了一項(xiàng)全新評(píng)估基準(zhǔn) EvoClaw，為上述問題上提出了新方案。研究團(tuán)隊(duì)從開源項(xiàng)目中提取高質(zhì)量代碼演進(jìn)歷史，讓 Agent 在同一代碼庫上連續(xù)完成數(shù)十個(gè)相互依賴的功能迭代。

結(jié)果顯示，頂尖 AI 能在獨(dú)立評(píng)估任務(wù)中表現(xiàn)優(yōu)異（得分 80%+），一旦進(jìn)入長周期的真實(shí)場景，即便是綜合得分最高的 Claude Opus 4.6 也只獲得了 38.03% 的得分。這意味著，AI 對(duì)于執(zhí)行自由度更高的任務(wù)容易偏離軌跡，其距離真正能夠處理長周期、連續(xù)的軟件演進(jìn)工作仍存在顯著差距。

（來源：arXiv）

這項(xiàng)研究揭示，AI 在長期演進(jìn)中極易陷入滾雪球式的技術(shù)債。盡管能持續(xù)添加新功能，卻無法控制回歸錯(cuò)誤累積，最終導(dǎo)致系統(tǒng)失控。這也意味著，AI 編程正從寫代碼向系統(tǒng)治理轉(zhuǎn)折。

相關(guān)論文以《EvoClaw：面向持續(xù)軟件演進(jìn)的 AI 智能體評(píng)估基準(zhǔn)》（EvoClaw: Evaluating AI Agents on Continuous Software Evolution）為題，近期發(fā)表在預(yù)印本網(wǎng)站 arXiv[1]。

圖丨相關(guān)論文（來源：arXiv）

現(xiàn)有 AI 編程評(píng)測與真實(shí)體驗(yàn)錯(cuò)位，問題出在哪里？

為何獨(dú)立測評(píng)獲得高分的頂尖模型，在 EvoClaw 測評(píng)中集體失利？問題的根源在于評(píng)測范式變了。

在以往研究中，主流編程測評(píng)基準(zhǔn)（benchmark）多數(shù)聚焦于獨(dú)立任務(wù)：給定一個(gè)議題（issue）或拉取請(qǐng)求（PR，Pull Request），模型在靜態(tài)的代碼快照上完成修復(fù)，驗(yàn)證通過即完成測評(píng)。

但以往基準(zhǔn)測評(píng)成績與現(xiàn)實(shí)開發(fā)能力之間，存在著一道不容忽視的鴻溝：靜態(tài)環(huán)境是一種相對(duì)理想的狀態(tài)，而真實(shí)環(huán)境則是更為復(fù)雜和動(dòng)態(tài)的。隨著時(shí)間的演進(jìn)，即便是數(shù)月前的微小 bug，經(jīng)過版本迭代后也可能像滾雪球那樣越來越大，進(jìn)而導(dǎo)致系統(tǒng)崩潰。

（來源：arXiv）

該論文第一作者、南加州大學(xué)博士生鄧港大對(duì) DeepTech 表示：“現(xiàn)有的 commit 以及 release 粒度，要么過于瑣碎要么過于粗糙。因此，這些開發(fā)歷史并不能體現(xiàn)軟件演進(jìn)的過程?！?/p>

圖丨鄧港大（來源：受訪者）

研究團(tuán)隊(duì)首次將時(shí)間維度引入 AI 編程能力的評(píng)估體系，采用了一種全新層級(jí)——里程碑（Milestone），對(duì)軟件演進(jìn)的歷史進(jìn)行重構(gòu)，能夠兼具語義完整性和演進(jìn)依賴關(guān)系保留能力的功能單元。其要求 AI 在同一代碼庫上按序完成多個(gè)功能單元，這樣不僅保留了每一步產(chǎn)出還成為下一步的起點(diǎn)。

（來源：arXiv）

為了支持從大量開源代碼庫中提取出高質(zhì)量軟件演進(jìn)歷史，研究人員基于頂尖 AI 強(qiáng)大的能力，提出了一套 Agent 驅(qū)動(dòng)的自動(dòng)化流水線 DeepCommit，首次實(shí)現(xiàn)將嘈雜的 Git 開發(fā)記錄重構(gòu)為可驗(yàn)證、功能內(nèi)聚的里程碑任務(wù)依賴圖（Milestone DAG），并為每一個(gè)里程碑構(gòu)造出評(píng)估環(huán)境。主要包括三個(gè)階段：Git 歷史預(yù)處理、Agent 驅(qū)動(dòng)的 DAG 構(gòu)建以及里程碑環(huán)境配置與驗(yàn)證。

實(shí)際上，用 Milestone 對(duì) Agent 歷史演進(jìn)進(jìn)行重構(gòu)并非易事，因?yàn)樗恢皇且獦?gòu)造一個(gè)靜態(tài)的、可純粹被觀測的 DAG，而是要一連串可以被執(zhí)行的評(píng)估環(huán)境，還要在演進(jìn)依賴變更的同時(shí)保證正確性。

這意味著，當(dāng)打亂 commit 的整體順序并把它重新聚類連接時(shí)，可能會(huì)面臨 commit 無法應(yīng)用、接口對(duì)不齊以及編譯大面積報(bào)錯(cuò)的情況。針對(duì)該問題，研究人員設(shè)計(jì)了一套迭代式修復(fù)循環(huán)：Agent 主動(dòng)分析報(bào)錯(cuò)日志、動(dòng)態(tài)修改 Dockerfile 確?？蓤?zhí)行。

更關(guān)鍵的是，它會(huì)基于原有 DAG 補(bǔ)充被遺漏的隱式依賴，通過調(diào)整 Milestone 的先后約束關(guān)系讓接口沖突問題得以妥善解決。經(jīng)過反復(fù)迭代，最終實(shí)現(xiàn)正確收集 87.1% 的原有測試用例。

“與單個(gè)編程任務(wù)場景相比，穩(wěn)定、可靠、有效的長周期自主編程是更前沿的研究熱點(diǎn)，例如 Anthropic、OpenAI 就明確表明他們已經(jīng)將重心轉(zhuǎn)移到訓(xùn)練模型的長周期編程能力?！编嚫鄞蟊硎?。

圖丨 DeepCommit 流水線架構(gòu)圖（來源：arXiv）

研究人員將 DeepCommit 自動(dòng)生成的演進(jìn)圖與人類專家的手動(dòng)標(biāo)注進(jìn)行對(duì)比，讓他們感到意外的是，二者采用了不同的組織邏輯且互為補(bǔ)充。

具體而言，人類專家的 Milestone 通常在局部時(shí)間窗口內(nèi)，先定議題再歸攏提交，是一種自上而下的語義切分；DeepCommit 為保證絕對(duì)準(zhǔn)確性，從提交之間的依賴關(guān)系出發(fā)，自下而上地重建軟件演進(jìn)脈絡(luò)，更強(qiáng)調(diào)拓?fù)浣Y(jié)構(gòu)與執(zhí)行約束。

對(duì)評(píng)測而言，這恰恰說明 DeepCommit 關(guān)鍵在于從代碼開發(fā)歷史中提煉出一套可執(zhí)行、可驗(yàn)證的里程碑結(jié)構(gòu)。從結(jié)果來看，DeepCommit 能篩選出高質(zhì)量、適合評(píng)估的 Milestone 任務(wù)，并且在真實(shí)環(huán)境中可執(zhí)行、可驗(yàn)證，為評(píng)測可靠性提供了保障。

一進(jìn)入真實(shí)開發(fā)，模型成績?yōu)楹渭w“腰斬”？

EvoClaw 覆蓋五種主流語言，包括 Python、Java、Go、Rust 和 TypeScript，選取的項(xiàng)目橫跨最長真實(shí)開發(fā)周期達(dá) 750 天。

在評(píng)測指標(biāo)方面，研究團(tuán)隊(duì)未采取簡單的通過率，而是引入了兩個(gè)更核心的維度——召回率（Recall）與精確率（Precision）的 F1 加權(quán)作為每個(gè) Milestone 的評(píng)分。其中，召回率用于衡量功能實(shí)現(xiàn)完備性，而精確率則捕捉模型在新增功能時(shí)破壞既有代碼的程度。

研究團(tuán)隊(duì)對(duì) Claude Code、OpenHands 等多種框架和模型組合進(jìn)行測試。結(jié)果顯示，在獨(dú)立評(píng)測中得分普遍在 80%-90% 的頂尖模型，在進(jìn)行 EvoClaw 基準(zhǔn)測試后集體斷崖式下降，其中最高得分的 Claude Opus 4.6 僅獲得 38.03% 得分。

圖丨 EvoClaw 主要實(shí)驗(yàn)結(jié)果（來源：arXiv）

GPT 5.3 Codex 以 28.88% 的綜合得分僅次于 Opus4.6，位居第二。分倉庫來看，GPT 5.3 Codex 在兩個(gè) Rust 項(xiàng)目（Nushell、ripgrep）上表現(xiàn)較弱，在其余倉庫上則能接近甚至超過 Opus4.6。在完整解決率方面，得分最高的 Gemini 3 Pro 也只有 13.37%，并且絕大部分能正確實(shí)現(xiàn)的都是沒有前置依賴的任務(wù)。

據(jù)了解，研究人員將整體開銷控制在合理范圍內(nèi)，以 Claude Opus 4.5 為例，完整測評(píng)一次的成本約為 500 美元，Kimi K2.5 以及 Gemini 3 Flash 則在 50 美元以內(nèi)，小模型的開銷會(huì)更低。

（來源：arXiv）

那么，如果給模型更長的開發(fā)窗口，它最終能 100% 把項(xiàng)目搞定嗎？

研究給出了否定答案：無論開發(fā)窗口多長，所有模型的表現(xiàn)最終都會(huì)撞上“天花板”。任務(wù)執(zhí)行順序越靠后、所處 DAG 層級(jí)越深，分?jǐn)?shù)和解決率就越低。飽和函數(shù)外推結(jié)果證明，即便是最優(yōu)的 Opus 4.6，累計(jì)分?jǐn)?shù)也會(huì)被卡死在 45% 左右的漸近線上。

“盡管 Opus 4.6 在 Anthropic 官網(wǎng)中提到比 4.5 在長周期的任務(wù)中表現(xiàn)更好，但是并沒有給出詳細(xì)的評(píng)估指標(biāo)，EvoClaw 算是從另一個(gè)角度驗(yàn)證了他們的說法。”鄧港大表示。

此外，從實(shí)驗(yàn)中還看到了不同模型家族之間存在顯著差異。具體而言，Claude 與 GPT 在持續(xù)演化場景中的表現(xiàn)，會(huì)隨著版本更新穩(wěn)步提升。其中，Opus 4.6 在長周期的編程上證明了其對(duì)系統(tǒng)的維護(hù)性能最佳；GPT 5.3 由于在 Rust 數(shù)據(jù)集上表現(xiàn)不佳而拉低了分?jǐn)?shù)，排名在第二位。

（來源：arXiv）

比較出乎意料的是，Gemini 家族呈現(xiàn)出完全不同的趨勢：從 3 Flash 到 3 Pro 再到 3.1 Pro，每一代都在早期啟動(dòng)更快、前期表現(xiàn)更好，但其長程表現(xiàn)幾乎沒有顯著提升。鄧港大解釋道：“Gemini 長周期運(yùn)行表現(xiàn)的明顯衰退，意味著其不僅指令遵循變差，越來越忽視軟件規(guī)格說明（SRS）的需求，同時(shí)對(duì)所構(gòu)造的軟件系統(tǒng)缺乏維護(hù)?！?/p>

當(dāng)研究人員把整體分?jǐn)?shù)進(jìn)一步分解為召回率與精確率時(shí)，一個(gè)更有意思的現(xiàn)象出現(xiàn)了：召回率幾乎呈不斷上升趨勢，接近線性增長。這意味著，哪怕代碼庫變得越來越混亂、越來越脆弱，Agent 依然擅長實(shí)現(xiàn)當(dāng)前給定的新目標(biāo)功能。

真正的瓶頸在于精確率：Agent 難以維護(hù)現(xiàn)有系統(tǒng)，回歸錯(cuò)誤積累的速度超過了它們修復(fù)這些問題的能力，而這正是長期開發(fā)最終停滯的根本原因。

圖丨左：錯(cuò)誤鏈?zhǔn)疽鈭D；右：錯(cuò)誤鏈分布（來源：arXiv）

為深入理解模型在迭代中失控的根本原因，研究團(tuán)隊(duì)提出了錯(cuò)誤鏈（Error Chains）的分析框架。他們從首次出錯(cuò)開始跟蹤每個(gè)測試，并觀察錯(cuò)誤在后續(xù) Milestone 中被繼承、擴(kuò)散、跳過還是修復(fù)。

結(jié)果發(fā)現(xiàn)，新問題的產(chǎn)生速度并不會(huì)加快，模型甚至?xí)?shí)質(zhì)性地被動(dòng)修復(fù)部分歷史錯(cuò)誤，但前置錯(cuò)誤的累積速度遠(yuǎn)超修復(fù)速度，最終陷入“技術(shù)債破產(chǎn)”。

為 AI Harness 調(diào)試提供通用評(píng)估

近期，有個(gè)非?；馃岬母拍?“Harness Engineering”，希望把軟件開發(fā)的全部流程配置成適合 Agent 參與的環(huán)境。EvoClaw 基準(zhǔn)測試提供了這樣一個(gè)通用且評(píng)估長周期代碼演進(jìn)的 playground，適合調(diào)試 AI Harness 框架。

例如，本次研究中所提到的失敗案例，如果 Agent 突然表現(xiàn)出非常積極的迭代，或不斷編輯、不斷驗(yàn)證，很可能是 Agent 遇到了困難。在這種情況下，可以通過在對(duì)應(yīng)位置構(gòu)造護(hù)欄，來盡早發(fā)現(xiàn)問題、及時(shí)人工介入，從而提高效率。

既然模型的架構(gòu)讓 Agent 具有“實(shí)現(xiàn)新功能遠(yuǎn)強(qiáng)于維護(hù)長期舊功能”的通用性質(zhì)，那么，未來是否會(huì)催生出新的軟件形態(tài)以及開發(fā)模式？

例如，軟件會(huì)更強(qiáng)調(diào)靈活性、兼容性，更可靠的大規(guī)模改動(dòng)重組；或者是更加的一次性，具體業(yè)務(wù)邏輯都是實(shí)時(shí)生成、不需要維護(hù)，重點(diǎn)在于強(qiáng)化可復(fù)用的組件、基礎(chǔ)設(shè)施。

研究團(tuán)隊(duì)認(rèn)為，在開發(fā)模式上，適當(dāng)放寬對(duì)軟件質(zhì)量的約束，可減少人類的介入次數(shù)，來換取更大的吞吐量，最終加速軟件的迭代。

鄧港大指出，“該研究證明我們正走在一條在正確的道路上，AI 的長期編程能力還沒有遇到瓶頸，能夠隨時(shí)間穩(wěn)定提升。有潛力在突然某一天，由榜單分?jǐn)?shù)的量變，變成改變世界的質(zhì)變。”

隨著技術(shù)的發(fā)展，未來 AI 有可能會(huì)從逐漸減少人類參與軟件開發(fā)，到 AI 自主提出新的需求來演進(jìn)代碼庫，再到 AI 徹底超越人類、拋棄人類，最終實(shí)現(xiàn)不斷自我進(jìn)化。

參考資料：

1. 相關(guān)論文：https://arxiv.org/pdf/2603.13428

2. 項(xiàng)目主頁：https://evo-claw.com/

3.https://ysymyth.github.io/The-Second-Half/

排版：劉雅坤