最近在使用 Agent 的過程中，我越來越常派出所謂的 SubAgent（子代理）。

不過我後來發現，SubAgent 最容易被誤解成：

「事情很多，所以多叫幾個 AI 來幫忙。」

其實不是。

至少以我自己的使用經驗來說，我開始派 SubAgent，通常不是因為「忙不過來」，而是因為我發現：一件工作裡，已經出現可以被獨立拆出去的任務。

有些可以同時進行，有些需要不同角度來審查，有些則必須等上一階段確認之後才能開始。

最近兩次製作教材的經驗，剛好讓我看到兩種很不一樣的 SubAgent 使用方式。

第一個案例：GitHub 初學者講義

前陣子我在製作一份 GitHub 初學者講義。

因為是要真的拿來教初學者，所以我對這份教材有幾個很基本，但也很麻煩的要求：

資訊必須正確。

操作畫面必須跟現在的 GitHub 對得起來。

教學順序要合理。

而且不能因為我自己已經很熟，就忽略第一次接觸 GitHub 的人可能卡住的地方。

所以這份講義其實經歷了很多輪修改。

從早期版本開始，就不只是單純潤稿，而是逐頁檢查、查 GitHub 官方文件、實際登入操作核對，甚至把一些看起來合理、但找不到足夠證據支持的說法重新拉出來查證。

講義一路從 v1、v5、v6 到後來的 v8，不斷進行內容、教學邏輯、一致性與資訊安全等不同角度的檢查。

到了後來，文字內容差不多完成，我又碰到另一個問題：

截圖很多。

初學者講義不可能只寫：

「接著到 Settings 裡設定 Pages。」

對第一次使用 GitHub 的人來說，可能還需要知道：

Settings 在哪裡？

Pages 在哪裡？

畫面現在到底長什麼樣子？

所以我開始準備大量操作截圖。

但就在這個時候，我突然發現：

我其實沒有必要停下所有工作，自己一張一張去操作、截圖、整理。

於是我派出了第一個 SubAgent。

我只負責把 GitHub 打開、登入完成，接下來讓它依照講義內容實際操作，去取得需要的畫面。

但有趣的是，這時候主線工作並沒有停下來。

這也是我後來覺得很重要的一個觀念。

它不是：我 → 主 Agent → SubAgent

這種單純的上下級關係。

比較像是：

我和主要 Agent 還留在原本的工作主線上繼續處理教材，另外再從主線分出幾條支線。

所以在第一個 SubAgent 去處理 GitHub 截圖的同時，我又派出了第二個。

第二個 SubAgent 不負責截圖。

它的工作是重新從不同角度審查講義。

看看技術內容有沒有問題、教學流程是否合理，以及一個真正的 GitHub 初學者可能在哪些地方產生誤解。

接著第三個 SubAgent 也出動了。

它負責的又完全是另一件事：規劃未來搭配這份講義的教學影片。

於是同一個時間，工作變成：主線仍然繼續處理講義。

一條支線操作 GitHub、準備截圖。

一條支線重新審查教材。

另一條支線開始規劃影片。

這時候我第一次很明顯感受到 SubAgent 帶來的改變。

原本必須排隊完成的工作，開始可以平行往前走。

但這不代表每個 SubAgent 都可以自己決定

例如審查 Agent 發現一個問題，它可以提出建議。

截圖 Agent 可以把畫面整理回來。

影片規劃 Agent 可以提出影片架構。

可是：

哪一張圖要不要放？

某個建議要不要採用？

教材內容要不要修改？

影片應該怎麼呈現？

最後仍然要回到主線判斷。

這也是我一直很在意的一件事：

Agent 可以執行，可以找問題，可以提出方案，但判斷與責任不能一起外包。

第二個案例：22 節生活科技課程

另一個案例就比 GitHub 講義更複雜。

這學期我的生活科技課程大約有 22 節，接近 11 週。

裡面包含木工、電子元件與電路，以及最後整體產品組裝等內容。

表面上看，每一段好像是不同單元。

但是它們其實又彼此相關，因為最後學生會把這些知識、技能與零件整合成一個作品。

所以這次一開始，我先讓 Agent 根據我的參考資料以及過去累積的教材，建立整套課程簡報的雛形。

但我沒有直接拿來用。

我自己先進行第一輪人工核對。

一頁一頁看。

哪裡要修改、哪裡要增加、哪裡要刪掉，我自己先處理。

這件事情做了一段時間之後，我開始發現一個長篇教材很容易出現的問題。

因為整份簡報太長，而且中間經歷很多次修改，我自己也可能產生盲點。

例如：

前面使用了一個名詞，後面卻換了另一種說法。

某一段內容單獨看沒有問題，但放回22節課程裡，銜接可能不夠自然。

某個步驟老師覺得理所當然，可是學生第一次看到可能根本不知道發生什麼事。

甚至是我自己改太多次之後，已經開始「看不到」問題。

所以這次，我沒有只跟主要 Agent 說：

「幫我再檢查一次。」

我直接派出了五個不同角色的審查 Agent。

有人從不同教學關卡需要的專業內容來看。

有人從整體教師角度看22節課的教學邏輯。

有人刻意站在學生角度，看哪些地方可能難懂。

不同 Agent 有不同的審查任務。

目的不是讓五個 AI 一起重新寫一份簡報。

而是：

讓五個角色去找五種不同類型的問題。

但是，審查完還沒有結束

這也是這一次和 GitHub 講義很不一樣的地方。

簡報確認之後，我還有學習單。

而且原本第一輪規劃課程時，其實就已經做過學習單的雛形。

問題來了。

簡報已經修改過這麼多次，原本的學習單還能直接用嗎？

答案當然不能假設是「可以」。

所以接下來，我又開始派新的 SubAgent。

有的負責根據最新版簡報重新整理、製作或修正學習單。

另外的工作則是開始回頭檢查教案。

因為如果簡報內容改了，學習活動改了，學習單也跟著改，那麼原本教案裡的節次安排、活動內容與教材之間，很可能也必須重新對齊。

於是 SubAgent 的任務又變了。

前一批是：

Review——審查。

後一批則開始變成：

Production——製作。

接著還有：

Alignment——對齊。

也就是開始檢查：

簡報教的內容，學習單有沒有接到？

學習單要求學生完成的事情，前面的教材有沒有教？

教案寫的活動，跟現在最新版的簡報還是不是同一件事情？

各節課之間的順序、任務與成果是不是一致？

這時候 SubAgent 已經不是單純幫我「做教材」。

它開始協助我維持一整套教材系統之間的一致性。

而且，最好不要讓作者自己驗收自己

這次我另外很在意一件事情。

如果某一個 Agent 剛剛負責製作學習單，完成之後又叫它自己說：

「請幫我確認這份學習單有沒有問題。」

其實很容易延續自己原本的思路。

就像我們自己寫完文章後，常常抓不到自己的錯字一樣。

所以在一些階段完成之後，我會再讓不同的 Agent 進來審查。

也就是：

製作者和審查者盡可能分開。

這時候整個流程就不再只是：AI 做 → 我看。

而開始接近：

生成 → 人工修改 → 多角色審查 → 修正 → 衍生教材製作 → 跨教材對齊 → 獨立驗收 → 教師最後確認。

這已經是一條完整的工作流程。

兩個案例，其實代表兩種不同的 SubAgent 用法

後來我把這兩次經驗放在一起看，才發現它們很有意思。

GitHub 初學者講義比較像：

平行型 SubAgent

主線繼續工作。

旁邊同時分出：

截圖、審查、影片規劃。

它們彼此的依賴性不高，所以可以同時往前跑。

核心是：

Parallelization——平行化。

生活科技22節教材則比較像：

流程型 SubAgent

先建立簡報。

教師修改。

再進行多角色審查。

簡報確認之後，才開始重新處理學習單。

學習單與簡報調整後，又必須回頭對齊教案。

接著再由不同 Agent 進行獨立驗收。

它有很明顯的上下游關係。

核心不是「全部一起做」，而是：

上一階段穩定了，下一批 Agent 才開始工作。

這比較接近：

Agent Orchestration——代理協作編排。

所以，什麼時候適合派 SubAgent？

經過這兩次經驗，我現在不太會用「工作很多」來判斷。

我反而會問幾個問題。

1. 這件事情能不能被獨立切出去？

例如：

查資料、操作截圖、測試、審查、整理教材、規劃影片。

如果任務邊界很清楚，就比較適合交給 SubAgent。

2. 它能不能跟主線同時進行？

如果我現在還在處理教材，而另一個 Agent 已經可以去截圖，那就沒有必要讓兩件事情排隊。這就是 GitHub 案例。

3. 我是不是需要「另一雙眼睛」？

有些時候派 SubAgent 不是為了產能，而是為了降低盲點。

尤其做教材時，我覺得這非常重要。

因為教材作者最容易出現一句話：

「這個應該很清楚吧？」

但學生可能完全不這麼覺得。

所以我會刻意讓不同角色來看同一份內容。

4. 這個工作是不是必須等上一階段確認？

如果答案是「是」，就不應該為了追求多 Agent 而全部同時開始。

例如簡報還沒有穩定，就大量重做學習單。

後面簡報又修改，學習單就得重新來一次。

這時真正重要的不是「多開幾個 Agent」，而是知道：

什麼時候才該叫哪一個 Agent 出場。

5. 製作者是不是也成了最後的審查者？

如果是，我通常會再考慮安排另一個 Agent。

因為「做得出來」跟「能不能發現自己做錯」是兩種能力。

這也是為什麼我越來越常把：

製作 跟 審查

拆成不同任務。

SubAgent 不是越多越厲害

這也是我覺得很需要提醒的一件事情。

如果只是改一句話，根本不需要派三個 SubAgent。

如果一件工作前後高度依賴，硬切成很多塊，最後反而會增加溝通與整合成本。

甚至很多人一起做一套教材，還可能出現另一種問題：

每一部分單獨看都很好，

但是放在一起不像同一套東西。

所以真正重要的是：

「我的工作到底該怎麼拆？」

我現在反而覺得，SubAgent 最重要的不是 Prompt

以前使用生成式 AI，大家很常談 Prompt。

怎麼下指令？

怎麼問得精準？

當然還是重要。

可是進入 Agent 的使用情境之後，我覺得另一組能力開始變得更重要：

Task Decomposition

任務拆解

知道哪些事情應該拆出去。

Parallelization

平行處理

知道哪些事情可以同時進行。

Agent Orchestration

代理協作編排

知道誰應該先做、誰應該後做，哪些結果是下一個 Agent 的輸入。

Quality Control

品質控制

知道怎麼查證、怎麼找第二意見，以及誰來驗收最後成果。

而這幾件事情，其實跟教師平常做課程設計很像。

我們本來就在做：

設定目標。

安排活動。

觀察結果。

發現問題。

調整。

再驗證。

Agent 只是讓這個過程裡，多了一批可以被安排工作的「數位協作者」。

所以現在如果有人問我：

「什麼時候應該派 SubAgent？」

我大概不會回答：

「事情很多的時候。」

而會回答：

當你開始看見一個複雜任務裡，其實存在不同角色、不同階段、不同專業、不同驗證需求，而且這些工作可以被清楚拆開的時候，就值得考慮 SubAgent。

GitHub 講義讓我看到的是：

工作可以分出去，同時前進。

22節生活科技教材讓我看到的是：

有些工作不能同時開始，而是必須經過審查、確認、對齊，再把成果交給下一批 Agent。

所以真正有趣的，或許已經不用太在意「AI 能幫我做什麼？」

而開始要變成：「我要怎麼安排這群 AI 工作？」

但不管 Agent 再多，我自己還是會保留最後一道工作。

判斷。

因為 Agent 可以幫我查、幫我做、幫我看、幫我挑錯。

但是：

這樣適不適合我的學生？

這是不是我要的教學方式？

這份教材最後能不能進教室？

最後還是得由教師自己決定。

我想，這也是我目前使用 Agent 最重要的一條界線：

執行可以分工，判斷不能外包。