目前，產業開發焦點正快速向以 Agent Skills 為核心的框架（如 Openclaw）收攏。業界已達成共識：將重複的 API 鏈路封裝成可執行的 Agent Skills，是解決長週期任務中「上下文爆炸」問題的唯一途徑。然而，理念確立後，真正的實戰深水區才剛剛開始。面對 Openclaw 的選型配置，您極大機率會被以下四個架構問題卡住：
Skill 的構建： 到底該用一個昂貴的強模型（如 Claude Opus 4.6）一次性解決問題？還是用弱模型堆量試錯？兩者差異究竟有多大？
多智能體如何協同？ 如果我有一個 Multi-Agent「龍蝦」🦞團隊，主模型和邊緣模型應該如何分配職能？
Skill 樹要不要點滿？ 複雜的嵌套調用會不會超出 LLM 的能力極限？邊界在哪裡？生產環境最穩定的方案是什麼？
Agent Skills 作為泛化接口的隱性認知成本有多高？ Agent 在什麼情況下必須果斷放棄 Skills，直接裸調底層 API？
牛津大學近期發布的《SkillCraft》基準測試，恰好為這四個痛點提供了極其精確的量化解答。
修貓今天的這篇文章不講空洞的宏觀趨勢，我們將直接透過該研究拆解出的 Token 帳單、報錯堆疊和調用日誌，為您揭示 Skills 時代多智能體協同的底層設計邏輯。
SkillCraft 基準與測試環境構建
為了確保後續所有架構建議的數據可靠性，我們必須首先審查研究者是如何構建測試沙盒與評估標準的。這也是過濾掉毫無工程價值的「跑分玩具」，獲取真實工業級數據的關鍵。
現有工具鏈評估的系統性缺陷
目前的工具使用基準測試（如 WebArena、AgentCompany 等）通常在部署時固定工具集，採用單實例的評估邏輯：即測試智能體能否使用給定工具解決當前這單個一次性任務。這種單次測試在長週期任務中暴露出兩個核心效率瓶頸：
冗餘的狀態傳遞： 複雜的業務邏輯被分解為一系列原子操作。在這個過程中，中間結果（如龐大的網頁 DOM 樹或冗長的 JSON API 回應）在連續的工具調用之間反覆被序列化，並被強制注入到模型的上下文中，產生了極其高昂的 Token I/O 開銷。
上下文窗口飽和： 漫長的工具調用序列及其海量返回結果佔據了大量上下文容量，導致模型在執行後期嚴重丟失早期資訊，甚至完全偏離最初的系統指令。
任務池構建與多維擴展邏輯
研究者構建的 SkillCraft 基準測試，故意在單個任務中嵌入重複的子結構，強迫智能體在固定的資源預算內多次識別並複用工具組合。構建過程透過嚴謹的三階段流水線完成：
階段一與階段二： 從現有基準提取任務設計原則，並基於真實的公共 Web API（如 GitLab、Open-Meteo、TVMaze 等）和本地數據集構建了 21 個種子任務。
階段三（多維擴展）： 研究者沿著兩個正交軸擴展了種子任務：數量擴展（例如，從「分析 1 個倉庫」增加到「分析 5 個倉庫」）和複雜性擴展（增加每個子實體所需的底層 API 調用次數）。
最終，SkillCraft 確立了極度標準化的測試用例：
包含橫跨 6 大領域（娛樂、參考、教育、開發者、科學、食品）的 126 個長週期任務。測試難度被量化為三個絕對標準：Easy 級別（包含 3 個實體，單實體需 3 次 API 調用，共 9 次調用）、Medium 級別（4 個實體，共 16 次調用）、Hard 級別（5 個實體，單實體 5 次 API 調用，共計 25 次複雜調用）。
底層設施：Skill Mode 協議棧與安全驗證
為了在測試時賦予模型構建工具組合的能力，系統在智能體的工作區維護了一個本地的 skill_cache.json 檔案。智能體被嚴格限制僅能透過以下四個 MCP（Model Context Protocol）原語與其交互：
save_skill：將成功的工作流保存為可執行的代碼宏。必須傳入macro_name（唯一標識符）、script_code（Python 腳本代碼）、parameters（變數名稱列表）和description（摘要說明）。execute_skill：運行已保存的技能。需傳入macro_name和具體的參數字典args，系統將返回狀態標識與執行結果字典。list_skills：無參調用，列出當前會話中所有的可用技能，供模型決策前檢查。get_skill：檢索目標技能的完整原始碼和參數簽名，用於複雜場景下的調試驗證。
為了保證智能體生成的代碼不會引發系統級災難，研究者部署了帶有三階段防禦機制的代碼驗證器（Coding Verifier）：
語法驗證： 在
save_skill寫入前，底層進行 AST 解析，攔截基礎語法錯誤並向模型返回具體的錯誤行號與代碼片段。運行時錯誤報告： 當
execute_skill崩潰時，沙盒攔截系統異常，向模型返回結構化的 Tracebacks 與輸入參數，協助模型定位參數綁定錯誤。執行後質量檢測： 為防止靜默失敗，系統強校驗輸出字典。若超過 50% 的欄位內容為 Unknown、None 或 0，該腳本將被直接拒絕入庫。
在實驗邊界上，研究者施加了嚴苛的約束：每個任務硬性限制最多 150 個對話輪次，超時時間 60 分鐘；全域最多累積消耗 1M 輸入 Token 和 150K 輸出 Token；模型採樣參數被徹底鎖死在 和
以保證輸出的確定性。在評分端，必須同時滿足檔案生成、JSON 結構有效性、數據完整性與欄位級準確性（總分超 90%）才計入成功。
核心結論：能用強模型不用弱模型
在了解了上述毫無水分的測試環境後，我們來看實戰中大家最關心的問題：為了節約成本，我們應該用便宜的弱模型多次嘗試，還是用昂貴的強模型一擊必中？數據給出的答案是後者。
Token 消耗的指數級坍縮
實驗對比了關閉技能庫接口的 Baseline 模式與開啟技能庫的 Skill Mode。數據清晰地顯示，在複雜的長週期調用中，強模型透過編寫代碼實現內部邏輯流轉，能夠極大地抹平由於自身定價較高帶來的成本劣勢：
GPT-5.2： 平均 Token 消耗從 1.23M 暴降至 0.26M（縮減 79%），單任務平均 API 成本從 1.77 美元直接跳水至 0.43 美元（節省 75%）。
Claude 4.5 Sonnet： 基線成功率已高達 96%，在技能模式下維持在 94% 的高水平。其 Token 消耗從 1.36M 降至 0.40M（縮減 71%），純粹的底層工具調用次數從 14.3 次降至 9.2 次。
DeepSeek-V3.2-EXP： Token 消耗下降 49%（從 1.04M 降至 0.53M），成本直接減半。
雖然智能體在查詢、驗證和緩存技能時會消耗少量的決策輪次（如 Gemini 3 Pro 的平均交互輪次增加了 13%），但由於代碼引擎直接接管了巨大的數據清洗與中轉工作，規避了向 Prompt 注入無效負荷，系統整體的 Token 消耗依然呈現出斷崖式下跌。
相關性分析：Coding 能力就是 Skill 能力
研究者透過跨指標相關性分析揭示了系統運行的底層規律。技能執行成功率與任務最終成功率呈現強正相關（），同時效率增益與模型的基線能力呈現正相關（
）。
這就解釋了開源弱模型在此類架構中的工程死穴：當模型在基線 Hard 任務上的成功率低於 60% 時，其代碼生成能力同樣羸弱。在封裝參數化接口時，弱模型會頻繁產出包含語法錯誤或邏輯死鎖的劣質代碼，隨後系統攔截報錯，模型被迫進入無限的「查錯 - 重寫」死循環。在這個過程中，為了節省算力而引入的框架，反而會大量燃燒 Token 用於修復代碼。
SkillCraft 結論一：在構建基礎 Skill 庫時，切忌使用弱模型透過堆砌 Agent 數量來碰運氣。強模型的單體代碼生成正確率，在系統總成本上具有絕對的碾壓優勢。
多 Agent 跨模型協同：創造者大於執行者
在 Openclaw 等多智能體協同框架中，架構師通常需要將任務拆解分發。系統中的「主模型」和「邊緣模型」應該如何分配職能？論文的跨模型測試數據給出了極其明確的工程指南。
跨難度遷移測試（Cross-task Generalization）
在驗證技能泛化性時，研究者進行了嚴格的靜態遷移測試（即在複雜任務中直接使用簡單任務跑出的技能代碼，期間禁止模型修改代碼）。數據證實，高質量的參數化代碼具備極強的跨級兼容性：Claude 4.5 和 Gemini 3 Pro 在 Easy 級別中抽取的技能，無縫平移到 Hard 級別任務中，均維持了 97%-100% 的極高執行成功率。Claude 的 Easy->Hard 遷移將成功率從基線的 95% 拉滿至 100%，同時 Token 從 1.92M 壓降至 1.56M。
跨模型執行熱力圖解析
研究者設計了一組極其殘酷的 16 組合交叉測試：讓 Claude、Gemini、GLM 和 Minimax 在 8 個 Hard 級別任務中各自創建技能庫，然後將這些純 Python 腳本交叉下發給所有模型進行純執行（禁用修改權限）。
這兩張熱力圖的數據對比極為強烈！尤其是第一張，Claude 寫的代碼在所有模型上執行都是 100% 成功率。
高質量代碼的向下兼容絕對性：Claude 創建的代碼邏輯嚴密、類型校驗完備。當這些腳本被下發給相對輕量的 Minimax、GLM 或 Gemini 執行時，全系跑出了 100% 的滿分通過率，並且為所有的執行端模型帶來了 54% 到 81% 的 Token 巨額節省。
低質量代碼的執行反噬效應：反觀由 Minimax 生成的代碼，由於內部狀態流轉混亂和參數接口設計缺陷，即便是交給 Claude 執行，也會高頻觸發底層報錯。這導致執行端的重試機制被頻繁喚醒，計算成本非但沒有下降，反而浮動在增加 48% 到小幅縮減 18% 之間，徹底摧毀了框架的提效初衷。
執行器算力的侷限補償：數據中一個有趣的細節是，Claude 強行執行 Gemini 生成的瑕疵技能庫，實現了 69.2% 的 Token 節省；而 Gemini 執行自己的技能庫，僅節省了 14.8%。這說明頂尖大模型的意圖理解和參數補全能力，能在一定程度上「兜底」中等質量的代碼缺陷，但這絕不是常規操作。
SkillCraft 結論二：因此在設計 Openclaw 等端雲協同的 Multi-Agent 系統時，最好遵守「創造者 > 執行者」原則。由雲端的頂級千億參數大模型作為「Skill 編譯器」，負責在少量複雜樣本上抽取、驗證並封裝出高質量的業務腳本；邊緣端或低成本私有化模型僅被授權作為「執行引擎」，負責接收參數並運行緩存腳本。絕對禁止弱模型向公共技能庫提交代碼。
防坑指南：深層嵌套與抽象的認知稅
工程師在設計系統架構時，常常帶有將代碼模塊化、層層調用的「面向對象」執念。論文中的微觀測試數據，徹底戳破了當前 LLM 能力在深度代碼結構面前的脆弱性。
Hierarchical Mode（層次化模型）的崩潰機制
研究者引入了允許技能調用其他技能的 Iteration Mode（最大嵌套深度設為 10）。從理論上看，高層技能負責編排，低層技能負責原子操作，似乎極其完美。
然而真實執行日誌（Log Trajectories）展示了令人絕望的錯誤傳播（Error propagation）過程。
在一個生成犬類百科的任務中，底層的數據抓取技能 get_breed_profile 碰到了稀有品種數據，其 API 原始回應中缺失了 temperament 欄位，從而返回了包含 null 的字典。這個底層隱患向上級傳遞。
當處於中間層級的聚合技能嘗試執行字符串操作 profile.temperament.split(',') 時，沙盒直接拋出致命的 TypeError: 'NoneType' has no attribute 'split'。這一行類型錯誤瞬間擊穿了整個調用樹，導致頂層組裝任務徹底宕機全盤潰敗。
實測數據異常慘烈：切換到嵌套模式後，強如 GPT-5.2，任務成功率也從扁平模式的 90% 跌落至 79%，Token 開銷也從 0.26M 反彈劣化至 0.60M。原因在於，嵌套架構對 LLM 的邊緣情況處理（Edge-case handling）和動態類型校驗提出了其能力上限無法企及的要求。高昂的故障追蹤成本遠遠超過了從頭執行一次原子操作。
SkillCraft 結論三：在工業環境中構建 Agent 的工具調用樹時，最好摒棄複雜的技能相互調用。保持技能架構的扁平化（Flat），確保單個腳本內部包含完備的 try-except 錯誤處理，是保證生產環境穩定性的唯一方案。
泛化的認知算力稅與「不抽象」的智慧
面對所有的業務流，是不是全都封裝成通用接口一定最高效？答案同樣是否定的。泛化本身需要交納高昂的「認知算力稅」。
研究者測試了放棄複用和參數接口、直接在單次使用腳本中硬編碼數值的 Direct Exec 模式。在 48 個任務子集中，數據對比極為極端：
Claude 4.5 Sonnet 在 Direct Exec 模式下，將 Token 消耗從基線的 1.72M 壓榨到了極其誇張的 0.16M，對話交互僅需 5.8 輪；而為了兼顧未來複用的標準 Skill 模式，由於需要設計通用的參數佔位符並執行「先保存、後執行」的完整流程，開銷為 0.34M Token 和 10.5 輪交互。
GPT-5.2 的表現同樣極致，Direct Exec 將單任務 Token 燃燒壓縮至 0.06M，交互輪次驟降至 4.5 輪。
透過查閱原始調用軌跡（Trajectories），我們可以清晰看到不同級別模型的工程直覺差異。
在處理只需針對三種貓獲取 9 次簡單數據的輕量級任務時，Claude 敏銳地判斷出「設計通用接口並緩存代碼」的抽象開銷遠大於直接裸調 API 的收益。它果斷放棄調用 save_skill，直接老老實實地完成了 34 步原子調用，消耗約 76 萬 Token 順利交差。而在處理需要分析五種雞尾酒、共計 25 次調用的高複雜度任務時，Claude 只用 1 次嘗試就精準寫出包含 5 個數據流轉通路的完美宏代碼 process_cocktail_complete，隨後連續循環調用 5 次，總計僅用 8 步交互和極低的 21 萬 Token 完美收工。
相反，DeepSeek-V3.2 在執行中完全被系統提示詞綁架，陷入了「指令過擬合」。在簡單的貓咪任務中，它強行造輪子生成了一個名為 process_cat_breed 的技能。然而代碼質量堪憂，輸出字典硬生生遺漏了 breed_facts 欄位。這導致執行後產生大面積數據空缺，它隨後被迫進入漫長的修復期，手動執行了 8 次局部追加寫入（Chunk write）等搶救操作，最終在簡單任務上荒謬地燃燒了逾 150 萬 Token。在複雜的雞尾酒任務中，DeepSeek 更是連續三次嘗試寫入腳本（v1, v2, v3），分別因 unexpected token '}' at line 8 和 'return' is invalid outside function 等基礎語法錯誤宣告流產，最終只能降級回全量手動調用，並在超時和上下文混亂中導致任務失敗，消耗 1.14M Token 且毫無產出。
SkillCraft 結論四：最高維度的 Agent 框架設計，不僅要提供代碼執行沙盒，更要賦予大模型「何時不使用框架」的自由度與判斷力。懂得識別低頻孤立任務並選擇硬編碼一次性腳本，規避處理參數綁定可能引發的幻覺，是系統極致降本的關鍵。
結語
《SkillCraft》的詳實數據徹底改變了我們評估和設計 Agent 架構的底層視角。在複雜的企業級業務流中，您需要將視野從單純追逐基準測試的 Accuracy，轉向極致的算力成本控制。
Agent 真正走向落地的商業護城河，在於其利用代碼作為中間媒介實現「計算壓縮（Token Compression）」的能力。請記住這些真金白銀換來的架構法則：用最強的大模型做代碼編譯器，用邊緣端小模型做執行器；克制代碼深度，堅守扁平結構；並在設計框架時，永遠留出一條允許模型放棄抽象、直接暴力執行的旁路通道。只有這樣，您的智能體系統才能真正兼顧工程健壯性與商業可行性。
未來已來，有緣一起同行！
＜本文完結＞