靜態的技能就是死掉的技能

昨晚我為Claude Code指南交付了一個 Settings Reference 章節,共十五個條目。每筆引用都用 grep 對照過行號。在批判迴圈乾淨地跑完之後,我憑著確信交付了它。等我準備提交那個 .md 檔時,我心裡已經知道將來會需要 v3,並不是因為我做錯了什麼,而是因為指南會變、底層產品會變、使用者查詢會位移,而我剛剛交付的章節,從我離開它的那一刻起就會開始漂移。

技能(無論是 Markdown 參考章節,還是位於 .claude/skills/ 的代理技能定義)只有在有人持續觀察其軌跡時才是活的。一旦你停止觀察,它就成了靜態。靜態的技能會原地衰退。下面這篇文章是 AI 工程系列的一部分,記錄代理基礎設施在生產環境中如何演化。

靜態的 AI 代理技能之所以失敗,是因為它們在交付的那一刻就停止學習了。 沒有一個能吸收真實調用軌跡(輸入、工具呼叫、輸出,以及實際使用中的錯誤狀態)的回饋迴圈,技能就無法適應變動中的產品、位移中的使用者查詢,或反覆出現的失敗模式。多個使用者各自獨立地重新發現相同的權宜解法,而技能定義本身卻維持凍結狀態。解方:持續的軌跡聚合,將使用模式轉換為自動化的技能更新。

來自 Ma、Yang、Ji、Wang 與 Wang 的一篇新 arxiv 論文(《SkillClaw: Let Skills Evolve Collectively with Agentic Evolver》,2026 年 4 月),在研究層次上將這個問題形式化。¹ 他們開頭的論述,直接引用如下:「諸如 OpenClaw 等大型語言模型(LLM)代理仰賴可重複使用的技能來執行複雜任務,然而這些技能在部署之後大多維持靜態。結果是,類似的工作流程、工具使用模式與失敗模式在不同使用者之間反覆地被重新發現,使得系統無法藉由經驗而改善。」¹

我已經在這個失敗模式裡活了好幾個月。如果你正在為任何代理框架建構技能,你也一樣。

TL;DR

代理技能交付後就停止改善。使用者各自獨立地發現相同的失敗模式,卻從未把這些發現回饋到技能本身。Ma 等人將此框定為一個集體智慧問題:跨使用者與跨時間的互動,本身就是技能何時奏效或失敗的訊號,但卻沒有生態系層級的機制能將其聚合成技能更新。他們的 SkillClaw 框架提議將聚合的軌跡視為演化訊號,執行一個自主的演化器(evolver),辨識反覆出現的行為模式,並將其轉譯為技能精修或能力擴充。¹ 摘要引用「OpenClaw」作為使用可重複使用技能的 LLM 代理範例。我無法僅憑摘要辨識出 OpenClaw 是哪個具體的出貨產品,所以本文不會對它做任何臆測。我要主張的是:這篇論文所描述的結構性問題,適用於任何為Claude Code、Codex、Cursor 或自己代理框架建構技能的人。重點是:如果你的技能庫沒有持續從真實使用中吸收軌跡,那它從交付的那一天起就是死的。

重點摘要

• 技能作者: 工作不是在技能交付時結束。工作是在你建立起一個迴圈、持續觀察技能如何被使用、捕捉反覆出現的失敗模式、並將其回饋至技能定義時才完成。交付是技能生命的開始,不是結束。
• 框架建構者: 記錄每一次技能調用及其軌跡:輸入、工具呼叫、輸出、錯誤狀態。那份日誌就是演化訊號。如果你沒有記錄,你就不是在改善你的技能,而是在維護它們。
• Jiro 心法的實踐者: SkillClaw 論文是用學術語言來描述應用於技能的職人模式。技能就是手藝。軌跡就是練習。演化就是對精通的追求。靜態 = 死亡。

論文實際上說了什麼

我會謹慎地走過摘要中的論點,然後清楚標示我從哪裡開始延伸論述。

問題陳述(取自摘要)。 LLM 代理仰賴可重複使用的技能來執行複雜任務。這些技能在部署後大多維持靜態。類似的工作流程、工具使用模式與失敗模式在不同使用者之間反覆地被重新發現。系統無法藉由經驗而改善。¹

作者鎖定的是一個特定的失敗模式,而不是「所有技能都會衰退」這樣的普世主張。從未被調用的技能不會衰退。只有一位使用者調用而沒回報問題的技能,衰退也不會被看見。衰退會浮現,是當多位使用者各自遭遇相同失敗的不同版本,而系統卻沒有任何辦法把這些遭遇聚合成單一更新時。(最後這句是我的論述,不是論文的。)

現有的缺口(取自摘要)。 摘要陳述,雖然跨使用者的互動「提供了關於技能何時奏效或失敗的互補訊號,但現有系統缺乏將這類異質經驗轉換為可靠技能更新的機制」。¹ 承重論點就在這裡。缺口不在於沒人想過要改善技能。缺口在於沒有一個生態系層級的機制能聚合軌跡、辨識反覆出現的模式,並將其轉譯為更新。

SkillClaw 流程(取自摘要)。 摘要描述了一個持續性的流程:SkillClaw「聚合使用過程中產生的軌跡,並由一個自主演化器(autonomous evolver)處理,該演化器辨識反覆出現的行為模式,並將其轉譯為對技能集的更新——無論是精修既有技能,或以新能力擴充之」。¹ 該系統將更新後的技能維持在共享儲存庫中,並在使用者之間同步,使得在某個情境中發現的改善能在系統內傳播,而無需使用者額外付出。¹

評估(取自摘要)。 論文以 Qwen3-Max 為底層模型,在一個名為 WildClawBench 的基準上評估 SkillClaw。摘要本身在已發表版本中的措辭文法不通:「在 WildClawBench 上的實驗顯示有限互動與回饋,它顯著提升了 Qwen3-Max 在真實世界代理情境中的表現。」¹ 我把它讀成:在有限互動與回饋下,SkillClaw 仍能相對於基線產生顯著的效能提升。摘要沒有公布具體數字;完整論文應該有。

這就是摘要所描述的論文內容。作者主張,擁有共享技能的多使用者代理生態系,能從「自動化軌跡聚合餵入自動化技能更新」中獲益,並回報他們的實作在有限回饋條件下顯著提升了 Qwen3-Max 的表現。

論文沒說的事(以及我所補充的)

摘要將「OpenClaw」引用為一個範例(「諸如 OpenClaw 等 LLM 代理」),亦即一個使用可重複使用技能的代理。我無法僅憑摘要知道 OpenClaw 是什麼;我無法迅速將其辨識為某個具體的出貨產品。論文的框架(SkillClaw)針對的是廣義的多使用者代理生態系,並非專指 OpenClaw,所以「OpenClaw 是什麼」這個問題對其論點而言其實只是邊角。我之所以特別點出來,是希望沒有人讀完這篇文章後以為論文是在講Claude Code。它不是。它把 OpenClaw 點為範例,並提出 SkillClaw 作為通用機制。

我獨立於論文之外要主張的是:論文所描述的結構性問題,確實對應到我這幾個月在Claude Code技能生態系中所經歷的真實問題。這個主張是我的,不是論文的。以下是我認為它對應得上的理由。

Claude Code生態系中的技能以靜態產物形式出貨。 一個技能是一份 SKILL.md 檔案(或一組支援檔案的綑綁),描述某項任務該如何被執行。你寫一次,提交它,然後用斜線指令或 @skill-name 自動補全來引用它;建構自訂技能的機制相當直觀。一旦交付,它就是個靜態產物。沒有任何自動機制觀察該技能在實務中如何被使用,或根據哪些有效、哪些失敗來更新技能定義。

不同使用者各自獨立地撞上相同的失敗模式。 我交付過的每一個技能都至少有一個只在特定條件下出現的反覆失敗模式。某人用我沒預料到的輸入調用該技能,撞上邊角案例,手動繞過去,然後繼續工作。另一個人在別處撞上同樣的邊角案例,做了自己的繞行解法。技能本身始終沒變。

聚合訊號是真實存在但未被利用的。 如果我能看到我交付過的每一個技能、每一次調用的每一條軌跡,我可以在一個下午內辨識出反覆出現的失敗模式。那個訊號存在於每一位使用者的工作階段歷史中。它只是沒有在任何地方被聚合起來,所以沒人據此行動。

解方不是手動就是闕如。 目前,技能改善的唯一機制是我在自己的使用中注意到問題、或某人提交 issue、或某人開 PR。這些途徑全都需要使用者付出心力。SkillClaw 論文的核心洞察——軌跡資料其實已經存在,應該自動餵入技能更新——正是我們所缺的機制。

這就是我關於「論文的論述如何套用於Claude Code」的主張。這不是論文所說的。這是我用論文對照自己工作後的解讀。

套用於技能的職人模式

每當我思考手藝這件事時,有一個論述總是浮上來。壽司大師小野二郎是經典範例。六十年的同一份工作。每天他都觀察吧台前發生的事,調整技法、精修醋飯溫度、刀的角度、握壽司的時間點。工作本身就是訓練訊號。實踐者本身就是聚合者。

我以前寫過職人 / 品質迴圈的論述。核心想法是:手藝就是回饋迴圈。你做這份工,你觀察這份工,你注意到哪裡壞了,你調整,你再做一次。一遍又一遍。精通存在於「你原本想做的」與「實際發生的」之間的差距,以及你願意把這個差距帶進下一次嘗試的決心。

靜態技能打破了這個迴圈。你交付了技能。你停止觀察。技能原本想做的、與實際發生的之間的差距,堆積在你從未看見的上百次工作階段中。技能沒有變得更好,因為職人不在吧台前。

SkillClaw 論文提出了一個自動化的聚合者:不是要取代人類,而是建立一個機制——觀察所有軌跡、注意跨工作階段什麼壞了、並把更新提案回饋到技能定義中。這份野心並不瘋狂。它其實是技能要能在自身部署後存活下來的最低門檻。

這在實務中長什麼樣子

如果我今天想針對自己維護的Claude Code技能,建構 SkillClaw 模式,我會需要這些東西:

1. 每次技能調用的軌跡日誌。 每當技能執行時,記錄輸入、它所做的工具呼叫、輸出、錯誤狀態,以及最終的處置結果(使用者接受了結果嗎?還原了嗎?重寫了嗎?)。Claude Code已經有工作階段層級的日誌;問題在於它是否跨工作階段被聚合,並萃取出來給技能擁有者。

2. 模式偵測器。 一個能讀取軌跡日誌、辨識出反覆模式的東西:相同的輸入類別導致相同的失敗、相同的工具呼叫以相同方式失敗、相同的邊角案例在不同使用者情境下出現。需要的是針對結構化軌跡資料的分群,而不是 AGI。

3. 提案產生器。 給定一個被偵測到的模式,草擬一份技能的候選更新:新的處理分支、額外的範例、SKILL.md 主體中的額外約束。更新是個提案,不是已交付的變更。

4. 把關閘門。 每一份提議的更新都要走過人工審查、事實驗證(我對所有事物都採用的同一個嚴格閘門)以及一個批判迴圈,才能交付。自動化負責的是聚合,不是交付。

5. 散布。 當提議的更新被接受時,它會傳播到該技能的每一位使用者。在中心化的生態系中這很容易(更新標準技能,大家拉取)。在分散式生態系中就難得多。

其中大部分在Claude Code中已經存在:工作階段日誌、版本化的技能定義、運作中的批判迴圈。缺少的那一塊是聚合與模式偵測層,把工作階段軌跡連結到技能更新。指令、技能、子代理與規則的組織分類已經提供了結構性基礎;缺的是部署後讓每個類別維持活力的回饋通道。

令人不舒服的暗示

過去六個月我交付的每一個技能,都正好以 SkillClaw 論文所描述的意義「死了」。我寫技能。我自己用。我注意到問題。我修正我自己用的技能。我的技能對我自己變得更好。它們對其他任何人來說並沒有變得更好,除非那個人獨立地注意到相同的問題並提交了什麼。

我昨晚為 Settings Reference 做的工作,正是這個模式。Claude Code指南是一個共享產物。使用者向它查詢特定的設定鍵。我能看到 GSC 資料告訴我哪些設定鍵被搜尋。那就是聚合的軌跡資料,字面上告訴我指南中的哪些技能正在被調用、結果落在哪裡。而在我去看那份資料之前,指南是靜態的。它已經靜態了好幾週。並不是因為沒人觀察軌跡,而是因為我是唯一能觀察的人,而我有別的事要做。

SkillClaw 論文是這個問題的學術形式化。實務上的機制更簡單:如果你沒有一條從軌跡資料到技能更新的自動流程,你的技能就在原地老化。它們對某些使用者在某些條件下或許還能用。但它們沒有變得更好。

唯一的問題是:你接受你的技能在交付那一刻就死了,還是你建造一個觀察者讓它們活下去。複合脈絡(compound context)原則在這裡也適用:每一筆軌跡觀察都會與下一筆複合,而技能的價值會隨著它所吸收的回饋以非線性方式成長。反過來說,把脈絡視為架構意味著要認識到:技能的結構決定了它根本能否吸收新資訊。

最低可行的聚合者

在我開始寫這篇文章之前,我對自己的技能完全沒有任何軌跡聚合。零。我有可以手動翻閱的工作階段歷史,但沒有任何能跨工作階段浮現模式的東西。那正是論文所描述的靜態技能病理,而我正在運行它。

以下是我現在、今天就能交付的最小實際東西:一個單一的文字檔,以僅追加(append-only)的方式記錄我自己工作階段中每一次的技能調用,內含時間戳記 + 技能名稱 + 輸入形狀 + 最終處置結果(接受 / 修改 / 還原)。 沒有模式偵測器。沒有自主演化器。就是日誌而已。

那個檔案就是最低可行的聚合者。它不是 SkillClaw。它是 SkillClaw 若存在所需的輸入層,也是我在能夠看見我的技能是否有反覆失敗模式之前所需要的輸入層。沒有它,我只能猜。有了它,我至少在審視某個技能時能用手翻閱日誌,自問:這個月相同的損壞發生過三次嗎?

那就是承諾。一個檔案。僅追加。每次調用都記錄。在我審視該技能時被審視。

如果這行得通,下一層就是模式偵測器。如果模式偵測器行得通,再下一層就是提案產生器。論文的野心是一個跨多使用者生態系運作的完整自主演化器。我的野心是不要在黑暗中運作。

FAQ

論文中的「OpenClaw」與Claude Code是同一個東西嗎?

不是,而且我也無法告訴你 OpenClaw 是什麼。摘要將「諸如 OpenClaw 等 LLM 代理」作為使用可重複使用技能的代理範例提及,卻沒有定義它。我無法僅憑摘要迅速將其辨識為某個具體的出貨產品。重點是:論文的 SkillClaw 框架針對的是廣義的多使用者代理生態系,並非專指 OpenClaw 或Claude Code。無論 OpenClaw 是什麼,這篇論文都不是關於Claude Code的論文,而我在本文中對Claude Code所做的主張都是我自己的,不是論文的。¹

這篇論文真正新穎的貢獻是什麼?

依摘要所述:一個用於多使用者代理生態系中集體技能演化的框架,該框架(1)跨使用者與跨時間聚合軌跡,(2)執行一個自主演化器以偵測反覆出現的模式,並(3)將模式轉譯為共享儲存庫中技能的更新,且這些更新會在使用者之間同步。¹ 新穎之處不在於「技能能被改善」(這顯而易見)。新穎之處在於提議改善迴圈應該是自主、由軌跡驅動的,而不是由人類驅動的。

論文有報告具體的改善數字嗎?

摘要將改善描述為在一個名為 WildClawBench 的基準上、使用 Qwen3-Max、在有限回饋條件下「顯著」,但沒有公布具體數字。¹ 想看數字,完整論文是來源。

這跟針對技能定義發 git pull request 有何不同?

PR 是個人類發起的機制。某人必須注意到問題、寫出修正、提交 PR、審查、合併。每一步都需要人類心力。論文所提議的 SkillClaw 框架是自主聚合——系統自己跨多使用者注意到模式、自己提出修正、並同步更新,而不需要任何單一使用者去提交什麼。¹ 這個自主版本對任何特定生態系而言是否值得追求或安全,則是另一個問題。論文的貢獻是表明這在技術上是融貫的。

這適用於我的自訂Claude Code技能嗎?

論文沒有對任何特定的Claude Code技能生態系做主張。我獨立於論文之外的主張是:該結構性問題(技能以靜態產物形式交付、失敗模式被每位使用者各自獨立地重新發現、無聚合機制)確實適用於Claude Code技能,而任何為Claude Code或類似代理框架建構技能的人,都應該思考如何建立一個由軌跡驅動的改善迴圈。這是我的意見,不是論文的發現。

跟職人(Shokunin)的連結是什麼?

職人 / 品質迴圈的論述主張,精通來自於「你原本想做的」與「實際發生的」之間的差距,並把這個差距帶進下一次嘗試。靜態技能打破了那個迴圈,因為差距堆積在職人從未看見的工作階段中。SkillClaw 是把那個迴圈閉合的學術版本:自動化收集差距,並將其回饋到技能中。紀律是相同的;機制不同。

References