Skill Lift

資料來源#

• Attackers Target Agents via The Skill Supply Chain
• Evaluating AI Agent Skill Performance with NVIDIA SkillEvaluator
• EVOMAL: Self-Poisoning in Self-Evolving Coding Agents

摘要#

Skill Lift 是單一代理程式技能在有技能與無技能兩種情況下的分數差，以 0–100 規準的分數點表示；每項技能在每個代理程式 harness 上各計算一次，再對技能–harness 配對取宏平均。這項指標來自 NVIDIA SkillEvaluator（開源，2026 年 8 月），是本文語料中第一個以個別脈絡產物為受測單位、對其執行受控消融實驗，並將差值發布在分發該產物的登錄庫中的工具。

比數字更值得關注的是它的結構性主張：測量從事後研究，轉變為分發的先決條件。NVIDIA 的說法——「經過驗證的部分，是決定它已準備就緒的測量」——讓每項技能的基準測試成為 verified 徽章所代表的意義。技能是為 NVIDIA 產品打包、簽署的能力描述；每項技能發布前都須通過三個評估層級，結果則以 benchmarks.json 隨附於 nvidia/skills repository。

這是 Agent Context Files 所述有限零效應的廠商版本。Khatri 的消融實驗發現，代理程式已能讀取的 repository 中，一般慣例脈絡對正確性的影響約為 0；SkillEvaluator 則針對代理程式可能無法自行推知的特定任務產品知識，報告正確性提高 41 分。這正是該文長期懸而未決問題所預測的方向——但本文「設計控制了什麼」一節將說明，這套方法無法證實此事。

證據註記。 vendor-claim，編譯時指派——原始資料沒有 evidence: 欄位。所有數字都是 NVIDIA 用 NVIDIA 自家的技能，對照由那些技能生成的評估集所測得，而且文章並未說明評分程序。對廠商文章而言，方法揭露異常詳盡（嘗試次數、宏平均定義、固定版本快照 commit，以及明確表示「我們不報告信賴區間」）；也正因如此，具體弱點才清晰可見，而非藏而不露。應把發現的整體趨勢視為有參考價值，至於數值大小則尚未經重現。

三層發布門檻#

每一層都回答不同問題，也能獨立執行：

1. 第 1 層——安全與結構。 靜態檢查：schema 與 frontmatter 驗證、品質評分、提示注入與資料外洩安全掃描、機密與 PII 偵測、授權條款檢查、指令碼 lint。沒有代理程式執行。這是將 Agent Supply Chain Risk 的緩解措施用於技能產物，而非模型或 MCP 伺服器。
2. 第 2 層——獨特性。 以嵌入相似度做兩種檢查：找出同一項技能內重複的指引，以及整個目錄中涵蓋範圍重疊的內容。理由是注意力競爭——「環境中的每項技能都在爭奪代理程式的注意力；不相關時仍載入的技能可能降低代理程式效能。」目錄整潔度成為可測量的屬性，而非風格偏好。
3. 第 3 層——即時評估。 消融實驗。以 Harbor（開源，harbor-framework/harbor）為基礎，進行可重複的隔離代理程式評估；SkillEvaluator 將評估案例轉成 Harbor 任務套件，每個案例在不同沙箱中各跑兩次——提示、模型、任務輸入和評分標準都相同，唯一差異是有沒有安裝該技能——接著分別評分並回報差值。

工作流程只需兩個指令：skillevaluator create-eval-dataset./my-skill --full 會產生 evals/evals.json（明確、隱含、脈絡式及反向案例，每項都有 ID、提示、預期輸出和可選斷言），接著 skillevaluator tier3 evaluate./my-skill --agents codex --env-mode docker 執行比較。

基準測試#

所有數字均來自 benchmarks.json 2026 年 8 月 12 日快照，commit 為 738d79e——涵蓋 30 多種 NVIDIA 產品的 300 多項已驗證技能，在 Claude Code 和 Codex 上評估，並採宏平均，讓每個技能–harness 配對權重相同。

面向	衡量內容	無技能	有技能	Skill Lift
正確性	最終答案是否正確？	46	87	+41
可發現性	相關時是否載入正確技能，不相關時是否保持未載入？	42	82	+40
有效性	代理程式是否達成目標並遵循預期工作流程？	39	78	+39
效率	是否避免浪費步驟或多餘工具呼叫而達成目標？	43	78	+35
安全性	執行過程是否避免不安全操作、機密外洩及未授權存取？	97	98	+1
所有面向				+31
排除安全性				+39

依 harness 分別為：Claude Code +34（所有面向；排除安全性為 +42），Codex +29（+36）。兩個 harness 相差約 5 分；NVIDIA 將之歸因於預設 system prompt、脈絡處理及工具呼叫實作不同。

文章本身提出了三種解讀，但單看數字並不足以支持：

• 只有正確性、有效性與安全性，是兩組都可比較的結果指標。 可發現性與效率有一部分是在評分技能如何被使用——技能不存在時，這些行為無從發生。基準分數分別為 42 和 43，而非 0，因為無技能組仍可因有效使用工具、乾淨俐落地完成操作，以及在無關任務中正確地不載入技能而得分。因此，總計 +31 的貢獻項目中，有兩項不能按一般意義視為提升；NVIDIA 表示，應把它們解讀為技能安裝後能正確啟用並使用的證據。
• 安全性的 +1 是回歸檢查，不是增益。 基準分數 97 表示目標是確認安裝技能沒有造成安全性退步。
• 分數不是通過機率。 正確性從 46 → 87，代表在受評估的專門任務上平均規準分數較高，而不是通過率提高 41 個百分點。

統計上的嚴謹度#

已發布技能中，85% 每項任務只跑一次，15% 跑兩次。 全文沒有報告信賴區間。即時代理程式執行結果每次都可能不同，因此個別技能分數以雜訊為主；只有彙整數千次試驗的整個目錄平均值，才足以作為可靠讀數。文章以白話明確揭露這一切——這是 Compute-Controlled Benchmarking 希望更多廠商採行的揭露標準——但後果依然存在：benchmarks.json 中的個別技能數字，都不應被視為具有已知誤差範圍的估計值。考量到市集 UI 正是把這些個別數字呈現給採用者，這點令人尷尬。

設計控制了什麼，沒有控制什麼#

在同一個 harness 內，消融實驗設計乾淨：相同提示、相同模型、相同輸入、相同評分器、不同沙箱，只有一個變數。這是實質的受控比較，優於大多數廠商基準測試。

它沒有控制的是任務來源。 create-eval-dataset./my-skill 會根據受測技能生成評估集。因此，技能本身的內容決定任務分布和預期輸出，而無技能組是在一份依據對照組答案卷編成的考卷上受評。對 NVIDIA 實際提出的問題——這項技能是否讓代理程式更擅長處理它聲稱涵蓋的工作？——這樣的設計站得住腳，或許也是唯一可行的方法。但對讀者可能帶走的問題——技能是否讓代理程式變得更好？——則行不通，因為描述獨特工作流程的技能會生成只有自己能完成的任務，並因此拿下高分。NVIDIA 自己的首項關鍵發現，從正面角度也說明了這一點：「技能的測量精確度，只能與評估集描述工作內容的精確度相當。」這套測量是對產物做自我一致性檢查，升級後成為分發門檻。

相同的循環性也出現在 harness 比較中。NVIDIA 報告，各產品的 Skill Lift 約介於 +2 至 +46，而兩個 harness 相差約 5 分，並得出結論：「產品比代理程式更重要——領域、任務與評估設計比 harness 更重要。」這說法沒錯，但要注意最後一項：評估設計會隨產品而變，因為每項產品的評估集都是由其技能生成。因此，「產品更重要」很大一部分其實是「評估集更重要」；這只是把循環性改述成一項發現。

文章從未指出評分器是什麼。 規準面向寫著「代理程式是否達成使用者目標並遵循預期工作流程」，評分範圍為 0–100，這暗示使用了 LLM 評審；但文章沒有說明評審模型、沒有人工一致性檢查、沒有經機率校正的一致性檢查，也沒有位置偏誤稽核。LLM-Judge Validation 的核心結果是，未經驗證的評審只計入機率校正，就會常態性地高估可靠度 33–41 個百分點；由未經驗證評審測得的 41 分差距，來源可靠度也是未知的 41 分差距。這是已發布方法中最大的單一缺口。

節省 Token 並非必然#

文章中最有用的實證細節，正因為它不利於廠商自身利益。SkillEvaluator 將 Token 使用量與效率規準分開追蹤，而兩個單次嘗試案例的結果方向相反：

技能	Token 數	經過時間
jetson-optimize-memory	617,306 → 142,540 (−76.9%)	474.9s → 220.0s (−53.7%)
cuopt-install	25,227 → 55,582 (+120.3%)	34.0s → 41.1s (+20.8%)

某項技能可能讓它原本要協助完成的任務，Token 成本增加一倍以上。NVIDIA 將此列為「找出可進一步最佳化的機會」，這樣回應沒錯，但一般性結論更重要：安裝脈絡產物對成本的影響方向未定，得透過測量才知道結果是哪個方向。

這和 Agent Context Files 中的 Khatri 結果直接形成張力；這兩者值得並列，而非取平均。Khatri 發現，在正確性沒有變化的情況下，唯一持續出現的效果是成本和延遲——選擇性檢索大幅減少建立快取的次數；檔案中的執行階段警告則依劑量反應地帶來約 24% 的經過時間降幅。那是脈絡檔案文獻中唯一可靠的勝利。SkillEvaluator 表明，即使是專為特定用途打造的技能，也無法保證成本改善方向一致。兩項研究在這個面向的統計效力都不足（Khatri：探索性研究，n=5，一個 repository、一個代理程式；NVIDIA：兩個單次嘗試軼例）；因此坦白的解讀是，目前沒有人以足夠的統計效力測量脈絡產物的 Token 成本，無法判定其影響方向，而兩項獨立研究如今已產生方向相反的結果。

測量結果正在哪裡分發#

兩個試點將評估結果放到採用環節，而非論文中：

• ClawHub 正為官方組織試行 SkillEvaluator：執行第 3 層測試，並在 Evals 分頁顯示有技能與無技能的結果，讓開發者在發現並安裝技能的地方看到評估訊號。這就像市集商品頁上的營養標示。
• Nous Research 的 Hermes Agent 測試了安裝時執行的選用提示掃描——SkillSpector（NVIDIA/SkillSpector）檢查 PII、Unicode 偷渡、指令碼 lint 問題、授權問題與安全發現，在安裝之前顯示檔案與行號。29 項測試通過；每項技能掃描約需 1.4–1.5 秒。

就 Agent Supply Chain Risk 而言，Hermes 整合值得注意：這是本文語料中首個技能登錄庫在安裝流程中執行靜態分析的案例，而且每次掃描成本低到足以無條件執行。它只提供建議，不會阻擋安裝；掃描的則是依 NVIDIA 描述已經簽署的能力描述——該文要求 MCP 應採用簽章加內容掃描的安全態勢，但實際上並未做到。

NVIDIA 將技能作為外掛發布給 Claude Code、Codex 和 Cursor，並透過 Skills.sh、ClawHub 及 Hermes Hub 發布——同一產物經六個管道分發，正是 Agentic Work Systematization 所觀察到的跨廠商分發現象，只是多加了一層測量機制。

同一個管道，卻沒有任何門檻（2026 年 8 月）#

其中一個管道在一個月後提供了反事實案例。Zenity Labs（Michael Bargury，2026-08-06，case-study，廠商撰寫）記錄了一起發生於真實環境的 skills.sh 活動：冒用相似拼字的發布者身分、一組遭植入木馬的 Markdown 技能，以及顯示超過 170 萬次安裝的累計數字（市集將平台計數器列為安裝次數，而非不重複使用者；作者明確表示「我們不知道不重複受害者的數量」）。這些技能在趨勢榜累積四週後，才有第三方將一批市集技能放進沙箱引爆而發現。這對本文有兩點啟示。

這是目前支持第 1 層作為分發先決條件的最有力論據，也支持把 SkillSpector 放在安裝時，而不是發布時執行；因為活動中的產物已被安裝，但使用者從未看到掃描結果。承載這些技能的登錄庫只公開了持續上升的安裝計數器，沒有提供任何內容資訊。

這也指出門檻尚未測試的邊界。 第 1 層和 SkillSpector 都描述了對單一技能執行的檢查——schema 和 frontmatter 驗證、提示注入與外洩掃描、機密、PII、授權條款、指令碼 lint。活動中的惡意文字從未放在技能檔案中：它藏在次要的 setup-installation.md，代理程式只有在安裝時才會被要求開啟，並透過同系列其他技能的交互參照觸及。因此，只打開前置檔案便停止的掃描，會判定產物乾淨。NVIDIA 的文章與 Hermes 試點都未說明掃描是否會解析技能的參照樹，而這正是此實際案例中關鍵的一問。這列為 Agent Supply Chain Risk 的待解問題；其偵測架構中的組合問題則見 MCP Tool Poisoning。

這項消融乘上的項目，以及過去沒人回報的指標（2026 年 9 月）#

Skill Lift 是兩組之間的差異：代理程式有技能，與代理程式沒有技能。Lin et al.（arXiv 2605.30621，empirical）測量的是決定第一組是否名副其實的量——技能載入率，也就是代理程式實際將技能載入脈絡的軌跡比例——而且這個比例遠不到 1。

在 SkillsBench 上，涵蓋六種底層模型：Qwen3-32B 為 0.251、GPT-OSS-120B 為 0.446、Haiku 4.5 為 0.794，Qwen3-235B、Sonnet 4.6 和 Opus 4.6 則為 0.957–0.961。這些數字直接取自執行器的動作紀錄，而非經評分所得。若載入率為 0.251，有技能組有四分之三的時候其實只是掛著標籤的無技能組，因此測得的提升是對技能實際生效之軌跡上影響的稀釋估計。

這對本文的測量工具有三項影響。

• 提升數字帶有未明說的啟用項，而且大小取決於模型。 同一項技能在兩種底層模型上測量，回報的提升可能全因載入頻率不同而有差異，產物本身完全沒變。SkillEvaluator 發現「產品比代理程式更重要——領域、任務與評估設計比 harness 更重要」，但這項發現只在兩個 harness 上、以固定模型測量；跨能力等級的測量仍付之闕如，而啟用項正會在這個範圍造成影響。
• 提升的上限取決於遵循率，而非 1 − 基準值。 載入是必要條件，卻非充分條件：這六個模型的 harness 遵循率介於 0.142 至 0.757，而且與載入率並不同步——Qwen3-235B 載入頻率與 Opus 4.6 相近（0.961 對 0.957），但遵循率不到對方一半（0.350 對 0.757）。只憑提升值就通過技能的發布門檻，無法區分難以遵循的技能和內容錯誤的技能。
• 這會讓前述評估集循環性問題更突出，而非緩和問題。 評估任務由受測技能生成，理應更容易觸發技能——任務文字取自理當能回應該任務的產物。Lin et al. 的啟用失敗，發生在代理程式已正確辨識自己需要哪項技能，卻在動作協定層面失敗的任務上。

這些數字也有必須一併說明的限制：診斷只針對 SkillsBench，模型集合早於 Claude 5，而 harness 遵循率則來自 LLM 評審，沒有一致性統計——本文對 SkillEvaluator 未具名評分器採用的 LLM-Judge Validation 折扣，也適用於此。完整分析見 Harness Activation and Adherence。

延伸閱讀#

• Harness Configuration Defects — 技能門檻中的靜態檢查部分、經驗證的結果及其明示限制。 不依賴模型的掃描器在固定 commit 上重新推導結果，發現已發布集合中 3.5% 所帶技能不符合規範，3.7% 在 allowed-tools 中附帶 shell 預先核准——正是第 1 層和 SkillSpector 執行的檢查。同一篇論文援引 ACES（arXiv 2608.20614），指出結構掃描與測得技能效果的相關係數為 0.14；這正是應將靜態門檻與本文即時消融實驗配對，而非擇一採用的理由
• Human-Governed Skill Maintenance — 另一種設計有相反弱點，得出方向相反的結果：對 143 項遷移任務進行預先註冊且具統計效力的比較，結果顯示，經維護版本相較最早版本的差異為 −0.09（CI [−0.28, +0.10]），與本文的正確性 +41 相比；在作者與模型共同建構的任務上，評審甚至低於其自身可靠度門檻，而本文的評估集正是由受測技能生成。兩者都沒有使用獨立來源的任務集；本文第一個待解問題正是詢問這項實驗
• Harness Activation and Adherence — 本測量工具假設存在，卻從未測量的先決條件。有技能／無技能消融只有在技能載入時才算消融；載入率為 0.251 時，多數情況其實是無技能組，而上文提到的遵循率則限制了即使技能載入時產物能帶來多少提升。兩種測量工具相互補足——Skill Lift 測量產物，載入率和遵循率測量使用端——單獨看都無法解讀
• Agent Context Files — 對照實驗，也是本文重要之處。Khatri 的兩代理程式受控消融發現，代理程式能完整讀取的 repository 中，自然形成的慣例與風格脈絡對正確性沒有明顯影響，僅在快取與經過時間上有持續效果；SkillEvaluator 則針對特定任務的專有產品脈絡，報告正確性提高 41 分。兩種產物類別恰好不同於該文開放問題所區分的類型——可推知與不可推知的脈絡——因此方向上可相互印證，但不能採用其數值大小；NVIDIA 的任務由技能生成，而 Khatri 的任務取自合併 PR，並使用隱藏的 gold-test oracle
• Agentic Work Systematization — 採用曲線；這是該曲線從未具備的效能測量。Codex telemetry 顯示，每週活躍使用者的技能使用率從 5.4% 升至 26.6%，而 53% 重複使用的技能從未修改；Skill Lift 是缺少的第二個軸。兩者合起來勾勒出真正的問題：採用率已經測量，品質如今也可測量，連接兩者的維護規範仍是缺口
• Agent Supply Chain Risk — 第 1 層與 SkillSpector 把供應鏈掃描延伸至技能產物：簽署描述、提示注入與外洩掃描、機密／PII 偵測、授權檢查、指令碼 lint，以及接入第三方安裝流程、約 1.4 秒完成的建議式掃描。2026-08 的 Zenity 活動是該文首個真實環境案例，也是本文的反事實案例——同一分發管道毫無掃描措施，酬載則放在單項技能掃描所檢查範圍之外的一層參照檔案中
• MCP Tool Poisoning — 本門檻所依據的下游偵測研究，以及正式陳述相同規避手法之處。 ShareLock 的門檻碎片化利用資訊理論上的隱密性擊敗單工具掃描；Zenity 活動則透過把載入器放在參照檔案中，不費力就取得較弱但類似的效果。這項區別關係到門檻能被要求完成什麼：前者無法掃描，後者只是尚未掃描；因此把第 1 層擴展到技能的傳遞參照閉包，是規格制定問題，而非研究問題
• Harness Build-vs-Buy — 自訂階梯第 3 階（技能與外掛）如今有了測量工具。階梯的主張是應在可行的最高層級進行自訂；Skill Lift 能在你往下走到第 4 階之前，讓你知道第 3 階是否有效
• LLM-Judge Validation — 尚未處理的依賴。五項 0–100 規準面向，卻沒有具名評分器、沒有一致性統計，也沒有偏誤稽核；每一項標題數字都繼承了該評審的可靠度
• Production-Sourced Evaluation — 相反的來源選擇，也是本文語料中最鮮明的對照。DRACO 的任務來自真實生產流量，且獨立於受評分系統；SkillEvaluator 的任務則由受評分產物生成。代表性與完美的主題對齊，失敗模式恰好互為映照
• Evals as Product Spec — 同一想法再往前一步：此處評估集由規格生成，因此規格本身的精確度決定測量精確度的上限；這是 NVIDIA 首項關鍵發現以設計限制形式表達的結果
• Compute-Controlled Benchmarking — 本文部分符合（固定快照 commit、明確列出嘗試次數、明確聲明不提供 CI）且部分未符合（未說明各組的成本或工作量預算，而且有技能組顯然使用了不同於無技能組的 Token 數）的揭露標準
• Evaluation Awareness & Grader Gaming — 此設計留下未解空間的相鄰失敗模式：當考題由受測產物生成時，高分可能代表產物設計出簡單考題，而第 3 層中沒有任何措施能區分這兩種情況
• Harness Shrinkage as Models Improve — 耐久性問題。提供專有 API 資訊的技能，應在模型進步時維持其提升；提供工作流程腳手架的技能，則應逐漸失效。benchmarks.json 持續重新執行，因此這是本文語料中少數能直接隨時間觀察效能衰減的地方
• Verification as the New Bottleneck — 把測量當成分發門檻，而非分發後的報告；技能登錄庫版的左移驗證
• AI-Native Organization — Tan 的對應關係將觸發評估視為技能檔案的績效考核，但觸發評估只檢查正確技能是否載入；Skill Lift 是考核的另一半——載入的技能是否改變結果——而同一技能在不同產品上的差距（+2 至 +46）正是組織比喻無法涵蓋的案例
• Agent Self-Poisoning (the CREATE-Path) — 在本來設計要測試的階段，以及該階段之後，檢驗發布前門檻。 第 1 層是在技能提交後、登錄目錄前，執行靜態安全與結構掃描。EvoMal（Wu、Shi et al.，Queen's University，arXiv 2608.25776，empirical）在這個准入階段，以四種主流偵測器檢查八項刻意植入、看似一般軟體工程輔助工具的技能：名稱封鎖清單偵測率為 0%，Llama-Guard-3-8B 為 25%；Prompt-Guard-86M 偵測所有種子，但在 232 項良性項目中誤報率達 47%——唯一能守住防線的偵測器，也會拒絕近半目錄內容。Bandit 透過單一 urllib.request.urlopen 特徵抓出八項技能，但只要換掉一行就能移除該特徵。對本文而言，深層問題在於結構，而非調整參數：一旦使用端的代理程式將新技能寫回同一儲存庫，推論 2 指出，提交端篩檢只能透過阻擋准入時的項目來減少感染，之後便毫無作用。發布門檻依然必要，但目錄同時成為寫入目標後，它便不再足以防範風險
• Write-Then-Trusted — 安裝時掃描所回應的失敗類型，以及其答案的限制。 市集清單在整體規模上屬於 RC2：信任決策依據安裝次數和趨勢排名做成，兩者都是單調且依據過去資料；身分背後的位元組內容之後仍可能遭替換。安裝時掃描是在最後仍能執行檢查的時點重新檢查——但也只檢查一次；重複採用後從未修改的技能占 53%，此後再檢查也觸及不到這群技能
• Harness Value Is a Product, Not a Score — Why the Artifact-Payoff Questions Keep Returning Partially Answered — 將本文指出的啟用項概括為端對端分數的完整乘積（啟用 × 遵循 × 產物品質 × 任務空間），並將 Skill Lift 歸入本文語料中的介入式測量工具——有技能／無技能兩組讓它具參考價值，也因此沒有任何觀察性代理指標能取代它

待解決的問題#

• 如果評估集不是技能作者生成的，Skill Lift 還能成立嗎？能區分兩種情況的實驗成本低，且 NVIDIA 完全有能力執行：根據產品文件獨立建立一組留存任務集，重新執行相同的第 3 層消融實驗，並同時發布兩組數字。如果提升消失，benchmarks.json 測量的就是技能與評估集的一致性，而非代理程式能力。
• 五個面向由誰或什麼評分？該評分器經過驗證了嗎？文章完全沒有說明評審模型，也未回報一致性統計；LLM-Judge Validation 的最小可行驗證流程才是標準。NVIDIA 只要將評分設定與 benchmarks.json 一併發布，便可驗證此事。
• 隨著模型進步，個別技能的提升會衰減嗎？目錄會持續以固定 commit 歷史重新評估；因此，只要在新一代模型上再做一次快照，就能顯示提供不可推知產品資訊的技能是否維持提升，而工作流程腳手架技能是否逐漸失效——這將是首個針對脈絡產物直接測量 Harness Shrinkage as Models Improve 的案例。觸發時機：後續 frontier model 發布時的 benchmarks.json 快照。

資料來源#

• Evaluating AI Agent Skill Performance with NVIDIA SkillEvaluator — Michelle Horton，NVIDIA Technical Blog，2026-08-20，約 1.8k 字。vendor-claim（編譯時指派；原始資料未標記）。所有數字均來自 NVIDIA/skills 中 commit 738d79e 的 2026-08-12 benchmarks.json 快照。取自 HTML 而非 PDF——不適用 _system/pdf-table-parsing.md；三份表格均為清楚的 Markdown，且彼此數字吻合（回報的 +31 和 +39 平均值與各面向的提升一致，兩個 harness 列的平均值也相符）
• 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（由廠商撰寫——Zenity 銷售代理程式安全產品，且文章預告一場有關代理程式引爆的 Black Hat USA 演講；OSV／Amazon Inspector 的佐證、commit SHA、封存畫面和公開雜湊值均視為事實；引爆結果來自廠商自有工具，而安裝計數器則由平台顯示，且明確指出不是不重複使用者數）。本文引用此來源說明 skills.sh 分發管道、顯示的安裝數字，以及「藏身漸進式探索」——逐項技能掃描無法觸及的參照檔案放置手法。完整分析見 Agent Supply Chain Risk
• 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。本文引用 §9.1 與表 5（在准入時及技能撰寫後評估植入種子的四種偵測器，以及在 232 項良性技能組合上的誤報率），並引用定理 1 與推論 2（說明提交端篩檢為何無法觸及代理程式自行撰寫的產物）。完整分析見 Agent Self-Poisoning (the CREATE-Path)