你有沒有遇到過這種情況：讓一個新來的實習生做一個複雜項目，你選擇完全放手，等他做完一周之後你才發現，他從第二天就走錯了方向，後面的所有努力都是在錯誤的路上狂奔。
這不是一個假設。這恰恰是現在所有AI智能體（Agent）
系統正在發生的事。
當AI智能體去執行一個需要幾十步、甚至上百步操作的複雜任務，比如在終端里排查一個系統故障，或者修復一個大型代碼倉庫里的多語言bug，它會一步步試錯、調整、再試錯。這個過程會積累大量的經驗，成功的路徑值得被記住，走過的死胡同值得被標記出來避開。
問題是，幾乎所有現有的"自我改進"方法，都是等這次任務徹底結束之後，才回頭去總結經驗。
這就帶來一個很扎心的後果：這次任務哪怕走偏了，也沒人能救它。經驗只能留給下一次任務用，而這一次，已經廢了。
一篇來自AllSpark團隊的論文《PILOT in the Loop: Live Self-Improvement for Long-Horizon Agents》提出了一個新思路：為什麼不能讓自我改進變成"活的"，一邊幹活一邊糾偏，而不是等幹完了才復盤？
這篇論文提出的系統叫PILOT，在Terminal-Bench 2.0這個高難度基準測試上，一次性把性能拉高了最多9.8個百分點，在持續自我進化的場景下，更是讓最好成績提升了14.6個百分點。這個數字意味著什麼，我們後面會慢慢拆開講。
事後諸葛亮式的自我改進，到底差在哪
先說清楚一件事：AI智能體的"自我改進"不是什麼新概念。
反思（Reflection）*：讓AI在完成任務之後回顧自己的操作記錄，找出哪裡做得不對。
評判式評估（Judge-based evaluation）*：用另一個模型或規則去給最終結果評分。
自我進化的執行框架（Self-evolving harness）*：根據完成的任務軌跡和反饋，去修改提示詞、技能庫或者記憶內容。
這三種方法都有一個共同的特點，它們都是"驗屍式"的，都發生在任務已經結束之後。
這樣做的代價是什麼？論文裡講得很直白：新提煉出來的知識，既沒法幫上產生它的那次任務，也沒法立刻被驗證是否真的有效，只能留到下一次運行或者另一次單獨評估里去試試看。
打個比方。你在健身房練深蹲，教練不在旁邊看，你自己錄了個影片，晚上回家復盤發現膝蓋內扣了整整兩周，這兩周的訓練全都是在錯誤姿勢下加重量。如果教練當場就能看到你的動作並喊一聲"膝蓋往外頂"，你立刻就能糾正，而不是帶著錯誤的肌肉記憶練了兩周才發現問題。事後復盤能讓你下次練得更好，但救不了這兩周已經練廢的動作。
那為什麼不能一邊執行一邊糾正呢？論文指出，這裡有一個架構上的死結。
現有的AI智能體架構大致分兩種。第一種是單智能體自我糾錯，就是同一個AI既執行任務，又要判斷自己做得對不對。問題在於，它的注意力資源（也就是它能記住和處理的資訊量，術語叫"上下文窗口"）是有限的。
上下文（Context）*：AI模型在生成回復時能夠"看到"和參考的全部資訊，包括之前的對話、執行記錄、工具輸出等，容量有限。
這就好比讓一個正在開車的人同時兼職做導航員和交通安全監督員。他既要盯著方向盤、油門、周圍車輛這些執行層面的細節，又要抽出腦力去判斷"我是不是已經開錯高速公路出口了"。執行細節會擠占本該用來做戰略判斷的腦容量，結果往往是，等他意識到走錯路的時候，已經開出去二十公里了。
第二種架構是子智能體委託（subagent delegation），也就是主智能體把任務分派給一個子智能體去執行，自己等結果。這種做法確實把"幹活"和"監督"分開了，但主智能體通常只有在子智能體徹底跑完之後，才能看到它的最終總結報告。
這就像你把一個任務外包給一個自由職業者，雙方約定"做完發我"，中途你完全看不到進度，等收到成果的時候，如果方向錯了，唯一能做的就是要求返工，而不是在他剛開始跑偏的那一刻就叫停。
論文把這兩種架構的問題概括成一句話：現有架構沒辦法同時做到"實時糾偏"和"專職監督"這兩件事。這就是PILOT要填補的空白。
PILOT怎麼設計：監督者和執行者，分工不分家
PILOT的核心思路其實很樸素：把"幹活的"和"看著幹活的"徹底分成兩個獨立的角色，但讓他們之間保持一條實時通話的熱線。
論文裡管這兩個角色叫"監督者"（Supervisor）和"工作者"（Worker）*：工作者負責實際執行任務，比如敲命令、改代碼；監督者不參與具體執行，專職盯著工作者的進展，判斷要不要出手干預。
工作者在一個獨立的上下文環境裡幹活，所有瑣碎的試錯細節、報錯資訊、死胡同，全部留在它自己的記憶空間裡，不會污染監督者的視野。監督者的上下文裡只保留任務目標、關鍵節點、最近發生的事，以及"這個方向是不是不對勁"這類判斷所需的資訊。
這套設計里有兩個關鍵機制，一個叫實時引導（live steering），一個叫實時自我進化（live self-evolution）。我們一個一個講。
實時引導：一條隨時能插話的熱線
實時引導機制的核心，是監督者和工作者之間維持著一條雙向的"活線"。這條線上跑著五種信號。
工作者這邊，會主動發出三種消息。第一種叫通知（Notification），工作者覺得該匯報進展了，就發個消息，發完繼續幹活，不用等回復。第二種叫提問（Question），工作者遇到需要監督者拍板的問題時，會暫停下來，直到得到回覆才繼續。第三種叫結果（Result），工作者徹底完成任務後，系統會自動把最終結果發給監督者。
監督者這邊，可以主動做兩件事。一種叫引導（Steer），監督者發現工作者當前的做法有問題，會去翻看工作者留下的相關執行記錄，然後給出具體的糾正建議，插入到工作者下一步的行動里，當前這一步不會被打斷，等它做完再接收新指令。另一種叫中止（Abort），如果監督者判斷繼續讓這個工作者跑下去已經沒有意義了，直接叫停。
這個設計解決的根本矛盾是什麼？
是"及時性"和"清醒的判斷力"之間的衝突。單智能體自糾錯能做到及時，但判斷力會被執行細節淹沒；子智能體委託能保持判斷力的清醒（因為不用親自下場幹活），但做不到及時（只能等結果）。PILOT把這兩個優點同時拿到了，辦法就是讓監督者一直"在線"，但從不"下場"。
論文裡舉了兩個真實的案例，特別能說明這套機制怎麼起作用。
第一個案例是關於一個叫winning-avg-corewars的中等難度任務，工作者花了二十多分鐘去調試一種叫DAT-clear的策略變體，反覆實驗，結果始終跟多個對手打平，一直達不到要求的勝率。監督者這時候插話了，說的是："別再測試那些合成對手了，徹底換個策略，去找一個已發表的成熟方案，拿它去打真正的五個對手。"工作者立刻接受了這個建議，轉向使用一個叫Silk Warrior 1.3的公開經典方案，調整複製策略後，最終通過了全部五項閾值測試。
第二個案例更技術性一些，涉及一個叫torch-tensor-parallelism的高難度任務。工作者在實現一個叫RowParallelLinear的模組時，把偏置項（bias）加進了矩陣運算里，然後再做跨設備的求和歸約（all_reduce），這個順序錯誤導致偏置項被重複累加了好幾倍。監督者發現問題後指出，偏置應該在歸約操作之後再加，而不是之前。工作者認可了這個糾正，改完之後順利通過了全部13項驗證測試。
這兩個案例的共同點是，監督者不是在事後指出"你之前錯了"，而是在錯誤還沒導致任務徹底失敗之前，就把工作者從錯誤的路徑上拽回來。
論文還做了一個很細緻的統計分析：在Terminal-Bench 2.0的一次性測試里，人工檢查所有成功的任務軌跡，統計有多少是真正靠這種實時糾偏才成功的。結果發現，簡單任務里一次都沒有出現（因為簡單任務本來就在AI能力範圍內，用不著外部糾偏），但在困難任務里，兩個不同的模型分別有6.1%和19.7%的成功案例，是直接依靠監督者的實時干預才沒有失敗的。
這個數據挺說明問題的。任務越難，執行鏈條越長越脆弱，出錯的機會越多，監督者能出手挽救的空間也就越大。反過來說，如果沒有這套實時糾偏機制，這部分本可以成功的任務，很可能就直接失敗了，而且是失敗在沒人看得見的中間某一步。
實時自我進化：把監督過程中學到的東西存下來
第二個機制解決的是另一個問題：這次監督學到的東西，怎麼才能不白費，讓下一次任務也受益？
論文把這套持久化的知識倉庫叫做"框架"（Harness）*：包含技能庫（Skill library）和記憶（Memory）兩部分，會跨任務持續保存下來，供後續啟動的工作者加載使用。
工作原理是這樣的：當監督者在實時監督某個工作者的過程中，發現了一個值得沉澱的成功套路，或者一個反覆出現的失敗陷阱，它會把這個知識寫進技能庫或記憶里，形成一個更新過的框架版本。而這個更新，是在任務還沒結束、還不知道最終成敗之前就發生的，靠的是"這個操作看起來可靠"這種直接判斷，而不是等裁判評分之後才決定值不值得記錄。
這裡有個很關鍵的細節：論文的實驗設計里，只有當一輪任務真正通過驗證之後，這次任務里產生的知識更新才會被正式併入下一輪的共享框架；如果這次任務失敗了，這些臨時更新會被捨棄。也就是說，驗證結果只用來篩選"哪些更新值得留下"，而不參與"要不要生成這個更新"的決策過程。
這套機制像什麼？
有點像一個老木匠帶徒弟。徒弟在做一件新家具的時候，師傅在旁邊看著，發現徒弟琢磨出了一個巧妙的榫卯連接方式，當場就把這個手法記在師傅自己的筆記本里，不是等這件家具賣出去、顧客滿意之後才補記。而且這個筆記本是所有徒弟共用的，下一個徒弟接手類似活計時，直接翻筆記本就能用上這個手法，不用再自己摸索一遍。如果不這樣做，每個徒弟都得從零開始試錯，同樣的坑要踩很多遍，這就是沒有這套機制時候的默認狀態：經驗困在了單次任務里，出不來。
實驗怎麼設計的：讓AI在"復用經驗"這件事上被真正考驗
論文設計了兩種評估場景，來分別檢驗這兩個機制。
第一種叫一次性場景（one-shot setting），每個任務都從一個全新的、乾淨的框架狀態開始，專門用來檢驗實時引導機制在單次任務執行中的效果，跟框架積累的歷史知識無關。
第二種叫自我改進場景（self-improvement setting），把Terminal-Bench 2.0的全部任務組織成一輪又一輪的疊代，每一輪所有任務共享同一個框架狀態，做完一輪之後，只有成功任務產生的知識更新會被合併進下一輪的共享框架里，然後所有智能體帶著這個更新過的框架進入下一輪。這個設計是為了檢驗實時自我進化機制能不能真正把監督過程中積累的經驗，變成對後續任務有用的知識。
論文選用了兩個開源大模型作為測試的基礎模型，分別是GLM-5.1和Kimi-K2.6，並且監督者和工作者用的是同一個模型，這樣能確保比較的是"架構設計"帶來的差異，而不是"模型能力差距"帶來的差異。
對比的基準系統包括Pi（PILOT就是在這個框架基礎上擴展出來的）、OpenCode、Terminus-2、Hermes等幾個業內常見的單智能體框架，以及在代碼修復任務上額外對比的Mini-SWE-Agent。
一次性場景下的結果
在Terminal-Bench 2.0上，PILOT在兩個模型上都拿到了最高的一次性通過率：GLM-5.1上是71.9%，比排第二的OpenCode（66.9%）高出5.0個百分點；Kimi-K2.6上是71.3%，比排第二的Pi（66.9%）高出4.4個百分點。
|框架|GLM-5.1|Kimi-K2.6|兩模型平均|
|---|---|---|---|
|Terminus-2|64.0|59.6|61.8|
|Hermes|60.1|64.0|62.1|
|OpenCode|66.9|64.6|65.8|
|Pi|65.7|66.9|66.3|
|**PILOT**|**71.9**|**71.3**|**71.6**|
在困難任務子集上，差距拉得更大：PILOT在兩個模型上都拿到55.0%，比Pi分別高出5.0和6.7個百分點。這跟前面提到的實時干預數據是吻合的，難任務恰恰是監督機制發揮作用的主戰場。
在軟體工程類的兩個基準（SWE-bench Multilingual和SWE-bench Pro）上，PILOT在SWE-bench Pro上以59.9%的平均分顯著領先，比第二名Pi的55.5%高出4.4個百分點；在SWE-bench Multilingual上位列第二，跟第一名Pi非常接近。
綜合六個"模型-基準"組合，PILOT拿了五個第一。
自我改進場景下的結果
這才是真正檢驗"活的自我改進"是否有效的地方。
跑了20輪疊代之後，PILOT在GLM-5.1上的最佳通過率從66.3%一路漲到80.9%，漲幅14.6個百分點；在Kimi-K2.6上從68.5%漲到80.9%，漲幅12.4個百分點。
而在同樣條件下，也就是所有框架從同一個初始技能庫出發、接受完全相同的任務輸入的對比實驗裡，PILOT漲了14.6個百分點，OpenCode只漲了7.9個百分點，Pi只漲了2.3個百分點。
這個差距說明什麼？說明單純擁有一個可以存放技能的倉庫，跟能不能真正把執行過程中的經驗高效地轉化成倉庫內容，是兩碼事。PILOT因為有專職的監督者盯著執行過程去提煉知識，轉化效率明顯更高。
技能庫本身也在實打實地變大：GLM-5.1對應的技能數量從62個漲到83個，Kimi-K2.6從50個漲到81個。這說明PILOT不是把每次任務當成孤立事件處理，而是真的在把執行經驗持續沉澱成一個越來越豐富的可復用技能池。
更有意思的是效率指標。隨著技能庫的積累，每完成一個任務所需要生成的輸出量（用token數衡量）顯著下降：GLM-5.1從每任務平均2.85萬個token降到1.63萬個，降幅42.9%；Kimi-K2.6從4.19萬降到2.21萬，降幅47.4%。
而"每百萬token能換來多少次成功評估"這個效率指標，反而漲了：GLM-5.1提升110.3%，Kimi-K2.6提升134.0%。
這組數據放在一起看特別說明問題。既省錢（token更少），又更容易成功（每單位成本的成功率更高），這背後的邏輯是，當一件事之前已經有人蹚過路，你不需要重新摸索，直接照著做就行，探索成本大幅下降了。
這就好比一個新手廚師第一次做紅燒肉，得反覆試火候、試調料比例，可能炒糊幾次才摸出門道。但如果廚房裡已經有一本詳細寫清楚"多大火候、幾分鐘翻面、糖色怎麼炒不發苦"的筆記，第二次做同樣的菜，速度快了，失敗率也低了。PILOT做的事情，本質上就是讓每個工作者不用重新當那個第一次做菜的新手。
按任務難度拆開看，性能提升也主要集中在難任務上：GLM-5.1在簡單任務上只多通過了2個，中等難度多6個，困難任務多8個；Kimi-K2.6分別是1個、7個、12個。這個規律跟一次性場景下的觀察是一致的，困難任務的執行鏈條更長，出錯和積累經驗的機會都更多，所以自我改進的收益也更大。
從這一整套數據來看，PILOT真正做到的，是把"這次任務的監督經驗"和"下次任務的執行能力"用同一條時間線串起來了，不再是兩件事後才發生聯繫的獨立事件。
寫在後面
讀這篇論文的時候，有個細節讓我停下來想了一會兒：監督者和工作者用的是同一個模型。
這意味著PILOT帶來的性能提升，完全不是因為用了一個更聰明的模型去監督一個較笨的模型，而是純粹的架構設計紅利。同一個能力水平的AI，僅僅因為被拆成兩個角色、分配了不同的注意力任務，整體表現就能提升好幾個百分點。這個事實本身，比任何具體數字都更值得琢磨：很多時候限制我們的不是能力不夠，而是同一份注意力被迫同時處理執行和判斷這兩件事，誰都做不精。
另一個值得單獨說一說的地方，是論文對"什麼才算真正被實時引導挽救的成功案例"的定義。他們沒有簡單地說"監督者插話之後任務通過了就算數"，而是要求必須證明監督者指出了具體錯誤、工作者確實採納了這個建議、並且最終是沿著修正後的路徑完成的，凡是干預被忽略、過時或者多餘的情況，都被排除在外。這種較真的統計方式，讓6.1%到19.7%這個區間的數字有了分量，不是一個可以隨便注水的漂亮數據。
論文自己也坦承了局限：因為疊代式的自我改進要把每個任務重複跑很多輪，成本比單次推理高得多，所以目前的驗證只覆蓋了三個基準和兩個開源模型，監督者和工作者也始終是同一個模型擔任。如果換成能力更強的模型來當監督者，去指導一個能力較弱的執行模型，會發生什麼？這個問題論文沒有回答，留給了未來的工作。
Q&A
Q1：PILOT是什麼？
A：PILOT是一個由監督者和工作者組成的雙角色AI智能體系統，能在任務執行過程中實時糾正走偏的操作，並把過程中學到的有用經驗實時存入可復用的技能庫，供後續任務直接使用。
Q2：PILOT和普通的AI自我反思方法有什麼區別？
A：普通反思方法都是等任務徹底結束後才總結經驗，沒法挽救正在進行的任務；PILOT讓一個獨立的監督角色全程盯著執行過程，能在任務還沒失敗之前就實時糾偏，並同步把經驗寫入知識庫。
Q3：PILOT的效果具體好在哪裡？
A：在Terminal-Bench 2.0上一次性通過率最高提升9.8個百分點；在持續自我改進場景下，最佳通過率提升12.4到14.6個百分點，同時輸出成本下降超40%，成功率反而更高。
