自治軟體開發的治理前線：worca-cc 8 agent 9 階段 pipeline 的啟示

今日大多數人講「AI 寫 code」仲停留喺 ChatGPT 抄一段、Claude 生成一個 function 嘅層面。但真正嘅命題唔係「AI 能唔能夠寫 code」——呢個問題 2024 年已經答咗。真正嘅命題係：當 AI agent 唔係幫你寫一行 function，而係 autonomously 管理成個 software development lifecycle，你點樣確保佢唔會製造災難？

呢個問題嘅答案，就係 governance layer——一個喺 AI agent 同生產環境之間嘅治理層。而 worca-cc 嘅 8 agent、9 階段 pipeline，正正係呢個治理層嘅 concrete embodiment。

從單一 prompt 到多 agent 管線：治理點解變咗必需品

單一個 LLM call 嘅風險係可控嘅：你睇到 output，唔啱就改 prompt。但當你擴展到 8 個 specialist agent——Planner、Plan Reviewer、Coordinator、Implementer、Tester、Reviewer、Guardian、Learner——每個 agent 都有自己嘅 context、自己嘅輸出、自己對「正確」嘅判斷，問題就幾何級數上升。

Planner 話要 refactor 一個 module，Implementer 執行咗，Tester 話測試通過，但 Guardian 發現呢個 refactor 打破咗另一個 team 依賴嘅 API contract。呢啲情境唔係假設——worca-cc 嘅 9 階段 pipeline（Preflight → Planner → Plan Reviewer → Coordinator → Implementer(s) → Tester → Reviewer → Guardian → Learner）正正係為咗捕捉呢類跨 agent 衝突而設計。

呢度嘅 insight 係：多 agent 系統嘅複雜性唔嚟自 agent 本身，而嚟自 agent 之間嘅依賴同潛在衝突。 每一個 stage 唔單止係一個任務節點，更係一個 governance check point——好似機場安全檢查咁，每個 checkpoint 都係為咗捕捉前一個 stage 可能 miss 咗嘅問題。而 Learner agent 喺 pipeline 最尾收集 data 用嚟改善未來 run，形成一個 closed-loop 嘅自我改進系統。

Circuit breaker、Approval Gates、Fan-Out：三種治理機制

Worca-cc 嘅設計入面有三個機制特別值得香港嘅 tech team 留意。

Circuit breaker（斷路器）：當 token 消耗超出 budget、或者某個 stage 嘅錯誤率高過 threshold，pipeline 自動暫停。呢個概念嚟自電路工程——防止小問題 cascading 成系統性災難。喺 AI 開發嘅 context，circuit breaker 嘅價值在於：佢唔需要 human judgment，純粹基於預設 threshold 做決定，係最快嘅防禦線。

Human approval gates（人工審批閘門）：某啲 decision point——例如涉及 production 數據、寫入 database、或者修改第三方 integration——必須停低等人類 approve。呢點同 moto 嘅 17 個 safety hooks 理念一致：AI 可以做 95% 嘅嘢，但嗰 5% 嘅 high-risk operation，人類必須喺 loop 入面。

Fan-out 執行：worca-cc 支援 fleet runs（同一個 pipeline 向 N 個 project fan-out）同 workspace runs（多 project DAG 執行）。呢個機制嘅治理含義係：當你同時改 10 個 repo，你需要一個 coordinator 嚟管理 execution order 同 dependency resolution。PM-Skills 嗰 5 個 orchestration sub-agents（pm-critic、pm-skill-auditor、pm-changelog-curator、pm-release-conductor、pm-workflow-orchestrator）正正係呢個 fan-out 場景嘅 product management 對應層。

對香港開發者同創業者嘅實際意義

香港嘅 tech team 好多得 3-10 個人，冇咁多 resources 去做 dedicated DevOps 或者 QA team。AI agent pipeline 嘅承諾係：用 automation 取代人手重複勞動。但 worca-cc 嘅設計話畀我哋知，取代嘅唔係 governance，而係 execution。

你可以用 agent 去 implement、test、甚至 review code，但你仍然需要諗清楚：

• 邊啲 decision 一定要 human approval？
• Token budget 同 time budget 嘅 threshold 係幾多？
• 多個 agent 改同一個 codebase 嗰陣，點樣避免 conflict？
• Pipeline fail 咗之後，係 automatic retry 定係停低等人睇？

呢啲問題唔係 technical question，而係 governance design question——係你要喺開始寫任何 agent 之前就諗好嘅。Worca-cc、PM-Skills、moto 呢三個 open source project 嘅共同 thread 係：佢哋都喺度建立一個 framework，令到 AI agent 嘅 autonomy 同人類嘅 control 之間有個清晰嘅邊界。呢個邊界越早畫清楚，你之後嘅 scaling 就越順。

行動點：你嘅 team 今日可以開始做嘅三件事

第一，引入 stage gate 思維。唔好俾 agent 直接 access production 或者直接寫 database。喺每一個 high-risk operation 前面加一個 check point——可以係 circuit breaker threshold，可以係 human approval，甚至可以係另一個 agent 嘅 cross-check（worca-cc 嘅 Guardian agent 就係做呢樣嘢）。

第二，track 你嘅 AI operational cost。Worca-cc 嘅 token 同 cost tracking with budget warnings 唔係 luxury feature——係必需品。如果你唔知道你嘅 AI pipeline 用咗幾多錢，你根本冇辦法做 governance decision。

第三，採用 agent-skill 架構。PM-Skills 嘅 65 個 plug-and-play skills 展示咗一個重要 pattern：將知識同 workflow 封裝成獨立嘅 skill module，令到 agent 可以按需要載入，而唔係每次俾佢成個 codebase context。呢個 pattern 大幅降低 token 消耗嘅同時，亦令 governance 更精準——你可以 control 邊個 skill 可以用、邊個唔可以用。

AI agent 嘅未來唔係更強大嘅模型，而係更聰明嘅治理架構。Worca-cc 嘅 8 agent、9 階段 pipeline 只係開始——但佢已經畫咗一條好清晰嘅路。