Google Research 的 WikiSkill 讓 AI 代理保留失敗與成功的紀錄,無需重新訓練底層模型即可提升重複任務表現。

Google Research 推出了 WikiSkill,這是一個旨在透過保留哪些做法有效、哪些做法失敗,來幫助 AI 代理在重複任務中持續進步的框架。系統不是更新模型參數,而是將執行經驗記錄到一個持久的、類似 wiki 的知識庫中,並把選定的經驗教訓轉化為可重複使用的指令。
這種方法處理了當今 AI 代理的一個核心弱點:在一次執行中收集到的資訊,常常會在任務結束時被丟棄。在報導中的研究裡,WikiSkill 在多個基準測試上帶來了顯著提升,不過這些結果來自研究評估,而不是商業產品發布或獨立驗證的部署。
WikiSkill 將代理的工作空間分成三層。Raw Layer 會保留完整的執行軌跡,包括工具呼叫及其結果。根據 The Decoder 報導的研究描述,這些材料是不可變的,並提供後續分析所依據的證據。
Wiki Layer 會把這些軌跡提煉成結構化知識。它可以記錄重複出現的失敗模式、成功策略,以及先前嘗試得到的教訓。與代理實際使用的主動指令不同,這一層被設計為能隨時間持續存在並擴充。
Skill Layer 則包含代理實際採用的程序性指引。這些指令被包裝成「Agent Skills」,讓系統能夠在不修改模型訓練權重的情況下,改變其處理任務的方式。如果某次更新降低了表現,skills 可以回滾,而底層 wiki 仍保留曾嘗試過什麼的紀錄。
這個流程把經驗蒐集與指令更新分開。推理代理執行任務並產生軌跡;「Wiki Maintainer」分析這些軌跡,而「Skill Proposer」則利用累積資訊提出修改建議。接著,一個 gate 機制會在獨立的驗證集上評估該提案。如果提議的 skill 沒有幫助,它就會被拒絕,但那次失敗的實驗仍可供未來提案使用。
這種設計更接近持久的外部記憶與迭代式提示或工作流程優化,而不是模型內部的持續學習。The Decoder 指出,底層模型在部署後並不會真正學習;相反地,系統會寫入更好的指令,並在後續執行時取用。
研究人員在五個領域評估了 WikiSkill:數學推理、網頁搜尋、試算表操作、文件問答,以及虛擬環境中的互動任務。報告中的模型包括多個 Qwen 版本、Gemma-4-31B 和 Gemini-3.5-Flash。
根據 The Decoder 引述的研究結果,WikiSkill 將 Gemini-3.5-Flash 的平均分數從 49.5% 提升到 68.1%。在同樣的比較下,Qwen-3.6-27B 從 39.4% 提升到 63.3%。在某些單項任務上,提升更大:Gemini-3.5-Flash 在 LiveMath 從 33.0% 上升到 72.6%,在 SpreadSheet 從 50.5% 上升到 76.6%。
這些是研究基準的主張,並不能證明 WikiSkill 在生產環境中會帶來相同提升。據報告,評估平均了三次獨立執行,且該框架在研究中與其他 skill 演化方法進行了比較。現有來源材料不足以評估完整的實驗設計、營運成本,或系統在變動的真實世界資料下如何運作。
效能也會因任務而異。數學與試算表工作帶來最明顯的改善,而涉及長篇文件內容的 OfficeQA 受益則小得多。研究者部分將較小模型表現較弱歸因於它們難以在長上下文中執行經過演化的多步搜尋策略。在那些情況下,模型有時會退回到預設行為。
結果顯示,持久記憶並不會消除模型能力上的限制。系統即使成功記錄了一個有用的程序,也可能無法可靠地執行它,特別是在該程序涉及許多步驟、長上下文視窗或多次工具互動時。
對 AI 建構者而言,WikiSkill 提供了一個實用替代方案:當代理反覆遇到同一類任務時,不必每次都重新訓練。程式撰寫助理、研究代理或試算表操作員都可以保留經驗證的流程、記錄失敗的工具呼叫,並逐步優化工作流程。只要記憶是結構化且能被選擇性取用,這或許能減少把每個教訓都塞進不斷膨脹的 system prompt 的需要。
Wiki Layer 與 Skill Layer 的分離,對生產系統尤其重要。團隊可以保留完整的稽核軌跡,同時只讓經驗證的指令影響線上行為。回滾機制讓實驗風險低於直接編輯 prompt 或代理政策,不過維護者與 gate 流程的品質,仍會決定不良教訓是否進入活躍的 skill 集合。
這個框架也可能影響模型經濟性。研究報告指出,在某些情境下,使用 WikiSkill 的較小模型可以達到未使用該框架之較大模型的表現。如果這種模式在受測基準之外也成立,企業或許能用持久 skills 來降低推理成本,或把較大的模型留給較難的案例。這個結論仍然是有條件的:來源並未說明整體系統成本,包括軌跡儲存、維護、驗證執行以及額外的模型呼叫。
可移植性是另一個潛在優點。報導中的研究發現,一個模型學到的 skills 有時可以被另一個模型使用,而且偶爾表現甚至優於接收模型自行創造的 skills。但這種轉移並非普遍存在,因此組織不能假設某個成功程序可直接移植,而必須針對每個模型、任務與工具環境逐一測試。
對 企業 AI 團隊來說,最重要的營運問題是治理。保留代理失敗的持久紀錄可以提升可靠性,但也可能保存錯誤結論、敏感資訊或過時流程。報導中的 gate 機制處理的是效能退化,不一定涵蓋隱私、授權或安全。任何生產部署都需要控管哪些內容可進入 wiki、誰能檢視,以及累積知識何時過期。
下一個訊號會是 Google Research 是否釋出更完整的技術細節、程式碼,或更廣泛的 WikiSkill 評估。這些材料有助於釐清框架的運算開銷、記憶需求、驗證設計,以及在分布轉移下的行為。
建構者也應留意更長時間運作的代理,以及較少結構化的企業工作流程之結果。當前證據對數學與試算表任務最強,對長上下文文件工作則較弱。在客戶支援作業、軟體儲存庫與多使用者環境中測試,將能看出此方法是否能超越基準情境而泛化。
另一個問題是,隨著工具、網站與資料格式改變,持久 skills 是否仍然有用。從某個介面學來的流程,在應用更新後可能反而有害。因此,skills 的年齡、來源、回滾頻率與過時記憶偵測等指標,和標題數字上的任務準確率同樣重要。
WikiSkill 的特別之處,不在於它解決了持續學習,而在於它為代理最顯而易見的限制之一提供了一種有紀律的替代方案。這個框架把經驗視為一種工程資產:保留軌跡、總結教訓、提出變更,並在部署前進行測試。
這種模式對打造 AI 代理 的團隊很有前景,但這些報告中的成效應被視為早期研究證據。真正困難的生產工作,在於判斷哪些教訓值得信任、要保留多少記憶,以及如何避免代理越來越擅長重複一種過時或錯誤的策略。