Repo-To-Skill 深度解讀：模型不動，MLE 成績翻倍？（2026）

2026 年 9 月 2 日，11 位研究者在 arXiv 發表預印本〈Repo-To-Skill: Distilling GitHub Repositories Into AI4AI Skills〉：他們把 GitHub 機器學習專案蒸餾成 Agent 可呼叫的技能圖，並報告固定 GPT-5.5 權重與 Codex harness 後，MLE-bench 的 Any Medal 成績由 31.11% 升至 72.89%。這不是「多 134.3 個百分點」，而是增加 41.78 個百分點、相對提升 134.3%，最終約為基線的 2.34 倍。

這個數字確實醒目，但它不是整篇研究最重要的地方。真正值得追的是：如果模型的參數知識、Agent harness 的操作能力之外，還能插入一層有來源、可路由、可驗證的程序知識，固定模型能否少走彎路？答案目前是「很有可能」，但 Repo-To-Skill 的公開技能庫、benchmark 用的任務專屬技能，以及建置成本，必須拆開來看。

先說結論：Repo-To-Skill 是知識層的初步證據，不是免費升級模型

我的判斷是：Repo-To-Skill 最有價值的貢獻，不是發明 Agent Skill，也不是證明 5,353 個公開 skills 直接讓 MLE-bench 翻倍；而是把「讀 repo、找證據、寫操作流程、驗證後再路由」做成一條可規模化的工程管線。它讓知識不只躺在模型權重或長 prompt 裡，而能成為有版本、有依賴、有失敗條件的部署物。

不過，模型權重沒有更新，不等於完整系統成本相同。MLE-bench 的每一個競賽都先建一張任務專屬 skill graph，可用最多 24 GPU-hours 探索；下游執行再另給最多 24 GPU-hours。這比較接近把前置研究壓縮成外部 context，再觀察同一個 Agent 的後續表現，而不是模型憑空長出新能力。

DisCo 做了什麼：把 repo 從文件變成可呼叫的技能圖

論文把整套研究 Agent 稱為 DisCo。Creator mode 負責製造技能圖；Researcher mode 只載入當前任務需要的分支。每個 skill 以 SKILL.md 說明何時啟用、怎麼做與何時失敗，較深的文件放進 references/，能安全執行的檢查或包裝則放進 scripts/。技能之間再用 routing、dependency 與 composition links 串成圖。

作者對核心差異的原話很精準：

“verification is what separates distillation from summarization”

中文：驗證，才是把知識蒸餾與一般摘要分開的關鍵。

Repo-To-Skill，Section 3.2

流程因此不是叫模型「讀完後寫一份教學」，而是四步循環：先界定能力範圍（scope），再把說法落到 source、文件、範例與 tests（ground），接著建技能圖（construct），最後用原生測試、CLI、tiny fixture 或 smoke check 驗證與修補（verify and refine）。重要的是，這些檢查是「可用時採用」，公開資料沒有揭露所有候選 skills 的通過、跳過、修補與淘汰比例；所以「verified」應理解為通過作者的內部 graph-level workflow，不是第三方逐項認證。

5,353 個 skills 的規模是真的，但「常用」與「驗證」仍是作者定義

AREX-Skill 官方專案公布的 snapshot 包含 1,000 張 repository graphs、5,353 個 skills、20 個 areas、178 個 capability families，以及 2,209 筆 repo-to-family assignments；其中 700 個 repositories 被分到不只一個 family。公開索引可以核對 1,000 個獨立 repository roots 與分類數量，但 5,353 與驗收狀態仍來自同一研究團隊的 artifacts。

建置本身也不便宜。作者表示使用 GPT-5.5 與 GPT-5.6-sol、xhigh reasoning，平均配置約每個 repository 40 美元。按論文描述，這筆預算不只用來產出摘要，也用於 provenance、使用條件、路由、測試與修補；建置流程另保存檢查紀錄，但公開 runtime skill graph 沒有完整附上 verification reports。是否划算，取決於同一知識會被重用多少次。一次性任務可能不值得，反覆發生的研究或工程流程才有攤提空間。

134.3% 怎麼來的：同模型、同 harness，但不是同總成本

MLE-bench 的受控配對使用 GPT-5.5、Codex 與 xhigh reasoning，覆蓋 75 個競賽。無 skill 的 Any Medal 平均為 31.11%，加入 AREX-Skill 後是 72.89%。兩者相減為 41.78 個百分點，再除以 31.11%，就是作者標示的 134.3% 相對提升。論文表格把兩個 Codex 條件都以三次重跑的 mean±SEM 呈現；但沒有公開每次原始 run，也沒有為兩條件差值提供 paired test。

其他三組作者自報結果方向也大致正面，但同時出現重要反例：

• PaperBench：平均 29.45 升至 39.59，相對增加 34.4%；20 個 replication tasks 中 18 個改善、2 個退步。
• FrontierCS：70.63 升至 77.14，相對增加 9.22%；同樣是五小時上限，但平均 tokens 從 2.46M 增至 4.47M，steps 與 tool calls 也增加。
• PassNet：AS Score 從 1.343 升至 1.5313，相對增加約 14%；correctness 提高，但 Fast_1 從 28.48% 降至 26.72%。

最關鍵的界線：公開 5,353-skill library 沒有直接產生這四組分數

這是讀完論文最容易漏掉、也最影響結論的一點。公開的 5,353 個 skills 是從 1,000 個 repositories 建出的 task-agnostic snapshot；四個 benchmark 則另外建立 paper-derived 或 task-oriented graphs。MLE-bench 為 75 個 competitions 各做一張 graph，PaperBench 從 153 篇相關 papers 蒸餾 636 個 skills，FrontierCS 與 PassNet 也各有專用 graph。所以現有證據支持「精心建置的任務知識層可以幫助固定 Agent」，但沒有直接證明「把 Agent 接上公開 5,353-skill 大庫，就會得到 134.3% 增益」。

論文自己也明白寫出：一次性的 skill 建置預算與下游執行分開計算。MLE 的 task-oriented graph 可在下游測試前使用最多 24 GPU-hours 做探索、web research、診斷與修訂；作者主張排除原競賽頁面與 competition-specific content，final skill 也沒有可直接 replay 的訓練或推論腳本。這些設計降低了直接搬答案的疑慮，但外部仍無法從目前公開 collection 完整重建 75 張 graph 與來源過濾紀錄。

這項研究支持了什麼，又尚未證明什麼？

我同意：程序知識值得成為模型與 harness 之外的第三層

模型擅長生成候選做法，harness 負責工具、迴圈與權限，skill 則能保存某個版本下已驗證的操作路徑。三者分開後，知識可以被更新、回滾、A/B test，也能在問題發生時追到來源。這比把所有經驗埋進 system prompt，或每次都讓 Agent 從搜尋開始，更接近真正可維運的研究系統。

我保留：大庫路由、跨任務泛化與總成本仍未過關

skills 不是越多越好。另一篇針對 34,198 個真實 skills 的大規模研究發現，加入干擾 skills 或依賴檢索，效果可明顯低於只給精選正確 skill；部分模型甚至低於 no-skill。這不能直接否定 DisCo，卻指出 Repo-To-Skill 尚未完成的壓力測試：從 5,353 個公開 skills 端到端路由到正確分支，是否仍能保住收益？

概念本身也不是憑空出現。Voyager早已展示不更新權重、累積可檢索技能；2026 年 6 月的 HASTE則在 MLE 任務使用階層式 engineering skills。Repo-To-Skill 更有說服力的新意，是把 ML repositories 的 source、docs、examples 與 tests 大規模轉成帶 provenance 的 Agent Skills，再把建置與路由形式化，而不是宣稱首次發明外部程序記憶。

截至 2026 年 9 月 4 日，本次以論文題名、arXiv ID、DisCo 與 AREX-Skill 所做的公開搜尋，尚未找到獨立重現這四組 headline results 的研究。這只是 v1 上線約兩天後的時間截面，不是永久判決；現在最合適的證據等級仍是「值得重做的作者自報結果」，而不是已建立的通則。

如果你在打造 Agent，現在可以怎麼用這個想法？

1. 只挑會重複的瓶頸：從一個每週都會重做、且失敗代價明確的 repo workflow 開始，不要先追求數千個 skills。
2. 把來源與版本寫進 skill：記錄 commit、文件位置、適用條件與已知失敗；repo 更新時，舊驗證不能自動沿用。
3. 做 With／Without A/B：固定模型、harness、任務與下游時間上限，同時記錄成功率、tokens、工具呼叫、牆鐘時間與 skill 建置成本。
4. 故意加入干擾項：測 router 選錯 skill、載入太多 context 或舊規則壓住新解法時，系統能否偵測並 fallback。
5. 先證明重用，再談攤提：若每個新任務都要再花一天做專屬 graph，那是有效的前置研究流程，還不是通用技能庫的勝利。

Repo-To-Skill 把一個很重要的問題推到檯面：下一輪 Agent 競爭，未必只看誰有更大的模型或更複雜的 harness，也可能看誰能把驗證過的操作知識，做成更新得動、找得到、載入不會害到任務的基礎設施。這個方向值得興奮；真正的分水嶺，將是獨立重現與跨任務、跨模型、含完整成本的測試。