草稿｜目標：lab.sodahsu.com｜視覺：approved

多代理 AI 工作流的治理核心：我如何用授權與風險邊界驅動協作

我如何把僕人式領導、決策權與失敗恢復寫進 AI 工作系統

多代理 AI 工作流的治理，核心在管理。我在驅動 DesignVault 的過程中，最先需要解的不是「下一個 Agent 要用哪個模型」，而是當多個 AI 角色同時工作時，誰有權決定、誰負責執行、成果怎麼交接、風險何時必須回到人手上。

DesignVault 是我實際維護的 AI DesignOps 工具箱，也是我管理跨平台 Agent、Skills、工作規範與驗證流程的治理系統。我沒有把組織圖搬進 prompt，而是把管理者腦中的判斷寫成一套可以反覆執行、換人仍能接手、失敗後找得到回程的工作系統。

當 AI 可以執行更多工作，管理問題才真正開始

只有一個 AI 助手時，使用者同時扮演需求方、調度者、審查者與最終決策者。流程不清楚，仍能靠同一個人補洞。

Agent 增加後，這種補洞方式立刻失效。每個角色都能理解需求、選擇工具、提出方案，也都可能自行擴大範圍。表面上是執行能力提升，背後卻新增了決策衝突、責任斷點、規則分叉與交接失憶。

我開始用 Design Lead／PM 的角度重新看這個系統：範圍由誰釘住？利害關係人的需求在哪一層被確認？完成條件由誰定義？如果輸出不合格，應該再執行一次，還是回頭重談方向？

這說明 AI 協作不能只靠更完整的 prompt。Prompt 能告訴一個角色怎麼做事，治理架構才決定整個系統怎麼合作。

制度分叉，才是第一個失控點

DesignVault 早期同時服務 Claude、Codex、Gemini 與 Copilot。每個平台都有自己的入口檔案，當入口開始重複技術限制、路由方式與交接規則，修改一項制度就得同步多份內容。

交接格式也曾經同時存在不同層級的 packet。它們都想解決需求整理與任務續接，欄位與責任卻互相重疊。接手者不只要理解任務，還要先判斷眼前的 artifact 到底屬於哪一套流程。

這些問題促使我做了兩個重構：平台入口退回 adapter，只負責指向共同權威；交接則收斂成低成本初判與正式控制檔案，並定義兩者如何升級。

這次經驗改變了我看 AI 架構的方式。當系統開始擴大，最先失控的往往不是模型能力，而是規則所有權與交接責任。

僕人式領導，先清掉執行障礙

我的管理傾向不是把每個決定都收回來。管理者的工作，是補足脈絡、提供資源、說清楚邊界，然後信任專業角色完成任務。

同一套原則也適用在 AI Agent。與其要求每一個 Agent 在每一步等待批准，我更在意它是否拿到足夠資訊、知道可自行判斷的範圍，也知道何時必須停止。

授權不是把工作丟出去。授權的前提，是先設計清楚工作怎麼回來。

先界定決策權，再安排 Agent

我把工作流拆成不同責任層。低成本入口先判斷任務類型；主調度者掌握正式路由；專業角色在授權範圍內執行；治理契約要求高風險與對外行動回到人類批准。這是責任分配，不代表每個平台入口都有對等的 runtime 阻擋能力。

這套分工不模仿公司的職稱。它切開兩種容易混在一起的權力：決定「做什麼」，以及決定「怎麼做」。

專業 Agent 可以選擇執行方法，也可以建議下一步，但不能自行改寫整體方向。主調度者能重新分派工作，卻不應取代專業角色完成所有細節。治理契約不要求人類逐步審批，而是把策略、風險與公開責任明確留在人手上。

這套分層想換取的效果，是讓自主和控制不再互相排斥。邊界越清楚，管理者越能放手；升級條件越明確，執行者越不需要猜測。

代價也很直接：中央調度會增加一次回程，並可能成為吞吐量瓶頸。我接受這個交換，因為這套系統優先保護決策一致性與責任可追溯，而不是追求每一條路徑都最短。

Dola 守住每一次交付的回程

Dola 是 DesignVault 的主調度者。它確保每一次分派都有回程，每一次交付都能接上下一個判斷；專業決定仍由各 Agent 在授權範圍內完成。

專業角色完成工作後，不直接把任務橫向丟給另一個角色。除了明確定義的例外，它們會帶著狀態、產出與 next-hint 回到 Dola。Dola 再依目前 artifact、授權範圍、修訂次數與風險，決定前進、退回、換角色或詢問使用者。

這個回程設計解決四種管理斷點：

• 專業角色只看見自己的局部任務，沒有人承接全局狀態
• 任務橫向轉派後，範圍與責任在途中被改寫
• 交付完成了，卻沒有人擁有下一個決定
• 失敗被留在原角色內反覆處理，管理者太晚才看見

Dola 把分散執行重新收回同一個治理迴圈。它不要求每件事都由中央完成，而是讓「下一步由誰決定」始終有明確歸屬。

這也是 Dola 和一般 router 最大的差別。Router 把輸入送到正確位置；Dola 還要承接回呼、維持狀態、套用 revision fuse，並在續接資料不足、授權未確認或需要使用者決定時，把判斷交還給人。

代價是 Dola 可能成為瓶頸。DesignVault 用低成本 intake、快速路徑與結構化回呼縮短它的判斷負擔，但沒有假裝中央調度完全免費。我選擇承擔這個成本。多走一步不昂貴；昂貴的是工作做完後，沒有人知道該往哪裡走。

單一真相來源，省下的是反覆解釋

如果每個平台入口都保存一份完整規則，制度修改一次，就要同步多個版本。只要漏掉一份，平台差異就會從介面差異變成治理分裂。

我的做法是把 adapter 壓回入口層。它只告訴平台應該去哪裡讀共同規則，不在入口檔案裡重新定義技術限制、角色關係與交接方式。共用行為、專案硬限制、角色層級與領域技能各自有權威來源，發生衝突時也有明確優先順序。

這個決定真正想移除的，是管理者反覆解釋制度的成本。多維護幾個檔案只是表面問題。

當規則散落在不同平台，協作者遇到問題時，很容易先問：「現在到底以哪一份為準？」當權威順序被寫清楚，討論才會從比對記憶，轉回處理真正的工作。

單一來源仍不代表零漂移。靜態檢查能找到缺少引用或明顯重複，卻不一定抓得到語意矛盾。架構能降低分叉機率，不能取代持續審查。

Artifact-first，把脈絡從個人記憶變成公共資源

跨 Agent、跨模型或跨平台續接時，聊天紀錄不是可靠的專案狀態。它混合探索、推測、修正與過期決定，接手者很難判斷哪些內容仍然有效。

我要求續接先讀 active artifact。最低續接資料模型必須涵蓋目前狀態、有效範圍、已驗證事實、假設、未知、唯一下一步、授權狀態、責任提示與更新時間。資訊不足時，只問阻礙續作的必要問題，不重新訪談整個需求。

我需要這套資料模型做到四件事：

• 工作不綁在某一段 conversation
• AI 工具可以替換，任務狀態仍能保留
• 假設與事實被迫分開
• 接手者知道下一個可執行動作，而不是只拿到一份摘要

Artifact-first 也帶來文書成本。沒有維護責任的 artifact，只會變成另一份過期檔案。所以我把它壓成最低資料模型，而不是要求每次交接都寫完整報告。治理要留下足夠證據，但不能讓留下證據本身吞掉執行時間。

交接契約，讓責任跟著成果回來

「做完了」不是可用的交付狀態。

我把回程收斂成結構化訊號：目前是通過、需要修訂或無法繼續；實際產出在哪裡；再以受限的 next-hint 指出品質檢查、修正、詢問使用者或完成等下一步。

對管理者來說，交接契約有兩個直接用途。

第一，成果與責任不再分離。執行者不能只丟出檔案，還要回報狀態、產出位置與下一步。這些訊號提供判斷輸入，但不等於品質證明。

第二，調度者不用重新解讀整段工作歷史。它可以根據可見狀態決定前進、退回、換人或詢問使用者。

格式不能變成表演。狀態填了 pass，不代表品質真的通過；next-hint 也只是契約內的建議，不是最終決策。結構化回呼的作用，是讓判斷有輸入，不是替代判斷。

Revision fuse：停止用更多執行掩蓋錯誤方向

AI 最危險的能力之一，是在方向不清楚時仍能持續產出。

如果同一份成果反覆被標記需要修訂，繼續派回原角色不一定會改善品質。問題可能已經從執行錯誤，升級成範圍、標準或期待沒有對齊。

我在流程裡加入 revision fuse。同一 artifact 在單一 session 內，修訂路由至 fix-code 或 fix-design 累計達兩次後，Dola 就停止自動路由至 Agent，改用 ask-user 把選擇權交還給人：調整規格、改由人工處理，或放棄這條路徑。

這是一條管理上的止損線。它承認「再做一次」不是永遠有效，也避免系統用更多輸出掩蓋真正的決策缺口。

目前這個計數僅在單一 session 內、以 artifact 為 key 追蹤，沒有定義跨 session 的持久化保存。若要把它升級成更完整的治理能力，修訂狀態必須跟著 artifact 保存，而不是只留在當次對話。

兩扇門決策：治理強度應該跟風險走

不是每一項 AI 行動都需要同樣的審查成本。

可逆、範圍清楚、有機械驗收條件的工作，應該快速授權。格式調整、資料整理、靜態檢查與可重跑的產出，可以交給 AI 執行，再由工具驗證。

不可逆或對外可見的行動必須提高治理強度。公開發布、權限變更、刪除、跨專案契約與敏感內容，不應因為 Agent 回報成功就自動往下走。依治理契約，AI 可以備齊資料、跑完檢查、揭露剩餘風險；最終批准仍由人承擔。這項責任分配目前沒有在所有平台入口形成同等的技術阻擋。

這個分層同時避免兩個錯誤：低風險工作被審批拖慢，高風險工作被自動化速度推過責任邊界。

高階主管治理 AI，不需要理解每一段 prompt，卻必須問清楚：哪些決策已授權？哪些證據會在行動前出現？失敗如何回復？最後由誰承擔對外影響？

品質閘門：把管理注意力留給真正的判斷

我不希望管理者花時間檢查機器已經能判斷的錯誤。

DesignVault 設計了本機 pre-commit 結構驗證，檢查角色、技能格式、入口引用與生成內容是否漂移。只有 hook 正確安裝、具備可執行權限，並走正常 commit 流程時，這些 guardrail 才能擋下明確的結構問題。

這次文章查核也抓到一個真實缺口：目前這份 clone 的 pre-commit 檔案缺少可執行權限。驗證腳本與 hook 流程都存在，不代表防線已經生效。這正是治理架構需要把「規範存在」和「控制有效」分開檢查的原因。

workflow-sync 是推送前由 Agent 執行的檢查流程，不是平台強制 gate；跨專案散布也不會自動複製本機 validator 與 hook。

目前可觀察的是部分本機控制。決策權分層、人類批准與跨平台續接主要仍是流程契約，不等於每個入口都具備同等的 runtime 阻擋能力。

把這條邊界寫出來，不會削弱架構。治理成熟度本來就包含知道控制在哪裡有效，也知道哪裡仍依賴人的紀律。

這套架構把管理工作移到哪裡

以下列的是設計目標。目前沒有量化成效，我不把預期效果寫成既成成果。

架構沒有消除管理工作。它把管理工作從重複提醒、人工補洞與追問進度，挪到更有作用的位置：定義範圍、界定決策權、設計升級條件、接受剩餘風險。

管理者設計的不是控制，而是回程

驅動這套 AI 治理架構後，我更確定一件事：管理能力不等於掌握每一次操作。

真正可擴展的管理，會讓專業角色在邊界內自主前進；讓成果離開管理者之後仍帶著脈絡與責任；讓錯誤在造成更大影響前被看見；讓不可逆決定回到願意承擔後果的人手上。

架構把原本藏在管理者腦中的判斷，轉成協作者與 AI 都能讀取的工作契約。

如果你正在建立自己的 AI 工作流，先不要新增下一個 Agent。先畫出四件事：誰能決定、交接留下什麼、什麼情況必須停止、最後由誰批准。這四個答案釘穩之後，自動化才有資格加速。

同時記住：這是一套治理設計，加上部分本機控制；它不是所有入口都已被技術強制的封閉系統。能清楚說出這條邊界，才算真正開始治理 AI。