Skill 就是新的 Feature：FactSet 怎麼打造以 Skill 為核心的 Agent 架構

如果 agent 變成產品的主要介面，那 feature 到底住在哪裡？這是 FactSet 首席 AI 工程師 Yogendra Miraje 在一場 AI Engineer 大會演講裡拋出的問題，也是這篇文章的主軸。FactSet 是一家金融資料與投資研究公司，equity research、wealth management 這些過去靠按鈕、下拉選單堆出來的工作流程，如今被他們重新蓋成一組一組的 Skill。Yogi 在演講中完整拆解了團隊怎麼把 Skill 支援加進自家 harness、怎麼設計 routing，以及當 skill 數量衝到上百個之後，靠什麼撐住整個系統不失控。

從自建的 Blueprints，到全面採用 Skills

Yogi 去年在同一場大會上分享的主題是「blueprints」——一組步驟或一份 recipe，讓 agent 不用每次都從零摸索路徑。回頭看，那其實就是 skill 的雛形，只是還很陽春，缺乏標準化的結構。去年 10 月 Anthropic 正式推出 Skills 標準（還半開玩笑地提醒大家「不要自己從頭建 agent」），FactSet 團隊評估後認為，既然業界標準已經 open source，沒有必要再維護自己的一套格式，於是直接放棄 blueprints，全面遷移到 skills 架構。這場演講，就是他在這趟遷移旅程裡踩過的坑與學到的教訓。

這場演講要談的，不是 coding agent 裡的 skill

Yogi 在現場做了一個小調查：先問有多少人做過 skill，幾乎全場舉手；接著請「只在 Claude Code、Codex 這類 coding agent 裡建過 skill」的人放下手；最後問「有沒有在自己的 harness 裡加過 skill 支援」，舉手的人明顯少了一大截。他點出這個落差的原因：現在網路上關於 skill 的討論，多半集中在 coding harness 場景——怎麼寫出一份好 skill、怎麼讓 coding agent 更有效率。這些內容都有價值，但他這場演講要談的是另一條線：skill 在面向一般使用者的 agentic product 裡扮演什麼角色，以及怎麼在自己的 harness 裡從零加上 skill 支援，並在 enterprise 規模下把它撐起來。

Who / What / How：Feature 住進了 Skill 裡

傳統產品介面是一個由畫面、按鈕、表單和 dashboard 組成的平面，使用者自己操作 UI 完成任務。但現在越來越多介面把 agent 推到最前面——使用者直接跟 agent 對話，或者 agent 在背後成為主要的決策者，帶著使用者導航整個產品。這個轉變帶出一個根本問題：如果 agent 成了產品的主要介面，feature 要住在哪裡？

Yogi 用一個簡單的框架回答：Prompt 定義 agent 是誰（who），tool 定義 agent 能連接什麼（what），skill 則告訴 agent 一個任務要怎麼完成（how）。Skill 正是放業務邏輯的好地方——它塑造 agent 的行為方式，決定 agent 面對特定工作流程時會怎麼行動。equity research、wealth management 這些過去用按鈕和畫面實作的金融業核心流程，現在都變成了 skill。

工程師的角色：從 shipping features 到 shipping harnesses

Yogi 認為 skill 最被低估的一點，是它讓任何對產品有深入理解的人都能建 skill——這些人不必是工程師，只要對業務流程夠熟悉，就能寫出有效的 skill。如果 skill 是新的 feature，而且任何人都能 ship 這些 feature，工程師的角色自然要跟著轉變：從 shipping features 轉移到 shipping harnesses。Harness 是讓 skill 能順暢運行的載具，工程師的價值在於讓這台載具穩定、快速、可擴充。

Skill 的核心：一份 skill.md

在深入 harness 實作之前，先回到定義。Skill 的字典意思是「把某件事做好的能力」——model 沒有 skill 也能運作，只是有了 skill 會做得更好。Yogi 給了更精確的說法：skill 是一種標準化的方式，用來教 AI agent 把特定任務做好。簡單的 skill 可以只是一份 markdown，複雜的 skill 則可能包含多個參考檔案和可執行的 script。

skill.md 是整份 skill 的核心。front matter 裡的 name 和 description 是 agent 發現、選擇 skill 的關鍵；業務邏輯與具體指令放在 body，body 裡也會參考外部檔案與 script。

最小可行的 Skill Registry

要在自己的 harness 裡加上 skill 支援，門檻其實比很多人想的低。最低限度只需要三樣東西：一個 skill registry、一個 system prompt、一個基本的 file read tool。如果 skill 需要跑 script，還會多一個 bash 或 code sandbox 環境，但這三項就是讓 skill 跑起來的底線。

Skill registry 就是一份 skill 的集合，每筆記錄包含 name、description、path，結構非常單純。Yogi 用三個範例 skill 示範這個結構：company research skill 負責對一家公司做基本 web search、產出 markdown；report HTML skill 把 markdown 轉成 HTML；report PDF skill 把同一份 markdown 轉成 PDF。三者組合起來，就是一條完整的研究報告產出 pipeline，agent 會依使用者的要求自動挑選並串接。

Progressive Disclosure：先給摘要，要用才讀全文

Agent 怎麼發現 skill？做法是把 registry 裡每個 skill 的 name、description、path 串接起來，放進 system prompt——注意，這裡只放摘要欄位，不會把 skill body 的內容全部灌進去，這就是 progressive disclosure 的概念。Agent 一開始只看到所有 skill 的摘要清單，只有決定要用某個 skill 時，才會透過 file read tool 去讀取那份 skill 的完整內容並遵循指令。好處是 system prompt 不會膨脹到失控，agent 在需要的時候仍能取得完整資訊。

接下來就是標準的 agentic loop：system prompt 載入後，所有訊息存進一個 messages array，每一輪都用 messages 和 agent tools 呼叫 model。如果 model 回傳 tool call，就把結果 append 回 messages、繼續下一輪；如果沒有 tool call，代表任務完成，輸出最終結果並結束。以 Yogi 的示範來說，當使用者要求「幫我做一份 NVDA 的報告」，agent 會先挑到 company research skill 做 web search，再用 build report skill 產出 HTML 報告——整個串接過程完全由 agent 自己決定。

Description 是 Routing Signal

Yogi 反覆強調一個觀點：description 是 routing signal。他舉了一個具體例子：他有 report HTML 和 report PDF 兩個 skill，但前面示範裡 agent 只用了 HTML 那個。原因在於 report PDF skill 的 description 寫著「只有使用者要求 PDF 報告時才用這個 skill」，「PDF」這個字就是觸發字（trigger word），幫助 agent 判斷該選哪個 skill。所以 description 必須對齊使用者的實際請求，而不是描述 skill 本身在做什麼；description 之間也要保持足夠的區別度，agent 才不會混淆；更不能讓 skill 的描述變得過時，因為過時的 description 正是 skill 不被觸發的常見原因。

他也點出 agentic product 場景與 coding agent 場景的一個關鍵差異：面向 agentic product 的 skill 大多是 model-driven 的。使用者是非技術人員，你不能期待他們記住所有 skill 名稱或手動觸發——那會增加不必要的認知負擔。Agent 必須自己根據使用者意圖選出正確的 skill，整個 routing 過程對使用者完全透明。這跟 coding agent 不同：在 coding agent 裡，使用者常常會自己指定要用哪個 skill；但在面向一般使用者的 agentic product 裡，選擇 skill 的責任完全落在 agent 身上。

用 User Intent 切 Skill，不要用 Data Model 切

另一個學到的教訓，是切分 skill 的方式要跟著使用者意圖走，而不是資料模型。Yogi 剛開始建 skill library 時，用的是很窄的資料維度，例如「estimation analysis skill」或「fundamentals skill」。但真實的使用案例進來之後，他發現使用者的需求並不對應資料模型的切法，只好多次重構 skill library——而這是正常且必要的過程。

• estimation analysis skill → 改成 earning preparation skill（財報準備技能）
• news and analyst rating skill → 改成 pre-market briefing skill（盤前簡報技能）

他的建議是：從簡單、窄小的使用案例開始，隨著發現更多真實場景再逐步重構，不需要一開始就切對。

沒有 Eval 的 Skill 只是許願

FactSet 團隊曾經換過一次底層 model，結果 agent 開始出錯、不再遵循 skill 的指令。skill 內容一行都沒改過，但它就是壞了。深入調查後發現，新 model 非常集中注意力在 skill 的開頭部分，而他們把關鍵指令放在 skill 的尾端，model 根本沒有好好讀到那些指令。什麼都沒動，只是換了 model 就壞掉——這正是 eval 為什麼重要。

Skills without evals are really just wishful thinking——沒有 eval 的 skill，就只是在許願。

很多人把 skill 當文件在寫，但 Yogi 認為 skill 應該被當成 contract 來對待，而且是跟特定 model 版本綁定的 contract。每次升級 model，都必須重跑 eval，確認 skill 在新 model 下的行為跟預期一致。

規模化的三個階段：個位數、十位數、上百個

只有幾個 skill 的時候，直接全部塞進 system prompt 是可行的，agent 看得過來。但 skill 數量一旦成長，超過大約 10 個 左右，這個做法就撐不住了——system prompt 塞太多摘要，model 的注意力會被稀釋，routing 準確度下降。這時候需要在把 skill 放進 system prompt 之前先做一輪篩選，做法可以是用 embeddings 加 similarity search 縮小範圍，或用一個較小的 model 先幫忙 shortlist 相關 skill，再把結果加進 system prompt。

當 skill 數量達到 上百個 的時候，問題的性質完全改變。你需要 skill 的階層結構、metadata filter，以及一套 governance 機制，才能讓 skill library 保持可搜尋、可維護。

Governance 的五個面向

Yogi 列出 skill library governance 的五個面向，聽起來很「enterprise」，但每一個都回答了一個核心問題。他強調 governance 不必變成繁瑣的官僚流程，關鍵在於實作方式——多少自動化，搭配多少恰當的 human in the loop。好消息是，很多軟體工程領域行之有效的管理實踐，已經運作了幾十年，可以直接借用到 skill 管理上。

• Admission（准入）：這個新 skill 應該獨立存在，還是併入既有的 skill？FactSet 的做法是為 registry 建立自動化的 git 流程，搭配 human in the loop 審核，類似 PR review。
• Ownership（擁有權）：誰維護這個 skill？就像 feature 由 application team 維護，skill 也需要具名的 skill owner，如同 code 裡的 code owners。
• Lifecycle（生命週期）：skill 隨時間怎麼變化？需要 semantic versioning，淘汰 skill 時要發 deprecation warning，變更要記錄在 changelog。
• Coherence（一致性）：skill 數量龐大時，整個 library 仍要合理——就像好產品的 feature 之間彼此 cohesive，需要定期做 audit 和 skill validation check。
• Boundaries（邊界）：skill 裡的工具權限。每個 skill 應該有 allow list，明確限制它能用哪些 tool——tool 本身就是 access control 的機制，這在 enterprise 環境下格外重要，確保 skill 不會越權碰到不該碰的資料或系統。

結語：Skill 就是產品介面

Yogi 用四個重點收尾這場演講：

1. Skill 就是 agentic product 裡的 feature——以前住在按鈕和畫面裡的東西，現在住在 skill 裡。
2. 工程師的角色正在轉變——從 shipping features 轉移到 shipping harnesses，工程師建造讓 skill 運行的基礎設施，skill 本身則可以由任何理解產品的人來寫。
3. Routing 機制隨規模改變的是機制本身，不只是調參——幾個 skill 全塞 system prompt 就夠；十幾個要靠 embeddings 篩選；上百個要有完整的 hierarchy 與 metadata filter。
4. Enterprise 規模下，skill library 的 governance 是非做不可的——跳過這一步，整個 skill 架構在規模化之後會失控；governance 是長期運作的基礎。