你有沒有想過一個問題：現在市面上那麼多AI編程助手，Claude Code、Codex、OpenHands，為什麼同一個模型放進不同的系統里，表現能差出一大截？
有個真實的例子。研究者發現，Claude-Opus-4.5這個模型在OpenHands這個系統里跑得最好，但換成Claude-Sonnet-4.5這個模型，反而是在另一個叫SWE-Agent的系統里表現最佳。同一批AI大腦，裝進不同的"身體"里,表現天差地別。這事兒聽起來有點反直覺：我們平時聊AI進步,聊的都是模型本身變聰明了,但這個例子告訴我們,決定AI程式設計師幹活好不好的,可能不只是腦子,還有裝它的那個"殼子"。
這個"殼子",專業說法叫編碼工具架
（coding harness）：*一套讓大語言模型能夠真正操作代碼倉庫的軟體外殼,它規定了AI怎麼規劃任務、怎麼調用工具、怎麼管理不斷累積的對話記錄。*
問題是,過去幾乎所有研究都是把這套殼子當成一個整體來比較的,就像兩台車比賽,只看誰先衝線,不管到底是發動機強還是輪胎好。這樣比較有個致命缺陷:你壓根不知道性能差異是來自規劃能力、工具設計,還是記憶管理機制,更不知道換一個模型,這些結論還成不成立。
一支來自UMass Amherst、Zoom、Emory University和UNC Charlotte的團隊決定把這台車拆開,一個零件一個零件地測。
拆解一台正在跑的賽車
要弄清楚每個零件的作用,最笨也最可靠的辦法就是造一輛能拆卸的車。研究者從零搭建了一個輕量級的編碼工具架,主循環固定不變,但裡面三個關鍵部件可以自由拆裝:規劃(planning)、行動空間(action space)、上下文管理(context management)。
這套系統遵循一種叫ReAct的經典循環模式：*每一輪交互包含推理、行動、觀察三步,AI先想清楚要做什麼,再執行動作,然後看執行結果,如此循環往復,直到任務完成。*
為什麼偏偏挑這三個部件來拆?因為它們各自對應長任務執行中的一個核心矛盾。規劃負責讓AI記住"我現在做到哪一步了",不然任務一長就容易跑偏;行動空間決定AI的意圖怎麼變成能真正執行的操作,是給它一套精細工具,還是就扔給它一個命令行;上下文管理則解決一個無法迴避的物理限制:AI的"腦容量"(上下文窗口)是有限的,任務越長,歷史記錄越多,總有一天會裝不下。
這就像給一個新員工安排工作。規劃相當於給他一份任務清單,行動空間相當於給他配的工具箱是精密儀器還是一把萬能扳手,上下文管理則相當於他的筆記本容量有限,該記哪些、忘哪些、怎麼整理舊筆記。這三件事互相獨立,又都在影響他能不能把活干好。
研究團隊選了三檔不同規模的Nemotron-3模型（30B、120B、550B參數）作為能力梯度,再加一個跨系列的對照模型Mistral-Medium-3.5,在兩個長任務基準測試上驗證：SWE-Bench Verified（500個真實的GitHub代碼問題修復任務）和Terminal-Bench 2.1（89個端到端的命令行操作任務）。
累計跑了176組實驗設置,涵蓋五種上下文管理策略、四檔上下文窗口預算（32k、64k、96k、128k token）,外加對規劃和行動空間的定向消融實驗。這個規模,基本上把"殼子"的每一顆螺絲都擰開看了一遍。
記憶是會溢出的:上下文管理到底在管什麼
先說上下文管理,因為這是全文最直觀也最容易被低估的一環。
想像你在用一個只能記住最近幾頁對話的聊天軟體跟人討論一個複雜項目。聊到第50輪,軟體突然彈窗告訴你:內存滿了,對話終止,前面聊的全部作廢。這就是沒有上下文管理時AI智能體面臨的窘境:任務執行到一半,歷史記錄塞滿了上下文窗口,直接崩潰退出,前功盡棄。
研究者設計了五檔策略來應對這個問題,編號從T0到T4。T0是什麼都不做,窗口滿了就崩;T1隻做"刪除"（elision）,把陳舊的工具輸出替換成一個簡短的占位符,原文直接扔掉;T2在T1基礎上加了個"外部倉庫+召回"機制（recall）,被刪掉的內容存到外部,AI可以用一個叫recall_event的工具隨時把原文調回來,相當於"刪掉但沒真刪";T3是純粹的"摘要"（summarization）,把舊的對話內容壓縮成一段自然語言總結;T4則是把刪除和摘要串聯起來用,先刪後總結,是三種機制的組合拳。
這套設計像極了整理舊郵箱的幾種方式。T0就是從不清理,郵箱塞滿了直接罷工。T1是把舊郵件標題改成"這裡曾有一封郵件,內容已丟失",騰出空間但資訊真沒了。T2是把舊郵件挪到一個歸檔文件夾,標題里留個鏈接,想看隨時能點開翻出來。T3是雇個秘書,把每周的郵件寫成一份摘要報告,你看報告就夠了,原文不留。T4呢,先把不重要的郵件挪進歸檔(留個索引),等歸檔也堆多了,再讓秘書把最老的一批寫成摘要。
實驗結果里最扎眼的一條規律是:上下文管理這件事,越是窗口緊張的時候越重要,窗口一旦足夠大,它的邊際價值迅速衰減。
具體數字是這樣的:在SWE-Bench上,窗口預算從32k漲到128k,有管理策略（T1到T4）相對於沒管理（T0）帶來的成功率提升,從35.7個百分點一路跌到15.9、5.5,最後只剩2.7個百分點。Terminal-Bench上也是類似曲線,從9.5一路降到2.8。
為什麼會這樣?研究者深挖了一層,發現秘密藏在"窗口溢出"這個指標里。在32k窗口下,沒有管理的T0策略,平均有78.7%的SWE-Bench任務和61.0%的Terminal-Bench任務是因為窗口裝不下而被迫中斷的,而所有有管理機制的策略,溢出率始終是零。也就是說,上下文管理帶來的那些成功率提升,大部分根源不是讓AI變得更聰明了,而是單純地防止了它因為"記憶爆表"而提前陣亡。窗口一旦足夠寬裕,自然溢出的概率就低,管理機制能救回來的任務自然也就少了。
這個發現挺打臉的,因為很容易想當然地以為上下文管理是在優化AI的"思考質量",但實際上它更像是個安全氣囊,車速慢的時候(窗口夠大)基本用不上,車速快真出事的時候(窗口緊張)才救命。
那五種策略里到底哪個最划算?
數據顯示,T4(先刪除再摘要的組合策略)在效率上碾壓其他選項。它在準確率上和T1到T3基本打平,但在八組"模型-任務"組合里有七組的成本是最低的。
研究者進一步拆解了為什麼T4這麼省錢。他們算了一個指標叫"峰值上下文占窗口預算的比例",數值越低說明壓縮得越狠。結果T4在四檔窗口預算下都是壓縮效果最好的那一檔。原因也很直白:T4的刪除機制(M1)在便宜的階段就先把不少多餘內容清掉了,真正需要動用昂貴的LLM摘要調用(M3)的次數就大幅減少了。摘要這一步是要額外調用一次大模型的,每次調用都要花錢,能少調用當然更省錢。
還有一個挺有意思的反常識發現:讓被刪除內容"可召回"這件事,幾乎沒人用,也沒帶來任何準確率提升。
T1和T2的唯一區別就是T2多了個召回工具recall_event,讓刪掉的內容能被找回來。理論上這應該是個純增益的功能,多一個選項總比沒有強吧?但實際統計下來,在64個啟用了T2/T4的實驗設置里,有36個(占56.3%)一次召回都沒用過,調用次數的中位數直接是零。即便是調用最頻繁的那個配置(Nemotron-3 30B在Terminal-Bench的32k窗口下),平均每個任務也只調用4.326次,而且成功率比不用召回的T1還低了3.37個百分點。
這就好比你花大價錢裝了個帶存檔功能的碎紙機,以為員工需要的時候能把碎紙拼回去看,結果發現大家碎完紙壓根沒人回去翻,存檔功能一直閒置,錢白花了。如果不做這個功能會怎樣?答案是:什麼也不會怎樣,該完成的任務照樣完成,該失敗的照樣失敗。這說明模型自己並沒有很強的意願或能力去主動"回憶"被刪掉的細節,它們更傾向於往前走,而不是回頭翻舊賬。這對後續設計者是個提醒:複雜的可逆機制未必值得為它付出額外的工程複雜度。
規劃:是拐杖還是累贅,取決於你有多能打
第二個被拆開檢驗的部件是規劃。啟用規劃後,系統會要求AI在動手之前先列一份任務清單,並通過一個叫update_plan的工具隨時更新這份清單的狀態,系統會在每一輪對話開始前把當前的計劃重新餵給AI看。
這個設計聽起來理所當然:誰做複雜任務不列個計劃呢?但實驗結果給出了一個分層的答案,規劃對不同能力層級的模型,起的作用完全不同。
對於能力最弱的Nemotron-3 30B,規劃是一根實實在在的救命拐杖。開啟規劃後,SWE-Bench上的成功率提升了11.6個百分點,Terminal-Bench上提升了4.5個百分點,代價是成本更高了。研究者往深處看了一層軌跡數據,發現關掉規劃之後,這個模型的SWE-Bench任務中位軌跡長度從40輪暴跌到只有5輪,而且68.6%的任務在還沒修改任何代碼的時候就已經終止了,其中58.4%的任務卡在"定位問題所在文件"這一步就放棄了。
這就像一個剛入職的新人,如果沒人提醒他"你現在該幹嘛了",他可能翻兩頁文檔就迷失方向,直接撂挑子走人。有了任務清單擺在眼前,哪怕他能力一般,至少能硬著頭皮把流程走完,嘗試去改一次代碼。規劃機制在這裡起到的作用不是讓他變聰明,而是防止他半途而廢。
而對於最強的兩個模型Nemotron-3 550B和Mistral-Medium-3.5-128B,規劃的角色徹底反轉了,它從"救命稻草"變成了"省錢工具"。在SWE-Bench上,這兩個模型開啟規劃後成本分別下降了約30%和32%,同時成功率只是輕微下降了2.0和0.4個百分點,幾乎可以忽略。軌跡分析顯示,規劃讓Nemotron-3 550B的中位軌跡長度從108輪縮短到74輪,Mistral從68輪縮短到53輪,而且這些被砍掉的輪次主要集中在"驗證階段"（重複跑測試確認修復有效）,而不是定位或修復階段本身。也就是說,強模型本來就知道怎麼修代碼,規劃的價值在於讓它別在驗證環節反覆自我懷疑、翻來覆去地跑測試。
這個發現有個挺有意思的隱喻:同一根拐杖,對腿腳不利索的人是救命工具,對身強體壯的人反而可能是累贅,因為它會讓人下意識地多走幾步沒必要的路。只不過這裡的"多走的路"反過來對弱模型是好事(逼它多試一次),對強模型是壞事(浪費一次不必要的重複驗證),而規劃機制恰好幫強模型把這多餘的重複砍掉了。
對於中等能力的Nemotron-3 120B,規劃的效果比較曖昧,成功率沒有穩定的提升,成本在兩個基準測試上一升一降,呈現出一種"看任務類型"的不確定狀態。這提醒我們,能力這個維度不是非黑即白的,中間地帶的模型,規劃該不該開可能真得具體問題具體分析。
行動空間:精密工具箱還是一把扳手走天下
第三個部件是行動空間,也就是AI跟這個世界打交道的接口。研究團隊對比了兩種極端配置:一種是給AI配備一套精心設計的預定義工具(讀文件、寫文件、編輯文件、列目錄、搜索文本、執行命令行、抓取網頁等等,每個工具都有嚴格的參數規範和使用協議),另一種是乾脆只給它一個bash命令行,讓它自己想辦法用shell命令完成一切操作。
結果同樣呈現出鮮明的能力分層。
對於bash操作能力較弱的Nemotron-3 30B,預定義工具集是決定性的救命裝備。有了這套工具,SWE-Bench成功率提升了15.0個百分點,Terminal-Bench提升了10.1個百分點。原因很直接:這個模型在訓練中學到的"工具調用習慣"跟預定義工具的接口高度契合,一旦拿掉這些工具只剩bash,它經常會嘗試調用一些根本不存在於bash註冊表里的操作,導致調用失敗。數據顯示,在Terminal-Bench上,66%的純bash軌跡都是因為這種"接口外調用"而被迫中斷的,平均軌跡長度從71輪驟降到15輪。
這就像給一個從沒學過開手動擋車的司機塞了輛手動擋車。他本來在自動擋上開得好好的(預定義工具),換擋、離合這些精細動作他都習慣了固定的操作方式,一旦換成純手動擋(bash),他連掛擋都掛不明白,車子經常熄火,根本沒法正常上路。
但反過來,對於能力最強的Nemotron-3 550B,砍掉預定義工具、只給它bash,反而帶來了成功率和效率的雙重提升:SWE-Bench上成功率提升3.6%,成本降低53%;Terminal-Bench上成功率提升5.6%,成本降低30%。軌跡分析給出了解釋:純bash模式下,這個模型發出的調用數量減少了32%(SWE-Bench)和24%(Terminal-Bench),它開始用更密集、更複合的shell命令,一條命令干多件事,而不是像用預定義工具那樣把工作拆成一堆細碎的獨立調用。研究者還統計了"重複打補丁"（re-patch,指對同一個已經改過的文件反覆修改）的次數,發現bash模式下這個數字從4.6次驟降到1.5次,說明它一次性就把代碼改對了,不需要反覆修修補補。
強模型用bash就像一個經驗豐富的老木匠,他不需要一整套貼著標籤、分門別類的專用工具,給他一把萬能瑞士軍刀,他反而能更快、更靈活地把活幹完,因為他清楚每一刀該怎麼下。而新手用瑞士軍刀,可能連該用哪個刀片都搞不清楚,給他一套標註清楚"鋸木頭用這個""擰螺絲用那個"的專用工具箱,反而能保證他不出岔子。
Mistral-Medium-3.5-128B這個模型的表現則揭示了另一層維度:任務類型本身的影響。在SWE-Bench上,預定義工具集讓它的成功率提升了23.2個百分點,但在Terminal-Bench上,純bash反而帶來6.7%的提升。研究者發現,啟用全部工具時,這個模型在Terminal-Bench上有71.9%的操作是通過bash發出的,而在SWE-Bench上這個比例只有40.4%。這說明Terminal-Bench這類命令行為中心的任務,本身就更契合shell操作的思維方式,拿掉那些跟shell"搶戲"的預定義工具,反而讓模型的行為更加統一順暢;而SWE-Bench這種需要精細讀寫代碼文件的任務,預定義的讀寫編輯工具依然扮演著重要角色。
軌跡背後的行為邏輯
如果只看成功率和成本這兩個數字,你可能覺得這篇論文講的就是"調參煉丹"的經驗總結。但研究團隊還做了一件更細緻的事:他們請了一個GPT-5.5模型作為"裁判",把每一條完整的執行軌跡拆解成一個個具體的行為階段,比如SWE-Bench上分為定位問題、復現問題、修復代碼、驗證結果、其他雜項這五個階段,Terminal-Bench上則細分成理解、寫代碼、驗證、其他四大類,底下還有十個更細的動作類型。為了確保這個AI裁判判斷得可靠,團隊專門找了三位人類標註員,對兩百條軌跡做了獨立標註,拿人類判斷跟AI裁判做對比,整體一致率約94.2%,統計學上的一致性係數(Cohen's κ)達到0.929,算是相當可靠的驗證。
有了這套細粒度的行為標籤,幾個原本停留在"數字層面"的結論,一下子有了行為學上的解釋。
上下文管理這件事,主要作用是拉長軌跡而不改變行為本身。在32k這種緊張的窗口下,不同管理策略之間的行為構成大致相似,只是軌跡能撐多久不一樣,從原本二三十輪就崩潰,拉長到能撐五十甚至一百八十輪,讓AI真正有機會走到驗證階段。而在128k這種寬裕的窗口下,不同策略之間的軌跡長度和終止方式幾乎沒差別,再次印證了前面說的:窗口夠大的時候,管理策略的邊際價值本來就不高。
規劃的效果差異,本質上是"停止時機"的差異。弱模型開啟規劃是為了撐住軌跡活到能修代碼;強模型開啟規劃是為了在驗證階段該收手時收手,不再無意義地反覆自我確認。
行動空間的差異,本質上是"代碼編寫的顆粒度"差異。預定義工具把編輯操作切得很細,一次改一小塊;bash讓強模型能一次性寫出更大段、更完整的修改,論文裡給出的數據是Mistral在bash模式下的中位最大編輯量是68行,而預定義工具模式下是87行——這個數字本身沒有絕對的好壞,但結合成功率和成本看,說明表達方式的顆粒度確實影響了整個任務的執行效率。
這些結論共同指向一個更大的圖景:編碼工具架的設計,從來不是一個"哪個方案絕對更好"的問題,而是一個必須結合模型能力、任務類型、資源預算三個維度聯合決策的系統工程問題。沒有放之四海而皆準的最優配置。
寫在後面
讀完這篇論文,最觸動我的其實不是某個具體結論,而是它提出問題的方式:我們平時評價AI編程助手,太習慣於把整個系統當成一個黑箱去評分,卻很少有人真正問過"這個分數里,有多少是模型的功勞,有多少是腳手架的功勞"。這種拆解思維本身,可能比任何一條具體結論都更有價值。
有個細節我反覆琢磨了很久:召回機制(recall)幾乎沒人用這件事。研究者花了不少工程力氣去設計一套"可逆的刪除",讓被壓縮掉的資訊理論上永遠不會真正丟失,結果模型自己壓根不怎麼調用它。這讓我想起人類寫筆記的習慣,很多人也是記完就再也不翻,與其花心思設計一套複雜的檢索系統,不如乾脆設計得更簡單粗暴一些,反而更貼合實際使用模式。這算是一種"過度設計"的警示,好的功能未必是被用得最多的功能,但沒被用的功能大概率不是好功能。
還有一點值得單獨說一下:這篇論文的實驗規模其實是有明確邊界的,規劃和行動空間的消融只在128k窗口這一個配置下做了,並沒有做完整的交叉驗證,Terminal-Bench只有89個任務,很多對比結果在統計意義上沒有達到顯著性門檻。研究者自己在論文裡坦承了這些局限,這種態度本身挺讓人信服的,一篇號稱"全面拆解"的論文,反而在結尾誠實地劃出了自己沒覆蓋到的邊界,這比強行說"我的結論放之四海皆準"要可靠得多。
如果你正在用某個AI編程助手,下次它突然表現不如預期,或者莫名其妙地繞圈子,也許答案不在模型本身,而在那個你看不見的殼子裡,在它此刻正用哪種方式管理記憶,給了它什麼樣的工具箱,又有沒有一份清單在提醒它"你現在該做什麼了"。
Q&A
Q1：編碼工具架（coding harness）到底是什麼？
A：編碼工具架是讓大語言模型真正操作代碼倉庫的軟體外殼，它決定AI怎麼規劃任務、怎麼調用工具、怎麼管理對話歷史。同一個模型換個工具架，表現可能天差地別。
Q2：上下文管理策略里哪種最划算？
A：論文裡的T4策略最划算，它先用便宜的刪除機制清理舊內容，再對更老的部分做摘要壓縮。這樣能在準確率不掉的前提下，大幅減少昂貴的LLM摘要調用，成本最低。
Q3：為什麼強模型用純命令行反而比用預定義工具更好？
A：強模型能把多個操作壓縮進一條複合的shell命令里，效率更高，重複修改代碼的次數也更少。而預定義工具集主要是幫助那些命令行能力較弱的模型，避免它們發出無法識別的調用。
