2021年，谷歌DeepMind的AlphaCode
團隊做了一件瘋狂的事：為了在編程競賽里達到人類中等水平的成績，他們讓模型對同一道題生成上百萬份候選答案，再用層層過濾挑出最可靠的幾份提交。
這句話你讀完是不是覺得哪裡不對勁。
一道題目，人類高手可能花二十分鐘就想清楚了用什麼算法、怎麼寫代碼，AI卻要靠"廣撒網"生成一百萬次嘗試才能勉強夠到及格線。這不是AI比人聰明的故事，這是AI比人"能扛"的故事，用算力堆出來的蠻力，而不是真正理解了問題。
這就是競賽編程留給大語言模型的一道坎。今天要講的這篇論文，MARS（Multi-Agent Relay of Specialized LLMs，多專家智能體接力系統），想解決的正是這道坎背後更深層的問題：AI寫代碼時，到底知不知道自己該用什麼算法。
競賽編程為什麼這麼難啃
你可能覺得，現在的大模型寫代碼已經很強了，日常的函數、腳本、小工具，隨手就能生成。但競賽編程是另一個物種。
一道競賽題往往會同時揉進好幾個算法領域：可能一半是圖論，一半是動態規劃，中間還夾雜著一點數論技巧。而且這些題目故意設計得讓人猜不出該用哪個套路，你得先"診斷"出題目的本質，才能對症下藥。這種診斷能力，恰恰是大模型最容易露怯的地方。
已有的解決方案思路是這樣的：搭一個多智能體（multi-agent）系統，讓不同的AI角色分工合作。
> 多智能體系統：讓多個AI程序（智能體）各自承擔不同任務，通過互相協作完成一件複雜事情的技術架構，類似公司里不同部門配合完成一個項目。
比如MapCoder、CodeSIM這些框架，會設置"規劃者""編碼者""調試者"這樣的角色，規劃者負責想思路，編碼者負責寫代碼，調試者負責挑錯。這個分工聽起來很合理，但論文作者精準地指出了一個盲點：這些角色的分工是按照"工作流程階段"劃分的，不是按照"算法領域"劃分的。
換句話說，不管題目是圖論題還是幾何題，負責規劃的都是同一個"規劃者"角色，它是不是真的懂圖論、懂幾何，全靠底層大模型自己的預訓練知識兜底，系統本身沒有為它注入任何針對性的專業背景。
這就好比一家醫院，接診、開藥方、做手術分別由三個人負責，聽起來分工明確，但不管病人得的是心臟病還是骨折，接診的永遠是同一個全科醫生，他懂不懂心臟，全看他自己平時讀了多少書，醫院沒有專門配一個心臟科醫生給他撐腰。如果病人真得了心臟病，這套流程照樣走一遍，但正確率就得看運氣了。
MARS這篇論文的核心想法就是：既然題目本身有明確的算法領域，那就應該有對應領域的"專家"來負責，而不是讓一個萬金油角色硬撐。
MARS怎麼組建它的專家團隊
MARS準備了十一個"專科醫生"，每一個都對應一個算法領域，比如動態規劃、圖論、字符串處理、幾何、構造性算法等等。每個專家不只是名字不同，更關鍵的是，他們各自"讀過"不同的專業書。
具體來說，MARS給每個專家配了一個檢索增強生成（RAG）系統，讓它能去查閱一個叫cp-algorithms的算法理論語料庫里和自己領域相關的那部分內容。
> 檢索增強生成（RAG，Retrieval-Augmented Generation）：讓AI在回答問題前先去一個知識庫里檢索相關資料，再結合檢索到的內容生成答案的技術，好比考試時允許翻書查資料，而不是全靠死記硬背。
這就解決了一個根本問題：不再是讓大模型憑記憶去猜"動態規劃該怎麼做"，而是讓動態規劃專家實實在在地帶著動態規劃的參考資料上場。
拿到一道題之後，系統不會一上來就指定誰來做，而是讓全部十一個專家都自我評估一遍：這題跟我的專業相關嗎？我有把握處理這部分嗎？每個專家會給出一個置信度分數，系統根據這些分數挑出最多三個最匹配的專家組成一支小隊，再單獨問一遍誰適合當"首發"，由這個首發專家先寫出第一版代碼。
這個自我舉手的機制其實挺有意思。它不是由某個中心化的"調度員"來分配任務，而是讓每個專家自己判斷"這活兒我能不能接"，有點像一個項目群里發了個需求，誰覺得自己擅長就主動認領，最後系統按認領意願和專業匹配度挑人組隊。
如果不這樣做會怎樣？論文裡做了對比實驗：如果換成一個更寬鬆、不那麼挑剔的團隊篩選機制（論文裡的"並行集成"方案），團隊規模確實更大了，連"暴力枚舉""圖論"這種邊緣匹配的專家都被拉了進來，但最終的正確率反而沒有提升，因為專家多不等於專業對口，團隊裡塞滿了打醬油的人，賬面上熱鬧，幹活上添亂。
接力棒式協作：寫代碼、跑測試、自查、交棒
團隊組好之後，真正的幹活環節開始了。MARS採用的是一種"接力"模式，這也是它名字里"Relay"的來源。
首發專家先寫出一版C++代碼，這份代碼會立刻被丟進一個叫ExecEval的沙箱環境里，跑一遍題目自帶的公開測試樣例。
> 沙箱環境（sandbox）：一個隔離的、安全的代碼運行空間，代碼在裡面執行不會影響到外部系統，通常用來測試不確定是否可靠的程序。
跑完測試之後，同一個專家會拿到一份執行報告，上面寫著哪些測試通過了、哪些失敗了、失敗的具體原因是什麼。這時候專家要做三選一的決定：保留這份代碼（覺得沒問題）、修復這份代碼（發現了具體的錯誤並且自己能改）、或者把代碼原封不動地交給下一個專家（覺得已經超出自己的專業範圍）。
這裡有一個特別值得注意的設計細節：如果專家選擇修復代碼，修復後的新版本必須重新跑一遍公開測試，而且必須確保通過的測試數量不能比修復前更少，才會被採納，否則系統會自動把代碼打回原來那個版本，拒絕這次修復。
這個機制的意義在於，它把"要不要採納這次修改"的決定權，從AI自己的主觀判斷轉移到了客觀的測試結果上。AI很容易覺得"我這次改得挺好"，但事實是不是這樣，得靠跑分說話。
這就像一個團隊裡做代碼審查（code review），如果只憑作者自己一句"我測過了，沒問題"就直接合併代碼，出問題的概率會很高，因為人對自己的判斷天然存在盲區。但如果強制要求"你這次改動必須讓自動化測試的通過數不減少，否則不能合併"，就相當於加了一道硬性的質量閘門。如果沒有這道閘門會怎樣？論文的統計數據顯示，在697次自我檢查決策里，有4.4%的修復提議被這道閘門攔下並撤銷，這些本該被攔下的錯誤修復，如果沒有測試驗證機制，就會被悄悄接受，進而污染後續的代碼。
專家做完自己這一輪，會打包一份"交接文檔"給下一個專家：我完成了哪部分工作、還剩下什麼沒做、有什麼潛在風險需要注意。這個交接文檔不是把原始的測試報告一股腦甩給下一個人，而是經過提煉的關鍵資訊摘要，讓接手的專家能快速進入狀態，而不用從頭理解一遍所有細節。
整個接力過程有嚴格的邊界：最多輪換三個專家、最多走八個步驟，如果連續兩輪都沒有實質進展就會重新路由，連續三輪沒進展就直接停止。這種"止損"設計避免了系統在無效嘗試里反覆空轉，浪費時間和算力。
收尾還得靠"基礎設施修理工"
代碼接力結束之後，MARS還留了一道保險：一個專門負責查漏補缺的"基礎設施修復"環節。
這個環節不負責修改算法邏輯，它只處理那些和算法本身無關，但會導致代碼直接跑不通的低級問題，比如輸入輸出格式不對、少了某個頭文件、整數類型寬度不夠導致溢出。這些問題往往和"這道題該用什麼算法"沒有半點關係，純粹是工程細節上的疏忽，但只要出現一處，代碼就直接判為失敗，非常冤枉。
這個修復環節只有在檢測到這類底層錯誤時才會被觸發，論文的統計顯示，在完整版MARS的運行中，這個環節實際發揮作用、真正改動了代碼的情況只占了0.2%，也就是165道測試題目里大概只幫上了一次忙。這說明底層的Gemma 4模型本身已經能把輸入輸出這些基礎環節寫得比較可靠，這道保險大部分時候是備而不用，但一旦用上，往往就是那種"辛辛苦苦算對了，卻因為一個格式錯誤滿盤皆輸"的冤案得到平反的時刻。
成績單：分數、時間、成本的三方權衡
說了這麼多設計思路，最終效果到底怎麼樣。
論文在CodeContests測試集上選取了165道題目，用谷歌的Gemma 4模型作為底層引擎，做了一系列對比實驗。
| 方法 | 通過率 | 每題耗時（秒） | 每題Token消耗（千） |
|---|---|---|---|
| 直接提問（Direct） | 0.48 ± 0.02 | 34.9 ± 49.6 | 1.8 ± 1.2 |
| 單一RAG專家（Single-RAG） | 0.53 ± 0.01 | 59.8 ± 21.2 | 25.0 ± 3.2 |
| 並行集成（Parallel ens.） | 0.56 ± 0.00 | 360.9 ± 172.9 | 29.8 ± 5.1 |
| 基礎接力（Base relay） | 0.55 ± 0.00 | 191.6 ± 91.5 | 34.1 ± 10.2 |
| **MARS** | **0.62 ± 0.01** | 244.3 ± 154.4 | 40.3 ± 8.1 |
| CodeSIM（對照組） | 0.73 ± 0.01 | 817.5 ± 1358.5 | 32.2 ± 54.8 |
先看最直觀的數字：直接把題目丟給模型，什麼都不做，通過率是48%。加上MARS的完整設計後，通過率提升到62.4%，多了整整14.4個百分點。這意味著什麼？意味著原本每兩道題里模型就要錯過一道，現在這個比例改善到了接近每三道題只錯一道多一點。
但真正讓人眼前一亮的不是這個數字本身，而是MARS和CodeSIM的對比。CodeSIM是目前這個賽道里表現最強的框架之一，通過率高達73%，比MARS還高出十個百分點。可是它的代價也非常驚人：每道題平均要花817秒，也就是十三分鐘以上，而且波動極大，標準差高達1358秒，意味著有些題目它會瘋狂地反覆調試。相比之下，MARS每道題只需要244秒，大約四分鐘，是CodeSIM耗時的三分之一都不到。
這個權衡背後藏著一個更深的道理：CodeSIM靠的是"死磕"，在困難題目上它甚至會嘗試多達45次調試疊代，硬生生靠數量堆出正確率。MARS靠的是"找對人"，用專業分工去減少無效嘗試的次數。這兩條路徑誰更好，取決於你更在意什麼。如果你是打比賽，時間不是問題，正確率才是唯一標準，CodeSIM更合適。但如果你是要把這套系統部署到實際的開發場景里，每次調用的成本和響應時間同樣重要，MARS這種"花小錢辦大事"的思路顯然更實用。
論文裡還專門統計了一個細節：MARS在token消耗上的標準差比CodeSIM小了大概七倍。這說明MARS的行為模式更加穩定和可預期，不會出現某道題突然消耗海量資源的極端情況，這對於需要控制預算的實際應用來說是個相當重要的優點。
再看難度分層的表現。論文把題目按Codeforces的難度分成簡單、中等、困難三檔。在簡單題上，各種方法的表現都逼近滿分，差距不明顯。真正拉開差距的是中等和困難題：中等難度上，MARS的通過率是72%，而直接提問只有59%；困難題上，MARS達到40%，直接提問只有18%，相當於MARS把困難題的通過率翻了一倍還多。這個現象也印證了論文的核心論點：題目越難，越依賴精準的算法領域判斷，專業分工的價值就體現得越明顯。簡單題目怎麼寫都能對，難題才是真正考驗"知不知道用什麼方法"的地方。
換個大腦、換種語言，結論還成立嗎
一個方法好不好，不能只在一個模型上測。論文額外做了跨模型和跨語言的驗證，這一步其實很關鍵，因為很多論文裡的方法只在特定條件下管用，換個環境就失靈了。
在Qwen3.5-27B模型上，MARS比單一RAG專家方法高出3.3個百分點；在GPT-5.4-mini模型上，這個優勢擴大到13.9個百分點。也就是說，不管換成哪個底層大模型，"直接提問
論文還測試了把目標編程語言從C++17換成Python的情況。結果顯示，MARS在Python上達到62.2%的通過率，直接提問只有48.5%，差距同樣接近14個百分點，和C++17上的表現基本一致，只是Python版本運行速度慢了一些（307.6秒 vs 244.3秒），這大概和Python本身的解釋執行特性有關。
值得一提的是，論文裡還拿MARS和另一個叫PairCoder的框架做了對比。PairCoder在Python上達到70.5%的通過率，比MARS高出8.3個百分點，但耗時是MARS的1.4倍。更重要的是，PairCoder依賴一個商業化的文本嵌入模型來做方案聚類，而MARS全程用的都是開源組件。這個細節說明了一件事：MARS的優勢不僅在效果，還在於它是一套完全開放、可以自由部署和二次開發的方案，不依賴任何閉源的關鍵組件。
拆掉零件看看哪個部分真的管用
任何一個複雜系統，最怕的就是說不清楚到底是哪個設計在起作用。論文做了細緻的消融實驗（ablation study），也就是每次拿掉一個組件，看看性能下降多少，以此判斷這個組件到底有沒有用。
> 消融實驗：通過逐一移除系統中的某個組成部分，觀察整體表現的變化，從而判斷該部分對整體效果貢獻大小的實驗方法，類似於拆解一台機器，一個零件一個零件地卸下來看少了它還轉不轉得動。
結果顯示，去掉RAG檢索增強這個環節，通過率從62.4%下降到60.4%，掉了2個百分點。如果連專家的"專科"身份設定都取消，讓所有專家變成通用型的全科選手（同時也去掉RAG），通過率是61.5%，僅比完整版低0.9個百分點，但這個版本反而更慢，每題多花31%的時間，調用次數也更多。
這組數據揭示了一個很微妙的現象：單獨拿掉"專業分工"這個身份標籤，對最終正確率的衝擊其實不算大，但代價是效率明顯變差，模型需要更多的試錯和調用才能達到差不多的效果。這就像一個團隊，即便不給每個人貼上明確的職責標籤，靠著足夠多的溝通和試錯，最終結果也許差別不大，但過程會拖沓得多，開會更多，返工更多。MARS真正的價值，某種程度上不完全在於"能不能做對"，而在於"能不能更高效地做對"。
而如果去掉的是接力過程中的執行反饋機制（也就是論文裡的"基礎接力"版本，不做公開測試的自我檢查），通過率直接掉到55.2%，跌幅達到7.2個百分點，這是所有消融實驗裡最大的一次下滑。這個結果說明，讓專家在寫代碼之後能立刻看到跑測試的真實反饋，並據此決定是保留、修復還是交棒，這個環節才是MARS整個體系里最核心的支柱，比"專家分工"這件事本身更重要。
接力棒交到了誰手裡
論文還統計了實際運行中，團隊的組成規模和專家的活躍程度。數據顯示，82.4%的題目最終動用了三個專家組成的滿員團隊，只有1.8%的題目一個專家就搞定了。平均下來，一個題目里真正動手改過代碼的專家有1.35個，剩下沒動手的專家可能只是在交接過程中確認了一下代碼沒問題就直接放行。
從專家的出場頻率來看，數學、構造性算法、數據結構和動態規劃這幾個領域的專家被選中的次數最多，說明這幾類知識在競賽編程里是最通用、覆蓋面最廣的基礎技能，而像博弈論、幾何這種更細分的領域專家，只有在題目明確涉及相關標籤時才會登場，屬於"專科門診"，平時不常開門，但一旦需要，作用不可替代。
論文裡還給出了一個具體的運行案例，題目是Codeforces上一道叫"矩形上的三角形"的題目，涉及幾何和數學知識。整個流程是這樣展開的：數學專家先推導出面積公式和四條邊的枚舉方法，寫出第一版代碼，結果在公開測試里翻車了，因為矩形的寬和高在兩條邊上被算反了。同一個數學專家看到測試報告後，立刻定位問題並修復，重新提交的版本通過了測試。接著幾何專家接手，把每條邊的計算簡化成端點相減，進一步優化了邏輯的清晰度。最後構造性算法專家完成了多組測試數據的讀寫框架、加速輸入輸出以及防止整數溢出的處理。三個專家各自完成了自己最擅長的那一部分，最終這份代碼順利通過了所有隱藏測試。
這個案例其實很好地展示了MARS的設計初衷：數學專家負責"想清楚公式對不對"，幾何專家負責"把邏輯寫得更優雅",構造性算法專家負責"把工程細節打磨紮實"，三個人各司其職，沒有誰需要同時精通所有這些領域，這正是專業分工帶來的效率。
寫在後面
讀完這篇論文最讓我意外的一點是，這套系統的核心創新其實相當克制。它沒有引入什麼複雜的新模型架構，也沒有用什麼驚天動地的訓練技巧，它做的事情說穿了就是給現有的大模型分配了明確的專業身份，並且給了它檢驗自己工作成果的機會。這種樸素到近乎簡單的思路，卻能帶來14個百分點的提升，某種程度上說明了一件更值得深思的事：很多時候制約AI表現的瓶頸，不是它的能力不夠，而是使用它的方式不夠聰明。
論文裡那個"自我舉手"的團隊組建機制也讓我多想了一層。系統沒有設置一個中心化的裁判來強行分配任務，而是讓每個專家自己判斷自己適不適合，這種去中心化的協商方式反而帶來了更精準的匹配。這或許暗示了一個更普遍的道理，判斷一件事該由誰來做，有時候讓當事人自己評估，比外部強行指派更可靠。
論文的局限性也寫得很坦誠，165道題目、三種底層模型、兩種編程語言，樣本量和覆蓋面其實還有很大的擴展空間。而且那套本地質量校驗機制只能攔住"這一輪改壞了"的情況，攔不住"這一輪改得看似沒問題，但其實藏著隱藏測試才能發現的漏洞"。這個問題什麼時候能被更徹底地解決，值得繼續追問。
Q&A
Q1：MARS是什麼？
A：MARS（Multi-Agent Relay of Specialized LLMs）是一個多智能體接力系統，用於解決競賽編程問題。它把大語言模型分成十一個算法領域專家，每個專家通過檢索增強生成技術掌握對應的專業知識，系統根據題目自動挑選出最匹配的專家團隊，讓他們以接力的方式輪流編寫、測試、修復和交接代碼，最終提交解答。
Q2：MARS相比其他方法有什麼優勢？
A：在CodeContests測試集上，MARS用Gemma 4模型達到62.4%的通過率，比直接向模型提問高出14.4個百分點。相比表現更強的CodeSIM框架（73.1%），MARS雖然正確率略低，但耗時只有CodeSIM的三分之一左右，且每道題的資源消耗更穩定，標準差小了約七倍，性價比更高。
Q3：MARS的核心設計機制是什麼？
A：核心機制有兩個，一是讓每個專家自我評估是否擅長處理當前題目，據此組建最多三人的專家團隊；二是每次代碼修改後必須重新跑公開測試，只有通過率不下降才會被採納，否則自動撤銷修復，用真實的測試結果而不是模型的主觀判斷來把關代碼質量。
