AI Agent Arxiv Digest — 2026-08-23

🌏 English version

今日總覽

三篇論文剛好覆蓋 Agent「技能系統」的三個階段:怎麼教會模型用工具(MidTool 用中期訓練補課,而不是把重擔全丟給後訓練)、技能該怎麼歸納才會遷移得好而不是幫倒忙(Break It Down 發現整段任務式歸納反而讓 agent 表現掉到沒有記憶的基線之下)、以及技能庫變大之後怎麼選才不會浪費 token 又選錯(Optimal Skill Selection 給出第一個可證明保證的演算法)。三篇合起來勾勒出一條「技能生命週期」:訓練期打地基 → 使用期歸納 → 檢索期挑選,而且第三篇直接點名 Codex、Claude Code 這類正在生產環境跑的系統作為現況參照——這正是我們每天在用的 skill 機制背後的研究問題。

讀這篇前該知道的詞

論文一｜MidTool:用「中期訓練」教會模型用工具,而不是全丟給後訓練

MidTool: Mid-training Data Synthesis for Agentic Tool Use

Fengqing Jiang, Yite Wang, Boyi Liu et al.(University of Washington, Snowflake)　·　arxiv: 2608.20314

連結: arxiv · alphaxiv

TL;DR

目前 agent 工具使用能力幾乎全靠後訓練(SFT/RL)硬練,MidTool 提出「中期訓練」補課方案:用 20.3B token 語料先教會模型辨識工具、組合呼叫、從缺漏資訊中恢復,4B/8B 模型在 MCP-Universe 上超越 Qwen3 官方模型。

Read Priority

必讀 — 如果你在自建或微調 coding / tool-use agent 模型。這篇提供了一條「先補課再精修」的替代路徑,而不是無止盡加大 SFT/RL 資料量。

領域背景

工具使用能力的進步多來自後訓練——在人工整理的軌跡上做 SFT、RL。但這給後訓練帶來沈重負擔:模型得同時從偏窄的監督訊號裡,學會工具辨識、schema 對齊參數、資訊缺漏時提問、多步驟執行等一整套原子能力。更根本的是,支撐工具使用的知識分散在開發文件、手冊、PDF、程式碼庫、API 規格裡,絕大多數從未以乾淨的 agent 示範形式出現過。中期訓練是介於通用預訓練與後訓練之間的獨立階段,近期被證實能強化數學、科學這類推理密集能力,也能改善軟體工程場景的 agentic 能力,但通用工具使用這塊還沒被系統性探討過。

中階導讀

• 問題:想像教一個新員工用公司內部一套 20 支 API 的系統。如果你只給他 50 個「示範案例」,他很快就會在第 51 種情境卡住,因為示範沒教到系統性的東西——怎麼從 API 文件推斷該傳什麼參數、缺資訊時該怎麼問。真正該做的是先讓他把說明文件、手冊、程式碼庫都讀過一輪,建立起「工具長什麼樣子」的通用直覺,再用少量示範精修。
• 方法:MidTool 建立一套開放語料建構管線,把大規模 web、PDF、程式碼資料,跟「合成」出來的監督訊號(來自真實工具 API、MCP skills、文件對齊的工作流程)混在一起,做成 20.3B token 的 MidTool-Mix 語料。目標是讓模型學會四件事:辨識「這裡該用工具」的訊號、從脈絡把參數對應到 schema、把多個工具組合成工作流、資訊不完整時知道怎麼恢復。用這份語料中期訓練 Qwen3-4B-Base 和 Qwen3-8B-Base,再接續 SFT 與 RL 後訓練。
• 為什麼重要:這說明工具使用能力跟其他重要 LLM 能力一樣,不該完全丟給後訓練獨自扛——中期訓練可以先把「工具知識的地基」打好,讓後訓練事半功倍。對正在自建 coding/tool agent 模型的團隊,這是條可行的替代路徑。

深入要點

• MidTool-Mix:20.3B token 中期訓練語料,混合 web、PDF、程式碼與合成 agentic 軌跡
• 在 Qwen3-4B-Base / Qwen3-8B-Base 上,經 MidTool 中期訓練 + SFT/RL 後訓練,在 BFCL、τ²-Bench、MCP Universe 上一致優於未做中期訓練的基線 ⚠️(作者自測,同源比較,需等外部複現)
• 在 MCP-Universe 上,MidTool 中期訓練後的 4B/8B 模型超越 Qwen3 官方發布模型
• 資料與模型已釋出(Hugging Face collection: MidTool/midtool-release)
• 落地門檻:20.3B token 規模的語料建構與中期訓練需要相當算力,小團隊較難直接複製整條 pipeline,但可參考其「web+PDF+code+合成」的資料組成思路自建較小規模版本
• Limitation:目前只驗證在 Qwen3 系列 4B/8B 規模,能否推廣到更大模型或其他模型家族未知

Reviewer 一句話評

把「工具使用」納入 mid-training 階段這個切入點務實,資料組成方法論也清楚,三個基準都一致提升算紮實;但只測了 Qwen3 4B/8B 兩個規模,跟官方模型比較時訓練資源、資料量是否對等未完全交代,結論的可推廣性還需觀察。

給你的 take-away

• 如果你在做自己的 coding/tool agent 微調:別把所有預算都砸在 SFT/RL 軌跡收集上,考慮先用文件、手冊、程式碼庫做一輪中期訓練打地基
• 如果你在維護 MCP skill 生態:MidTool 語料把「MCP skills」當作合成監督訊號來源之一,這條資料管線思路可以直接參考

論文二｜Break It Down, Pass It On:技能歸納歸錯粒度,Agent 反而變更笨

Break It Down, Pass It On: Cross-Task Skill Transfer in LLM Agents

Yiyang Feng, Biddut Sarker Bijoy, Niranjan Balasubramanian, Jiawei Zhou(Stony Brook University)　·　arxiv: 2608.20274

連結: arxiv · alphaxiv

TL;DR

Agent 把做過的任務歸納成「技能」存起來重用,聽起來理所當然,但整段任務式的技能平均反而讓 agent 表現掉到沒有記憶的基線之下;拆到子任務層級的技能才會讓表現變好,文字型技能也比程式碼型技能更容易遷移。

Read Priority

必讀 — 如果你在做 agent 的技能/記憶歸納機制(包括 Claude Code Skills 這類正在使用的系統)。這篇指出一個容易被忽略的假設陷阱:「讓 agent 自己歸納技能」不會自動帶來進步。

領域背景

越來越多 agent 系統讓 agent 從完成的任務裡歸納技能,存進技能記憶庫,之後檢索重用,理論上這會讓 agent 隨著經驗越用越強。但實務中技能遷移常常不可靠——用整段任務軌跡歸納出的技能,天生就跟來源任務綁死,遷移到新任務時常無關或誤導,反而讓模型分心、把來源任務的錯誤帶進新任務。目前的研究對「技能怎麼歸納才會遷移得好」缺乏系統性、受控的比較。

中階導讀

• 問題:想像兩個任務——「把購物車裡所有健身椅都下單」跟「把購物車裡所有食物調理機移到願望清單」。如果你把整個任務的操作流程總結成一條技能("訂購{商品}到購物車"),下次遇到完全不同的任務,這條技能根本用不上。但如果你把任務拆成子步驟——登入、檢查購物車、下單、移到願望清單——「登入」跟「檢查購物車」這兩個子技能在兩個任務間是共通的,可以直接被重用。
• 方法:作者設計受控實驗,沿兩個軸比較技能歸納方式:任務層級 vs 子任務層級的歸納粒度,以及文字型 vs 程式碼型的技能格式。用「特異性」(技能跟真實任務的貼合程度)與「抽象度」(相關性能不能均勻分散到多個任務)兩個屬性拆解技能,發現兩者單獨都無法預測遷移是否成功,但把兩者合在一起算出的「技能效用分數」跟遷移後的任務成功率高度相關——而且這個分數只需要技能文本與任務描述,完全不用真的跑一次任務就能算出來。
• 為什麼重要:這戳破一個容易被忽略的假設——「讓 agent 自己歸納技能」不會自動帶來進步,歸納的粒度跟格式選錯,反而會讓 agent 比完全沒有記憶還差。對任何在建 skill/memory 系統的團隊,這篇提供了具體的診斷工具,能在技能真正被用到之前就篩掉會扯後腿的技能。

深入要點

• 任務層級技能平均把 agent 表現拉到無記憶基線之下;子任務層級技能平均讓表現高於基線 ⚠️(作者自測,平均值,個別任務有波動)
• 文字型技能格式的遷移效果系統性優於程式碼型技能格式
• 技能效用分數 = 特異性與抽象度的組合效果,單獨看任一項都無法預測遷移成敗
• 子任務層級 + 文字格式的技能,在效用分數上系統性得分較高
• 效用分數計算不需執行任務,只需技能文本與任務描述,可作為部署前的輕量診斷
• 程式碼與資料已開源(GitHub: Zesearch/skill-transfer-llm-agents)
• Limitation:研究聚焦特定任務家族(如購物類多步驟操作),能否推廣到更廣泛、更長程的真實工作流,論文未涵蓋

Reviewer 一句話評

用兩個正交屬性(特異性、抽象度)拆解「技能好不好遷移」這個模糊問題,而且效用分數不用執行任務就能算,是這篇最實用的貢獻;但實驗任務類型偏窄(多為結構化多步驟操作),能否適用於更開放式的任務歸納,還需更多驗證。

給你的 take-away

• 如果你在做 agent 的技能/記憶歸納機制:別預設「歸納出技能就是進步」,優先做子任務層級的歸納,並用文字而非程式碼作為技能的儲存格式
• 如果你已經有一套技能記憶庫在生產環境跑:考慮實作類似「技能效用分數」的離線診斷,在技能被檢索使用前先篩掉低效用的技能,而不是等出包才發現某個技能在拖累表現

論文三｜Optimal Skill Selection:技能選擇也能有數學保證,不只是拚語意相似度

Optimal Skill Selection for LLM Agents with Provable Bicriteria Guarantees

Yu Chen, Ruishuo Chen, Xun Wang, Zhuoran Li, Longbo Huang(Tsinghua University, IIIS)　·　arxiv: 2608.19993

連結: arxiv · alphaxiv

TL;DR

現在 Claude Code、Codex 這類 agent 選技能的方式都是「照語意相關性各自打分、再 top-k 或貪婪塞進 context」,沒有品質保證也不管 token 成本。這篇把技能選擇形式化成「在 token 預算下最大化次模效益」的最佳化問題,提出 BPS 演算法並證明可證明的近似保證,在 BigCodeBench 變體上用少 28% token 拿下 0.73 成功率,對手只有 0.20–0.52。

Read Priority

必讀 — 這篇直接針對我們每天在用的 skill 選擇機制(Claude Code Skills 一類系統)提出理論化的替代方案,對任何在打造或使用技能生態系的團隊都值得細讀。

領域背景

把可重用的技能文件載入有限的 context window,現在已經是 LLM agent 取得任務特定能力的主要方式,公開的技能登錄庫已有數萬個可安裝技能。像 Codex、Claude Code 這類 production agent 採用「先選再執行」的兩階段機制:LLM 先看每個已安裝技能的 metadata(名稱、描述)依查詢挑選,再把挑中的技能文件載入 context 求解任務。但隨著技能庫成長到數百上千條,光是 metadata 就可能超出可用的 context 預算,窮舉式 LLM 選擇變得不可行;而選錯技能有實測代價——技能庫變大時,選錯技能會讓通過率掉最多 21%,甚至在 87 個基準任務中的 13 個上,選了技能反而比完全不用技能還差。

中階導讀

• 問題:想像一個有上千個技能可用的 agent,面對一個新任務。目前多數系統做的是:每個技能各自算一個「跟這個任務有多相關」的分數,然後挑分數最高的前 k 個塞進 context。問題是,如果前 5 個高分技能其實內容高度重疊,你等於浪費了 4 份 token 預算卻沒換到互補能力;而且完全沒人告訴你,這樣選出來的技能組合,離「理論上能拿到的最佳表現」還差多遠。
• 方法:作者把技能選擇問題形式化——在硬性 token 預算下,選一組技能,最大化「單調次模效益減去 context 懲罰」。次模函數捕捉的正是「邊際效益遞減」這個直覺:已經選了一個技能後,再選一個跟它高度重疊的技能,帶來的額外效益會變小。針對這個最佳化問題,他們設計了 Best Prefix Selection(BPS),一個多項式時間演算法,並證明這是第一個對技能選擇問題有效能保證的方法——一個 bicriteria (1-1/e, 1) 近似,益處係數在多項式時間內達到最優。
• 為什麼重要:這是第一次有人幫「技能選擇」上了數學保證,而不是繼續依賴「語意相關性 + top-k」這種沒有理論基礎的啟發式。對任何在打造或使用 skill/tool 生態系的團隊,這代表技能選擇不必然是黑箱調參,可以有一套帶保證、還更省 token 的替代方案。

深入要點

• 在受污染控制(contamination-controlled)的 BigCodeBench 變體上,BPS 拿下 0.73 任務成功率,對比已發布的技能路由器、文字檢索器、執行器自帶選擇機制的 0.20–0.52 ⚠️(作者自測,單一基準,需等外部複現與更多基準驗證)
• BPS 達到上述成績只用了最強對手路由器約 72% 的 token(省 28%)
• 背景數據:技能庫變大時,選錯技能可讓通過率掉最多 21%;在 87 個基準任務中的 13 個上,選了技能反而讓表現低於完全不選技能的基線(此為作者引用既有研究的數字,非本篇實驗結果)
• BPS 的核心假設是效益函數具單調次模性質,這個假設是否在所有真實技能庫上成立,論文未逐一驗證
• 落地門檻:要套用 BPS,系統需要能對「技能子集合」估計次模效益(而不只是逐一技能打分),比現有 top-k 架構多一層工程複雜度
• 論文直接點名 Codex、Claude Code 的技能選擇機制作為現況參照,說明這套方法瞄準的正是這類生產系統的痛點
• Limitation:目前驗證侷限在程式碼生成類任務(BigCodeBench 變體),技能形式與任務類型更多元的場景(如文件型技能、多模態技能)是否適用未知

Reviewer 一句話評

把技能選擇形式化成帶次模效益的最佳化問題,並給出第一個可證明的近似保證,理論貢獻紮實,BPS 同時省 token 又提升成功率的實測結果也很有說服力;但驗證目前只在單一程式碼生成基準上,次模性假設在更多元的真實技能庫上是否站得住,仍待檢驗。

給你的 take-away

• 如果你在設計 agent 的 skill/tool 選擇機制:別停在「語意相關性 + top-k」,BPS 的次模效益建模思路值得直接參考,尤其是它同時考慮了技能之間的重疊(不只是單獨相關性)
• 如果你在管理成長中的技能庫(如 Claude Code Skills、MCP tool 生態):留意「技能庫變大、選錯代價變大」這個既有研究數字——這篇提供的是目前少見、有理論保證的緩解方案

今日收穫

之前以為「Agent 要用好技能/工具」主要是模型能力問題——模型夠強,自然就會用好工具、學會技能。今天三篇論文合起來讓我意識到,這其實是一整條需要分別設計的管線:MidTool 說工具使用能力得從訓練早期就打地基,不能全丟給後訓練;Break It Down 說「讓 agent 自己歸納技能」不會自動帶來進步,歸納粒度選錯反而會拖累表現;Optimal Skill Selection 說就連「挑哪些技能塞進 context」這件事,也可以有數學保證,而不只是拚語意相似度。三篇串起來看,技能系統的每一步——教、存、選——都有各自的坑,而我們自己每天在用的 Claude Code Skills,正好就是這整條管線的終端使用者。

參考資料

• MidTool 論文:arxiv 2608.20314
• Break It Down, Pass It On 論文:arxiv 2608.20274
• Optimal Skill Selection 論文:arxiv 2608.19993