K1 論文詳解

背景

近年來,自主 AI agent 已經開始嘗試獨立完成完整的機器學習(ML)研究流程——從讀論文、寫程式碼、跑實驗到分析結果。這類 agent 通常由兩部分組成:一個作為「大腦」的模型 backbone(例如 GPT-5.5),以及一套負責規劃、執行、記憶與驗證的 harness(執行框架)。這套架構在理論上已經相當完整,但論文作者指出一個長期被忽略的缺口:operational knowledge(操作知識)。

所謂操作知識,是指「知道一個方法」和「真的能讓這個方法跑起來」之間的差距。舉例來說,論文摘要或 GitHub README 可能會告訴你某個模型的架構,但真正讓訓練穩定收斂、避免顯存爆掉、正確設定超參數、繞開版本相容性地雷的訣竅,往往散落在原始碼的細節、issue 討論、或是資深工程師的經驗裡。這些知識並非不存在——它們就寫在成千上萬個 GitHub 倉庫與論文裡——但這些內容是為「人類讀者」設計的,格式冗長、非結構化,遠遠超過 agent 在單次任務中能塞進 context window 的容量。結果就是,即使 agent 有能力搜尋這些資料,也往往因為資訊過載而無法有效利用,只能每次任務都從頭「重新摸索」,而不是重複使用前人已經驗證過的做法。

這篇論文(arXiv: 2609.02749,提交於 2026 年 9 月)由北京智源研究院(BAAI)、中國科學技術大學、中國人民大學與香港理工大學的研究團隊共同完成,提出了一套系統性的解法,試圖把這層「操作知識」從人類可讀的文獻,轉化為 agent 可直接調用的、經過驗證的「技能(skill)」。

方法

論文提出的核心系統名為 DisCo,是一個具備「技能生成」與「技能使用」雙重能力的研究 agent。其設計理念是:不去改動模型 backbone 或 agent harness 本身,而是在其上疊加一層可重用的知識層,讓 agent 在需要時載入相關技能,而不是每次都得閱讀完整的原始碼倉庫。

DisCo 的蒸餾(distillation)過程分為兩種互補模式:

1. Task-agnostic(任務無關)蒸餾:預先、離線地把 ML 領域中被廣泛使用的知名倉庫(例如常見的訓練框架、模型實作、資料處理工具等)轉化為通用型技能,供未來各種任務重複調用。
2. Task-oriented(任務導向)蒸餾:針對一個具體任務即時生成專屬技能,透過問題拆解(problem decomposition)與資料來源探索(source discovery),找出解決當前任務所需的知識並加以萃取。

兩種模式都遵循相同的四階段流程:先界定能力範圍(scoping capabilities),再以實際證據佐證(grounding with evidence),接著建構技能之間的關聯圖譜(constructing skill graphs),最後透過實際執行來驗證技能是否真的有效(verifying through execution)。這個「先驗證再收錄」的機制,確保進入技能庫的知識不是憑空生成的幻覺,而是真正跑得通的操作步驟。

每個技能本身採三層結構設計:第一層是一份精簡的 markdown 介面,概述技能用途;第二層是更詳細的參考文件;第三層則是可直接執行的腳本。這種分層讓 agent 能夠採用「漸進式揭露(progressive disclosure)」策略——先看摘要判斷是否相關,只有真正需要時才展開完整內容,避免一次把大量無關資訊塞進 context,浪費 token 也稀釋注意力。

將這套 task-agnostic 蒸餾流程套用到整個開源生態系後,研究團隊建立了 AREX-Skill Library:從 1,000 個廣泛使用的 ML 倉庫中,蒸餾出超過 5,000 個(精確數字為 5,353 個)已驗證技能,並組織成 20 個領域(areas)與 178 個能力家族(capability families),再搭配一套路由機制(router)協助 agent 快速定位所需技能。

實驗結果

為了驗證技能層本身的價值,研究團隊刻意「控制變因」:固定使用 GPT-5.5(Codex 版本)作為 backbone、固定研究 harness、也固定下游執行的運算預算,唯一的差異是「有沒有配備 DisCo 蒸餾出的技能」。這樣的設計讓實驗結果能乾淨地歸因於技能層本身,而非模型能力或算力的提升。

在四個具代表性的 benchmark 上,結果如下:

• MLE-bench(端到端 ML 工程任務評測):分數從 31.11% 提升到 72.89%,相對提升 134.3%,幾乎是原本的兩倍以上。
• PaperBench(考驗 agent 重現論文結果的能力):從 29.45% 提升到 39.59%,相對提升 34.4%。
• FrontierCS(前沿電腦科學任務):從 70.63 分提升到 77.14 分,相對提升 9.2%。
• PassNet(以 AS Score 衡量):從 1.343 提升到 1.5313,相對提升 14.0%。

其中 MLE-bench 的漲幅最為驚人——超過翻倍的成績提升,意味著在沒有任何模型升級或算力加碼的前提下,單純補上「操作知識」這一層,就能大幅改變 agent 完成端到端 ML 工程任務的成功率。這也印證了論文的核心假設:許多 agent 在真實研究任務中失敗,並非因為推理能力不足,而是因為缺乏足夠具體、可執行的領域訣竅。

意義

這篇論文的價值不只在於一個好用的工具庫,更在於它點出了 AI 研究 agent 發展路徑上一個容易被忽視的維度。過去改進 agent 的主流思路多集中在兩個方向:一是換更強的模型 backbone,二是優化 harness 的規劃與驗證邏輯。DisCo 提出的第三條路——把人類專家寫在文檔與程式碼裡、但難以被機器直接消化的「隱性知識」系統化地萃取、驗證、並以 agent 友善的格式重新封裝——某種程度上類似人類專業社群中「最佳實踐(best practices)」與「內部 wiki」所扮演的角色。

從實務角度看,這種做法有幾個延伸意義。首先,它降低了 agent 重複踩坑的成本:一旦某個訓練技巧或環境設定問題被蒸餾成技能並驗證通過,之後所有任務都能直接複用,而不必每次重新試錯,這對於運算資源有限的場景尤其重要。其次,5,000+ 技能、20 個領域、178 個能力家族的規模,顯示這套方法具備一定的可擴展性,未來有機會持續納入新出現的倉庫與論文,讓技能庫隨著 ML 領域的演進而動態成長。第三,這種「知識層」與「模型層」解耦的設計,意味著未來即使 backbone 換成更強的模型,累積下來的技能庫依然可以延續使用,形成一種跨模型世代的知識資產,而不必每次都從零開始。

當然,這也帶來新的問題:技能庫的品質與覆蓋範圍高度依賴蒸餾流程本身的可靠性,如何持續驗證、更新甚至淘汰過時或錯誤的技能,將是未來維護此類系統的關鍵挑戰。但整體而言,Repo-To-Skill 提供了一個具體且數據紮實的範例,說明「操作知識工程」有可能成為繼模型能力與 agent 架構之後,推動自主 AI 研究邁向實用化的第三根支柱。

背景

過去兩年,「agent」已經從研究原型走向真正部署的產品,但大家很少注意到一件事:agent 的表現不只取決於底層模型本身,更取決於模型之外的「執行基礎設施」——也就是所謂的 agent harness。harness 包含了工具呼叫的介面、記憶管理、檔案系統存取、錯誤重試邏輯、評分回饋機制等一整套支撐系統。同一顆模型權重,換一套 harness,下游任務表現可能天差地遠。

問題是,目前絕大多數 agent 評測,都是「固定一套人類工程師精心打造的 harness,再測試模型在上面表現如何」。這其實只回答了一半的問題:模型能不能用好工具?卻沒有回答另一半更根本的問題:模型能不能自己打造工具?隨著企業愈來愈依賴 LLM 自動生成整套 agent 系統(而非人工維護),這個能力差距變得至關重要。這正是 HarnessDev 這篇論文想要填補的空白——把評測單位從「任務輸出結果」轉移到「可執行的基礎設施本身」。

方法

HarnessDev 設計了兩個階段的評測流程,並區分三個角色:負責打造 harness 的「創造者模型」(Creator LLM)、負責在固定 harness 上執行任務的「執行者模型」(Executor LLM),以及負責打分的評審(Evaluator)。

第一階段「Creation(創造)」:創造者模型只拿到一個極簡的種子範本和少量範例任務,必須從零打造出一整套可運作的執行系統——包括工具介面、控制流程、錯誤處理等。第二階段「Evolution(演化)」:模型從自己剛創造出的 harness 出發,根據下游執行的實際回饋(哪裡失敗、哪裡浪費 token),反覆修改精進 harness,目標是提升 benchmark 分數。

研究團隊評測了六個創造者模型(涵蓋 Claude、GPT、Gemini 等主流家族),涵蓋四個應用領域:程式碼(code)、資料分析/機器學習實驗(ML experimentation)、寫作(writing)、以及搜尋研究(search & research)。下游測試集包括 SWE-bench Pro(731 個任務)、Terminal-Bench(89 個任務)、MLE-bench(33 個任務)、一個自建寫作測試集(46 個任務),以及 BrowseComp 與 EQ-Bench3 兩個搜尋研究相關測試,總計 2,207 個獨特下游任務實例。特別重要的是,其中有一部分「隱藏評測任務」在開發過程中完全不對模型開放,以檢驗生成的 harness 是否只是過擬合到訓練時看過的案例。評測指標分為兩軸:能力(在保留測試集上的任務成功率)與效率(執行過程消耗的 token 成本)。

實驗結果

創造階段的結果相當耐人尋味:LLM 自己生成的 harness,在程式碼與搜尋研究這兩個領域,明顯落後於人類工程師精心打造的參考系統(reference harness),差距不小;但在寫作與機器學習實驗這兩個領域,自生成的 harness 竟然能追平甚至超越參考系統的表現。換句話說,模型「造工具」的能力在結構化程度較低、較依賴語言生成的任務上更成熟,但在需要嚴謹工程規範(例如程式碼倉庫的建置、測試、除錯迴圈)與長鏈搜尋推理的任務上仍有明顯短板。

執行成本的變異也非常大——例如在 MLE-bench 上,不同 harness 之間的 token 消耗可以相差高達 19 倍,而且花更多 token 並不代表分數更高,顯示許多生成的 harness 效率低落。

演化階段的結果則揭露了穩定性問題:模型確實能透過回饋改善 harness,在可見的回饋任務集上平均提升約 3.11 分,但這些進步「不穩定且只能部分遷移」到隱藏測試任務上——回饋集分數與隱藏測試集分數的方向一致比例僅有 53.1%,幾乎就是擲硬幣的機率。此外,研究團隊也測試了「固定執行者模型」的情境,發現同一套演化出的 harness,換到不同執行模型上表現差異巨大——例如當執行者固定為 Gemini 時,只有 Opus 演化出的 harness 有進步,其餘幾個模型演化出的 harness 反而退步,顯示 harness 與特定模型之間存在明顯的「共適應」(co-adaptation)現象,可移植性有限。

意義

HarnessDev 的核心價值在於把「agent 評測」的討論往前推了一層:過去我們問「模型在既定工具鏈上表現如何」,現在必須追問「模型能否勝任打造與維護那套工具鏈本身」。這對正在推動「AI 自動化 AI 開發流程」的產業趨勢極具警示意義——如果企業想讓 LLM 自主搭建、迭代自己的 agent 基礎設施以節省人力,目前的證據顯示這條路在程式碼工程與複雜搜尋推理場景還不成熟,自動生成的系統與人類專家設計的系統之間仍有實質差距;而演化過程中出現的不穩定與跨模型遷移失敗,也提醒我們:針對單一模型特化優化出來的 harness,未必能在換模型、換任務分布之後繼續有效。這對於想要建立「模型無關」(model-agnostic)且長期可維護的 agent 系統的工程團隊來說,是一個值得認真評估的風險點,也為後續研究指出了明確方向:如何讓 LLM 生成的基礎設施更穩健、更具泛化能力,而不只是針對眼前的回饋訊號做局部優化。

背景

人類學習很多時候是從一個模糊的目標開始的，例如「成為更厲害的物理學家」或「把研究做得更好」。學習者必須自己解讀這句話到底在說什麼、找出自己哪裡不足、決定要用什麼方法學習，最後還要判斷自己是不是真的進步了。這整套「自己出題、自己解題、自己打分數」的能力，正是目前 LLM 自我進化（self-evolution）研究普遍缺乏的一環。過去的研究通常直接給模型明確的任務和評分標準，於是所謂的「自我進化」其實只是在一個已知目標函數上做最佳化，模型不需要決定「該學什麼」與「該怎麼學」，只需要把既定分數衝高。這種設定和真實世界裡人類面對的模糊目標差距很大，也讓人懷疑現有的自我進化方法是否真的具備自主學習的能力。

為了填補這個空缺，研究團隊提出了 ASPIRE 基準測試，專門用來檢驗模型在「只給一句模糊的能力目標」時，能不能像人類一樣完成從目標解讀到能力驗證的完整閉環。

方法

ASPIRE 的核心設計是：只提供一段自然語言描述的能力目標，下游真正用來評分的任務對 agent 完全隱藏。Agent 必須自己完成一連串決策——挑選訓練資料、選擇更新方法（例如微調權重或改寫自己的執行框架）、建立訓練與驗證訊號，並自行決定何時該進行評估。這個環境同時支援兩種進化路徑：一是「模型權重進化」，直接對模型參數做微調；二是「agent 框架進化」（harness evolution），也就是修改 agent 的程式邏輯與工作流程本身。

評測部分，ASPIRE 準備了一組隱藏、由專家編寫的 520 道測驗題，涵蓋六個能力目標：科學與學術推理（75 題）、人文與社會科學知識（110 題）、健康與醫療推理（100 題）、數學推理（126 題）、邏輯與指令遵循可靠性（89 題），以及學術與科學寫作（20 題）。實驗中測試的決策模型包含 Qwen3.5-4B 與 Qwen3.5-9B（作為「Self」自我進化組），以及 GPT-5.6 衍生出的三個變體 Luna、Terra、Sol，另外也納入 Claude Opus 4.8；實際執行訓練與推論的底層模型則統一使用 Qwen3.5-4B。作為對照基準，研究團隊手工打造了一套工程化的 Qwen-Agent 參考框架，在學術寫作子集上拿到 Task macro 28.64、Example micro 27.65 的分數，作為衡量 agent 自行演化出的框架好壞的標竿。

實驗結果

在「權重進化」(RQ2) 實驗中，研究分成兩種協定測試。第一種「僅看最終結果」協定共執行 24 次訓練，12 組模型與目標配對中只有 1 組的平均分數超過基礎模型，24 次個別執行裡也只有 3 次出現進步，例如 Qwen3.5-9B 在科學推理上從 45.33 分升到 48.00 分。第二種「自適應回饋」協定涵蓋 30 組配置與目標組合，其中 28 組成功產生可評估的檢查點，但只有 2 組的最佳檢查點超越基礎分數，像是 Terra 在數學任務上從 17.86 分進步到 20.10 分，是唯一被保留下來的提升。整體而言，權重層級的進步非常稀少且不穩定。

在「框架進化」(RQ3) 實驗中，三個由 agent 自行演化出的後繼框架全部低於工程化的 Qwen-Agent 參考分數：Sol 版本得到 Task macro 27.22、Example micro 25.97（比參考低 1.42 分），Terra 版本為 20.76／20.14，Luna 版本更只有 19.32／18.33。研究也發現，agent 常常訓練在與目標不匹配的資料上，並過度信任自己建構的、範圍狹窄的自我評估訊號，導致在本地測試看似進步，卻無法轉移到隱藏的正式評測上；甚至持續搜尋與訓練還可能把先前累積的進步抹掉。

意義

ASPIRE 的結果揭示了一個關鍵落差：現有的 LLM agent 已經能夠熟練地跑完「訓練—評估—修改框架」這整套自我進化的操作流程，看起來像是在自主學習，但真正衡量「有沒有變強」時，答案大多是否定的。無論是直接調整模型權重，還是讓 agent 重寫自己的執行框架，成功案例都屈指可數，甚至比不上人類工程師手動設計的 Qwen-Agent 基準。這說明目前自我進化研究的瓶頸並不在於「能不能訓練」，而在於「知不知道該學什麼、該怎麼驗證自己真的學會了」——也就是目標解讀與可靠自我評估的能力。對於想推動 AI 走向更自主學習形態的研究者來說，這是一記提醒：在把自我進化系統部署到開放式、模糊目標的真實場景之前，必須先解決資料選擇偏差與過度自信的自我評估問題，否則看似熱鬧的訓練迴圈，很可能只是原地打轉甚至倒退。