Agentic Work Systematization

資料來源#

• Attackers Target Agents via The Skill Supply Chain
• Driving the Agent Quality Flywheel from Your Coding Agent- Google Developers Blog
• Enable on-demand expertise with Agent Skills in Genkit Go
• EVOMAL: Self-Poisoning in Self-Evolving Coding Agents
• From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained
• The New Physics of Business — Garry Tan, Y Combinator
• The Shift to Agentic AI: Evidence from Codex
• Who Maintains Agent Skills? A Longitudinal Study of Human-Governed, AI-Assisted Skill Maintenance

摘要#

這是 OpenAI 的 Codex 使用研究用來衡量代理式 AI 是否超越一次性協助的三種「如何」邊際之一：系統化——從臨時委派（描述任務、代理程式執行、互動結束），轉向可重複使用的工作流程基礎設施，讓類似工作能一再委派，不必每次重新提供脈絡。 在 Codex 中，這透過 skills（SKILL.md 工作流程規格）和 plugins（可安裝的 skills 與整合功能套件）實現。論文的說法是：若沒有系統化，「使用者就必須一再提供任務脈絡、程序指引與指示，限制了工作交接的程度。」因此，系統化是深度委派的前提，而不是進階使用者才講究的小事。這是 Loop Engineering 中 skills 基礎元件，以及 Agent Context Files 所說「把意圖寫在外部」的實測、經驗性對照——Osmani 的意圖債務論點，如今有了採用曲線。

證據註記。 empirical——根據 Codex 日誌按每週時段測量 skill 來源呼叫；OpenAI 內部使用情況是前沿預覽，並非母體估計（參見 Conversation-to-Delegation Shift 的證據註記）。

Skill 使用普遍、持續增加，而且分布不均#

在截至 2026 年 6 月 11 日的 7 天期間：

族群	至少呼叫 1 個 skill 的比例
個人使用者	25.7%
組織使用者	30.4%
OpenAI 員工	96.2%

而且成長迅速：每週活躍 Codex 使用者中，呼叫任何 skill 的比例從 5.4%（2026 年 3 月 1 日）→ 26.6%（2026 年 6 月 11 日），三個月內約增加 5 倍。在 OpenAI 內部，系統化實際上已成為預設使用方式；外部使用者採用率仍屬少數，但正在成長。

Skill 分類，以及自訂 skills 揭示的訊息#

論文區分五種 skill 來源，從產品提供到使用者撰寫依序排列：

1. 預先安裝——Codex 隨附的能力（例如圖片生成）。
2. 精選——OpenAI 發行、不隸屬任何 plugin 的獨立 skills（例如 PDF 處理）。
3. Plugin skills——打包於 plugin 內的 skills（例如 Google Drive 文件工作流程）。
4. 自訂 plugin skills——與已識別的 plugin 關聯，但不符合精選目錄的 skills。
5. 自訂 skills——獨立、由使用者或組織撰寫，並非 OpenAI 發行（例如團隊資料視覺化準則、研究工作流程）。

成長尤其來自 plugins 和自訂 skills——系統化光譜的兩端。Plugins 將通用能力延伸到重複出現的成果物領域（文件、試算表、簡報）；自訂 skills 則編碼在地程序脈絡——團隊寫作標準、定期報告、組織專屬工作流程、使用者偏好。自訂 skills 的增加是關鍵訊號：使用者重視的不只是模型的一般能力，也重視能為重複發生、太過專門而難以標準化的任務，附加持續有效的程序脈絡。

組織梯度#

Plugin 與自訂 skill 的使用率在 OpenAI 最高，而且組織使用者明顯高於個人使用者。 論文將此解讀為系統化報酬的差異：若重複任務仰賴共用慣例、內部程序或團隊層級標準，自訂 skills 最能發揮價值；這些條件在組織情境中遠比個人獨自使用常見。因此，系統化集中在持續有效的程序脈絡能降低重複任務協調成本之處。（附錄細節：OpenAI 的協作對話有 50.9% 會呼叫 skill——系統化已在內部從程式碼延伸到知識工作。）

這與 複利脈絡 的邏輯相同：價值不在單次呼叫，而在於編碼後的工作流程能跨人、跨時間重複使用及分享。Skill 是撰寫格式；plugin 是散布單位——讓一個人的系統化成果在組織內擴散的機制（這也是 Loop Engineering 所區分的 skill≠plugin）。

規範版本：「絕不做一次性工作」（Garry Tan，2026 年 7 月）#

這個頁面以採用曲線衡量的現象，Garry Tan 將它表述為一種紀律（practitioner-opinion）：代理任務成功後，就**「把它 skillify」**——繼續下一件事之前，把完成的互動轉成可重用的 skill 檔案，因為「同一件事如果得問兩次，就是你失敗了。」他對組織的看法是：「能像這樣記下所學的組織，每天都會變得更聰明。做不到的組織每天早上醒來都像失憶一樣，不管模型有多好。」他表示，這種做法已從 YC 的工程師延伸到媒體、活動和財務人員撰寫 skill 檔案；若這具有代表性，就是上述組織梯度論點在一個互補性極高的機構內實際發生的情形（AI-Native Organization）。

Skills 作為跨廠商的方法論散布管道#

組織內部系統化又向前一步：2026 年 6 月，Google 將其代理品質評估方法論做成可安裝的 skills（從 skills.sh 使用 npx skills add … 安裝，有兩個套件），設計上可由客戶已在使用的任何程式碼代理程式驅動。上述分類是在單一產品內從產品提供延伸到使用者撰寫；這是第三種位置——廠商撰寫的方法論，以 skill 格式跨代理程式產品散布。Skill 不只逐漸成為組織編碼在地程序脈絡的方式，也成為廠商將專業知識交付到其他廠商 harness 的方式。

一個月後，鏡像的另一面出現了。Genkit（Daniela Petruzalek，2026-07-31，vendor-claim）由 Google 在自家 SDK 中，為 TypeScript、Go、Dart 和 Python 實作相同格式的載入執行環境——透過 metadata 注入發現 SKILL.md、use_skill 啟用工具，以及隨附的 scripts 與 references。合看這兩篇文章，同一廠商位於格式的兩側：為其他公司的 harness 撰寫 skills，也在自家產品中採用其他公司的規格。這比單看任何一篇都更能顯示兩者匯流，也是我們應將 skill 格式視為跨廠商慣例、而非散布技巧的理由。機制與證據限制見 Agent Context Files——Genkit 文章聲稱漸進揭露能節省 token，但沒有提供測量。

採用後發生什麼事：實測 skill 生命週期（Gao 等人，2026 年 7 月）#

上述 Codex 遙測測量的是採用。首項大規模研究將 skills 視為工程成果物（From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained，empirical：18,463 個 skills.sh registry skills，加上來自 5,876 個 GitHub repo 的 23,199 個個人使用 skills、3,709 條找回的重用連結、444 個人工編碼的差異），測量採用之後發生什麼事——答案大多是「什麼也沒有」。

重用是一次性複製，不是相依關係。 在 2,462 組歸類為軟體工程的重用配對中，1,841 組（75%）幾乎逐字採用（內文相似度 ≥0.99）；只有 621 組在引入時有所修改。所有已連結配對中，70.3% 的相似度 ≥0.99。採用之後，複本便不再更新：只有 47.4% 的重用 skills 曾收到本地 commit，53% 完全未經修改。若從供應鏈角度看，更糟的是，在未曾本地更新的重用 skills 中，40.2% 的上游版本至少更新過一次，但變更從未傳到本地複本；在那些本地曾更新、且上游也有變動的案例中，62.3% 各自分岔演進，沒有重新納入上游變更。Skills 的行為像是附帶 registry 的複製貼上片段，而非鎖定版本的相依套件。安全上的推論於 2026 年 8 月在真實環境中出現。 skills.sh 上一組遭植入木馬的 skill 被揭露後 12 小時內，就從市集和 GitHub 移除（Zenity Labs，case-study）；報告結尾提醒：「複製出去的指示可能仍留在下游儲存庫、聚合器和使用者機器中。」 這些數字說明，依照這種結構，殘留規模有多大：沒有更新管道就沒有撤銷管道，因此 70.3% 幾乎逐字複製、53% 從未碰過的複本，正是下架無法觸及、甚至無法列出清單的族群。附有 registry 的複製貼上片段，承襲 registry 的缺陷，卻沒有任何補救措施。參見 Agent Supply Chain Risk。

維護以新增為主。 排除原地修改後，新增數量整體是刪除數量的 2.7 倍——對隨時間演進的本地撰寫 skills 而言是 6.1 倍（採用時的客製化新增與刪除近乎均衡，比例為 1.1:1，因為採用者會精簡內容）。Skills 持續膨脹；最常被刪除的內容只有 registry 的授權與作者 metadata。這是複雜度棘輪（Ambrosino：模型會新增，很少刪除）出現在脈絡層，而非程式碼層。

客製化讓脈絡重新落地；演進則層層累積。 兩種情境修改的內容不同。客製化（registry → repo）主要是重新排版（佔差異的 48.9%）、改指向其他 references 與資源（34.6%）、移除來源與授權 metadata（17.6%）、調整環境設定（16.0%），以及依宿主專案重新界定範圍（14.9%）——例如 android-data-layer skill 將 Hilt 換成 Koin，以符合專案技術組合；重新封裝以適配宿主平台只在客製化階段發生（12.2% 對 0.0%，是資料中最明顯的差異），通常是移除 Claude 專屬 frontmatter，改為平台中立的版型。演進（本地撰寫，隨時間變化）則是擴充程序：重塑工作流程（38.4%）、修訂內嵌領域知識（32.5%）、強化限制（27.8%），以及隨周邊專案重整而追蹤名稱和工具替換（24.3%，相較於 5.3%）。

行為契約是繼承而來，未經審查。 在兩種情境中，skill 與使用者對話、監控執行階段狀態、以及失敗後復原的規則，都是最少被編輯的內容：使用者互動佔差異的 1.6%/1.2%，執行階段狀態監控 0.5%/0.0%，失敗處理 5.9%/7.1%。採用者幾乎原封不動地從 registry 取用這些內容，之後從不重新檢視。作者的推論是：skill 作者必須在建立時就把這些部分做好，因為下游沒有人會做——這是一種供應鏈風險集中，與從相依套件繼承的缺陷相似，但載體是任何 linter 都不會讀取的散文。

Registry skills 與本地 skills 按知識領域分流——這獨立印證了 Codex「自訂 skills 編碼在地程序脈絡」的說法。軟體建構在兩邊都是主流（registry 28.3%／個人使用 22.1%），其餘 17 個 SWEBOK 領域則占較小比例；但 registry skills 偏重通用能力（設計 4.3% 對 2.5%、架構 3.2% 對 1.9%、安全性 3.8% 對 2.3%），個人使用 skills 則偏重與專案相關的生命週期工作——組態管理 9.4% 對 4.1%、測試 6.4% 對 4.9%、品質 5.7% 對 3.8%、維護 3.9% 對 2.6%。兩組獨立資料集（OpenAI 遙測、GitHub 挖掘）得出相同分工：registry 提供通用程式碼能力，本地撰寫則提供沒有外部市場的專案專屬程序脈絡。

封裝紀律。 Registry skills 比個人使用 skills 更長，段落也更多（中位數 1,678 對 1,114 個 token、19 對 13 個標題；Mann-Whitney p<0.001，效果小）。兩個族群對必要的 Agent Skills 規格條款符合率都達 ≥99%（存在 SKILL.md、YAML 有效、description 為指定型別且 ≤1024 字元），但選用欄位幾乎乏人問津：license 16.1%/9.1%、metadata 13.1%/10.4%、allowed-tools 15.0%/12.5%、compatibility 4.0%/3.2%。最常見的選用子目錄是 references/（31.0%/17.0%）。個人使用 skills 也較常偏離規格要求的 name == 上層目錄規則（91.2% 對 97.7%）——這類錯誤會悄悄阻止 skill 啟用。就內容而言，對 180 個 SKILL.md 檔案進行主題分析後得到六個主題：界定範圍與協調（100% 的 skills）、執行工作流程（89%）、為領域知識提供根據（85%）、管理代理程式行為（81%）、確保輸出品質（69%）、使用者與代理程式協調（68%）。

比文件過時更值得注意之處。 作者說明其重要性時指出：「人類閱讀過時的 README，可以辨識並繞過其中落差；但代理程式會讀取 SKILL.md，並對其環境採取行動，因此過時指引會被執行，而不是閱讀。」

與複利脈絡論點的張力#

Tan 所說「能記下所學的組織，每天都會變得更聰明」（practitioner-opinion，見上文）以及此頁的複利脈絡框架，都假設編碼後的工作流程能持續更新。實測的生命週期卻顯示，中位數 skill 只撰寫一次、逐字複製，然後擱置——53% 從未觸碰，40.2% 的靜置複本上游已過時。依證據層級加權（empirical 高於 practitioner-opinion），只有在多數採用者並未實踐的維護紀律下，系統化才會產生複利；缺乏這種紀律時，skill library 只是複製當下慣例的快照，會悄悄退化，代理程式卻仍持續執行其中內容。注意適用範圍：Gao 等人抽樣的是至少 10 顆星的公開 GitHub 儲存庫，並非互補性高的組織（OpenAI 的 skill 使用率為 96.2%、YC）；Tan 與 Codex 研究的主張在這些組織中最有力——兩組族群可能確實不同，而非彼此矛盾。

誰負責維護，實測結果為何（Shen 與 Hruschka，2026 年 9 月）#

上文 Gao 等人測量的是成果物；Shen 與 Hruschka（Megagon Labs，arXiv 2609.05677，empirical，COLM 2026 Workshop on Lifelong Agents）測量的是流程——與 Gao 的樣本不同，他們研究的正是實際有維護的少數 skills。研究挑選五個持續活躍的公開 repo（getsentry、trailofbits、obra/superpowers、anthropics、cloudflare；873 個 commit、143 個 SKILL.md 檔案，2025 年 10 月至 2026 年 6 月），找到 254 次建立後的實質編輯。對此頁第二個開放問題，公開 repo 的答案是：具名的人類負責，AI 輔助程度則取決於 repo，而不是任務。 每一次實質編輯都由具名人類帳號撰寫，或透過網頁合併；其中 158 次（62%）附有 AI 共同作者標記，但這包含兩種雙峰模式——getsentry 和 trailofbits 分別為 93% 與 92%，obra 為 16%，anthropics 為 5%，cloudflare 為 0%——作者認為這反映了揭露與合併文化的差異，和 AI 使用程度的差異同樣有關（Anthropic 自家 repo 只有 19 次編輯中的 1 次帶有標記，但公司表示合併的正式環境程式碼有 >80% 由 Claude 撰寫）。標記無法預測編輯內容：編輯規模沒有差異（中位數 15 對 21 行，p = 0.20）、範圍沒有差異，排除大量重構後，也沒有能持續成立的元件專業化差異。

維護內容以60% 增強、38% 修正為主（254 次編輯中，內容擴充 72 次、事實修正 56 次、重整 50 次、因失敗修正 41 次）；整併（10 次）和棄用（1 次）合計僅 4.3%——有維護的族群也像 Gao 研究中遭棄置的族群一樣持續累積內容。編輯間隔的中位數為 5 天（obra 為 1.5 天，trailofbits 為 14.5 天）；120 個至少有兩次大小觀測值的 skills 中，32 個成長 >10%，7 個縮小，81 個維持穩定。主要編碼流程判定只有 24% 的編輯附有具體失敗證據；交叉分類重編碼則為 63%，因此這個數字會隨測量工具而變。接著是與本頁第四個問題相關的結果：一項預先註冊且具統計檢定力的移轉任務研究（13 個至少有 6 次實質編輯的 skills、143 項任務、跨家族盲測評審）發現，最新版本不優於觀察期間最早的版本，在 1–5 分量表上差 −0.09，95% CI [−0.28, +0.10]；效果差異取決於編輯新增的內容，而非數量——程序鷹架有害（brainstorming −0.95），輸出限制有幫助（pr-writer +0.31）。範圍限制：五個廠商 repo 依活躍程度選出；標籤由 LLM 編碼，主要結論依據經人工驗證的雙向歸併（κ 0.72）；「由人類合併」指透過網頁合併流程，並不代表已確認經過審查；評審團也未達到自身設定的信度門檻。完整分析見 Human-Governed Skill Maintenance。

延伸閱讀#

• Human-Governed Skill Maintenance——從流程面補足本頁從成果物面測量的生命週期：在有維護的少數案例中（五個公開廠商 repo、254 次實質編輯），每次編輯都由人類發布，62% 帶有 AI 標記且各 repo 呈雙峰分布，增強與修正占 60/38，254 次中只有 1 次棄用；具統計檢定力的移轉任務測試發現，維護後版本不優於最早版本，因此本頁指出多數採用者略過的維護紀律，目前尚未測得回報

• Skill Lift——缺少的第二條軸線。本頁測量 skill 採用（每週活躍 Codex 使用者比例從 5.4% 上升至 26.6%，53% 的重用 skills 從未修改）；NVIDIA SkillEvaluator 則以成果物為單位測量 skill 效能，並把有／無 skill 的消融測試設為發布前提。兩者共同指出真正的落差：採用已經過測量，品質如今也能測量，而串起兩者的維護紀律正是生命週期資料顯示多數採用者略過的部分。這也為本頁觀察到的跨廠商散布增添測量層——一套 NVIDIA skill 目錄以 plugins 形式發布給 Claude Code、Codex 和 Cursor，另有三個第三方 registry；每個都帶有相同的 benchmarks.json 數字

• 將代理工作凝結成工作流程——把「外化你必須重新推導的內容」再往前推一步：不是「記下來，讓代理程式重新閱讀」，而是「編譯好，讓代理程式根本不必執行」，並以證據作為晉升門檻，回歸時自動降級

• Harness Build-vs-Buy——OpenHands 自訂化階梯的第三級：skills 和 plugins 讓代理程式取得「組織專業知識，而不必永久維護分支差異」——本頁測量的正是這些成果物，但這裡主張的是避免維護分支，而非將其視為槓桿

• Loop Engineering——相同基礎元件的實務紀律來源：skills 是五種迴圈基礎元件中的第三種，將「意圖寫在外部」，讓迴圈每個週期不必重新推導專案狀況；本頁則是其採用曲線的實測對照

• Systems Thinking Over Specialization——Netflix 組織設計上的對照：「以一組核心能力一次解決問題」（鋪設好的路徑、事實來源資料）將系統化邊際表述為招聘主張，而非遙測實測結果

• Agent Context Files——以 skills/SKILL.md 將專案脈絡外化並重複使用；系統化是顯示這項基礎元件正大規模採用的使用資料證據

• Conversation-to-Delegation Shift——系統化是該研究用來衡量委派深度的三種「如何」邊際之一，另外兩者是並行性和執行環境

• Parallel Agent Orchestration——同一研究中的相鄰邊際；系統化讓平行與可重複委派變得可行

• Compounding Data Moat——自訂 skills 是編碼後的組織專屬程序脈絡，能產生複利並分享；系統化報酬的梯度是以脈絡構築護城河的論點

• Harness Shrinkage as Models Improve——Skills/plugins 是被產品吸收的 harness 能力，成為具名且可分享的基礎元件，而非需要手動維護的鷹架

• MCP and Computer Use——Plugins 除了 skills，也會打包 MCP/連接器整合功能；這是系統化中擴展工具觸及範圍的部分

• Agentic Technical Debt——未系統化的代理程式使用會導致從零重新推導／意圖債務；skills 是持續性脈絡的解方，本頁顯示它正逐漸普及，也顯示它本身開始成為債務面：53% 的重用 skills 在採用後從未修改，本地維護新增與刪除比例為 2.7:1，因此 skill library 規模持續膨脹，卻逐漸與專案脫節

• Agent Supply Chain Risk——Skills 是一條由散文構成的供應鏈：70.3% 的重用連結是幾乎逐字複製，沒有更新管道（40.2% 的靜置複本上游已變更）；行為契約（使用者互動、執行階段監控、失敗復原）又是最少編輯的內容，因此作者的缺陷會未經審查地傳給每位採用者

• Write-Then-Trusted——本頁的過時發現為何也屬於安全問題。 該頁針對「檢查一次，就永遠信任」的補救方式是在使用前重新驗證；此處測量的生命週期顯示，skill 使用者與上游已不存在可供重新驗證的關係——逐字複製、沒有版本鎖定、沒有摘要、沒有公告動態，53% 複製後再也沒碰過。因此，市集上的身分可以先累積指向乾淨內容的安裝量，之後再替換內容；已複製出去的版本也無法透過更新或撤銷觸及

• Ticket-Driven Agent Orchestration——看板／工單狀態是另一種持久化外化；skills 的系統化處理程序面，工單則處理工作圖面

• OpenAI——提供此處 Codex 遙測資料的實驗室

• Codex——本頁測量其 skill/plugin 系統的工具

• Agent Quality Flywheel——以 skill 格式跨代理程式產品發布廠商撰寫的方法論；這是系統化光譜的跨廠商延伸

• AI-Native Organization——Tan 以此邊際為基礎的組織論點：skills 是組織編碼後的角色，「絕不做一次性工作／把它 skillify」則是產生複利的紀律

• Owning Your Externalized Cognition——這個邊際引發的所有權問題：讓個人產生複利的行為（把判斷寫成可重用檔案），也讓持有 repo 的人能據為己有。本頁的遙測資料也是檢驗該主張複利前提最有力的現有測試——53% 的重用 skills 從未修改，維護新增與刪除比例為 2.7:1，這是一次性複製，而非會隨時間改善的 library

• Standardize the Infrastructure, Not the Tools——同一種將基礎層標準化的思路再往上一層：Skills 將個人工作方式系統化，中央 LLM proxy 則將組織採購與計量模型存取的方式系統化

• Evals as Product Spec——本頁實測的維護缺口所缺少的紀律。Anthropic 的 Applied AI SDLC playbook（vendor-claim，2026-08-21）規定，任何變更 CLAUDE.md、skills 或 hooks 時，都應在 CI 執行包含 20–50 個任務的 eval suite，因為「這些設定會引導代理程式，理應像程式碼一樣接受回歸測試」，並將其設為合併檢查。這正是此處一次性複製族群所欠缺的維護迴圈——53% 的重用 skills 從未修改，維護新增與刪除比例為 2.7:1——而且 playbook 也指出紀律仍遭略過的原因：執行 eval 會消耗 API 預算，因此同一份 playbook 承認有些團隊會改成離線、定期執行

• Agent Self-Poisoning (the CREATE-Path)——本頁測量的複製式重用機制中，帶有對抗性的一面。 Gao 等人證實代理程式 skills 透過逐字複製傳播（找回的 3,709 條重用連結中有 70.3% 相似度 ≥0.99），53% 在採用後從未修改，也沒有更新管道或下游審查。EvoMal（Wu、Shi 等人，Queen's University，arXiv 2608.25776，empirical）在上一層使用同樣機制並加入攻擊者——載體從散文變成可執行 skills，複製者則從人類變成代理程式。看似良性的結構鷹架橫幅包住可互換的酬載；它能在重新撰寫時留存，原因與過時 skill 能在採用後留存相同：沒有人檢視伴隨而來的內容。在六種模型中，代理程式會在 20.3–41.8% 與工具相關的 SWE-bench 任務中重現該內容，使 library 留下相當於預植惡意項目 4.9–9.0 倍的條目。過時與傳播，是同一項特性的良性與對抗性表現——也就是以複製為基礎、沒有審查步驟的重用；因此，本頁主張的維護紀律，也是同一項安全介入措施

開放問題#

• 5.4%→26.6% 的曲線只涵蓋三個月。這是持久的行為改變，還是 Codex 推出 skills 功能後的新鮮感高峰？（參見論文提到的 OpenAI 內部培訓活動。）
• 自訂 skills 編碼組織專屬脈絡——但當程式碼庫和慣例逐漸變化時，誰來維護？如果 skills 腐朽，系統化本身也可能成為債務面（Agentic Technical Debt）。#oq/source 已有部分解答： From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained（empirical，2026-07）直接測量公開 GitHub 上的變化——53% 的重用 skills 在採用後從未修改，40.2% 未更新的複本上游已變更，本地維護新增與刪除比例為 2.7:1（本地撰寫 skills 為 6.1:1）；追蹤名稱／工具替換是最大的單一演進活動（24.3%）。因此 skills 確實會腐朽，棘輪效應也真實存在。仍未解答的是後果——目前沒有研究將 skill 過時與代理程式任務成果下降連結起來，而且樣本（至少 10 顆星的公開 repo）排除了採用曲線最陡峭、互補性最高的組織。2026-09-22 更新： Who Maintains Agent Skills? A Longitudinal Study of Human-Governed, AI-Assisted Skill Maintenance（empirical，Shen 與 Hruschka，COLM 2026 workshop）直接回答公開 repo 中的誰負責——五個由廠商維護的 skill repo 共 254 次實質編輯，每一次都由具名人類帳號撰寫或透過網頁合併；62% 附有 AI 共同作者標記，各 repo 呈雙峰分布（93%／92%／16%／5%／0%），反映的可能同樣是揭露文化與 AI 使用情況——也進一步研究腐朽：有維護的少數案例中，38% 編輯是修正，24–63% 編輯由失敗觸發（視編碼工具而定），檔案大小維持穩定到增加的趨勢（120 個之中 32 個增大／7 個縮小／81 個穩定），幾乎不會精簡（254 個中棄用 1 個、整併 10 個）。這還沒有回答原本提出問題的原因：問題前提是組織內部自訂 skills 隨私人程式碼庫變動而過時，但此研究樣本是五個依持續活躍程度選出的 AI 工具廠商公開 repo；這些 skills 的主題是廠商自家產品，而非單一團隊的慣例。若要解決此問題，需要研究私人或組織內部的 skill 目錄——例如從上述 Codex 使用族群中分析自訂 skill 編輯歷史的廠商遙測切面，或組織案例研究——並回報由誰編輯、編輯頻率，以及編輯是否隨程式碼庫變更而發生。
• 系統化會造成更深度的委派，還是只與原本就大量使用的使用者相關？論文顯示的是關聯，並未判定方向。#oq/source（From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained 沒有探討此問題——該研究挖掘的是成果物與其差異，從未觀察使用者或委派任務，因此無法說明因果方向。）
• Skill 過時是否會實際降低代理程式任務成果，或者模型愈來愈能避開過時指示（Harness Shrinkage as Models Improve）？Gao 等人證實過時情況很普遍，也指出過時指引會「被執行，而不是閱讀」，但從未測量下游影響；SkillsBench 式評估或許能解答。2026-09-22 已有部分解答： Who Maintains Agent Skills? A Longitudinal Study of Human-Governed, AI-Assisted Skill Maintenance 進行了目前最接近的實驗，結果是在有限範圍內得到與問題前提相反的零效果——維護沒有帶來可測量的改善，因而過時也沒有造成可測量的損失：針對 13 個至少經過 6 次實質編輯的公開 skills，在 143 項移轉任務中，最新版本相較於觀察期間最早版本低 −0.09 分（95% CI [−0.28, +0.10]）；控制長度後結果仍為零效果，使用較弱的非推理解題器時也相同（因此並非強模型避開舊版指示的結果）。信賴區間仍容許小幅效果；評審團的 ICC（0.52）低於 0.6 門檻；任務由作者與模型建構，而非取自實際 repo 工作流程——因此此結果只限制試點規模的效果，不能涵蓋所有效果。尚待解答：在獨立來源的任務集上測試相同的 v_old/v_new 配對。

資料來源#

• The Shift to Agentic AI: Evidence from Codex — §5.3「代理工作的系統化」；§6 結論；註腳 13（skill 與 plugin 定義）；附錄圖 A8（依任務領域區分的 skill 使用情況）

• Driving the Agent Quality Flywheel from Your Coding Agent- Google Developers Blog — Google 將 eval 方法論製作成 skills.sh 套件，供任何程式碼代理程式使用（vendor-claim）

• Enable on-demand expertise with Agent Skills in Genkit Go — Daniela Petruzalek、Google Developers Blog、2026-07-31（vendor-claim）：同一廠商與 skill 格式關係中的執行環境部分——Genkit 支援四種語言的 Agent Skills，實作 agentskills.io 規格。此處僅引用以支持跨廠商慣例論點；文章沒有提供測量

• The New Physics of Business — Garry Tan, Y Combinator — Garry Tan，AI Engineer 演講（2026-07-17，practitioner-opinion）：「絕不做一次性工作／把它 skillify」的紀律

• From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained — Gao、Lulla、Lin、Baltes、Treude、Zahedi，arXiv 2607.00911（2026-07-01，empirical）：§IV SWEBOK 知識領域分布；§V-A 封裝與規格符合度（表 I）；§V-B 內容分類（表 II）；§VI-A 採用時的修改；§VI-B 編輯分類（表 III）；§VII-A 新增式維護與穩定行為契約分析

• EVOMAL: Self-Poisoning in Self-Evolving Coding Agents — Wu、Shi、Q. Li、Zhao、X. Li、Adams、Hassan 與 Ni（Queen's University），arXiv 2608.25776，2026-08-26，empirical。此處用於說明複製式 skill 重用的對抗性解讀：§2（CREATE-path）、§5.1（撰寫時的橫幅／酬載區分與結構模仿）、§6.3（六種模型的 ASPR 範圍與 library 擴增 4.9–9.0 倍）。完整分析見 Agent Self-Poisoning (the CREATE-Path)

• Attackers Target Agents via The Skill Supply Chain — Michael Bargury（Zenity Labs），Attackers Target Agents via The Skill Supply Chain，labs.zenity.io，2026-08-06，case-study（由廠商撰寫；OSV／Amazon Inspector 的交叉佐證、commit SHA 和封存擷取資料視為事實；安裝數由平台顯示，且明確指出不是不重複使用者數）。此處僅引用其重用殘留論點：「影響與下架」以及 TL;DR 的結尾提醒：所有列表移除後，複製的指示仍會留在下游儲存庫、聚合器和使用者機器中。完整分析見 Agent Supply Chain Risk

• Who Maintains Agent Skills? A Longitudinal Study of Human-Governed, AI-Assisted Skill Maintenance — Chen Shen 與 Estevam Hruschka（Megagon Labs），arXiv 2609.05677，2026-09-04，empirical（依 PDF 頁尾標示，COLM 2026 Workshop on Lifelong Agents）：§3 語料與編碼手冊；§4 與圖 1 的操作分布及雙向歸併；§5 編輯頻率與大小趨勢；§6 與表 3 的 repo 治理；§7 與附錄 D 的具統計檢定力移轉任務零效果。圖 1 的數量只以原始檔中的圖片呈現，已根據 pdftotext -layout 擷取文字層還原；表 5 和表 6 有未標示的解析損壞（列位移、欄位合併），已記錄於原始檔註記區，本文未引用。完整分析見 Human-Governed Skill Maintenance