---
title: "Skill 就是新的 Feature：FactSet 怎麼打造以 Skill 為核心的 Agent 架構"
description: "金融資料公司 FactSet 的首席 AI 工程師 Yogendra Miraje 分享團隊從自建 blueprints 全面遷移到 Anthropic Skills 標準的過程：Skill Registry 怎麼設計、Description 如何當 routing signal、規模化到上百個 skill 時要靠哪五個治理面向撐住。"
author: "莊哲昀（AJ）"
tag: "AI Agent 與自動化"
date: 2026-08-04
canonical: https://www.ahadigit.work/blog/factset-skill-centric-agent-harness
source: "blocks"
---

# 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 是長期運作的基礎。

> **重點回顧**
>
> Skill 是新的 feature，取代傳統按鈕、表單和畫面；Prompt 是 who、tool 是 what、skill 是 how；skill.md 的 name 與 description 決定 agent 找不找得到它；progressive disclosure 讓 system prompt 只放摘要，用到才讀全文；description 是 routing signal，trigger word 決定 agent 選哪個 skill；用 user intent 切 skill，不要用 data model 切；沒有 eval 的 skill 就是許願，skill 是跟特定 model 版本綁定的 contract；超過十個 skill 要靠 embeddings 或小 model 篩選；超過一百個 skill 要靠 admission、ownership、boundaries、lifecycle、coherence 五面向的 governance 撐住。

## 資料來源

- [Skills are new features: Building Skill-Centric Harness（YouTube，Yogendra Miraje / FactSet）](https://youtu.be/7jjudsEhBtM?si=DQyZmhJiiVPGHJyR)