Skills are new features: Building Skill-Centric Harness — Yogendra Miraje, FactSet
三句話摘要
Anthropic skills 在 agentic products 中的應用架構與企業級 skill library 治理。 Skills 是 agentic products 的新特徵系統，工程師角色從交付特徵轉向交付 harnesses（平台），而企業級規模下 skill library 的治理——從路由信號的精心設計到訪問控制邊界的維護——是產品可靠性與可擴展性不可或缺的基礎。 Skills 是 agentic products 的新特徵。傳統產品以 UI 介面驅動，現代 products 將 agent 置於核心位置。此時特徵應該住在哪裡？答案是 skills——Prompts 定義 agent 是誰、Tools 定義它能連接什麼、Skills 定義如何完成任務。因此 skills 本質上取代了按鈕、下拉選單與表單，成為承載業務邏輯的容器。
重點整理
重點- 1
Skills 是 agentic products 的新特徵。傳統產品以 UI 介面驅動，現代 products 將 agent 置於核心位置。此時特徵應該住在哪裡？答案是 skills——Prompts 定義 agent 是誰、Tools 定義它能連接什麼、Skills 定義如何完成任務。因此 skills 本質上取代了按鈕、下拉選單與表單，成為承載業務邏輯的容器。
- 2
描述是路由信號，不是文檔。Agent 通過 skill name 與 description 判斷何時調用特定 skill。描述必須對齐真實用戶請求措辭（如在描述中寫明「僅當用戶要求 PDF 報告時使用」），而非技術實現細節。描述之間也要保持清晰差異化，否則 agent 會混淆。
- 3
模型升級後必須重新執行評估。Skills 不是靜態文檔，而是「與模型版本化的合約」。不同模型對 skill 指令的理解差異很大——實例中新模型過分關注指令開頭而忽視結尾的關鍵指令，導致原本正常的 skills 失效。未經評估驗證的 skills 只是一廂情願。
- 4
企業規模下需要五層治理：Admission（skill 應否存在或併入現有 skill）、Ownership（由對應業務團隊維護，類同 code owners）、Boundaries（工具訪問控制邊界）、Lifecycle（語義版本化、棄用警告、變更日誌）、Coherence（定期審計保持一致性）。治理無需成為紅帶瓶頸，而應通過自動化搭配人工介入實現。
實用技巧與重點
乾貨- Skill 結構與最小實現：
- Skill.md 包含 frontmatter（name、description）與 body（業務邏輯、檔案/腳本引用）
- 啟用 skills 的最少要求：skill registry + system prompt + file read tool
- 若需執行腳本則另加：Bash 或代碼沙箱環境
- 路由與發現機制：
- Progressive disclosure：system prompt 中僅放 name 和 description，agent 按需查看完整指令
- 描述中的觸發詞決定調用（例：描述提及「PDF」就成為路由信號）
- 組織原則：
- 按用戶意圖而非數據模型組織（例：用「earning preparation」而非「estimate analysis」、「pre-market briefing」而非「news + analysis」）
- 按實際使用場景迭代（從窄用例開始，隨發現逐步重構）
- 規模擴展與治理：
- 10+ skills：開始使用 shortlisting（embeddings similarity search 或小型模型過濾）
- 100+ skills：實施層級結構、元數據過濾、governance 框架
- Lifecycle：semantic versioning + deprecation warnings + changelog
- 評估策略：每次模型升級都必須重新執行 evals
- 企業治理五層面：
- Admission（自動門禁 + 人工審核，類同 PR review）
- Ownership（命名 skill owners，類同 code owners）
- Boundaries（工具白名單與訪問控制）
- Lifecycle（版本管理與棄用流程）
- Coherence（定期審計與驗證）
結論
結論“Skills 是 agentic products 的新特徵系統，工程師角色從交付特徵轉向交付 harnesses（平台），而企業級規模下 skill library 的治理——從路由信號的精心設計到訪問控制邊界的維護——是產品可靠性與可擴展性不可或缺的基礎。”
完整解析
詳細在過去一年，skills 的角色從講者去年介紹的「blueprints」演進至 Anthropic 開源並正式推出的完整功能。Blueprints 本質上是一套簡單步驟交給 agents，使其無需每次都重新探索路徑；而 skills 則是這一概念的標準化、生產級實現。既然 Anthropic 已開源 skills，FACTSET 決定完全採用而非維護自有標準，這也激發了講者構建「skill-centric agentic products」的思路。
在傳統產品中，使用者通過導航 UI 介面（屏幕、按鈕、表單、儀表板）與系統互動。但現代的 agentic products 正在翻轉這一模式——agent 成為產品的主要介面，代替使用者做決策。當 agent 成為核心時，一個自然的問題浮現：特徵應該住在哪裡？透過「誰、什麼、如何」的框架可以清晰回答：Prompts 定義 agent 是誰、Tools 定義它能連接什麼、Skills 定義如何完成任務。Skills 實質上是「一種標準化的教 AI agents 如何將特定任務做好的方法」，可以簡單如純 markdown，也可以複雜到包含多個檔案與可執行腳本的引用。
實現 skills 支持的門檻遠低於想像。最少只需三樣：skills registry（一個集合，包含每個 skill 的名稱、描述與路徑）、將 registry 整合進 system prompt、基礎的檔案讀取工具。如果 skills 需要執行腳本，就加上 Bash 或沙箱。Agent 通過「progressive disclosure」機制發現 skills——system prompt 中僅放入 name 和 description，當 agent 決定調用某個 skill 時，才會深入查看完整的業務邏輯指令。
實踐中最關鍵的洞察來自描述的作用。Skill 描述不是文檔，而是路由信號。以「報告 HTML」與「報告 PDF」兩個 skills 為例，儘管功能相似，但當描述中明確寫著「僅當用戶要求 PDF 報告時使用此 skill」時，「PDF」這個詞就成了觸發信號，引導 agent 選擇正確的 skill。這意味著描述必須對齐真實用戶請求的措辭，而非技術實現細節，且要保持足夠的區分度。另一個深刻的教訓來自模型升級的經歷。更新到新版本模型後，原本正常的 skills 突然失效，儘管 skill 代碼完全未改動。根本原因是新模型對指令的理解方式改變了——它過分關注 skill 的開頭，忽視了結尾的關鍵指令。這個事件揭示了一個根本真理：skills 不是靜態文檔，而是「與模型版本化的合約」。每次升級模型都必須重新執行評估（evals），沒有評估的 skills 不過是願景清單。
當 skills 數量增長時，簡單的 system prompt 方法會失效。超過 10 個 skills 時，應考慮 shortlisting 機制——例如基於 embeddings 的相似度搜索或用較小的模型過濾應添加到 prompt 中的 skills。達到數百個 skills 時，必須引入層級結構、元數據過濾與完整的治理框架。企業級 skill library 治理包含五個方面，每個回答一個核心問題：Admission 決定某個 skill 是否應該存在或應該併入現有 skill；Ownership 則由業務團隊維護，類同代碼中的 code owners 概念；Boundaries 通過工具白名單確保訪問控制邊界清晰；Lifecycle 則通過語義版本化、棄用警告與變更日誌管理 skill 的生命週期；Coherence 則通過定期審計確保整個 library 的一致性與搜尋能力。這些做法借鑑自數十年驗證過的代碼治理實踐，無需成為瓶頸，而是通過自動化搭配人工介入來平衡效率與質量。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
