Claude Code Subagents 商業團隊應該怎樣設計 Operator Workflow

有用的 subagent setup，應由公司重複出現的工作開始。如果每個需求都會經過 discovery、scope、implementation、review、QA 和 deployment，就應該圍繞這些階段設計。先命名五個 agents 反而容易倒轉，因為那些角色未必對應真實交付流程。

對 business buyer 來說，重點不是 Claude Code setup 看起來是否聰明，而是它能否減少管理負擔、提高 review 質量，並比舊流程更快將粗略需求變成交付成果。

第一個有用角色是 planner。Planner 將業務需求變成任務 brief：目標、受影響用戶、需要檢查的文件、限制、風險和驗收標準。這可以避免 coding agent 將模糊目標當成重設整個系統的許可。

第二個角色是 builder。Builder 負責改代碼，但範圍應該窄：知道要做哪一段、改哪些文件、跑哪些測試，以及哪些行為不能改。第三個是 reviewer，檢查可維護性、安全、邊界情況，以及是否符合原本業務目標。第四個是 tester，負責跑或設計 regression check，並記錄驗證了什麼。

Subagents 可以令主 conversation 更乾淨，因為每個角色都在自己的 context 工作。這很有用，但也會帶來交接問題。如果 planner 給出的 brief 太弱，builder 可能會優化錯東西。如果 builder 不清楚總結改了什麼，reviewer 就要重新發現整件事。

操作規則應該很簡單：每個 agent 都要交回一份 artifact。Planner 交任務規格，builder 交行為變更和觸及文件，reviewer 交 findings、風險和 approval status，tester 交 commands、結果和未覆蓋路徑。這樣 AI 工作才可以由人審核。

Review agent 未必需要 deployment agent 的工具。Testing agent 可能需要 shell access，但不應接觸 production credentials。Documentation agent 可能只需要 read access。工具權限應配合角色，因為過闊權限會令小錯誤變成業務風險。

當 workflow 涉及付款、客戶資料、內部記錄或 deployment，這件事更重要。工作越敏感，權限邊界越要刻意設計。好的 AI operations 在這裏應該有點沉悶，這正正是目的。

即使有 subagents，仍然需要有人決定優先次序、scope 和 release timing。AI 可以提出 implementation，但它不知道今個星期的緊急客戶問題是否比計劃中的 dashboard 改善更重要。

Human operator 亦要負責 final acceptance。這代表按業務需求檢查成果，而不只是看 code 是否 compile。一個乾淨但解決錯 workflow 的 pull request，仍然是失敗交付。

先由三個 reusable subagents 開始：planner、reviewer 和 tester。Builder 可以先保持在主要 Claude Code workflow 內，直到你有足夠重複任務類型，才建立更專門的 builders。這樣可以避免在未理解工作模式前，先創造一套複雜系統。

兩至三星期後，回看 artifacts。哪些 brief 不清楚？哪些 review 真的捉到問題？哪些測試重複出現？這些歷史會告訴你哪裏值得加 agent，哪裏其實一份 checklist 已經足夠。