Harness 到底是什麼？！關於提升 AI 生產力的 Harness
Claude Code 洩密事件揭示的真相：模型效能差異不在智能，而在包裹模型的「外殼」？！
前言
去年 3 月 31 日，發生了一件令人難以置信的事。Anthropic 不小心將自家 AI 編碼工具 Claude Code 的完整原始碼公開到了 npm 上。51 萬 2 千行、1,906 個 TypeScript 檔案。在發現後幾小時內就被備份到 GitHub，被 fork 超過 41,500 次，至今仍在網路某處流傳。
Anthropic 解釋說「只是打包失誤」，但開發者社群卻因另一個原因沸騰了——洩漏的程式碼證實了長期以來僅以傳聞形式流傳的「AI 代理生產力差距的秘密」。（關於此議題，我也曾在 ZDnet 上撰寫過專欄。）
矽谷最大的創投加速器 Y Combinator 執行長 Garry Tan 親自閱讀了那 51 萬行程式碼後，寫下了這句話：
「秘密不在模型，而在包裹模型的那個東西。」
今天，我們就來聊聊這個 「那個東西」。同樣使用 Claude，為什麼有人生產力只提升 2 倍，有人卻能達到 100 倍。 其實最初我帶著懷疑開始挖掘的，因為我對「生產力提升幾倍」這種說法非常不信任。但這次確實有點道理。而且，這將如何顛覆企業未來的 AI 投資策略。
同一個模型，100 倍差距：差異在哪裡
擁有 40 年資歷的工程師 Steve Yegge 在最近的訪談中拋出了一個大膽的數字。熟練駕馭 AI 編碼代理的工程師，比使用一般聊天機器人的工程師生產力高出 10 倍到 100 倍，比 2005 年的 Google 員工大約高出 1,000 倍。
實務工作者一直懷疑這個數字有誇大成分。但 Yegge 明確指出了一點：「生產力 100 倍的人和生產力 2 倍的人，使用的模型是一樣的」。兩邊都在用 Claude Opus 4.6，兩邊都用同一個 API 金鑰。
差異不在「智能」，而在「結構」。而且這個結構簡單到可以寫在一張索引卡上。
這次 Claude Code 洩密事件為這個論點提供了實證數據。分析 51 萬行原始碼的開發者發現的，不是「更聰明的模型」，而是「更精巧設計的包裝層（wrapper）」。洩漏的程式碼中包含 44 個隱藏的功能旗標、三層結構的「自我修復記憶（Self-Healing Memory）」系統，以及名為「KAIROS」的自主代理守護程序模式。而 LLM 模型本身在程式碼中根本找不到。取而代之的是「在正確的時機、以無雜訊的方式，向模型傳遞正確上下文的精緻架構」。
業界將這稱為 Harness（harness）1，意為駕馭馬匹所用的馬具。
「薄 Harness，厚 Skill」：架構的顛覆
Garry Tan 提出的框架，從名字就很直觀——「薄的 Harness，厚的 Skill。」 這個理念與業界以往的作法完全相反。
傳統的**「厚 Harness」做法是這樣的：把 40 多個工具定義硬塞進系統提示詞，每次 MCP**2** 伺服器呼叫都要等 2 到 5 秒，把每個 REST API 端點都單獨包裝成一個工具。結果呢？token 用量 3 倍、延遲 3 倍、失敗率 3 倍。模型的上下文窗口有一半被工具說明佔據，真正用來解決問題的空間就沒了。**
而「薄 Harness，厚 Skill」的結構則是這樣的：
Skill（技能）3** 是以 Markdown 撰寫的可重用程序文件。它不是告訴模型「要做什麼」，而是「怎麼做」。Tan 舉的例子很精彩：有一個 /investigate 技能，由 7 個步驟組成，接收 TARGET、QUESTION、DATASET 三個參數。
- 放入一位安全研究者和 210 萬封郵件 → 它就變成醫療研究分析師
- 放入一家空殼公司和 FEC 選舉資金申報表 → 它就變成鑑識調查員 同一個 Markdown 檔案，同樣的 7 個步驟，只是輸入不同而已。Tan 將此形容為「以 Markdown 為程式語言、以人類判斷為執行時的軟體設計」。這不是提示詞工程。
Harness 是驅動 LLM 的薄層。以 Tan 的標準來看，大約 200 行。它只做四件事：讓模型循環運轉、讀寫檔案、管理上下文、設置安全機制。就這些。
最後一層是確定性（deterministic）工具。像是 SQL 查詢、編譯後的程式碼、算術運算這類「相同輸入永遠產生相同輸出」的任務。Tan 特別強調了這樣一段話：
「LLM 可以安排八個人坐在晚餐桌上，考慮性格和社交動態。但你讓它安排 800 個人，它就會幻覺出一張看起來合理但完全錯誤的座位表。」
組合優化是確定性問題。硬把它塞進潛空間（latent space）4會失敗。反過來，「兩位創辦人都在 AI 基礎設施領域，但並非競爭對手——一位專注於成本歸屬，另一位專注於編排」這樣的判斷，嵌入相似度搜尋絕對抓不到。「哪項任務放在哪一層」才是系統設計的核心。
總結起來就是：智能往上（Skill）、執行往下（確定性工具）、Harness 保持纖薄。這個結構最強大的特性在於：每次模型升級時，所有 Skill 都會自動變好，而底層的確定性層則始終穩定運轉。
為什麼這很重要：Anthropic 的「Skill」開放策略
洩密事件之所以令人震驚，不僅僅是因為原始碼被公開了，更因為 Anthropic 已經在推動將這個架構變成業界標準。
2025 年 10 月 16 日，Anthropic 公開了「Agent Skills」功能。兩個月後的 12 月 18 日，將其轉為開放標準。這與將 MCP（Model Context Protocol）打造為業界標準的劇本如出一轍。只需要一個 SKILL.md Markdown 檔案和 YAML 金資料，就能為 AI 代理注入領域專業知識。Microsoft、OpenAI、Cursor、GitHub、Atlassian、Figma 等公司已經採用這個標準。
這裡的關鍵設計原則是漸進式揭露（Progressive Disclosure）5。啟動時，只有 Skill 的名稱和描述被載入系統提示詞（50~100 token）。當模型判斷「需要這個 Skill」時，才讀取完整的 SKILL.md，而其中引用的輔助檔案則在需要時才載入。就像把上下文窗口當作圖書館——以索引方式檢索，但只有在需要時才翻開書頁。
Tan 分享的一個故事完美詮釋了這個原則的核心。他曾經把 Claude Code 的設定檔 CLAUDE.md 寫到 2 萬行，想把自己經歷過的所有模式和教訓都包含進去。結果呢？模型的注意力急劇下降。Claude Code 自己說「請把它縮短」。解決方案是一份約 200 行的「指標文件」（pointer document）。2 萬行的知識原封不動，但改為由解析器（resolver）在需要時才載入。
這個模式類似硬體業界所說的「分層快取」設計。L1、L2、L3 快取，常用資料放在近處，少用資料放在遠處。AI 代理也用同樣的原理設計「知識的記憶體層級」。
奧茲的視角
這個框架真正的爆發力，在於它顛覆了企業內部知識資產的結構。過去幾十年，企業管理知識資產的方式有兩種：一種是文件（如 Confluence、Notion 等），另一種是程式碼（如 ERP、CRM、內部工具等）。兩者都有侷限。文件需要人來讀才能發揮作用，程式碼則缺乏彈性且維護成本高昂。而兩者之間模糊地帶（例如「業務團隊的報價流程」、「法務團隊的合約審查標準」、「行銷團隊的品牌指南」）一直只存在於人的腦海中。
Skill 檔案是將這個「模糊地帶」資產化的新方法。用一張 Markdown 寫下程序、判斷標準和範例，它就成為可重用的組織能力。Canva、Stripe、Notion、Zapier 等 SaaS 公司已經開始以 SKILL.md 的形式公開自家服務的操作方式，原因就在這裡。這與 API 文件截然不同。API 告訴你「怎麼呼叫」，而 Skill 告訴你「何時、以什麼順序、經過什麼判斷來呼叫」。
我在這個趨勢中最關注的是 Tan 的這句話：「Skill 是永久升級」。傳統軟體越用技術債（tech debt）6越多。但 Skill 恰恰相反。一次寫好的 Skill，每當新模型推出就會自動變好。判斷部分隨模型升級而提升，確定性部分則保持穩定。「一次建立，永久運轉」。
不過有一個點我想冷靜地指出。根據 Snyk 2026 年 2 月發布的報告，經過公開稽核的 Skill 中有 36.82% 存在安全漏洞。惡意的 Skill 可能導致資料外洩、未經授權的系統存取等風險。Skill 應該被當作「程式碼」而非「文字」來對待。版本管理、指定負責人、定期審查……這些是企業導入 Skill 時無法迴避的成本。
「AI 時代的新資產不是模型，而是 Skill 庫」這個命題，聽起來很浪漫，但目前仍是一個「必須妥善管理才能成立的假設」。最先建立這個假設的組織，將成為下一輪生產力差距的受益者。
結語
我對「生產力 100 倍」「爆發性成長」這類說法，通常會先持懷疑態度。原因很簡單：要說 X 倍，就必須有基準數字，如果沒有，我們怎麼能相信那個成長呢？1 人變 3 人說 3 倍，和 100 人變 300 人說 3 倍，分量顯然不同。本期電子報就是從這種疑惑出發的——用 Harness 就能讓生產力提升 100 倍？真的嗎？也許新名詞會不斷出現：提示詞工程、上下文工程、Harness 工程……別太緊張。與其追趕名詞，不如清楚地理解它們背後的運作原理。
第一，AI 生產力差距的本質不在模型，而在架構。Claude Code 洩密事件展示的，不是「更聰明的大腦」，而是「更精巧的結構」。
第二，「薄 Harness，厚 Skill」是軟體設計哲學的轉向。智能用 Markdown 放在上層，執行用程式碼放在下層，編排保持纖薄。這個原則已經被 Anthropic、Microsoft、OpenAI、Cursor 採用為業界標準。
第三，企業的競爭力正在從「使用多好的模型」轉向「擁有多深厚的 Skill 庫」。 但這個資產化過程也伴隨著安全與治理的課題。
如果你讀到這裡，腦中浮現了「我們組織目前的 AI 導入策略偏向哪一邊？」這個問題，那這個問題本身就是本期電子報的價值。與其花時間研究模型比較規格表，不如花時間找出團隊內部重複工作中「用一張 Markdown 整理就能成為永久資產」的事項，這個時間點更有意義。
如果反應好的話，下一期電子報我會聊聊這個結構的另一面，也就是「擁有 Skill 架構的組織，為什麼能撼動傳統大型企業」。所謂反應好，就是留言多、分享多！快把這份電子報分享給朋友，推薦他們訂閱吧！
參考資料 & 延伸閱讀
核心來源
- Garry Tan, “Thin Harness, Fat Skills”, gbrain GitHub repository, 2026. : 本期電子報框架的原始文件。「厚 Skill、薄 Harness」三層架構被壓縮在一張索引卡上。
- Anthropic, “Equipping agents for the real world with Agent Skills”, Anthropic Engineering Blog, 2025.12. : 詳細說明 SKILL.md 標準和漸進式揭露設計原則。想親手建立 Skill 的話，建議先讀這份文件。
- Steve Yegge, “The AI Vampire”, Medium, 2026.02. : 分析 10 倍/100 倍生產力的真相，以及背後的「吸血鬼效應」（無法持續超過 3 小時）。
- Gergely Orosz, “Steve Yegge on AI Agents and the Future of Software Engineering”, The Pragmatic Engineer, 2026.02. — 包含 Yegge 的「8 階段 AI 採用模型」，以及為什麼大型企業在結構上無法吸收這種生產力的洞察。
背景知識
- VentureBeat, “Claude Code’s source code appears to have leaked: here’s what we know”, 2026.03.31. : 關於洩密事件技術細節的分析，涵蓋公開的「Self-Healing Memory」和「KAIROS」設計。
- Zscaler ThreatLabz, “Anthropic Claude Code Leak”, 2026.04. : 整理洩密事件時間軸和安全風險（特別是與 Axios 供應鏈攻擊的結合）的報告。
- Snyk, “Agent Skills Security Audit Report”, 2026.02. (新聞引用基準) : 公開 Skill 中 36.82% 發現安全漏洞的依據資料。正在考慮 Skill 資產化的組織值得參考。
각주
-
Harness：驅動 LLM 的框架。負責讓模型循環運轉、讀寫檔案、管理上下文和設置安全機制。名稱源自駕馭馬匹所用的馬具。 ↩
-
MCP（Model Context Protocol）：Anthropic 於 2024 年公開的開放標準，標準化了 AI 代理與外部工具和資料來源的連接方式。與 Agent Skills 互為補充。MCP 負責「連接」，Skills 負責「使用方式」。 ↩
-
Skill 檔案（SKILL.md）：以 Markdown 撰寫的可重用程序文件。不是告訴模型「做什麼」，而是「怎麼做」。由 YAML 金資料和 Markdown 正文組成。 ↩
-
潛空間（Latent space）vs 確定性（Deterministic）：潛空間是 AI 進行判斷和解釋的領域，相同輸入每次可能產生不同輸出。確定性領域則像 SQL 查詢或算術運算，相同輸入永遠產生相同輸出。系統設計的核心在於「哪項任務放在哪一層」。 ↩
-
漸進式揭露（Progressive Disclosure）：不一次性載入所有資訊，而是在需要的時候只取出需要的部分。對 AI 代理而言，先只載入 Skill 的名稱/描述，實際內容在需要時才載入。這是高效利用上下文窗口的核心技巧。 ↩
-
技術債（Tech debt）：為了短期便利而選擇捷徑的程式碼或設計，長期累積後產生的成本。導致後續修改或擴展變得困難的狀態。 ↩
