多 SKILL 的 AI Agent 用久之後，我越來越確定一件事：真正麻煩的通常不是 Agent 不會做，而是它太容易「什麼都想做一點」。

你只是請它修一個前端 bug，它可能想同時讀前端、UI、瀏覽器、Playwright、QA、設計系統、GitHub、部署文件。每一個都看起來相關，但不是每一個都應該在第一分鐘就被載入。

所以我做了一個 SKILL，專門用來控管 SKILL。

它叫 Workflow Skill Router。

我也把它開源了：

這篇不是要介紹網站，也不是 release note。這篇想講的是：Workflow Skill Router 這個 SKILL 到底在做什麼，以及為什麼我實際用了一段時間後，覺得它非常值得被整理成開源專案。

先說 Agent sprawl：我處理的是其中一層

這段時間很多人開始討論 Agent sprawl。

不同廠商的定義有一點差異，但核心意思很接近：AI agents 在缺少集中盤點、擁有者、權限邊界與治理規則時，不斷被不同團隊或不同工作流建立出來，最後變成一堆重複、難追蹤、難稽核、也難控成本的自動化單位。 Okta 把它描述成缺少 centralized tracking、inventory、governance 的 uncontrolled proliferation； IBM 也把問題指向缺少 unified strategy 與 strong governance； Gartner 在 2026 年 4 月 28 日的說法 裡，也把 centralized agent inventory 放在管理 AI agent sprawl 的前段步驟。

這些討論多半站在治理層：這個 Agent 是誰？被誰擁有？可以讀哪些檔案？可以碰哪些憑證？哪些工具需要人工核准？

Workflow Skill Router 不是在回答這些問題。

更精準地說，它不是 permission boundary，也不是 agent registry。它不決定 Agent 被允許讀哪些檔案、拿哪些 token、呼叫哪些外部系統。那些應該由 scope、permission、approval policy 或平台層控管。

Workflow Skill Router 回答的是下一層問題：

在已存在、已允許的 SKILL 裡，這次任務到底該啟用哪幾個？

也就是說，我處理的是 Agent sprawl 裡的一個很實際、很貼近日常開發的分支：skill selection sprawl。

Agent 不一定真的變多，但它手上的 SKILL、工具、connector、工作流越來越多。最後每個任務都像在召喚整個工具箱：修前端 bug 時順手載入設計系統、QA、部署、文件、GitHub；改 API 時把資料庫、前端 client、release review 全部揉在一起。短期看起來很方便，長期就會變成上下文噪音、錯誤路由、重複工作流與驗證責任不清。

Workflow Skill Router 解決的正是這個層級的問題。

你可以把它放在這個位置：

Scope / permission layer
= 這個 Agent 被允許做什麼
  ↓
Workflow Skill Router
= 在已允許的 skills 裡，這次任務該啟用哪些
  ↓
實際執行 skills / tools / connectors
= 開始做事

它不取代上層治理，但能補上治理之後很常被忽略的一步：available 不代表 active；被允許存在的 SKILL，不代表這次任務就應該啟用。

它解決的不是能力問題，是啟動順序問題

AI Agent 有很多 SKILL，本來是一件好事。

後端設計可以有 API SKILL，前端可以有 Vue SKILL，除錯可以有 systematic debugging，瀏覽器驗證可以有 Playwright，文件可以有 documentation，部署可以有 DevOps。每個 SKILL 都能讓 Agent 在特定情境下變得更可靠。

但 SKILL 一多，另一個問題就出現了：

這個任務到底該由誰主導？
哪些 SKILL 只是相關，但現在不該載入？
規劃、實作、除錯、驗證，需要使用同一組 SKILL 嗎？

Workflow Skill Router 的定位就是這裡。

它不是讓 Agent 變得「更萬能」的 super skill，而是一個開工前的 routing layer。它先幫 Agent 判斷任務，再選出最小但足夠的 SKILL 組合。

核心模型很簡單：

任務性質
  -> 工作階段
    -> 技術領域
      -> 1 個 Primary SKILL + 最多 3 個 Supporting SKILL

Primary SKILL 負責主軸，Supporting SKILL 只補足必要的領域、驗證或工具。這個限制很重要，因為它會逼 Agent 在開工前先做取捨，而不是把所有相關內容都塞進 context。

講白一點，這個 SKILL 的核心價值不是「多叫幾個技能來幫忙」，而是阻止 Agent 亂叫技能來湊熱鬧。

它怎麼降低 skill selection sprawl

Workflow Skill Router 不是把 Agent 變少，也不是替 Agent 加上一整套權限系統。它做的是讓 Agent 的能力使用方式變得可控。

我把它想成五個小閘門：

  1. 先盤點，再啟用：skill-tree.md 讓可用 SKILL 不再只是散落的清單，而是依任務性質、工作階段與技術領域整理成路由表。
  2. 把 available 和 active 分開：環境裡有某個 SKILL，不代表這次任務要用它；Router 只挑當下需要啟用的最小組合。
  3. 一次只選一個主責 SKILL：Primary SKILL 讓任務有清楚 owner，避免每個 SKILL 都覺得自己該主導。
  4. Supporting SKILL 要說得出理由：最多 3 個 supporting skills，而且每個都要能說明它降低哪一種風險。
  5. 先輸出 route，再開始動手：routing contract 讓使用者可以在 Agent 讀檔、改碼、跑工具之前，先檢查方向有沒有跑偏。

這幾個限制看起來很小，但剛好對應 skill selection sprawl 最常見的症狀：SKILL 清單很平、主責不清、邊界模糊、決策不可追蹤。

換句話說，Workflow Skill Router 不是要取代大型治理平台；它比較像是把治理概念縮小到每一次任務開工前。先讓單次工作流不失控，後面才談得上把更多 agents、tools、connectors 管起來。

我想要的是「可被檢查的路由契約」

Workflow Skill Router 最有用的地方，是它會讓 Agent 在真正動手前先輸出一段 routing contract。

像這樣：

Route: Frontend / Debugging > Browser reproduction > Single-page app
Use SKILL: vue-expert, systematic-debugging, playwright
Reason: vue-expert 處理 component 行為；systematic-debugging 維持因果式排查；playwright 固化回歸驗證。

這段看起來很短，但它改變了整個工作流。

以前 Agent 可能直接開始讀檔、改檔、跑測試。你要等它做了一段時間，才發現它一開始就選錯角度。

有 routing contract 之後，工作會先停在一個可以檢查的點：

  • 這次任務的分類對不對？
  • Primary SKILL 選得合理嗎？
  • Supporting SKILL 是真的降低風險，還是只是看起來相關？
  • 這個任務是不是應該拆成多個階段？

這對多 SKILL Agent 很關鍵，因為 Agent 的第一個判斷常常會決定後面整段工作的方向。Workflow Skill Router 把這個判斷拉到檯面上，讓它可以被修正。

它不是 prompt collection，也不是固定 SOP

我一開始做這個 SKILL 時，很刻意避免把它做成一包 prompt collection。

因為 prompt collection 很容易變成「有一堆招式，但不知道什麼時候該出哪招」。

Workflow Skill Router 做的是另一件事：它先建立一個決策入口，再把不同 SKILL 放到對的位置。

它主要由幾個部分組成：

  • SKILL.md：定義這個 router 何時啟用、如何輸出 route、一次最多選幾個 SKILL。
  • skill-tree.md：把任務依照性質、階段、技術領域整理成可查的路由表。
  • routing-rules.md：處理 SKILL 重疊、優先順序、connector 類工作、過度觸發等規則。
  • 範例 routes：示範不同任務如何選 Primary SKILL 與 Supporting SKILL。
  • Validator：檢查 router package 是否符合基本結構與公開分享需求。

真正重要的是前面三個：入口、路由表、衝突規則。

這讓它不是單純「記住很多技能」，而是讓 Agent 在每次工作開始前先回答：

這次應該由哪個 SKILL 主導？哪些 SKILL 只需要在旁邊支援？

這個問題問對了，多 SKILL Agent 的品質就會差很多。

我實際用下來，最明顯的效果

我把 Workflow Skill Router 放進自己的日常 AI Agent 工作流後，連續用了三週左右。最有感的不是速度變快，而是工作變穩。

1. Agent 比較少一開始就跑偏

以前複雜任務很容易出現「一開始方向錯，後面越做越認真」的狀況。

Router 會先要求 Agent 分類任務，再選 SKILL。這個小動作讓我可以在它讀檔或改檔前，就先看到它打算用什麼工作流。

如果它把一個文件任務路由成前端任務，我可以立刻修正。 如果它把一個除錯任務路由成重構任務，我也可以立刻叫停。

這比等它做完再 review 省太多力氣。

2. SKILL 的上下文噪音變少

多 SKILL 最大的副作用，是 context 裡會混進太多「也許用得到」的資訊。

Workflow Skill Router 強制一次只選 1 個 Primary SKILL，最多再加 3 個 Supporting SKILL。這個限制讓 Agent 必須說清楚每個 SKILL 的理由。

沒有理由，就不要載入。

這對實作任務尤其有感。Agent 不會因為看到 UI 就順手拉設計系統，不會因為看到測試就把整套 QA 流程搬進來，也不會因為提到 GitHub 就立刻切到 PR 工作流。

3. 工作階段變得更清楚

同一個任務在不同階段，其實不該用同一組 SKILL。

例如 API 合約同步：

  • 設計階段需要 API 設計與合約規劃。
  • 實作階段需要後端與型別產生。
  • 驗證階段需要測試與回歸檢查。
  • 發布前才需要 release 或 CI 類 SKILL。

Workflow Skill Router 會讓 Agent 先講清楚目前是在規劃、實作、除錯、驗證，還是 release review。這讓我更容易把大任務拆成幾個可控階段，而不是讓 Agent 一次吞下整包工作。

4. 我自己的工作習慣變成可以重複使用的規則

這是我後來最喜歡的一點。

很多 AI Agent 使用經驗，本來只存在腦袋裡：什麼情境要先查文件、什麼時候要先用瀏覽器重現、什麼時候不能急著改碼、什麼時候要把驗證 SKILL 放進來。

Workflow Skill Router 把這些習慣寫成 routing rules。

它不只是給 Agent 用，也是在整理自己的工程判斷。當這些判斷變成可讀、可改、可驗證的文字，整個 AI 協作流程就不再只是「今天手感不錯」。

一個實際路由範例

假設使用者提出這個任務：

新增 customer settings endpoint，更新 OpenAPI，並讓前端 client 跟上新合約。

沒有 router 時，Agent 可能會把後端、前端、OpenAPI、測試、文件、GitHub 全部混在一起。

有 Workflow Skill Router 時，它應該先輸出類似這樣的 route：

Route: API / Contract lifecycle > Backend-to-frontend sync
Use SKILL: api-designer, openapi-contract-generation-skill, openapi-to-typescript, qa-test-planner
Reason: api-designer 穩定 endpoint 設計；openapi-contract-generation-skill 管理 schema diff 與 contract generation；openapi-to-typescript 更新 client types；qa-test-planner 定義合約測試覆蓋。

這裡的重點不是這幾個 SKILL 名字一定要跟你一樣，而是它的思考順序：

  1. 先判斷這是 API 合約同步，不只是後端新增 endpoint。
  2. Primary SKILL 應該負責主要設計方向。
  3. Supporting SKILL 只補足合約產生、前端型別同步與測試覆蓋。
  4. 如果任務變大，就拆階段，而不是繼續塞更多 SKILL。

這就是我說的「用 SKILL 管理 SKILL」。

不是讓 Agent 背更多規則，而是讓它在使用規則前先選對規則。

為什麼我把它開源

我一開始做 Workflow Skill Router，是為了解決自己在多 SKILL Agent 上的實際痛點。

但用了一段時間後，我發現這不是只有某個專案會遇到的問題。只要你開始認真建立 AI Agent SKILL，或把不同工具、connector、工作流整合進 Agent，就一定會碰到同一件事：

SKILL 越多，越需要一個控管 SKILL 的入口。

所以我把這個 pattern 整理成開源專案。

我希望它不是一份只能照抄的個人配置，而是一個可以被 fork、改寫、驗證、放進自己專案的基礎範本。

你可以只拿 starter，建立自己的 skill tree。 也可以參考範例 catalog，調整成自己的工作場景。 如果你要公開分享自己的 router package，也可以用 validator 檢查結構與基本安全性。

重點不是使用我的 SKILL 清單。重點是：把你的工作流判斷，變成 Agent 每次開工前都會執行的路由規則。

適合誰使用

如果你還只有一兩個 SKILL，Workflow Skill Router 可能不是最急迫的工具。

但如果你已經遇到下面幾種狀況，它就會很有感：

  • 你有很多 AI Agent SKILL，但 Agent 常常一次載入太多。
  • 你希望 Agent 在動手前先說明工作路線。
  • 你想把專案習慣、技術棧、驗證規則整理成可重複流程。
  • 你常做跨領域任務，例如 API 到前端、文件到部署、PR review 到 CI 修復。
  • 你想打造自己的 AI Agent 工作流，而不是每次靠臨場 prompt 控制。

它特別適合已經開始把 AI Agent 當成工程協作者的人。

當 Agent 只是回答問題時，你可能不需要 router。 但當 Agent 會讀檔、改碼、跑測試、整理文件、處理 PR、檢查部署風險時，你就會希望它每次開工前先選對工作模式。

更白話地說：如果你已經開始看到 Agent sprawl 的早期症狀，不一定要等到企業裡真的長出幾百個 agents 才處理。很多時候，第一個能落地的治理點，就是你手上這個每天都在開工、切技能、跑工具的 Agent。

專案裡目前提供了什麼

Workflow Skill Router 目前開源的內容，主要是為了讓你可以快速複製這個 pattern：

  • Codex-ready starter skill。
  • 可改成自己使用情境的 routing references。
  • public-safe 的 template skill catalog。
  • 多種常見工程場景的 route 範例。
  • 用來檢查 router package 的 validator。
  • 中英文文件與使用說明。

文件入口只是讓大家比較容易閱讀與導入；真正的核心仍然是 repo 裡那個可以被放進 Agent skill 目錄的 Workflow Skill Router SKILL。

如果你也在打造多 SKILL 的 AI Agent，或剛好覺得 Agent 常常「太熱心、太容易把事情做大」，建議先從 Quickstart 開始，照著 starter 建立自己的 router：

如果這個 pattern 對你有幫助，也歡迎幫這個開源專案點一顆 Star。 這會讓更多正在實作 AI Agent 工作流的人看到它，也讓我更有動力把後續範例、文件與工具補得更完整。

延伸閱讀