從 Skills 到分層 Workflow：AI Agent 系統的下一層抽象

原始來源與檔名：20260512_2026-05-12T093211+0800-从 Skills 到分层 Workflow：AI Agent 工程化的下一层抽象.md

來源：[[@ZeroZ_JQ]] / X — 2026-05-09 原始檔名：2026-05-12T093211+0800-从 Skills 到分层 Workflow：AI Agent 工程化的下一层抽象.md

NAPKIN | 餐巾紙

餐巾紙公式

Skills Library = Local Optimization (Random execution). Layered Workflow = Global Engineering (State Machine). Hierarchy: CANON -> Command -> Agent -> Skill -> Artifact -> Hook.

很多 AI Agent 專案到了中後期會遇到瓶頸：堆疊了幾十個 Skill (寫測試、Debug、寫文件)，但系統依然不穩定。作者指出，Skill 解決的是「怎麼做」的能力問題，但在真實工程中，我們更需要解決「什麼時候做、由誰決定、失敗退回哪裡」的流程控制問題。真正的 Agent 工程化不是技能庫，而是一套嚴格的分層工作流 (Layered Workflow)：從底層約束 (CANON) 到階段狀態機 (Command)，再到責任切分 (Agent) 與方法論 (Skill)，最終透過產物 (Artifact) 留下審計證據，並用 Hook 強制攔截錯誤。

一句話

如果你只是把一堆 Skill 平鋪在資料夾裡讓 Agent 自己決定什麼時候調用，你的系統就會是一場充滿隨機性的即興表演。真正的軟體工程需要「狀態機」。Agent 不能一邊寫 Code 一邊偷偷修改需求；它必須經歷明確的 /refine -> /design -> /plan -> /build -> /review -> /ship 階段門控。我們需要將 Agent 的職責切開：不該由同一個角色負責寫需求、寫實作和自我審查。分層工作流是解決 Agent 「會做事但不靠譜」的終極解法。

餐巾紙草圖

[ Layered Workflow Architecture ]

1. CANON     : The global constitution (No Yes-man, test first)
2. COMMAND   : State Machine Controller (Is /build allowed to start?)
3. AGENT     : Role & Responsibility (Separation of execution and review)
4. SKILL     : Methodology (How to do TDD)
5. ARTIFACT  : Audit Trail (01-spec.md, 03-plan.md)
6. HOOK      : Runtime Guardrails (Pre-commit Git hooks to enforce rules)

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

• 痛點: Skills Library 的上限是工程失穩（時序失穩、責任失穩、證據失穩、治理失穩）。Agent 會跳過設計直接寫 Code，然後自己審查自己說沒問題。
• 解決方案一：橫向的階段流 (State Machine):
  • 工作流不是自由聯想，是狀態機：/refine -> /design -> /plan -> /build -> /review -> /ship。
  • /build 只能消費已批准的 spec，不能在實作時重新定義目標。
  • /review 是門控 (Gatekeeper)，發現問題必須退回 /build。
• 解決方案二：縱向的分層 (6 Layers):
  • CANON: 憲法，全域紀律（如：遇到矛盾先停止）。
  • Command: 階段控制器（檢查是否具備進入下一階段的條件）。
  • Agent: 責任視角，不是人格表演（區分執行者與審查者）。
  • Skill: 具體的可複用方法論。
  • Artifact: 過程的證據鏈，用於事後復盤與防漂移。
  • Hook / Validate: 運行時的硬性護欄（攔截違規動作）。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

核心論證鏈

1. 工程的本質是責任邊界，不是能力堆疊: 同一個 Agent 自己設計、自己寫 Code、自己 Review，這叫 Self-confirming loop (自我確認迴圈)。人類工程團隊為什麼要分 PM、Dev、QA？因為不同的認知視角能打破盲點。Agent 也必須遵循這種責任分離。
2. 沒有 Artifact 就沒有證據: 如果 Agent 在一次對話裡把所有事情做完了，幾天後你根本不知道當時的需求邊界是什麼。強制產出 01-spec.md 到 05-ship.md 不是文件潔癖，而是為了建立可追溯的審計軌跡 (Audit Trail)。

關鍵證據

• 舉了「兩階段 Review」的例子：第一關 (Spec Compliance) 檢查功能是否做全；第二關 (Code Quality) 檢查架構與效能。如果混在一起，Agent 會在功能殘缺時去糾結 Code Style。這種分層門控的設計，完美體現了 Workflow > Prompt 的價值。

邊界條件

• 開發成本: 建立這套 6 層架構需要極高的初期成本，且會讓原本一兩句話就能搞定的簡單任務變得繁瑣。這套框架適用於需要長期維護的「複雜專案」，不適用於拋棄式的腳本開發。

ROUND 3: SOUL | 靈魂提取

“還能怎么用”

• 知識連結: 本文是對《The Agentic Development Lifecycle (ADLC)》以及《What Apple’s Leaked CLAUDE.md Teaches Us》的完美技術落地。它將 ADLC 中抽象的「驗收門檻」具象化為 Command 狀態機和 Artifact 證據鏈。
• 深層洞見: “Skill 是執行方法論，不是工作流總控。” 我們常犯的錯是把流程控制邏輯寫在 Prompt 裡，期望 AI 自己做好調度。但 LLM 是一種機率模型，讓機率模型自己決定狀態機的流轉，注定會產生亂流。用確定性的程式碼來控制流程 (Command/Hook)，用機率性的模型來執行節點 (Skill)，這才是正確的 Agent 工程學。
• 行動呼籲: 如果你正在構建自己的 AI 程式設計輔助系統，請立刻引入「雙視角」機制。不要讓同一個對話 Session 負責生成程式碼和審查程式碼。建立一個獨立的 Review Agent，它看不到前一個 Agent 的辛苦過程，只能對照 Spec 和產生的 PR 進行冷酷的打分。這會是你系統穩定性的一大躍進。