用 Sub-Agent 解決長任務：AI 多工處理的設計模式

跟 AI 助理對話時，最讓人崩潰的事情是什麼？不是它答錯，不是它幻覺，而是你丟了一個複雜任務出去，然後整個對話就卡住了。你眼睜睜看著它一步一步慢慢跑，想問個別的問題？不行，排隊。想改個東西？等著。整個使用體驗就像回到了單核心 CPU 的年代——一次只能做一件事。

問題的本質：LLM 是同步的

先搞清楚為什麼會卡住。LLM 本質上是一個同步處理器——你給它一個 prompt，它生成一個回應，在這個回應完成之前，它沒辦法處理其他事情。這在簡單對話中完全不是問題，問個問題幾秒就回了。

但當任務變複雜，問題就來了：

批量 API 呼叫：比如要幫你補建過去 28 天的每日報告，每天要呼叫好幾個 API、整理資料、寫入檔案，整個流程跑下來可能要 10 分鐘
爬取多個網頁：要比價、要做市場調研，得一個一個網站爬過去
寫多篇長文：像現在這樣一次寫三四篇部落格文章，每篇都要一兩千字
全面性分析：投資分析、技術評估，需要蒐集大量資料再交叉比對

這些任務有個共同特徵：耗時長、不需要即時互動。你丟出去之後其實不需要一直盯著，但傳統的 AI 助理架構就是會把你的對話鎖住。

更具體地說，假設你請 AI 助理整理過去一個月的投資數據。它要依序呼叫 API 拿每天的股價、三大法人買賣超、融資融券異動，每個 API call 都要等個一兩秒。光是資料蒐集就要好幾分鐘，整理分析又是幾分鐘。這整段時間你的對話通道就是被佔住的——你連問一句「今天天氣怎樣？」都得排隊等它跑完。

Sub-Agent 模式：分身之術

解法其實很直覺——既然一個 agent 忙不過來，那就多生幾個出來。

這就是 Sub-Agent 模式的核心概念：

主 agent 收到任務，先評估這個任務大概要花多久
如果預估時間較長，主 agent 不自己做，而是 spawn 一個獨立的 sub-agent 在背景執行
主 agent 立刻回到對話，告訴你：「我派了一個分身去處理，好了會通知你」
Sub-agent 在背景默默跑完，把結果送回指定的地方（一個頻道、一個檔案、或直接回報給主 agent）

聽起來很像作業系統的多執行緒對吧？概念上確實是。主 agent 就是主執行緒，sub-agent 就是 worker thread。差別在於每個 sub-agent 其實是一個完整的 LLM session，有自己的 context、自己的工具存取權限。

Sub-Agent vs 傳統 Queue 系統

你可能會問：「這跟 message queue + worker 不是一樣嗎？」概念類似，但有幾個關鍵差異：

Worker 是預定義的程式，只能執行寫好的邏輯。Sub-agent 是一個完整的 LLM，可以處理任意指令。你不需要事先寫好每一種任務的處理程式碼。
Worker 不會「思考」。Sub-agent 遇到意外情況可以自行判斷怎麼處理，不會因為少一個 edge case 就整個 crash。
Worker 需要 deploy 和維護。Sub-agent 隨用隨 spawn，不用管 scaling、不用管 deploy，用完就消失。

當然，sub-agent 也有 worker 做不到的缺點——它比較貴（每個 sub-agent 都在燒 token），而且行為不像程式碼那麼 deterministic。所以它不是要取代傳統 queue 系統，而是填補「太複雜不適合寫成固定程式碼，但又太耗時不適合主 agent 自己做」的那個空間。

什麼時候該 Spawn Sub-Agent？

不是所有任務都適合丟給 sub-agent。以下是我實際使用下來歸納的判斷標準：

適合 spawn 的場景：

大量 API 呼叫：批量建立報告、批量更新資料。反正就是「迴圈 × N 次」的那種任務。
等待外部回應：爬取多個網頁、呼叫多個外部服務。這類任務大部分時間都在等 I/O，不需要佔住主對話。
任務本身就很長：寫多篇文章、做大範圍的分析報告。產出量大，不可能幾秒搞定。
獨立且不需互動：任務規格明確，中途不需要問你「這裡要不要改？」
可以平行化的多項任務：比如同時分析五支股票的技術面，每支股票的分析互不相依，就可以 spawn 多個 sub-agent 平行跑。

不適合 spawn 的場景：

需要即時對話：你想一邊給意見一邊讓 AI 修改，這種來回互動的任務不適合丟到背景。
小任務：查個天氣、算個數字、回答一個問題——spawn sub-agent 的開銷比任務本身還大，不值得。
需要主 session context 的任務：sub-agent 看不到主 agent 的對話歷史。如果任務需要「記得我們剛剛聊了什麼」，就不適合。
有安全敏感操作的任務：sub-agent 的行為不容易即時監控。如果任務涉及刪除資料、發送訊息等不可逆操作，最好還是在主 agent 的監督下進行。

簡單的判斷原則：如果你覺得「這個任務我丟出去之後可以去做別的事」，那它就適合 sub-agent。

設計考量：魔鬼藏在細節裡

Sub-Agent 模式看起來簡單，但要做得好有幾個關鍵的設計考量：

1. Context 隔離

Sub-agent 是完全獨立的 session。這代表它不知道你剛剛跟主 agent 聊了什麼。很多人踩到的第一個坑就是這個——覺得 sub-agent 應該「知道」前面的對話，結果做出來的東西完全不對。

解法：Task prompt 要寫得夠完整。 把 sub-agent 需要知道的所有 context 都塞進 task prompt 裡。與其寫「幫我把剛剛討論的那個功能實作出來」，不如寫「實作一個 XXX 功能，規格如下：1. 2. 3.」

2. Task Prompt 的品質決定一切

這是最重要的一點。Sub-agent 只看到你給它的 task prompt，所以這個 prompt 的品質直接決定產出品質。

好的 task prompt 應該包含：

明確的目標：做什麼、做到什麼程度
具體的規格：格式、風格、技術要求
必要的 context：背景資訊、相關資料
交付方式：結果要存到哪裡、用什麼格式
限制條件：哪些事不要做、哪些邊界要注意

把它想成你在寫一份外包需求文件——對方沒有跟你開過會，所有資訊都要寫在文件裡。

舉個實際的例子，以下是一個寫得不好的 task prompt：

1	幫我擴充這些部落格文章。

問題很多：哪些文章？擴充到什麼程度？什麼風格？存到哪裡？sub-agent 只能猜測你的意思。

改善後的版本：

擴充以下 5 篇 Hexo 部落格文章到至少 1500 字（中文字數計算）。

檔案路徑：
1. ~/Blog/source/_posts/article1.md
2. ~/Blog/source/_posts/article2.md

處理步驟：
1. 用 read 讀取每篇文章
2. 保留原本的 front matter 完全不動
3. 在原有內容基礎上擴充
4. 用 write 寫回原檔

寫作風格：
- 第一人稱，繁體中文台灣用語
- 自然口語，有個人觀點
- 程式碼和專有名詞保持英文

完成後回報每篇的字數。

看出差別了嗎？後者幾乎不可能被誤解。

3. Timeout 設定

一定要設 timeout。我踩過的坑：一個 sub-agent 因為某個 API 一直 retry 失敗，跑了快一個小時才被我發現。設一個合理的 timeout（比如 15 分鐘），超時就自動結束，比讓它漫無目的地跑下去好得多。

經驗法則：一般任務設 10-15 分鐘，大批量任務（像處理 28 天的報告）可以放寬到 30 分鐘，但超過 30 分鐘的任務建議拆分成多個 sub-agent。

4. 結果投遞方式

Sub-agent 完成後，結果要送到哪裡？常見的幾種方式：

送回主 session：適合需要主 agent 後續處理的場景
送到特定頻道：比如送到 Discord 的某個頻道，你直接在那邊看結果
寫入檔案：最穩定的方式，sub-agent 把結果寫成檔案，你隨時去看

我個人最常用的是「寫入檔案 + 通知主 agent」的組合。檔案不會遺失，通知讓我知道什麼時候可以去看。

實際案例

分享幾個我實際使用 sub-agent 的場景（當然都匿名化了）：

案例一：批量寫部落格文章

有一次需要同時產出 4 篇部落格文章。如果讓主 agent 一篇一篇寫，整個對話大概要被佔住 20 分鐘。改成 spawn 一個 sub-agent，把 4 篇的大綱、規格、風格要求一次丟進去，sub-agent 在背景全部寫完再交回。主 agent 在這段時間可以繼續處理其他問題——回覆訊息、查資料、排行程。

有趣的是，後來我發現如果 4 篇文章的主題互相關聯，交給同一個 sub-agent 反而比 spawn 4 個分別處理更好。因為同一個 sub-agent 可以確保文章之間的連貫性，避免不同 agent 寫出重複的觀點或矛盾的論述。

案例二：補填歷史資料

某個自動化流程需要回填過去 28 天的每日資料。每天的資料都要呼叫 API 取得、整理格式、寫入資料庫。直接交給 sub-agent 跑，它花了大約 10 分鐘把 28 天的資料全部補完。這段時間主 agent 完全不受影響，繼續正常回答問題。

這個案例有一個額外的設計：我在 task prompt 裡加了「每完成 7 天就回報一次進度」的要求。這樣我不用一直去查 sub-agent 跑到哪了，它會主動告訴我。

案例三：平行跑分析報告

要測試不同的分析報告模板，一共 4 個版本。每個版本都要蒐集資料、套用模板、產出報告。直接 spawn 4 個 sub-agent 平行跑，速度比依序執行快了 3 倍不止。

但這裡踩了一個坑：4 個 sub-agent 同時呼叫同一個 API，觸發了 rate limit。後來調整成錯開啟動時間，每個 sub-agent 間隔 30 秒再 spawn，問題就解決了。

案例四：程式碼重構

有一次要把一個 monolithic 的 service 拆成幾個獨立模組。這種大範圍的重構任務很適合 sub-agent——規格明確（哪些函式要搬到哪個模組）、不需要即時互動（我已經想好怎麼拆了）、而且耗時（幾十個檔案要改）。

spawn 一個 sub-agent 去做，它花了大約 15 分鐘把整個重構完成，包括更新所有的 import 路徑和相關的測試。我在這段時間繼續處理其他的 code review。

監控與管理

Sub-agent 放出去之後不是就不管了（雖然大部分時候確實不用管）。OpenClaw 這類框架通常提供幾個管理工具：

列出所有 session：看看目前有幾個 sub-agent 在跑、跑了多久
查看 session 歷史：sub-agent 做了哪些操作、呼叫了哪些工具
追加指令：如果中途想修改需求，可以直接對 sub-agent 發送訊息

這就像你有一個團隊在背景幫你做事，你隨時可以去看進度、調整方向。

我自己的習慣是：spawn 之後先繼續做自己的事，大約每 5 分鐘瞄一眼 session 列表，確認 sub-agent 還在正常跑。如果超過預期時間還沒完成，就去查看它的歷史記錄，看看是不是卡在哪一步。

踩坑紀錄

用了幾個月下來，踩過的坑也不少：

坑一：重複執行的冪等性問題

有一次 sub-agent 跑到一半 timeout 了，我重新 spawn 了一個。結果新的 sub-agent 從頭開始跑，把已經做完的部分又做了一遍——產生了重複的資料。

教訓：任何可能被重跑的任務都要設計成冪等的（idempotent）。 寫入前先檢查是否已存在、用唯一識別碼避免重複。這不只是 sub-agent 的問題，是所有非同步任務的基本原則。

具體做法：在 task prompt 裡明確要求 sub-agent「寫入前先檢查檔案是否已存在，如果存在就跳過」。或者用 upsert 而不是 insert。

坑二：Task Prompt 太精簡

早期我寫 task prompt 很隨意，覺得「它應該懂我的意思吧」。結果 sub-agent 做出來的東西常常不是我要的。後來學乖了，每次都把規格寫得非常詳細——寧可囉嗦也不要模糊。

這裡有一個 tradeoff：prompt 越長，token 消耗越大。但比起 sub-agent 做錯了要重跑，多花一點 token 在 prompt 上絕對划算。

我後來養成一個習慣：寫完 task prompt 之後，自己先讀一遍，想像自己是一個完全不了解前因後果的人，看能不能光靠這份 prompt 就做出正確的產出。如果不行，就繼續補充。

坑三：不是所有事都要 spawn

剛開始用的時候太興奮，什麼任務都想 spawn sub-agent。結果反而更慢——spawn 本身有 overhead，小任務直接在主 agent 做完反而更快。後來我建立了一個經驗法則：預估超過 2 分鐘的任務才考慮 spawn。

坑四：多個 Sub-Agent 的資源競爭

這個比較進階。當你同時 spawn 好幾個 sub-agent，它們可能會競爭同一個資源——比如同時寫入同一個檔案、同時呼叫同一個有 rate limit 的 API。

我的解法是在 task prompt 裡限制每個 sub-agent 只操作自己的範圍。比如 sub-agent A 處理 1-7 天的資料，sub-agent B 處理 8-14 天的資料，各自寫入不同的檔案。如果最後需要合併，再由主 agent 來做。

成本考量

Sub-Agent 不是免費的。每個 sub-agent 都是一個完整的 LLM session，都在消耗 token。一些成本相關的考量：

Token 消耗：每個 sub-agent 的 system prompt、task prompt、工具定義都算 input token。如果你的系統 prompt 很長（像我的超過 2000 token），每 spawn 一個 sub-agent 就是一筆固定成本。
工具呼叫：sub-agent 呼叫的每一個工具，回傳的結果也是 token。批量讀取 28 個檔案，每個檔案的內容都算在 token 裡。
模型選擇：不是每個 sub-agent 都需要用最貴的模型。寫文章可能需要 Opus 級別的品質，但批量重命名檔案用 Haiku 就夠了。

我的做法是：根據任務的複雜度選擇模型。簡單的資料搬運用便宜的模型，需要思考和判斷的用好的模型。長期下來能省不少錢。

從單執行緒到多執行緒

Sub-Agent 模式本質上就是讓 AI 助理從「單執行緒」進化成「多執行緒」。

回想一下電腦的發展歷史——從單核心到多核心，從單工到多工，每一次進化都帶來使用體驗的質變。AI 助理也在走同樣的路。當你的助理可以同時處理多件事，一邊在背景跑報告、一邊跟你聊天、一邊整理資料，那種「它真的在幫我工作」的感覺是完全不同的。

這不是什麼遙遠的未來——如果你正在使用支援 sub-agent 的 AI 助理框架（像 OpenClaw），現在就可以開始享受這種多工體驗。第一次看到主 agent 說「我派了分身去處理，我們繼續聊」的時候，你會覺得：對，這才是 AI 助理該有的樣子。

心得總結

用了幾個月 sub-agent 模式下來，我覺得它最大的價值不只是「省時間」，而是改變了我跟 AI 助理互動的心態。以前我會下意識地避免丟太大的任務出去，因為知道一丟出去整個對話就卡住了。現在我反而會主動把大任務拆解出來丟給 sub-agent，自己繼續處理其他事情。

它也讓我更深刻地理解了一件事：好的工具設計是讓使用者不需要遷就工具的限制。 以前的 AI 助理逼你適應它「一次只能做一件事」的限制，sub-agent 模式則是讓工具去適應你「我同時有好幾件事要處理」的工作方式。

如果你也在經營自己的 AI 助理系統，強烈推薦研究一下 sub-agent 模式。設定的門檻不高，但帶來的使用體驗提升是非常有感的。