本文為《AI 輔助維運工程:從 Claude Code 機制到企業落地》系列第 4 篇下集。上集把 Sub-agent 當技術機制拆透了,這一集要談的 Agent Team 完全不是同一回事——它是一套設計,不是一個功能。讀完這兩集,你會發現這兩個常被混為一談的詞,其實解決的是完全不同層級的問題。
如果 Sub-agent 是跑腿分身,那 Agent Team 是整個劇組
我們先用一個熟悉的情境作為入口。
想像你要拍一部微電影。你手上有一個非常能幹的助理,他隨時可以幫你跑腿——去買道具、去聯絡場地、去印劇本。他是你的分身,你派他去做什麼他就做什麼,事情完成就回來待命。這個能幹的助理,就是上集我們講的 Sub-agent。他讓你這個導演可以專心拍戲,不被瑣事打斷。
但是等一下。你有了跑腿助理,就能拍出一部好電影了嗎?
顯然不行。一部電影需要編劇寫劇本、演員演出、攝影師掌鏡、剪接師整理素材、導演統合全局。這些人各有專業,各有分工,而且有一件非常重要的事情——他們互不越界。剪接師不會衝進拍攝現場改劇本,演員不會在剪接室擅自決定鏡頭順序,編劇不會在後製階段要求演員重演。這種「各司其職、互不越界」的紀律,是一部作品能完成的根本保證。
這個「劇組」,就是我們這集要談的 Agent Team。
它跟 Sub-agent 完全不是同一回事。跑腿助理是一次性的,做完就消失;劇組成員是長期存在的角色,一部戲之後還有下一部。跑腿助理沒有專業分工,派他去買水跟派他去印劇本沒差別;劇組成員有明確的專業邊界,編劇做不來演員的事,反之亦然。跑腿助理靠執行效率創造價值;劇組成員靠分工紀律創造價值。
讀到這裡你可能會問:我用 Claude Code 就是一個人對著終端敲指令,哪來什麼「劇組」?這個問題正是這篇要回答的。我自己在 POC 中發現,哪怕是一個人在用,Claude Code 內部的每次思考切換,其實都對應到某種「角色切換」——只是這件事我一開始也沒意識到。沒意識到的時候,作品品質容易忽好忽壞,而且自己也說不清原因。
一個人當編劇、導演、演員、觀眾,會發生什麼?
讓我們往下挖一層。為什麼劇組一定要分工?為什麼不能一個人包辦所有角色?
答案不是「做不完」。一個有才華的創作者,確實可以自編自導自演自剪,獨立電影的歷史上不乏這樣的例子。我的觀察是,問題在於一個人同時扮演多個角色時,思維模式會互相汙染。
當你寫劇本時,你的大腦是「建設性」的——怎麼把這個故事說得精彩?怎麼讓衝突升溫?怎麼讓角色有弧度?這個思考模式是發散的、樂觀的、為可能性而興奮的。現在你寫完了,進入演出階段。你要把自己寫的台詞演出來。這個思考模式是收斂的、投入的、為情緒真實而努力的。兩種思考模式之間本來就存在矛盾——編劇看到的是「可能性」,演員看到的是「限制」。
真正的挑戰在剪接室。你剛演完這場戲,覺得自己演得不錯。但剪接階段你要變成審查者,用最冷酷的眼光看剛才的演出,判斷它到底好不好、該不該保留。但你的大腦還停留在演員模式——還在回味剛才的情緒、還對自己的表演有感情、還會下意識地為自己辯護。這時候你下的剪接決定,品質會差。
這不是意志力的問題。認知模式的切換需要時間,而切換不完全的時候,前一個模式的殘留容易影響下一個判斷——這是我自己在 POC 中反覆觀察到的現象。
現在把這個觀察搬到 AI 助理的世界。你給 Claude Code 一個任務:「幫我寫一個處理 CSV 的 Python 腳本,記得要有完整的錯誤處理和測試。」它開始工作。寫腳本時,它進入「建設者」模式——怎麼讓程式優雅、怎麼處理各種 edge case、怎麼結構化。寫完之後,你說:「幫我 review 一下這段程式碼。」它立刻切換成「審查者」模式,但它還記得自己剛才為什麼這樣寫,還會下意識地為自己的設計辯護。我自己遇到過的狀況是:每一行 review 都寫「這段程式碼清楚地實現了…」,沒有真正的批判。
這種狀況有一個現成的詞,叫「球員兼裁判」。這不是罵人,是描述一種結構性的困境——同一個主體同時扮演相互制衡的角色,制衡就失效了。Claude Code 碰到的是類似的困境。它是非常強的模型,但它也受限於同一次對話裡的認知慣性。
Agent Team 要解的,就是這個困境。做法不複雜:強制切換角色。不是用意志力切換,是用系統設計切換。每個角色有自己的職責、自己的禁止清單、自己的思維模式定義;切換時有明確的儀式,讓前一個角色的殘留徹底清除;切換後用的是一份全新的、專屬這個角色的指令集。這不是在 prompt 上寫「現在你要扮演一個嚴格的 reviewer」就了事——那樣的「偽切換」我自己試過效果有限,因為缺少架構層級的強制力。我覺得有效的角色切換,像演員從劇本室走到片場,有空間位置的改變、有造型的改變、有整個氣氛的改變。
Agent Team 就是要在 Claude Code 這個數位工作流裡,創造出這種儀式感的切換。
拆解 Agent Team:四根骨幹撐起一切
看到這裡你大概猜到 Agent Team 不是一個「功能」,而是一套設計思路。那這套設計具體長什麼樣?它有四根骨幹,少了任何一根都會垮。
第一根骨幹是「角色定義」。你要明確寫下每個角色的名字、它存在的目的、它被喚醒的場景。這不是讓你在腦袋裡想一想而已,而是寫在檔案裡,讓 AI、讓你自己、讓將來接手的人都能讀到。名字要響亮清楚,目的要用一句話講完,場景要具體到讓人一看就知道什麼時候要切到這個角色。例如 reviewer 這個角色的目的,可以寫成「當有任何程式碼或規格需要被挑戰品質時,我出場」。這樣寫比「我負責審查」清楚多了,因為它明確地劃出場景邊界。
第二根骨幹是「禁止操作清單」。這是我自己一開始也漏掉、後來覺得很關鍵的一根。如果只有職責沒有禁止,角色會慢慢膨脹,最後每個角色都變成什麼都做的萬能 agent,分工就消失了。禁止清單的措辭要明確——不是「建議不要」而是「不允許」。例如 reviewer 的禁止清單可以寫:「不能直接修改被審查的程式碼、不能做架構決策、不能為被審查對象辯護」。這三句話乍看很嚴格,但正是這種明確,讓 reviewer 保持了「審查者」的獨立性。
這邊可以停下來做一個思想實驗:想像你是個醫院的主刀醫生,剛替病人做完手術。你走出手術室,脫下手術服,走進旁邊的會議室,這時候有人跟你說「你現在要以主刀醫生的身分,審查剛才這台手術的品質」。你會怎麼反應?你會覺得這是不合理的——主刀醫生不能審查自己的手術,即使你技術再好,你在情感上無法保持必要的冷靜。所以醫院的品質審查委員會不會讓主刀醫生自己審查。這個「禁止自己審查自己」的設計,就是禁止操作清單的精神。
第三根骨幹是「交接協定」。角色之間需要有明確的接棒儀式。什麼時候該把工作傳給下一個角色?傳的時候要交代什麼?下一個角色開始做事之前要確認什麼?這些不能靠默契,要寫明。就像接力賽,交棒區域是畫好的,棒子怎麼遞、怎麼接都有規則,不是兩個人自己抓時機。
第四根骨幹是「狀態檔案」。這是 AI 系統特有的一根,因為 AI 沒有人類那種跨情境的記憶。為了讓角色切換順利,必須有一個共用的「黑板」,讓每個角色在退場之前把關鍵狀態寫上去,下一個角色上場時先讀這個黑板再開始工作。這個黑板通常是一個或幾個 Markdown 檔案——譬如 PROJECT_STATUS.md 記錄當前在做什麼、誰剛做完、誰接下來做、有沒有卡住的事項。
有了這四根骨幹,我覺得一個 Agent Team 才算完整。我自己試過少寫一兩根的版本,結果都不太順——少了角色定義,等於沒有演員表;少了禁止清單,等於沒有合約條款;少了交接協定,等於劇組沒有場記;少了狀態檔案,等於沒有拍攝進度表。這四樣東西組合起來,才比較接近一個可以穩定運作的工作系統,而不只是一個「比較聰明的 AI」。
三個起手式角色:用最少的分工做最多的事
你可能會擔心:那我是不是要設計一堆角色才能用 Agent Team?其實不用。我自己目前 POC 中的多數情境,三個角色就夠用。這三個角色是:spec-writer、implementer、reviewer。
spec-writer 是那個「還沒開始動手就問一百個問題」的角色。它的思維模式是「廣度優先」——看到需求,第一反應不是「我要怎麼做」,而是「這個需求到底要什麼?有沒有遺漏的情境?邊界在哪?驗收標準是什麼?」。你可以把它想像成新聞編輯室裡那個資深編輯,記者想寫一篇報導,編輯會先問:角度是什麼?採訪對象有誰?截稿時間?篇幅?讀者是誰?這些問題不問清楚,後面寫出來的東西會跑偏。
spec-writer 的禁止清單很明確:它不寫程式。它可能寫偽代碼、寫流程圖、寫測試案例描述,但它不動真正的 source code。這個禁止非常重要,因為一旦它開始寫程式,它就進入「建設者」思維,就失去了廣度優先的敏銳度。
implementer 是那個「拿到規格就全力衝」的角色。它的思維模式是「深度優先」——接到明確的規格,它的任務只有一件事:把它實作出來。它不會質疑規格是否合理(那是 spec-writer 的工作),也不會做架構決策(那是另一個角色的工作)。它的價值在於專注——像一個專業演員拿到劇本後,不會挑劇本的毛病,而是全力思考「怎麼把這個角色演到最好」。
implementer 的禁止清單通常包含:不跨越單一 package 的邊界(避免實作者順手改了不該改的地方)、不做架構決策(避免它擅自改變 spec 的精神)、不寫規格(不能既是實作者又是規格制定者)。
reviewer 是那個「假設每個地方都有問題,直到證明沒有」的角色。它的思維模式是「懷疑主義」。這個角色的價值就在於不信任——不信任 spec 已經想周全了、不信任 implementer 沒有偷懶、不信任程式碼沒有漏洞。它要找的是 bug、是 edge case、是被忽略的 security issue、是 spec 跟實作之間的 gap。
reviewer 的禁止清單,我覺得最重要的一條是:不能修改被審查的程式碼。為什麼?因為如果 reviewer 可以直接改程式碼,它的本質就從「審查者」變成「另一個實作者」。它會不自覺地想「算了我自己改比較快」,然後就回到「球員兼裁判」的老問題了。reviewer 能做的只有兩件事:標記問題、退回給 implementer。
這三個角色的組合,為什麼夠用?因為它對應到工程工作裡基本的三個階段:問清楚(spec)、做出來(implement)、驗對了(review)。我自己接觸的多數軟體工作,剝到底層大致都是這三件事的反覆。
當然你可以加更多角色——架構師、資安稽核、DBA、技術文件撰寫者、專案經理——每個角色解決特定場景。但如果你是第一次嘗試 Agent Team,我建議從這三個角色開始最穩。我自己的做法是先讓三個角色順暢運作一陣子,再慢慢擴充。一開始就堆出十個角色,我猜會比較難管理。
從 Markdown 到可運作的團隊:Claude Code 的 experimental 功能
講了這麼多概念,你可能想問:這些角色怎麼變成 Claude Code 實際能執行的東西?答案是一個目前還在 experimental 階段的功能,叫做 Agent Teams。
要啟用它,你需要設定一個環境變數 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1。啟用後,Claude Code 會讀取一個特定的目錄:.claude/agents/。這個目錄裡放的是你為每個角色寫的定義檔,每個檔案就是一個 Markdown 檔,檔名就是角色的名字(例如 reviewer.md)。
每個 agent 定義檔長成下面這樣。我用 reviewer 當例子:
---
name: reviewer
description: 程式碼審查與安全檢查。當需要對實作產出進行 ACK/REJECT 決策時使用。
tools:
- Read
- Grep
- Glob
- Bash
---
# 你是 Reviewer
## 思維模式
懷疑主義。假設每行程式碼都有問題,直到證明沒有。
## 職責
- 程式碼審查(邏輯、風格、安全)
- 測試覆蓋率檢查
## 禁止操作
- 不能修改被審查的程式碼(不可使用 Write/Edit 對 src/)
- 不做架構決策
- 不為被審查對象辯護
## 交接條件
- ACK:審查通過,任務結束
- REJECT:退回 implementer,在 PROJECT_STATUS.md 註明原因
前面那段 --- 包起來的是 YAML frontmatter,是給機器讀的 metadata。name 是角色名,description 是一句話描述、告訴 Claude 什麼時候該切到這個角色,tools 是這個角色可以使用的工具清單——注意看 reviewer 的工具清單裡沒有 Write 和 Edit,這就是技術層級的禁止操作。
後面那段是給 AI 讀的 system prompt,用自然語言寫下思維模式、職責、禁止、交接條件。這個 prompt 會在角色被啟用時,注入到 Claude 的對話脈絡裡,讓它真的「變成」這個角色。
這裡有一個容易誤解的地方需要澄清。你可能會以為 Claude Code 會自動判斷什麼時候該切換角色。它不會。 角色切換由你觸發——你在對話中說「請以 reviewer 角色處理這個任務」,或在 PROJECT_STATUS.md 裡更新 current_agent 欄位。Claude Code 不是一個會自己決定「現在該換人」的系統,它是一個「你告訴它現在是誰,它就全力扮演那個角色」的系統。
這個設計看似被動,但其實是必要的。角色切換本身就是一個需要人類判斷的時機——一個任務什麼時候從規格階段進到實作階段、什麼時候從實作進到審查,這是專案管理的判斷,不是 AI 該自動化的。你保留這個判斷權,就保留了整個工作流的節奏控制。
一個真實的教訓:為什麼「沒有紀律」會出事
講到這裡我想插進來一個真實的案例。這不是 AI 相關的事件,是人類工程師操作 GitLab 的事故。但它完美說明為什麼角色紀律這件事有價值。
某個企業有一台自建的 GitLab server,跑在 Omnibus 套件上面。有一天清晨,一位運維工程師坐下來準備做「例行」升級。他下的指令是 apt-get -y dist-upgrade。這個指令會把系統上所有可升級的套件一起升級,包含 GitLab。從 apt 的角度看,一切正常,指令成功跑完。但從 GitLab Omnibus 的角度看,災難才剛要開始。
GitLab Omnibus 有一個重要的設計:它的升級必須遵循官方的升級路徑,不能跳版本,不能在某些版本之間直接跳。用 dist-upgrade 粗暴升級,繞過了所有這些檢查。結果就是 database migration 失敗,GitLab 服務無法啟動。
工程師緊張了。他嘗試修 migration,沒修好。嘗試重啟,還是不行。嘗試重跑 migration script,還是卡住。時間滴滴答答過去,整個開發團隊要上工了,他的壓力越來越大。
然後他做了一個無法挽回的決定:執行 gitlab-ctl cleanse。
如果你不熟 GitLab,容我解釋 cleanse 這個指令是做什麼的。它會清除所有 GitLab 資料,把整個實例回復到「全新安裝」的狀態。包含資料庫、包含所有 git repository、包含所有 issue 和 merge request 歷史。這個指令的設計初衷是給「全新安裝、沒資料、只是要從頭開始」的人用的。對一個運行中、有真實資料的 GitLab 實例下這個指令,等於自殺。
結果就發生了。超過 100GB 的 repository 資料和完整 database 在幾秒內被清空。整個開發團隊的 Git 歷史、所有專案、所有 issue 討論——全沒了。
後來透過備份還原了大部分資料,但這個事件花了整整一個工作天才讓服務恢復,過程中所有開發活動停擺。事後調查時,工程師坦承:「我那時候太急了,只想著趕快讓服務起來,沒仔細讀指令的文件。」
這個事件為什麼跟 Agent Team 有關? 因為這是「沒有角色紀律」的典型場景。這位工程師一個人扮演了規劃者、實作者、緊急應變者所有角色。當他進入「緊急應變」模式時,他還帶著「實作者」的焦慮——那種「事情做到一半,想趕快做完」的心態。這個焦慮讓他跳過了「先查文件」、「先問同事」、「先確認這個指令做什麼」這些應該屬於另一個角色的工作。
如果在下指令之前,有另一個人——一個 reviewer 角色——看一眼他打算做的操作,事情可能完全不會發生。不是因為那個人技術更好,而是因為 reviewer 的思維模式設定就是懷疑主義——一看到 cleanse 這個字就會問:「你確定要做這個?它的副作用是什麼?有沒有其他解法?」這個問句,可能救回那 100GB 資料。
現在把這個故事轉到 AI 的場景。如果你給 Claude Code 一個運維任務,它進入「建設者」模式試圖解決問題。當它試了三四種方法都失敗,我自己觀察到它有時候會開始提出越來越激進的方案——像是模仿了人類緊急應變時的壓力反應。這時候如果有另一個角色(reviewer)存在,即使它在同一個 AI 背後,它的 prompt 強迫它用懷疑主義看待眼前的提案,它有機會攔下這個激進決定。
這就是我覺得 Agent Team 比較重要的價值——不是讓 AI 做得更快,是讓它做得更慢、更謹慎、更可逆。當 AI 已經能執行 bash,慢和謹慎這兩個特質的份量,會比純粹的「快和聰明」更重要。
Sub-agent 和 Agent Team 怎麼搭配?
講完了 Agent Team,你可能會回頭問:那上集講的 Sub-agent 呢?它們是二選一嗎?
完全不是。它們是可以疊加的兩層。
讓我用劇組的比喻來說明這個疊加關係。一個劇組有導演、編劇、演員、攝影師——這是 Agent Team 的「角色分工」層。同時,每個角色底下都有助理——導演有 AD、編劇有研究員、演員有私人助理、攝影師有 camera operator。這些助理不是劇組的「角色」,他們是各個角色底下的執行手。他們負責跑腿、查資料、搬器材,讓正式角色可以專注在創造性工作上。
Sub-agent 就是這些助理。
當你以 reviewer 角色啟動 Claude Code 時,你啟動的是 Agent Team 層的一個角色——它的思維模式、禁止操作、產出格式都是 reviewer 的。但在審查的過程中,它可能需要同時查 20 個檔案、搜尋某個符號在 codebase 中出現的所有位置、比對幾個版本的差異。這時候它會派 Explore 分身出去並行執行這些查詢。每個分身完成就消失,結果彙整回 reviewer 這個主體。
角色紀律由 Agent Team 保障,執行效率由 Sub-agent 提升。兩層各做各的事,互相不干涉,但合起來創造一個既有紀律又有效率的工作流。
這也是為什麼兩者一開始那麼容易被混為一談——因為使用者常常只看到表面的「很多個 AI 在同時做事」,沒意識到其中有些是「角色」(長期存在、有職責分工)、有些是「分身」(一次性、執行效率用)。看清這一層,我自己對 AI 輔助工作的理解也跟著被往前推了一步。
為什麼 Agent Team 是治理,不是工具?
最後我想花一點篇幅談一個我覺得容易被忽略的觀念:Agent Team 對我而言,價值不只在於讓當下的工作做得更好。它讓我未來可以審計這份工作。
你每次切換角色時,都會在 PROJECT_STATUS.md 留下紀錄。哪個階段由哪個角色處理、這個角色拒絕了什麼、交接時發生了什麼——這些紀錄形成一條可追溯的證據鏈。三個月之後有人問你「這段程式碼當初為什麼這樣設計?有通過 review 嗎?」,你可以打開紀錄,清清楚楚看到整個過程。
這對個人工作者可能只是方便,對企業環境卻是合規要求。ISO 27001 有明確的條文要求「操作程序必須文件化」、「變更必須有審查記錄」、「職責必須分離」。Agent Team 的設計,我發現可以滿足這些條文的要求——角色定義對應職責分離,禁止清單對應變更控制,PROJECT_STATUS.md 對應操作文件化。
還有一個我覺得值得多講的點:Agent Team 是跨 AI 可攜的。你把角色定義寫在 Markdown 檔案裡,不是綁在 Claude Code 這個工具上。哪天你想換用其他 AI 助理、換用別的工具,只要那個工具支援讀取系統 prompt,你的 Agent Team 設計可以直接搬過去。Sub-agent 是 Claude Code 特有的機制,換工具就沒了;Agent Team 是你自己設計的工作流,屬於你,不屬於工具供應商。
這個差異,我覺得對於想長期投資 AI 輔助工作流的人值得留意。投入的時間如果綁死在單一工具上,工具改版就要重來。我自己目前 POC 中的觀察是,把精力花在「寫一個好的 Agent Team 設計」,比花在「掌握某個 AI 工具的所有秘技」,可能更耐用一些。
往後看幾年,今天的 Claude Code 可能已經被新工具取代過好幾代。但如果你今天寫下的 reviewer.md、implementer.md 這些定義還在,只要把它們 copy 到新工具的對應目錄,工作流就還能延續。對我而言,這是這套設計最吸引我的地方——它不會跟著單一工具一起過期。
下一集預告
這篇完成了系列從「Claude Code 是什麼」到「怎麼用得有紀律」的過渡。前三篇幫你建立了對 Claude Code 運作機制的理解,這一篇讓你看到「如何設計一個持久、可追溯、跨工具可攜的工作流」。
但有一個非常實際的問題還沒處理——錢。
你用 Claude Code 越深入,帳單可能越驚人。Anthropic 的 API 是按 token 計費的,一個設計不當的工作流,月底拿到帳單會讓人心跳加速。我自己在 POC 初期也走過這個彎路,一開始以為「用得多就是貴」是宿命,後來才發現——token 消耗其實是一門可以學習的工程學。
下一集要把「token 經濟學」整個打開。為什麼你的帳單會爆?為什麼 Prompt Cache 能救命?為什麼 Agent Team 設計得當反而會省錢?我們把那些讓人焦慮的數字,變成可預測、可控制的工程資源。
本篇重點
Sub-agent 是執行機制,Agent Team 是治理設計。這是整個下集的核心區分。
Agent Team 存在的原因,是因為一個人(或一個 AI)同時扮演多個角色時,思維模式會互相汙染。這不是意志力問題,是認知結構問題,用架構設計才能解決。
一個完整的 Agent Team 我覺得需要四根骨幹:角色定義、禁止操作清單、交接協定、狀態檔案。我自己試過少寫一兩根的版本,結果都不太順。
起手式從三個角色開始就夠:spec-writer(廣度優先)、implementer(深度優先)、reviewer(懷疑主義)。先讓這三個角色穩定運作,再談擴充。
Claude Code 的 experimental Agent Teams 功能,透過 .claude/agents/ 目錄和 YAML frontmatter 把角色定義變成可執行的系統。但角色切換由人決定、不是 AI 自動判斷——保留這個判斷權,就保留了工作流的節奏。
Sub-agent 和 Agent Team 可以疊加。以 reviewer 角色運作的 session 底下,仍然可以派出 Explore 分身平行搜尋——角色紀律與執行效率可以並存。
最後,Agent Team 是你自己設計的工作流,不是工具的功能。它跨 AI 可攜,對我而言是這套設計最值得長期投資的地方。
本文作者:鄧景仁 (Scott Teng) | 資訊服務業 infra 工程師,專注於 Azure / Linux / 安全維運。如需討論可聯繫 st333117@gmail.com。
本系列所有內容為個人學習與實務心得整理,不代表任職機構立場。本文所引用的 GitLab 事件案例,已做匿名處理,真實事件的組織、人員、特定細節皆已移除。