2026年初，有個說法在AI圈子裡悄悄流傳：如果一個AI系統足夠聰明，它是不是應該能自己發現自己的短板，然後自己想辦法補上？
這聽起來像科幻小說，但NeoHorse團隊
做了一件挺實在的事，他們沒有去寫一個能自我改寫代碼的超級智能體，而是盯上了一個平時不太起眼的東西，路由系統。
這個選擇本身就很有意思。
想像一下你是一個客服中心的調度員，每天要把打進來的電話分給不同水平的客服。簡單的問題分給新人，複雜的投訴轉給資深員工，特別棘手的升級給主管。做久了你會發現一件事，你手裡握著的調度記錄，其實是一份關於"這個團隊到底能幹什麼、不能幹什麼"的完整檔案。誰擅長處理哪類問題，誰在什麼場景下會掉鏈子，全都寫在這些分配記錄里。
大模型的世界裡，這個調度員就是路由系統。當用戶發來一個請求，路由系統要判斷這個任務有多難，然後決定用哪個模型去處理。NeoHorse團隊的洞察是：這套路由系統每天產生的記錄，本身就是一座關於模型能力的金礦，而這座金礦此前基本被浪費了。
遞歸自我提升*：Recursive Self-Improvement，簡稱RSI，指AI系統逐漸參與到改進自身的過程中，從優化單次回答，到調整自己的執行環境，再到從自己產生的經驗里學習，是一種越往後自動化程度越高的改進路徑。
這篇論文的核心問題，就是怎麼把路由系統這座金礦真正利用起來，讓模型通過"被使用"這件事本身變得更強。
哪裡卡住了
先說清楚一件事，訓練一個會用工具、會執行任務的智能體模型，傳統做法是收集一堆"指令-回答"的問答對，餵給模型學。
但這種做法有個天生的缺陷。
一個真實的智能體任務從來不是一問一答那麼簡單。它可能是這樣的：用戶提出需求，模型思考該怎麼做，調用一個工具查資料，工具返回結果，模型根據結果再思考，可能再調用一次工具，最後才給出答案。中間還可能出錯，模型發現走錯了路，得往回退，換個方法重試。
這整個過程叫做一條軌跡，如果你只截取最後的問答對來訓練，等於把一部電影剪成了一張海報，中間所有的決策邏輯、試錯過程、恢復能力全部丟了。
Trajectory（軌跡）*：模型和環境之間一次完整交互的全過程記錄，包括用戶請求、模型的思考過程、工具調用、工具返回的結果，以及最終的處理結果。
之前的一些研究，比如FireAct和AgentTuning，已經開始用完整軌跡來訓練模型，這是個進步。但這些軌跡大多是靠一個固定的老師模型生成的，學生模型學的時候只能照貓畫虎，模仿老師當時怎麼做，而不是根據自己實際會犯的錯誤去調整。這就好比讓一個剛學開車的人只看教練的示範影片學車，而不是真正坐在方向盤後面，教練根據他自己的操作習慣現場糾正。前者學得再認真，遇到真實路況還是會手忙腳亂，因為影片裡的情況和他自己開車時遇到的情況壓根不是一回事。
NeoHorse團隊面對的問題就是：怎麼讓訓練數據不只是"老師做過的事"，而是能跟上"學生自己實際會遇到什麼"？答案就藏在路由系統天天產生的海量交互記錄里。
從路由記錄里挖出訓練金礦
NeoHorse的做法是建立一個異構模型池，配合智能路由，在真實任務場景里跑起來。
異構模型池*：由多個能力檔次不同的模型組成的模型集合，路由系統根據任務難度從中挑選合適的模型去執行。
每次有用戶請求進來，路由系統要做三件事：預測這個任務需要多強的能力，決定派哪個模型去處理，記錄最後處理的結果如何。這三件事連起來，就形成了一條"預測-行動-結果"的完整鏈路。這條鏈路里藏著兩種寶貴的資訊，一種是任務本身的執行經驗，另一種是關於模型能力邊界的證據，也就是模型在哪些地方遊刃有餘，在哪些地方力不從心。
這裡團隊做了一個精細的數據組織設計，把每次交互切分成三個層級。
最大的單位叫軌跡，指一次完整的任務執行過程。中間層叫用戶輪次，從一次用戶提問開始，到下一次提問或任務結束為止，這是訓練數據的基本單元。最小的單位叫子場景，把幾個圍繞同一個小目標的用戶輪次歸併到一起，方便打語義標籤。
這種三層結構不是隨便設計的。
打個比方，你去醫院看病，掛號、問診、檢查、開藥、複診，這是一整套完整流程，對應"軌跡"。其中"醫生問你哪裡不舒服然後給出初步判斷"是一個單獨的互動回合，對應"用戶輪次"。而"檢查發現問題後調整治療方案"這一連串相關的回合，共同服務於"確診並治好這個病"這個小目標，對應"子場景"。如果病歷只按整個就診過程記錄，你沒法單獨分析某次問診質量；如果只按每句對話記錄，你又看不出這幾次對話其實是在解決同一個問題。三層結構讓你既能看清全局，也能精確定位到某個環節出了什麼問題。
數據質量控制也做得很細。所有軌跡先經過結構校驗，檢查請求和回復是否完整、工具調用有沒有閉環、有沒有孤立的觀察結果找不到對應的調用。這一步靠的是可復現的規則，不依賴模型評分，因為這些結構性問題是客觀可判定的。
通過結構校驗的軌跡，接著進入六維語義評估，從目標達成、指令遵循、工具使用、證據一致性、錯誤恢復、終止行為六個維度評分，每個維度給出PASS、WARN、FAIL或者未評估四種狀態之一。
六維語義評估*：對一條軌跡從目標達成度、是否遵守指令、工具使用是否得當、證據是否前後一致、出錯後能否恢復、任務是否正確終止這六個方面分別評分，而不是壓縮成一個籠統的總分。
為什麼不直接給一個綜合分數就完了？因為一個籠統的分數會掩蓋問題所在。如果一條軌跡總分是及格線，你根本不知道它是哪裡出了問題，是目標沒達成，還是工具用錯了，還是最後沒能正確收尾。分開評分之後，訓練團隊才能對症下藥，知道該給模型補哪方面的課。
除了質量評分，團隊還給每條數據打上了場景、目標、結果三個維度的標籤，描述用戶到底在做什麼、期望達成什麼效果、最後結果是否驗證成功。這套標籤體系連起來，就是一張關於"用戶想幹什麼、模型做得怎麼樣"的地圖，為後續的數據分配提供依據。
路由分數，怎麼變成學習節奏
有了這些精細標註的數據，接下來的問題是：怎麼用？
團隊想到的辦法是把路由系統對任務難度的預測，變成訓練的節奏器。
具體來說，路由系統會把每個用戶請求分到四個服務檔位里，從簡單到複雜依次是C0、C1、C2、C3。
服務檔位*：C0應對低風險的簡單請求，C1是默認的通用檔位，C2支持多步推理和執行，C3提供最高能力或可靠性保障，必要時甚至會組合多個模型協同處理。
這個檔位資訊原本是給線上服務用的，用來決定該派哪個模型去處理請求。但團隊發現，這其實也是一個天然的難度標籤，可以拿來給訓練數據排隊。
不過這裡有個坑要避開。實際被派去執行任務的模型，未必真實反映了這個任務的難度，因為用戶可能手動指定了模型，伺服器可能正忙沒有空閒資源，運營策略也可能臨時調整了派單邏輯。如果直接拿"實際用了哪個模型"當難度標籤，等於把噪音也當成了信號。
團隊的解決辦法是重新估算，只根據請求本身和當前對話歷史，獨立算出一個難度分數，不管當時實際派給了哪個模型。這個分數分為硬排序和軟排序兩種算法，硬排序直接用檔位編號，軟排序則用四個檔位的加權平均，能區分出檔位相同但難度略有差異的樣本。
有了這個分數，團隊設計了一個三階段課程學習方案。
課程學習*：按照由易到難的順序給模型餵訓練數據，而不是把所有難度混在一起隨機打亂，讓模型先打好基礎再挑戰難題。
訓練分三個階段，每個階段大約占三分之一的數據量，隨著階段推進，高難度樣本的比例逐漸增加，但每個階段都會保留一部分低難度樣本，不會讓高難度樣本完全占滿後期訓練。
這個設計的用意值得琢磨。
想像你在健身房請了個私教，第一周私教如果直接讓你舉最大重量的槓鈴，你大概率會受傷，而且動作變形，學到的都是錯誤姿勢。合理的做法是先從輕重量練熟動作，再逐漸加碼。但如果訓練全程只在做輕重量，你又永遠突破不了自己的極限。私教真正的做法是循序漸進地加重，同時時不時穿插一些基礎動作鞏固，防止你只會舉重卻忘了怎么正確發力。三階段課程學習就是這個邏輯，既要循序漸進往難處走，又不能把簡單樣本徹底拋棄，防止訓練末期模型只見過高難度樣本，反而在簡單任務上變得生疏。
監督微調，學的是什麼
具體到訓練細節，團隊用的是標準的監督微調思路，但對哪些內容該算進損失函數做了精心設計。
監督微調*：SFT，Supervised Fine-Tuning，用人工或者高質量標註的數據繼續訓練一個已經預訓練好的模型，讓它學會特定任務的做法。
每條訓練樣本包含當前這一輪用戶請求，以及模型針對這輪請求產生的思考過程、工具調用、可見回復。歷史輪次里，只保留可見的回覆內容和工具交互結果作為背景資訊，但歷史輪次的思考過程會被去掉。
為什麼要把歷史的思考過程去掉？
這裡的邏輯是，思考過程是模型內部的推理鏈條，屬於"過程"，而不是"結果"。保留歷史輪次里可見的回覆和工具交互，是因為模型確實需要知道之前發生了什麼事，才能在當前輪次做出合理判斷。但歷史輪次的思考過程如果也全部保留，會讓訓練序列變得極其冗長，而且當前輪次的學習目標是讓模型學會針對這一輪的問題該怎麼思考，而不是重複背誦歷史上的思考軌跡。
訓練時，只有當前輪次里模型該說的話，也就是思考內容、工具調用、可見回復這些部分，會被計入損失函數，其他所有內容包括系統指令、工具規格說明、用戶消息、工具返回結果，全部不計入損失，只作為上下文背景存在。
這就像老師批改作文，只給學生自己寫的那部分評分，題目要求、參考材料這些不算學生的產出，不該被評分。
學生自己生成的答案，才是最真實的考驗
監督微調有個繞不開的短板，它學的是"記錄下來的正確答案"，但模型部署上線之後，面對的是自己一步步生成的內容，而不是照抄一份現成的標準答案。
這個差距被稱為分布偏移。訓練時模型總是看到"正確的前一步"，但實際使用時模型自己生成的前一步可能就已經錯了，後面的推理建立在錯誤的地基上，越走越偏。
團隊引入了在線策略蒸餾來解決這個問題。
在線策略蒸餾*：On-Policy Distillation，簡稱OPD，讓學生模型自己生成回答，教師模型則針對學生生成的這些內容提供逐個詞元的概率分布指導，而不是簡單地把教師原本準備好的答案硬塞給學生。
這個方法和監督微調最本質的區別在於，監督微調教的是"標準答案該怎麼寫"，在線策略蒸餾教的是"你剛才這樣寫，接下來該怎麼修正"。
打個比方，監督微調像是照著字帖臨摹，字帖上寫的什麼你就照著描什麼。在線策略蒸餾更像是書法老師站在你身後，看著你自己下筆寫的每一筆，實時告訴你這一筆該往哪個方向收。如果只靠臨摹字帖，你永遠學不會自己獨立創作時該怎麼控制筆鋒，因為字帖上的每一筆都是提前設計好的，不是你真實書寫時會遇到的狀態。而站在身後實時糾正的老師，才能真正針對你自己寫字的習慣給出有效指導。
團隊同樣把路由分數用在了這裡，用同樣的三階段方式安排"起始情境"的呈現順序，學生模型從這些情境出發自己生成回答，固定住的教師模型則給出逐詞元的指導信號，用反向KL散度作為優化目標，只更新學生模型的參數。
為了讓計算更高效，團隊採用了一個簡化技巧，只保留概率最高的K個候選詞元，把剩下所有的概率質量歸併成一個額外的桶，這樣既保留了關鍵資訊，又大幅壓縮了計算量。
評估反饋，反過來決定下一輪訓練什麼
整套系統最有意思的地方在於閉環設計。
每一輪訓練完成後，當前模型會在一個和訓練數據完全隔離的評估集上接受測試，測試結果按照場景標籤、質量維度、結果狀態、路由檔位聚合起來，形成一份"模型能力缺陷畫像"。
這份畫像不是拿來評分排名用的，而是直接指導下一輪訓練該往哪裡傾斜數據比例。表現薄弱的領域會被增加覆蓋，表現良好的領域適當保留但不再過度堆積。
評估-篩選-更新循環*：模型評估的結果反過來影響下一批訓練數據的構成，形成一個持續運轉的閉環，模型學到的東西決定了它接下來會從什麼樣的數據里繼續學習。
這個設計打破了"訓練數據一次性準備好、訓練完就結束"的傳統模式。傳統模式類似於一次性備考，考前把所有可能考的知識點複習一遍，考完就結束了。而這套閉環設計更像是一個長期跟蹤輔導的家教，每次模擬考之後，家教會根據這次考試暴露出的具體薄弱環節，調整下一階段的學習計劃，專門加強薄弱點，而不是每次都把整本教材從頭到尾重新過一遍。如果沒有這個反饋環節，團隊就只能憑經驗猜測模型哪裡學得不夠，訓練資源很容易浪費在模型已經掌握得很好的地方。
數字說話，效果到底怎麼樣
說了這麼多方法設計，最終還是要看效果。
團隊在十個基準測試上評估了兩個規模的模型，一個是40億參數級別，一個是90億參數級別，覆蓋了基於執行環境的智能體任務、工具調用、代碼生成、指令遵循四大類能力。
40億參數模型經過訓練後，宏觀平均分從58.94提升到64.87。90億參數模型從65.60提升到69.04。
這兩個數字背後藏著一個更值得關注的現象：訓練後的40億參數模型，在多個基準上已經追平甚至超過了未經訓練的90億參數基礎模型。這意味著後訓練方法能在一定程度上彌補模型規模帶來的差距，一個更小的模型經過恰當的訓練，可以打出接近大模型的戰鬥力。
具體到幾個代表性的智能體測試基準，訓練後的40億參數模型在PinchBench上從71.19分提升到77.33分，在τ?-Bench上從84.29分提升到88.46分，在WorkBuddy Bench上從24.62分大幅躍升到34.41分。
90億參數模型的提升同樣可觀，在PinchBench上從74.55分提升到82.25分，在τ?-Bench上從88.04分提升到90.82分，在VitaBench上從31.25分提升到42.25分。
不過團隊也很坦誠地指出，規模效應在訓練之後依然存在，而且不是均勻分布的。
在需要持續調試、從失敗中恢復、維持長序列狀態追蹤的任務上，90億參數模型的優勢依然明顯。而在相對靜態的指令遵循類任務上，兩個規模模型之間的差距反而比較小。
團隊用具體的執行軌跡案例說明了這個差異。在一個WorkBuddy的代碼修復任務里，40億參數模型只嘗試了一次實現就停下了，沒有建立起有效的測試和修復循環，留下了一個線程執行語義上的錯誤。而90億參數模型完整走完了編輯、測試、檢查、修復的循環，反覆根據執行反饋調整，直到通過驗證。
另一個更有說服力的案例出現在PinchBench的數據分析任務中。當發現pandas庫不可用時，40億參數模型反覆嘗試安裝依賴、手動解析CSV、修補腳本，這些嘗試始終無法解決根本問題，還引入了新的錯誤，最終沒能完成報告。90億參數模型則果斷放棄了原有思路，轉而使用Python標準庫里的csv模組和數學函數庫，順利完成了分析和報告。相比40億參數模型的這次嘗試，90億參數模型在請求次數、執行時間、詞元消耗三項指標上分別減少了約70.8%、76.7%、83.6%。
這個對比揭示了一個重要事實，更大模型的優勢不是"做得更多"，而是"更懂得什麼時候該換思路"。這種判斷力，恰恰是執行智能體任務里最難訓練出來的能力。
數據來源也做了對照實驗。團隊把自家路由系統產生的軌跡數據和一份公開的合成工具智能體數據集Toucan放在完全相同的訓練條件下對比，結果路由系統數據訓練出的模型在五個基準上的平均分是70.57，公開數據集訓練出的模型是64.32，差距達到6.26分，其中HumanEval提升8.54分，τ?-Bench提升11.31分。這說明真實交互場景里產生的數據，比人工合成的數據更貼近部署時模型會遇到的實際情況，訓練出來的能力也更能遷移到真實使用場景。
團隊還做了一組數據規模的擴展實驗，從同一批質量排序過的軌跡池裡，逐步擴大訓練數據量，保持模型初始化、優化設置、訓練輪數等條件不變，只改變數據量。結果顯示，五個基準的平均分隨著數據量的對數增長穩步從69.31提升到71.45，沒有出現明顯的性能瓶頸。這說明在當前的數據規模範圍內，繼續投入高質量的智能體交互數據，依然能換來實實在在的性能提升。
寫在後面
讀完這篇論文，最讓我覺得有意思的一點，不是任何一個具體的技術細節，而是這個團隊選擇切入點的方式。
大部分談論"AI自我提升"的討論，容易滑向科幻式的宏大敘事，聊模型能不能自己改代碼、自己設計新架構。但NeoHorse團隊做的事情樸素得多，也現實得多，他們只是重新審視了一個已經存在、每天都在運轉、大家卻沒太當回事的系統，路由系統，然後發現這個系統本身就自帶一套觀察自己能力邊界的機制。
這背後其實藏著一個更普遍的道理：很多時候，你想找的答案不需要憑空發明，它可能就藏在你現有系統日常運轉產生的副產品里，只是沒人把它當回事去挖掘。路由系統本來的職責是決定"這次該用哪個模型"，但順帶記錄下來的"為什麼這麼決定、結果怎麼樣"，恰恰是訓練下一代模型最缺的那種帶著真實反饋的經驗數據。
另一個值得拿出來說的細節，是團隊處理"哪個模型實際被使用"這個信號時的謹慎態度。他們明確指出，不能把執行時實際用了哪個模型當成難度標籤，因為這裡面混雜了用戶手動指定、服務資源緊張、運營策略調整這些噪音。這種對數據源頭保持警惕的態度，在很多論文裡其實是缺失的，大家往往默認能拿到的信號就是乾淨的信號。這個細節提醒我，做數據工程的時候，第一步永遠該問：這個信號到底測量的是我想測量的東西，還是別的什麼東西的混合物？
論文的結尾也很克制，團隊自己承認這只是"評估-篩選-更新"這個循環跑了一遍，還沒經過多輪疊代的驗證，至於這種自我提升能不能在模型能力持續演化的過程中長期維持下去，仍然是個懸而未決的問題。這種不誇大的態度，反倒讓人更願意相信這個方向是認真的。
如果這個循環真的能持續跑下去，一代代模型不斷被使用、被觀察、被針對性地補短板，那會是什麼樣子？會不會有一天，我們回頭看今天這種"人工設計訓練數據、人工決定訓練重點"的方式，就像現在回看手工特徵工程的年代一樣，覺得那是一個必然會被自動化取代的過渡階段？
Q&A
Q1：NeoHorse-1是什麼？
A：NeoHorse-1是一個探索遞歸自我提升的智能體模型系列，核心思路是利用部署中的路由系統記錄的交互數據來指導模型的後續訓練，形成一個評估反饋驅動訓練數據分配的閉環。
Q2：NeoHorse-1的訓練效果具體提升了多少？
A：在十個基準測試上，40億參數模型的宏觀平均分從58.94提升到64.87，90億參數模型從65.60提升到69.04，訓練後的40億參數模型在多個測試上已經追平甚至超過未訓練的90億參數基礎模型。
Q3：路由系統在NeoHorse-1的訓練中起什麼作用？
A：路由系統給每次任務預測所需能力檔位，這個信號被用來給訓練數據排課程順序，從低難度逐步過渡到高難度，同時評估反饋還會指導下一輪訓練該往哪些薄弱領域傾斜數據。
