Article

Workflow Skill Router V2 正式版：把 SKILL 路由變成可驗證的 Codex 控制層

Workflow Skill Router V2 把原本寫在 SKILL.md 裡的路由習慣，整理成會先驗證能力、再選擇路徑的 Codex 控制層；開發者仍可用 Personal 與 Workspace Profile 管理自己的 Skill Tree。

2026-07-23 4909 字預計閱讀 10 分鐘點閱 70

標籤：

系列：

開源專案 AI Agent 實戰

快速導覽查看本文目錄

多 SKILL 的 AI Agent 用久後，我真正常遇到的狀況是：它太勤快，什麼都想插一腳。

你只是要修一個 Vue bug，它卻想同時載入前端、UI、瀏覽器、Playwright、QA、GitHub 和部署文件。這些能力各自都有用，但不代表一開始就該全部塞進 Context。那種「反正先帶著」的習慣，久了只會讓任務越做越胖。

我在前一篇 Workflow Skill Router 處理的，就是這件事：工作一開始，先選一個 Primary SKILL，再補上真的少不了的 Supporting SKILL。方向沒錯；但我實際用了一陣子後才發現，只靠一份 SKILL.md 要模型「記得遵守」，還是有極限。多輪同意要怎麼保存？Runtime 現在到底有沒有那個能力？大型 Goal 中斷後怎麼接回來？這些都不能只靠文字規則撐著。

這也是我做 Workflow Skill Router V2 的原因。2026 年 7 月 23 日發布的 v2.0.1 ，把路由從一份建議清單，拉到 Codex 執行前真正會面對的 Runtime：先選最小而且能驗證的路徑，使用者指定的 SKILL 不會被偷換，做不到的事也直接講明白。

範圍也要先講清楚。它不碰 Host 權限、人工核准、sandboxing 或 production orchestration；它專心處理一個常被忽略、卻很容易拖慢 Agent 的問題：Skill selection sprawl。

V1 管規則，V2 讓規則有狀態

V1 比較像熟悉團隊習慣的資深同事：收到任務，先看 Skill Tree，再按 routing rule 建議該用哪些 SKILL。

V2 多了 Router Core、Codex Plugin、MCP Server 和可單獨安裝的 Skill-only package。SKILL.md 繼續負責把路由原則講清楚；保存 proposal、比對狀態、驗證能力、回報結果這些容易失憶的工作，交給 deterministic Runtime。

V1	V2 正式版
靜態 Skill Tree 與 route templates	Runtime Capability Discovery 與 typed routing contract
一次任務套用一條 route	`single`、`phased`、`managed-goal` 三種工作形狀
多輪同意主要靠文字規則	先持久化 proposal，再由 state machine 轉換
看到 SKILL 資料夾就推測可用	分開檢查安裝、Host exposure、驗證、政策、freshness 與風險
關掉對話後要重新推理	Plugin 模式可保存本機 R0 plan、consent 與 status
Profile 像一張靜態清單	Profile 是「意圖」，仍由 Runtime 決定能否實際路由

%%{init: { 'theme': 'base', 'themeVariables': { 'primaryColor': '#10b981', 'secondaryColor': '#3b82f6', 'lineColor': '#6b7280' }}}%%
flowchart LR
    User["開發者需求"] --> Host["Codex Host"]
    Host --> Skill["Router SKILL"]
    Host --> Plugin["Router Plugin"]
    Plugin --> MCP["MCP Server"]
    MCP --> Core["Deterministic Router Core"]
    Core --> Local["Local R0 State"]
    Core --> Verified["Verified Host Adapters"]
    Core --> Eval["Configured Evaluation Adapter"]

講白一點，V1 是好用的工作守則。V2 則讓守則有地方保存、有辦法驗證，能力不夠時也會老實回覆：「這件事現在不能保證做到。」

不是所有任務都該進 Goal 模式

我不想把 Router 做成另一種「只要做事就先開大型流程」的工具。先判斷任務長什麼樣子，再決定路由要多細，這件事反而比較重要。

工作形狀	適合的任務	Router 的做法
`single`	修一個明確 bug、補一段文件、檢查單一 API	選一個最小的 Primary SKILL，避免過度工程化
`phased`	規劃 → 實作 → 測試 → 文件或 PR	每個 Phase 重新選擇當前需要的能力，不預先載入未來技能
`managed-goal`	跨 Repository、存在相依關係、可中斷並需恢復的大型目標	維護可恢復的工作圖，尊重 Host 擁有的 Goal 狀態

像「修正登入頁按鈕樣式」，不用因為工具箱裡有 GitHub、QA、部署 SKILL，就硬塞進 Goal 流程。相反地，若要重新設計 API、調整資料庫、補測試、更新文件並準備發布，拆成階段才比較合理；每到一個真正的決策點，再重新路由。

差別看起來不大，實際上很影響 Context。Router 不需要找出所有可能沾得到邊的 SKILL，它只要找出：

目前 Phase 的 Primary SKILL
+
目前 Phase 完成前不可缺少的 Supporting SKILL

還沒輪到的能力，就先不要來佔位子。

使用者指定 SKILL 時，Router 必須退一步

這是 V2 裡我最不願意妥協的一點。

當使用者明確說：

只使用 security-review SKILL 檢查這個專案。

Router 會建立 Explicit Skill Lock。你指定的 SKILL 就是這次請求的主導選擇；Router 不能偷偷改成別的 Primary，也不能自動加進一串 Supporting SKILL。

如果它判斷真的需要額外能力，必須先提出 scoped consent，清楚說明：

為什麼需要這個 Supporting SKILL。
它只處理哪一段範圍。
拒絕後會少掉什麼驗證或能力。
會增加多少 Context 與工具暴露。

同意才加入；拒絕就照原本指定的路線走。反過來，使用者沒有指定 SKILL 時，Router 直接選最小充分路由，不必每件小事都跳出來問「要不要再加一個輔助 SKILL？」。

執行前要說明預計用哪些 SKILL，結束後也要回報實際用了哪些、和原計畫有沒有差異。這樣人才能看得懂 Agent 到底做了什麼。

V2 的精髓：你仍然可以定義自己的 Skill Tree

我沒有打算把 V1 最有價值的部分收進 Router 的黑箱。Skill Tree 還是使用者的資料與決策。

V2 只是把它整理成可驗證的 Routing Profile。你可以放自己的工作習慣，也可以在 Repository 裡放團隊一起遵守的路由規則。

flowchart TD
    A["System / Host hard constraints"] --> B["使用者當次明確指定 SKILL"]
    B --> C["Workspace Profile"]
    C --> D["Personal Routing Profile"]
    D --> E["Built-in routing"]

優先序就是由上往下看。專案規則可以覆寫個人偏好，但這次請求中明確指定的 SKILL 仍然優先；系統安全與 Host 限制永遠排在最上面。

Workspace Profile 和 Personal Profile 同時命中時，Router 會採用完整的 Workspace Skill Tree，不會把兩棵樹偷偷 deep merge 成一條誰都沒定義過的路由。我刻意保守一點，因為團隊流程若會隨每個人的本機偏好改變，之後幾乎沒辦法重現。

三步驟，建立自己的工作流

1. 先選擇規則放在哪裡

Personal Routing Profile：放長期習慣，例如 API 先做 contract，再實作、測試。
Workspace Profile：放在專案的 .codex/workflow-skill-router.json，例如這個 Repository 的變更要先跑架構檢查，再進入實作與驗證。

Personal Profile 適合「我怎麼工作」；Workspace Profile 適合「這個專案怎麼工作」。

2. 把任務條件映射成階段與 SKILL

下面這份 API 交付流程，可以當成第一條規則。它會依 objective keyword、domain、tag 或 work mode 命中；每個 Phase 只留一個 Primary SKILL，Supporting SKILL 最多三個，並寫清楚 exit gate。

{
  "schema_id": "workflow-skill-router/routing-profile",
  "schema_version": "1.0.0",
  "artifact_kind": "routing-profile",
  "profile_id": "personal:api-delivery",
  "scope": "personal",
  "enabled": true,
  "rules": [
    {
      "rule_id": "api-delivery",
      "priority": 100,
      "match": {
        "objective_keywords": ["api", "應用程式介面", "openapi"],
        "domains": ["api"],
        "tags": [],
        "work_modes": []
      },
      "route": {
        "work_mode": "phased",
        "skill_tree": [
          {
            "phase_id": "contract",
            "primary_skill_id": "skill:api-designer",
            "support_skill_ids": ["skill:api-guidelines-skill"],
            "exit_gate": "contract-reviewed"
          },
          {
            "phase_id": "implementation",
            "primary_skill_id": "skill:csharp-developer",
            "support_skill_ids": [],
            "exit_gate": "implementation-complete"
          },
          {
            "phase_id": "verification",
            "primary_skill_id": "skill:qa-test-planner",
            "support_skill_ids": ["skill:playwright"],
            "exit_gate": "tests-passed"
          }
        ]
      }
    }
  ]
}

這份設定不是要把每件工作都鎖死。它只是告訴 Router：碰到這類 API 交付目標，先走哪一條大家看得懂、也能 code review 的路。至於每個 SKILL 當下能不能用，還是得讓 Runtime Capability Discovery 驗證。

3. 先驗證，再放進日常工作

如果你是在 repository checkout 或已解壓的 Plugin artifact 中維護 Profile，可以使用內附 Runtime 驗證與預覽：

python plugins/workflow-skill-router/runtime/workflow_skill_router.pyz profile validate .\my-profile.json
python plugins/workflow-skill-router/runtime/workflow_skill_router.pyz profile install .\my-profile.json
python plugins/workflow-skill-router/runtime/workflow_skill_router.pyz profile preview --objective "Deliver the API" --work-mode phased --domain api --explain
python plugins/workflow-skill-router/runtime/workflow_skill_router.pyz profile lint .\my-profile.json

preview --explain 會把規則為什麼命中、為什麼沒命中攤開來看；lint 則會找出重複、永遠被遮蔽，或把 Primary SKILL 寫成 Supporting SKILL 的規則。它們只做 deterministic diagnostics，不會讀取 SKILL 的 instruction body，也不會因此多拿到任何權限。

這裡要先把期待壓低：Profile matching 是可預測的 lexical matching，不是 embedding，也不是語意檢索。想同時比對 API 和「應用程式介面」，就把兩個詞都寫進 objective_keywords。少了點魔法，但規則能測、能 review，出錯時也找得到原因。

Profile 命中，不等於 SKILL 已經可用

很多「關鍵字選工具」的做法，問題就卡在這裡。

Profile 只說明你想使用哪些能力，結果會標成 intended-unverified。Runtime Capability Discovery 仍會檢查它是否已安裝、Host 是否暴露、相容性、驗證狀態、政策資格與 freshness。

電腦裡有 Playwright SKILL，不代表這個 Runtime 現在就有瀏覽器；MCP Server 列出部署 Tool，也不代表你拿到 production 權限。能力不足時，Router 應回傳 capability-unavailable 和替代行動，不能假裝工作已經完成。

所以 Routing Profile 不能帶 shell command、可執行路徑、權限或任意 agent instruction。它只是路由資料，不該變成另一種繞過安全邊界的設定檔。

Plugin + MCP 與 Skill-only：兩條路都能用

我把 Plugin + MCP 和 Skill-only 都留下來，因為兩種人要解的問題不同。前者需要 Runtime 控制層；後者可能只想先把路由規則帶進工作環境。

能力	Plugin + MCP	Skill-only
任務分類、最小路由與 SKILL 使用揭露	有	有
Personal / Workspace Profile	deterministic 載入、驗證、優先序與 preview	依相同 JSON contract 提供 advisory 解讀
本機持久化 plan 與 scoped consent	有	無
跨程序 compare-and-swap、完整 drift detection	取決於 Runtime / Host	無
verified Host scheduling 與 route validation	Host 整合後可用	無
sealed model evaluation	需要 configured adapter	僅能人工流程
Runtime 標籤	`bundled-local-r0` 或 verified profile	`skill-only-fallback`

Plugin + MCP：需要 Runtime 控制層時選它

Plugin 模式需要支援 Plugin 與 MCP 的 Codex，以及 Python 3.11+、Node.js 24+。我會建議一般使用者固定安裝不可變的 v2.0.1 snapshot，不要追浮動分支：

codex plugin marketplace add eric861129/Workflow-skill-router --ref v2.0.1
codex plugin add workflow-skill-router@workflow-skill-router
codex plugin list

接著開一個新的 Codex task，要求它顯示 Workflow Skill Router status。正常情況下會看到 bundled-local-r0 和各 MCP Tool 的 readiness；完整安裝與檢查方式請看官方 Plugin 安裝文件。

Skill-only：只想載入路由規則時選它

如果 Host 不能載入 Plugin / MCP，或你只需要 instruction-only routing，就下載正式版的 workflow-skill-router-skill-v2.0.1.zip ，把內層 workflow-skill-router/ 放到 Codex Skills 目錄：

.codex/
└── skills/
    └── workflow-skill-router/
        ├── SKILL.md
        ├── assets/
        └── references/

Skill-only 還是會做工作形狀判斷、Explicit Skill Lock、support consent 和執行前／後的 SKILL 揭露。只是它明確是 skill-only-fallback：沒有 durable resume、compare-and-swap、完整 drift detection 或 enforced activation。這些限制放在桌面上，比假裝它和 Plugin 模式一樣可靠得多。

詳細限制與安裝位置請看官方 Skill-only 安裝文件。

12 個 MCP Tools，不等於 12 個工具現在都能跑

這一點很容易被「工具很多」的文案帶偏，所以我想直接寫清楚。

v2.0.1 對外提供 12 個 typed MCP Tools，但其中只有 4 個在 bundled local R0 一定 local-ready：

plan_work
propose_support_consent
transition_support_consent
get_router_status

另外 5 個操作需要 verified Host capabilities，3 個 model evaluation 操作需要 configured adapter。這是刻意的 fail-closed 設計：沒有 Host scheduler、evidence store 或授權 adapter，就回傳明確限制和 fallback；不要編造排程成功、驗證通過或模型評測結果。

對個人使用者來說，前四個 local-ready 操作已經能支援小任務、分階段任務、Scoped Consent 和狀態查詢。若團隊需要跨程序 Goal、Host authority、正式 evidence gate，就要把 Host integration 當成另一個工程項目，不能期待安裝 Plugin 後自然長出來。

關於真實模型評測：保留證據，也保留邊界

V2 的 beta.1 行為評測曾以 gpt-5.6-sol 跑過 36 attempts、42 model turns，比較 model-only 與 hybrid-router 的 routing-contract 行為：

指標	結果
Candidate route-contract match	77.78%
Baseline route-contract match	61.11%
差異	+16.67 個百分點
Hard violations	0

我還是把這組數字留下來，因為它至少不是把 deterministic fixture 包裝成模型行為。不過它只是 beta.1 的歷史證據，涵蓋範圍只有路由契約。它不驗證 Personal Routing Profile，不能被說成 v2.0.1 的新模型評測，也不能延伸成「已證明 SKILL activation、Token 成本下降或任務成果提升」。

這條線我想畫清楚。評測還不夠，就把範圍寫出來；一個漂亮但說不清楚的 benchmark，對使用者幫助不大。

正式版得經得起檢查

v2.0.1 是從凍結的來源 revision 建置並發布的正式版本。下載 Plugin 或 Skill-only ZIP 後，先比對 release 內的 checksums.sha256，再視需要查看 SBOM 和 provenance：

Get-FileHash .\workflow-skill-router-skill-v2.0.1.zip -Algorithm SHA256

雜湊值要和 release 的 checksum manifest 相符。它不能取代權限或簽章檢查，但能確認你下載後拿到的檔案沒有被改動。

此版也把文件站升到 Astro 7.1.3、Starlight 0.41.4，文件站 lockfile 的 npm audit 是 0 vulnerabilities。這不等於整個專案的相依風險都歸零；Plugin 的 MCP SDK 還有獨立的安全決策。這種差異應該寫清楚，不該用一個好看的零字把技術邊界蓋掉。完整資訊以 v2.0.1 Release Notes 的 artifact、SBOM 和 security decision 為準。

哪些人現在適合用？

如果你已經有 8 到 10 個以上的 SKILL、常做多階段開發，或不想讓模型擅自替換使用者指定的 SKILL，V2 值得裝起來跑幾個真實任務。想把 Workspace Skill Tree 放進團隊 code review 的人，也會用得到。

但如果你只有三、四個 SKILL，每次又都是一次性小任務，一份清楚的 AGENTS.md 或 SKILL.md 可能更省事，也更容易維護。不要為了看起來像平台，就替自己加一層要照顧的系統。

做 V2 時，我最不想做的就是再多包一層很炫、卻沒人能檢查的 Agent 魔法。比較讓我在意的是：原本只能靠模型記住的習慣，現在可以由開發者自己定義，團隊一起 review，Runtime 也能誠實驗證。

如果你正在整理自己的 Codex 工作環境，先從一條最常用的 Personal Routing Profile 開始就好。把你真的會重複做的流程寫成一棵小 Skill Tree，拿幾個真實任務來跑。用過以後，再決定要不要把它升成專案級的 Workspace Profile。