2026年的今天，AI寫代碼這件事已經不新鮮了。你打開一個編程助手，扔給它一個任務，它就會開始翻代碼、跑測試、改文件，一步步把活幹完。
但有一個問題越來越明顯：這些編程助手現在很少是被人一步步盯著的。
更常見的做法是，開發者搭一個"循環"，讓這個循環自動決定編程助手每一步該幹什麼、什麼時候該停。這個做法有個專門的名字，叫**循環工程**。
Loop Engineering：一種圍繞編程智能體組織開發工作的實踐方式，不再是人工逐條寫提示詞，而是設計一套自動化流程來監督進度、分配任務、運行檢查、決定下一步。
這套流程聽起來挺美好，省心又高效。但DreamX團隊的研究者們盯上了一個被大家忽略的漏洞：如果最後任務失敗了，到底是編程助手能力不行，還是這套"循環"本身指揮錯了？
這個問題乍一看有點抽象，但換個場景你就懂了。假設你請了一個裝修工人，又雇了一個包工頭來指揮這個工人幹活。最後房子裝修得一塌糊塗，你能立刻判斷出是工人手藝差，還是包工頭瞎指揮嗎？大概率不能，因為你只看到了最終結果，中間誰的責任大你根本分不清。如果不把這兩者分開評估，你永遠沒法對症下藥，工人可能被冤枉背鍋，真正瞎指揮的包工頭卻全身而退。
這正是這篇論文想解決的核心矛盾。研究者們提出了一個叫**LoopArena**的評測基準，專門用來回答一個問題：一個模型指揮另一個編程智能體幹活的能力，到底怎麼樣？
核心問題：誰在給誰打工
在LoopArena的設定里，出現了兩個角色。
一個叫**Controller**：也就是被評測的那個模型，它不親自寫代碼，只負責看報告、下指令、決定繼續還是收工。
另一個叫**Worker**：也就是真正幹活的編程智能體，它是固定不變的，每次評測都用同一個Worker，這樣才能確保結果的差異來自Controller，而不是Worker換了個更強或更弱的版本。
這個設計的關鍵在於"控制變量"。研究者們把coding領域一個長期存在的評測盲區暴露出來了：以前的編程基準測試，比如著名的SWE-bench，衡量的都是"整個系統"跑完一個任務後行不行，從來沒人單獨把"指揮官"的水平拎出來量化。
SWE-bench：一個廣泛使用的編程智能體評測基準，通過讓AI解決真實的GitHub issue來評分，衡量的是整個編程系統的端到端能力。
這就好比一場足球比賽，你只看比分，卻從來不單獨評價教練的臨場指揮水平和球員的個人能力誰更該背鍋。而LoopArena要做的，就是把"教練"單獨拎出來評分。
那麼具體怎麼評分？研究者設計了三種互補的評測方式，分別對應不同的執行成本和評測精度。這三種方式共同構成了這篇論文最核心的方法論創新。
三種測試方式：從便宜到貴，從局部到全局
第一種叫**Type I：合同選擇**。
在某個任務執行到一半的關鍵節點上，Controller會拿到一份關於當前進度的結構化摘要，然後面對四個候選指令選一個，選完就完事了，不需要真的跑代碼去驗證。
這裡有個巧妙的地方。這四個候選指令里，正確答案不是研究者事先拍腦袋定的，而是提前把這四個候選指令都拿去真跑一遍，看哪個指令帶來的最終結果最好，那個才是"標準答案"。
這就好比考試出題的人，先把四個選項都實際操作了一遍，用真實結果確定哪個是對的，再把這道題拿去考學生。學生做題的時候不需要重新操作一遍，直接選就行，省下了大量時間和計算資源。如果不這樣提前驗證，那出的題目本身可能就是錯的，你測出來的"正確率"根本沒有意義。
Loop Contract：Controller下達給Worker的一份結構化指令，裡面規定了下一步該幹什麼、什麼時候該停、需要滿足哪些條件。
第二種叫**Type II：任務切片**。
這次是真刀真槍地跑，但只跑一個任務的某一段，比如從"已經寫了一半代碼"這個中間狀態開始，讓Controller指揮Worker把剩下這一段搞定。
第三種叫**Type III：完整任務**。
這是最貴最全的測試，從任務最原始的狀態開始，一路指揮到底，覆蓋從最初的探索、到實現、到驗證、再到最終決定"收工"的全過程。
這三種設置有一個精妙的設計，Type II和Type III用的是同一批任務，只是切片的長短不同。這樣就可以直接對比：用便宜的Type II測出來的排名，和用昂貴的Type III測出來的排名，是不是一致的？如果一致，以後就可以只用便宜的Type II來省錢評測了。
結果發現，兩者的排名相關性達到了0.9747（這是一種叫Spearman等級相關係數的統計指標，1代表完全一致），而Type II平均能省下64.4%的推理成本。這意味著大部分情況下，你不需要每次都跑完整任務來驗證一個Controller模型好不好，跑個切片就基本能看出苗頭了。
這就像醫生看病，有時候不需要把你全身做個核磁共振，抽個血化驗一下關鍵指標，就能大致判斷出問題在哪。當然，抽血不能代替所有情況的診斷，但對於大部分常規問題，它足夠便宜也足夠准。
Reporter：一個臨時創建的報告員角色，它讀取Worker的對話歷史，用只讀方式檢查代碼倉庫當前狀態，寫出一份關於任務進展、已完成工作、驗證證據、待解決問題的四段式摘要，本身不能改代碼也不能執行任何操作。
Evidence Packet：由系統自動整理好的、給Controller看的結構化報告，裡面包含Reporter寫的摘要和它引用的關鍵對話片段。
這裡有個細節值得單獨說一下。Reporter每次生成報告的時候，用的是一份"臨時對話副本"，不會污染Worker原本持續進行的對話記錄。這個設計的用意是讓報告這件事本身不影響正式的工作流程，就像醫院裡的護士記錄病歷，不會因為記錄這個動作本身改變了病人的病情。
評測結果：24.69%，這就是目前最好的水平
論文裡公布的實驗結果相當紮實，也相當"打臉"。
研究者測了五個主流模型當Controller，包括Qwen3.7-Plus、DeepSeek-V4-Flash-0731、GLM 5.2、GPT-5.5和Claude Opus 4.8。
在最難的Type III完整任務測試里，表現最好的GPT-5.5的**嚴格成功率**（Strict Success Rate，簡稱SSR，指一次運行既通過評測又符合控制協議才算成功）只有24.69%。也就是說，即便用了當前最強的模型來當"指揮官"，指揮一個編程智能體從頭到尾把一個真實任務做完美，成功率也不到四分之一。
這個數字乍一看不算震撼，但對比一下就明白它的分量了。研究者還設置了兩個對照組。
一個叫**無控制**（No control）：Worker接到任務後完全自主運行，沒有任何外部指揮。
另一個叫**固定控制**（Fixed control）：受Codex的"/goal"命令啟發，每次到了決策點，系統就死板地重複一遍原始任務目標，讓Worker繼續干，完全不管當前實際進展到哪一步了。
結果發現，固定控制這個"死腦筋"策略，在Type II（切片任務）上把成功率從39.51%拉到了46.91%，看起來還有點用。但一到Type III（完整任務），固定控制的成功率是18.52%，和無控制的18.52%完全一樣，一個百分點都沒提高。
這個對比說明了一件很重要的事情。在短任務里，反覆提醒一下"你的目標是什麼"多少有點用，就像考試的時候監考老師隔一會兒喊一句"還有半小時"，能讓人集中精神。但對於長任務，這種死板的重複完全無效，因為真正需要的不是重複目標，而是根據當前進展靈活調整下一步該幹什麼，是繼續寫代碼、還是先去驗證一下之前的工作有沒有漏洞、還是乾脆就該收工了。
這就好比爬一座很高的山，嚮導如果只會不停地喊"我們要爬到山頂"，這句話在半山腰有用嗎？沒用。真正有用的嚮導，得會看你現在體力怎麼樣、天氣有沒有變化、這條路是不是走岔了，然後臨時調整路線。光喊口號的嚮導，跟沒有嚮導差不多。
這也是這篇論文最核心的發現之一。
有效的循環控制必須能感知並適應任務的實時狀態，而不是機械地重複一個靜態目標。
再看看Type I的結果。這五個模型選四選一的**合同準確率**（Contract Accuracy）在72.22%到87.78%之間，GPT-5.5最高，達到了87.78%。研究者還特意測了幾種"作弊式"的簡單策略，比如完全隨機選、只看選項長度、看文字重合度這些方法，結果這些偷懶策略最高也只能到31.11%的準確率，遠遠低於所有測試的模型。這說明，模型確實是在真正理解任務進展和候選指令的內容，而不是靠某種表面規律蒙對的。
成本的賬，也得算清楚
這篇論文還有一個容易被忽略但很重要的貢獻，就是把"推理成本"這件事量化了。
研究者用各家廠商公開的標準定價，把每次調用消耗的token數換算成美元，統計出了每種Controller模型完成一次任務平均要花多少錢。
結果顯示，GLM 5.2在成本上最省錢，Type II只要1.63美元一次，Type III也只要4.86美元。而表現最好的GPT-5.5成本最高，Type III跑一次要18.84美元，是GLM 5.2的將近4倍。
這裡就出現了一個很現實的權衡：花更多錢能不能換來更高的成功率？GPT-5.5雖然成功率最高（24.69%），但成本也最高（18.84美元/次）；GLM 5.2成功率最低（16.05%），但成本也最低（4.86美元/次）。這意味著在實際部署時，選擇哪個模型當Controller，不能只看誰跑分最高，還得算算這筆投入產出比劃不划算。
這就像請私人教練健身，最貴的教練不一定練出的效果比中等價位的教練好20%那麼多，你得看自己的預算和實際需求來選。
論文裡還有個挺有意思的細節，DeepSeek-V4-Flash-0731和GLM 5.2這兩個相對便宜的模型，有相當比例的回覆會撞到輸出長度上限（也就是Controller一次能說的話有個字數限制），撞上限之後這次任務就直接判定失敗了。數據顯示，在使用DeepSeek
或GLM當Controller的167次評測里，有77次至少發生過一次撞上限的情況，占比高達46.11%。這說明便宜模型省錢的代價之一，可能是話說不完就被系統掐斷，從而丟掉了本該拿到的分數。
這個思路後來被怎麼用了
這篇論文發表於2026年8月，雖然時間還很新，但它提出的"把指揮能力和執行能力分開評測"這個思路，已經能看到它和此前幾項工作的呼應關係。
比如論文提到的**LoopsBench**（Li et al., 2026年發布），研究的是"從Harness工程到Loop工程"的轉變，比較的是不同編碼模型和不同循環實現方式的組合表現，跟LoopArena的角度不完全一樣，但都指向同一個大趨勢：循環本身的設計，正在變得和模型能力一樣重要。
再比如**ManagerWorker**這項研究（Liu, 2026年發布），探討的是"一個AI模型能不能指揮另一個AI模型"這個更根本的問題，把組織結構本身當作探測訓練局限性的一個切入點。這和LoopArena的核心假設是一致的：指揮別人幹活，和自己親自動手幹活，需要的是完全不同的能力。
還有一項叫**LongHorizon-Harness**的工作（Ma et al., 2026年發布），提出了一種"管理者-執行者-審計者"三角色循環，用來處理長任務的狀態管理問題，這跟LoopArena里Controller、Worker、Reporter的三角色設計有異曲同工之處，都是想辦法把"幹活"和"管理"這兩件事從架構層面拆開。
寫在後面
讀這篇論文的過程中，最讓我意外的一點，是"固定控制在長任務里完全失效"這個結果。
我原本以為，哪怕是死板地重複目標，多少也該有點用處，畢竟"提醒任務是什麼"聽起來總不是壞事。但數據擺在那裡，18.52%對18.52%，一個百分點的差距都沒有。這說明在真實的長期任務里，"重複"這個動作本身可能是沒有資訊增量的，甚至可能是一種噪音，因為它沒有根據實際進展給出任何新的判斷。
另一個讓我停下來想了一會兒的細節，是那162次"撞到輸出上限"的Controller調用。這些失敗不是因為模型判斷錯了，而是因為它話還沒說完，指令就被系統硬生生截斷了。這種失敗方式挺有意思的，它提醒我們，很多時候AI系統的短板不在於"想得不夠好"，而在於工程層面的一些邊界條件設置，比如輸出長度這種看起來很技術性、很不起眼的參數，反而成了決定成敗的關鍵因素之一。
論文裡還有一個我覺得值得單獨拎出來的地方，就是那個替換掉的Django依賴包的例子。四個候選指令里，正確答案不是"刪掉一個還在被使用的依賴"，也不是"保留這個已經沒用的依賴再檢查一遍"，而是"刪掉那個已經沒人用的孤立依賴，同時保留其他正在使用的配置"。這個例子特別真實，因為它反映的正是軟體工程里最常見的一種陷阱：表面上看起來"清理乾淨了"的操作，很可能誤刪了還在被使用的東西，而真正正確的做法，需要對整個系統的依賴關係有精確的理解，不能只看表面。
這篇論文最後留下的問題，其實比它回答的問題更讓我好奇：如果連GPT-5.5這樣的模型當指揮官，成功率也只有24.69%，那到底是什麼東西還沒被解決？是模型對"進展是否真實"的判斷力不夠，還是它壓根就缺乏那種能感知任務全局節奏的直覺？這個問題，恐怕要等下一篇論文來回答了。
Q&A
Q1：LoopArena是什麼？
A：LoopArena是DreamX團隊提出的一個評測基準，專門用來測試一個AI模型指揮另一個編程智能體完成長任務的能力，而不是測整個系統端到端的表現。
Q2：為什麼固定重複任務目標的策略在長任務里沒用？
A：論文實驗顯示，固定控制策略在完整任務上的成功率是18.52%，和完全不加控制的無控制策略完全一樣，說明機械重複目標不能提供任何有效的實時判斷，長任務需要的是能根據當前進展靈活調整的指揮。
Q3：目前表現最好的Controller模型成功率是多少？
A：GPT-5.5在完整任務測試中表現最好，嚴格成功率為24.69%，是所有測試模型中的最高值，但整體來看長任務的循環控制能力仍有很大提升空間。
