前一陣子密集讀了兩篇關于 Self-Improving Agent 的綜述文章不是翻目錄式快讀而是一行行標注、來回對照著看的那種讀法。讀完最大的感受是這個方向的論文已經多到必須靠綜述來整理脈絡但如果你只是零散刷論文很容易被各種名字繞暈——Self-Instruct、Reflexion、SPIN、Voyager、ExpeL、RLAIF……它們其實都在回答同一個問題一個 Agent 能不能不用人標數據靠自己的經驗越用越好這就是 Self-Improving Agent 的核心命題。這篇文章打算把兩篇綜述的讀法、核心分類、關鍵技術點和實踐落地經驗一次性理清楚。適合兩類讀者一類是剛接觸 Agent 方向、想快速建立全景認知的同學另一類是自己已經在搭 Agent 流程、想讓系統(tǒng)具備自我改進能力的工程師?？赐昴阒辽倌芑卮鹑齻€問題Self-Improving Agent 的組成模塊是什么最常用的技術路線有哪些以及如果自己要動手搭一個最小閉環(huán)應該從哪里開始。1. Self-Improving Agent 到底在解決什么問題為什么突然這么熱1.1 一句話定義不靠人工標注Agent 從自己的經驗里變強傳統(tǒng) Agent 是靜態(tài)的。Prompt 寫好后模型參數固定工具調用邏輯固定它每次執(zhí)行任務都在消耗工程師預置的能力不會因為做過一次任務就變得更好。Self-Improving Agent 要打破的就是這件事它把經驗變成可被利用的資產在完成任務的過程中收集數據、獲得反饋、沉淀記憶再通過這些反饋來更新自己的策略、技能甚至模型權重。換句話說它把開發(fā)-部署-失效-重新開發(fā)的循環(huán)壓縮成了部署-執(zhí)行-改進-再執(zhí)行的自動化循環(huán)。為什么這件事突然變得可行核心是兩個能力被大模型解鎖了。第一LLM 本身能生成大量多樣化數據解決了數據從哪來的問題第二LLM 可以做裁判解決了誰來判斷好壞的問題。以前要做強化學習或者迭代訓練得請人工標注成千上萬條偏好數據成本高、周期長?，F在大模型可以自己生成候選答案再自己打分、自評、過濾然后用過濾后的數據繼續(xù)訓練自己。這就是 Self-Improving Agent 在工程上能夠跑起來的最底層原因。1.2 理解自改進前先分清三件事我讀第一遍綜述時被繞暈是因為沒分清三件容易被混在一起的事改進什么、反饋從哪來、用什么機制更新。改進什么決定了整個系統(tǒng)的設計粒度?？梢愿倪M模型權重那是傳統(tǒng)訓練路線可以改進 Prompt 和上下文策略成本極低也可以改進外部記憶庫和技能庫讓 Agent 在跨任務時積累可復用的能力。反饋從哪來更是關鍵維度自生成數據里的隱性偏好算反饋環(huán)境里的可執(zhí)行結果比如代碼跑通沒跑通、工具返回報錯沒報錯也是反饋多 Agent 互相評審還是反饋。最后是更新機制是走梯度更新的 SFT/DPO還是走上下文注入的 Reflection或者寫外部記憶庫三種路線的成本、速度和穩(wěn)定性差別非常大。這兩篇綜述最值錢的地方是各自給出了一套分類法把幾十種方法歸置到這幾個維度下面。你把兩套分類法對照著看這個方向的整體地圖基本就清楚了。2. 兩篇綜述兩種切法從模型側和從 Agent 側怎么看自改進2.1 第一篇綜述模型側的自進化核心是數據-獎勵-訓練循環(huán)第一篇綜述的主線是從模型能力切入的它把自改進理解成一個大模型自我進化的過程。作者沿著數據生成-評估反饋-訓練機制-推理增強這條鏈做分類我按這個框架把它提到的核心方法歸了歸類。數據生成類方法最典型的是 Self-Instruct先用一小批種子指令讓模型生成大量候選指令再過濾清洗拿這批數據反哺訓練。評估反饋這條路主流做法有 RLAIF用 AI 反饋代替人類反饋和 Self-Rewarding LM——模型既生成答案又給自己的答案打分再把打分結果做成偏好對去訓練。訓練機制這邊SPIN 是讓當前模型生成數據、再由下一版模型踩著上一版的輸出往前走把訓練變成了模型和自己對弈的過程。推理增強類則更像免訓練優(yōu)化Reflexion 就是典型模型每失敗一次把失敗原因寫成反思文本下一輪帶著反思再試。這類綜述給人的整體印象是自改進被抽象成了一條自我造數據、自我評價、自我訓練的流水線。好處是方法論統(tǒng)一很多方法可以跨任務復用代價是它不太關心 Agent 在真實環(huán)境里長長的交互軌跡大部分工作都集中在文本生成類任務上比如指令遵循、數學推理、代碼生成。2.2 第二篇綜述Agent 側的生命周期學習核心是記憶-技能-環(huán)境第二篇綜述的切法完全不一樣。它不把討論焦點放在模型權重怎么更新上而是把 Agent 看成一個在環(huán)境里長期存活的系統(tǒng)關注它如何在一生中積累經驗。這篇綜述把方法按 Agent 架構模塊來分記憶模塊、技能模塊、規(guī)劃模塊、工具使用模塊各自都可以被自我改進。記憶模塊的代表是 ExpeL 這類經驗學習框架Agent 把成功軌跡抽取成經驗存入數據庫新任務來了先檢索相關經驗再行動。技能模塊最出名的案例是 Voyager它在游戲環(huán)境里不斷把驗證有效的操作序列抽象成技能函數存進技能庫后邊面對類似場景直接調用。規(guī)劃模塊的自改進則體現在任務拆解上比如 Agent 發(fā)現自己拆解的子任務順序不對就在下一次規(guī)劃時調整策略。工具使用模塊更好理解Agent 調工具報錯了能否從錯誤信息里學到正確用法這就是最樸素的自我改進。第二篇的關注點從模型變得更強轉移到了Agent 在它的生命周期里變得更聰明。它更重視環(huán)境反饋和交互軌跡也更重視跨任務的經驗復利。代價是這套框架非常重涉及記憶、檢索、技能抽象、環(huán)境接口一堆工程問題很多方法還處在實驗室階段。2.3 兩篇放在一起讀共識和分歧都很明顯我把兩條路線的核心差異整理成了表格對照著看會非常直觀對照維度第一篇模型側自進化第二篇Agent 側生命周期學習關注單元模型權重、推理策略記憶、技能庫、規(guī)劃策略、工具使用反饋來源自生成數據、模型自評為主環(huán)境反饋、工具返回、自我反思更新粒度往往跨大量樣本做一輪訓練單任務多次試錯 跨任務長期積累時間尺度以訓練周期為單位以任務與生命周期為單位典型方法Self-Instruct、RLAIF、SPIN、STARReflexion、Voyager、ExpeL、AgentTuning 路線主要風險數據坍縮、獎勵黑客、評估虛高災難性遺忘、技能遷移難、反饋稀疏兩篇的共同結論三個第一可靠的評估器是自改進能否成立的關鍵不管你是自評還是用環(huán)境反饋裁判崩了一切都白搭第二要警惕生成數據的多樣性坍縮模型如果只在自我重復的數據里打轉幾輪之后能力不升反降第三自改進帶來的安全性和可控性問題被嚴重低估一個會自己改策略的 Agent行為漂移后誰能及時發(fā)現這是個懸而未決的大問題。分歧也很清楚。模型側路線相信參數變強則 Agent 變強Agent 側路線則強調能力沉淀在記憶、技能和流程里更可控、更可解釋。這兩條路線不是二選一實際做產品的人基本都是混合著用用記憶和反思做輕量在線改進用定期微調做重量離線升級。3. 自改進閉環(huán)的五塊核心拼圖缺一塊都轉不起來把兩篇綜述的方法論抽干了看任何 Self-Improving Agent 系統(tǒng)都逃不過這五塊積木自生成數據、評估器、更新機制、記憶系統(tǒng)、環(huán)境和任務設計。下面逐個拆我把為什么這么做也一并說清楚。3.1 自生成數據種子質量決定天花板自改進的一切起點是模型自己造數據。Self-Instruct 的做法是準備幾十條高質量種子指令讓模型按這些種子的風格擴展出成千上萬條新指令再自己采樣回答。實操里最常見的坑是種子數據質量不行生成的指令和答案會迅速退化到一個很低的質量水平上而且這種退化是有累積效應的——第一輪生成的臟數據進入第二輪訓練只會產生更臟的數據。所以我的建議是種子數據寧少勿濫。20 條精心設計、覆蓋各個難度梯度的種子遠好過 200 條隨便湊的種子。生成時把隨機性拉高。采樣溫度調到 0.8 以上多做幾次采樣再過濾而不是只生成一次就收。過濾不是走過場。用長度過濾、去重、困惑度過濾、自評過濾每層過濾都有自己的作用。這里最容易被忽視的是多樣性。很多人只盯著生成數據的質量分結果幾輪下來所有數據都長成相似的句式、相似的推理路徑。自改進本質上是在一個由自己生成的數據分布上迭代如果這個分布迅速坍縮模型就會在窄分布里過度自信泛化能力反而下降。3.2 評估器整個閉環(huán)的裁判也是最容易崩的一環(huán)自改進閉環(huán)里誰來打分比怎么訓重要得多。評估器選錯后面全是白干。目前主流評估器有三類。第一類是程序化評估最典型的是代碼任務里的單元測試、數學任務里校驗最終答案這類評估最可靠但覆蓋面窄。第二類是規(guī)則評估比如過濾非法格式、檢查關鍵詞、算分數區(qū)間簡單直接但容易被鉆空子。第三類是 LLM-as-judge讓一個大模型當裁判給輸出打分覆蓋面最廣但也是最容易出問題的一環(huán)。LLM 裁判的毛病我踩過的就有好幾種它傾向于給自己的輸出類型打高分self-preference bias傾向于給長答案打高分verbosity bias還會在連續(xù)打分幾十條之后出現嚴重的分數漂移。應對辦法也不復雜能上程序化校驗的地方堅決用程序化校驗LLM 裁判要多模型投票、盲評、隨機打亂順序最好再給一個對照樣例做錨定。凡是評測標準寫得含糊的任務判分結果基本都不可復用。3.3 更新機制梯度、上下文、記憶三種路線怎么選有了高質量數據和可靠評估接下來就是用什么方式更新自己。三條路線各有適用場景更新機制更新對象成本適用場景典型做法梯度更新模型權重高需要算力和數據工程離線批處理追求深度能力提升SFT、DPO、SPIN、RLVR上下文更新對話上下文低即時生效在線學習單次任務內快速試錯Reflexion 反思筆記、注入新樣例記憶寫入外部記憶/技能庫低但需要檢索配合跨任務長期積累經驗庫、技能函數庫選哪條路線本質上是成本和質量之間的取舍。梯度更新上限最高但你要湊一個批次的數據、要盯著訓練防止坍縮、要設計驗證集周期是小時到天級。上下文更新勝在快失敗了下一次嘗試立刻帶上反思信息但知識只在上下文窗口里存活沒法變成長期能力。記憶寫入則像是中間路線經驗被持久化到外部不占權重也不占上下文靠檢索把相關經驗調出來。我的經驗是剛起步做自改進先別急著上權重訓練。先用上下文反思 記憶寫入把閉環(huán)跑通驗證數據質量和評估器可靠再考慮把積累下來的高質量數據拿去微調。直接上梯度的坑是模型快速記住了自己上次的錯答案在訓練分布上表現飆升一換任務分布立刻打回原形。3.4 記憶系統(tǒng)跨任務經驗如何沉淀兩篇綜述里第二篇對記憶的強調遠超第一篇。原因很好理解一個 Agent 完成了任務 A如果經驗只留在那次會話里任務 B 不會從中獲得任何好處那這就算不上真正的自我改進只是單任務內修修補補。記憶系統(tǒng)要分兩層來看。短期經驗層存的是具體某次任務的軌跡、錯誤、反思粒度細、檢索靠相似度長期技能層存的是抽象出來的可復用能力比如 Voyager 里的技能函數、ExpeL 里的跨任務經驗總結。寫入機制也比想象中講究不是所有成功軌跡都值得存只存那些有信息增量的經驗也不是所有反思都該入庫入庫前最好再做一次質量過濾。檢索比寫入更容易被忽略。經驗庫如果只管寫不管讀Agent 在新任務里檢索不到相關經驗等于白存。我見過不下三個項目死在記憶寫了一堆但沒人接得住上。檢索策略至少要包含相似度閾值設置、過期策略、以及檢索結果在 Prompt 里的排布方式這幾項不調記憶寫的越多反而越干擾主任務。3.5 環(huán)境和任務設計課程學習與自對弈的價值第五塊拼圖是任務層面的設計也是大部分文章最不重視、卻最能拉開效果差距的部分。自改進的學習信號來自任務執(zhí)行。如果任務永遠是同一批 Prompt模型學到的是記憶而不是能力如果任務難度一開始就拉滿模型永遠失敗反思積累不起來。所以不少系統(tǒng)性更強的研究工作會引入課程學習先易后難當前模型在某個難度區(qū)間達到閾值之后再推進到更難的任務。這跟人練題是一個道理全都是拔高題只會挫敗基礎題做對了要及時給甜頭。還有一類設計叫自對弈AlphaGo 是這條路的祖師爺語言模型里的 SPIN 也是這個思路。自對弈的價值在于它讓學習信號永遠不枯竭——模型打敗舊的自己要生成新數據新數據再訓練出新模型理論上可以無限滾下去。但要清醒地認識到自對弈對評估器的要求極高評估一旦有偏向對弈就會往錯誤的方向無限加強。4. 從論文到實踐5步搭一個最小可用的自改進循環(huán)綜述讀得再多不如動手跑一個最小閉環(huán)。我建議選代碼生成或者數學推理這類自帶程序化評估器的任務起步因為這類任務評估信號硬不依賴 LLM 裁判的主觀判斷最適合驗證自改進這個機制本身是否成立。4.1 最小閉環(huán)的五步設計整體流程我固定成五步定任務和評估標準 - 準備種子數據集 - 讓模型生成候選 - 評估和過濾 - 更新模型或寫入記憶。跑完一輪之后用一塊從未參與生成和評估的留出測試集來驗證效果。選種子數據時我習慣按難度分成三檔每檔 10 到 20 條。訓練集足量但不大避免過擬合到種子分布上。評估標準在開始之前就要寫清楚代碼任務就是單元測試用例數學任務就是最終答案校驗規(guī)則和通過條件都要提前凍結。4.2 核心循環(huán)的偽代碼與逐行解讀下面這段偽代碼是我每次搭自改進流程時的腳手架框架無關換成你最順手的訓練或編排框架都能落地# self_improve_loop.py —— 偽代碼按需替換為實際框架調用 from statistics import mean def self_improvement_round( model, # 當前模型或 Agent 主流程 seed_prompts, # 經過難度分檔的種子任務列表 judge, # 評估器程序化校驗 / LLM judge update_fn, # 更新策略SFT/DPO 或寫記憶庫 num_samples8, temperature0.85, keep_ratio0.3, ): # 1. 候選生成每個種子任務采樣多條保證多樣性 candidates [] for prompt in seed_prompts: outputs model.generate(prompt, nnum_samples, temperaturetemperature) for out in outputs: candidates.append({prompt: prompt, response: out}) # 2. 評估打分優(yōu)先走程序化評估否則用 judge for item in candidates: item[score] judge.score(item[prompt], item[response]) # 3. 過濾只保留高分段樣本寧可少而精 candidates.sort(keylambda x: x[score], reverseTrue) kept candidates[: max(1, int(len(candidates) * keep_ratio))] # 4. 更新兩條路線可二選一也可組合 update_fn.finetune([(k[prompt], k[response]) for k in kept]) # 路線 A權重更新 update_fn.write_memory([k for k in kept if k[score] threshold]) # 路線 B寫經驗庫 return { kept: len(kept), avg_score: mean([k[score] for k in candidates]), } # 每輪結束之后務必用 held_out_test() 驗證泛化而不是只看自評分數這段代碼最核心的設計決策有三處。第一采樣數拉高到 8偏低會把低質量輸出漏進來第二過濾比例 keep_ratio 設在 0.3 左右高了質量沒保證低了多樣性受損第三評估和更新解耦評估器可以隨時替換成更強版本不影響循環(huán)整體結構。4.3 怎么判斷改進真的發(fā)生了自改進最迷惑人的地方在于訓練集上的分數上升可能是假的?？赡苣Ｐ椭皇怯涀×苏_答案的格式或者記住了種子數據里的特定模式換一批同分布但沒見過的題又不行了。我的驗證習慣是三件事。第一凍結一塊留出測試集任何訓練數據都碰不到它每輪結束都跑一遍記錄分數曲線。第二除了準確率還要看多樣性指標比如輸出之間的相似度防止模型退化成復讀機。第三做一個消融對比拿同樣數量的隨機數據做一輪普通訓練和自改進循環(huán)做一輪訓練對比如果差距不大說明自改進流程里某個環(huán)節(jié)出了問題不是流程本身有效。4.4 成本與數據管理的實操提醒自改進循環(huán)的隱性成本比想象中高。每個種子任務采樣 8 條100 個種子任務就是 800 條生成再加上 LLM 裁判打分一輪下來 API 賬單不低。我的處理辦法是分批運行而不是一次性全量跑每批 20 個任務觀察分數曲線穩(wěn)定后再擴大LLM 裁判的調用盡量緩存同一個 Prompt 的同一次輸出不要重復打分另外所有生成數據都要帶版本號記錄是哪一輪、哪個模型、什么溫度下產生的沒有元數據的自改進數據后期排查問題根本查不動。5. 實測中常見的6個坑以及排查思路實錄自改進方向論文里寫得都很美實際跑起來問題一個接一個。我把踩過和圍觀過的經典問題整理成速查表方便你直接對著排查?，F象可能原因排查思路處理辦法多輪訓練后輸出越來越單一生成數據多樣性坍縮計算生成數據的相似性指標調高采樣溫度、擴充種子任務、引入外部負例LLM 裁判分數虛高和留出集成績對不上裁判存在 self-preference / 長度偏差抽樣人工復核打分記錄換盲評、多模型投票、能程序化就程序化訓練集分數漲留出集不漲甚至降數據污染 / 過擬合到訓練分布檢查訓練數據是否泄漏進留出集訓練與評估數據嚴格隔離擴大留出集難度更新之后舊能力明顯退化災難性遺忘對比更新前后在舊任務上的表現混合一部分舊數據回放或改用 LoRA 局部更新Agent 交互很長卻只有最終成敗信號反饋過于稀疏檢查軌跡日志是否可以拆分子目標引入過程獎勵按子目標完成度打分連續(xù)多輪改進幅度趨近于零系統(tǒng)到了能力天花板檢查過濾后保留的數據量是否過少換更難的任務分布或升級評估器精度我想展開講三個最典型的問題因為它們的排查鏈路比較長。第一個是數據坍縮。自改進數據是模型自己生成的如果過濾標準過分苛刻幾輪之后幸存的數據只剩下最標準、最安全的那些樣本多樣性迅速流失。排查方法很直接把每輪保留數據抽 100 條出來算一下它們的 n-gram 重合度或者直接用 self-BLEU 這類指標。對策是在過濾階段對低分但新穎的樣本做額外保留給多樣性一個保底。第二個是裁判和真實效果的背離。LLM 裁判打分高不代表能力真的提升。我經歷過一個案例裁判給長答案高分模型在學習之后開始瘋狂堆砌廢話程序化指標沒受影響但人工閱讀體驗極差。排查時要對比裁判分數和程序化指標一旦兩者相關性掉下來優(yōu)先懷疑裁判有系統(tǒng)性偏置而不是懷疑模型。第三個是反饋稀疏這在 Agent 類任務里尤其常見。長任務執(zhí)行幾十步只有最后一步告訴你成沒成中間的反思根本無從寫起。我的處理辦法是在任務的中間節(jié)點埋日志每完成一個子目標就記錄一次中間結果然后把中間結果也納入評估范圍。稀疏反饋是自改進落地到真實業(yè)務場景時最普遍的攔路虎這個坑躲不開只能靠工程手段攤薄。6. 最后聊幾句讀綜述的個人心得這兩篇綜述我建議不要按順序從頭讀到尾而是先讀引言的分類框架圖再跳到開放問題那一節(jié)最后才回來看具體方法。綜述最大的價值不是羅列方法而是幫你建立一套坐標系。讀的時候帶著三個問題會高效得多這套分類法能否把我手里的業(yè)務問題放進去方法的評估設置跟我的真實場景差多遠作者的邊界條件有沒有我忽略掉的東西我個人這兩年做 Agent 工程最大的體會是不要一上來就追求完全自動化的自改進系統(tǒng)。先用最笨的方式把一個單任務的改進閉環(huán)跑通任務固定、評估固定、只改一個變量。等你親眼看到訓練曲線在第二輪第三輪確實因為自己造的數據而上漲再逐步放開任務范圍、引入記憶、引入多反饋源。自改進的威力是逐步顯現的但它的坑是跳著踩的。最后分享一個小技巧把兩篇綜述的參考文獻表下載下來按被引次數排序挑前面的 30 篇精讀你就等于同時擁有了兩套精讀課程。綜述是別人的地圖論文才是真正的地形兩者配合著走這個方向你基本就不會迷路了。