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

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

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

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

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

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

（來源：arXiv）

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

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

圖丨相關論文（來源：arXiv）

現有 AI 編程評測與真實體驗錯位，問題出在哪里？

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

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

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

（來源：arXiv）

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

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

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

（來源：arXiv）

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

實際上，用 Milestone 對 Agent 歷史演進進行重構并非易事，因為它不只是要構造一個靜態(tài)的、可純粹被觀測的 DAG，而是要一連串可以被執(zhí)行的評估環(huán)境，還要在演進依賴變更的同時保證正確性。

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

更關鍵的是，它會基于原有 DAG 補充被遺漏的隱式依賴，通過調整 Milestone 的先后約束關系讓接口沖突問題得以妥善解決。經過反復迭代，最終實現正確收集 87.1% 的原有測試用例。

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

圖丨 DeepCommit 流水線架構圖（來源：arXiv）

研究人員將 DeepCommit 自動生成的演進圖與人類專家的手動標注進行對比，讓他們感到意外的是，二者采用了不同的組織邏輯且互為補充。

具體而言，人類專家的 Milestone 通常在局部時間窗口內，先定議題再歸攏提交，是一種自上而下的語義切分；DeepCommit 為保證絕對準確性，從提交之間的依賴關系出發(fā)，自下而上地重建軟件演進脈絡，更強調拓撲結構與執(zhí)行約束。

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

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

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

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

研究團隊對 Claude Code、OpenHands 等多種框架和模型組合進行測試。結果顯示，在獨立評測中得分普遍在 80%-90% 的頂尖模型，在進行 EvoClaw 基準測試后集體斷崖式下降，其中最高得分的 Claude Opus 4.6 僅獲得 38.03% 得分。

圖丨 EvoClaw 主要實驗結果（來源：arXiv）

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

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

（來源：arXiv）

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

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

“盡管 Opus 4.6 在 Anthropic 官網中提到比 4.5 在長周期的任務中表現更好，但是并沒有給出詳細的評估指標，EvoClaw 算是從另一個角度驗證了他們的說法。”鄧港大表示。

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

（來源：arXiv）

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

當研究人員把整體分數進一步分解為召回率與精確率時，一個更有意思的現象出現了：召回率幾乎呈不斷上升趨勢，接近線性增長。這意味著，哪怕代碼庫變得越來越混亂、越來越脆弱，Agent 依然擅長實現當前給定的新目標功能。

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

圖丨左：錯誤鏈示意圖；右：錯誤鏈分布（來源：arXiv）

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

結果發(fā)現，新問題的產生速度并不會加快，模型甚至會實質性地被動修復部分歷史錯誤，但前置錯誤的累積速度遠超修復速度，最終陷入“技術債破產”。

為 AI Harness 調試提供通用評估

近期，有個非常火熱的概念 “Harness Engineering”，希望把軟件開發(fā)的全部流程配置成適合 Agent 參與的環(huán)境。EvoClaw 基準測試提供了這樣一個通用且評估長周期代碼演進的 playground，適合調試 AI Harness 框架。

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

既然模型的架構讓 Agent 具有“實現新功能遠強于維護長期舊功能”的通用性質，那么，未來是否會催生出新的軟件形態(tài)以及開發(fā)模式？

例如，軟件會更強調靈活性、兼容性，更可靠的大規(guī)模改動重組；或者是更加的一次性，具體業(yè)務邏輯都是實時生成、不需要維護，重點在于強化可復用的組件、基礎設施。

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

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

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

參考資料：

1. 相關論文：https://arxiv.org/pdf/2603.13428

2. 項目主頁：https://evo-claw.com/

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

排版：劉雅坤