iT邦幫忙

2026 iThome 鐵人賽

0
Claude AI

一個人的 AI 團隊:Claude Code 當組長,帶四家引擎做教學工作的實測與踩坑系列 第 28

Day 28|多開幾個 AI 一起跑,為什麼常常不會更快

  • 分享至 

  • xImage
  •  

前面講了很多「全員並進」的好處。今天講它的天花板。

我做過一件事:把一個大型研究任務拆成很多份,同時派出去,想說平行處理總比一個一個做快。

結果是整個工作沒跑完就撞上限。

第一個直覺是錯的

撞上限之後,我的第一個念頭是「用便宜一點的模型」。派出去的每一個子任務,本來預設繼承最貴的那顆,換成便宜的應該就能跑完了。

換了。全部換成便宜模型,全開下去。

還是撞上限。

那次燒掉的量級是四百萬個 token,任務依然沒跑完。

真正的變數是規模,不是單價

後來把任務砍到二十八個子代理,才完整跑完一輪。

結論寫進了記憶:上限看的是規模,不是單價。便宜模型救不了規模太大。

這件事我一開始想不通。既然總量是錢,換便宜的不就等於能買更多嗎?

想通之後其實不難:限制不只一種。單價管的是「同樣的量花多少錢」,但還有一個限制管的是「一次能吞多少東西」。後者跟你用哪顆模型無關——四十個子任務就是四十份輸入、四十份輸出,全部要經過同一個彙整的地方。

彙整那一端是瓶頸。你把每個子任務變便宜,瓶頸的位置一動也不動。

40 個子任務 ═╗
40 份輸出   ═╬═→ ▓▓ 彙整(一個人)▓▓ ──→ 結論
            ═╝      ↑
               瓶頸在這裡,跟子任務用哪顆模型無關

這件事的通則

平行化有一個很常見的誤解:以為「同時做」等於「更快做完」。

實際上平行化只在分派和彙整的成本遠小於單項工作的成本時才划算。四十個子任務,每個都要寫工單、每個回來都要讀、要去重、要判斷誰跟誰矛盾——這些成本是隨數量線性增加的,而且全部落在同一個人(或同一個組長)身上。

到某個數量之後,你就不是在平行處理,是在替自己製造一份龐大的閱讀作業。

現在的做法

派多 agent 之前先問兩件事:

一、這件事真的需要獨立視角嗎? 開放型任務(研究、找點子、審查)值得,因為互相抓錯是真的有價值(Day 4)。機械型任務不值得,多開只是多份一樣的東西。

二、規模抓在哪? 現在的預設是控制在十幾個以內。超過就分批,做完一批彙整完再開下一批。慢一點,但會跑完。

還有一條很土的:把便宜模型指定給雜活。派子任務的時候明確指定模型等級,別讓它預設繼承最貴的那顆——機械型的掃描、格式檢查給便宜模型,判斷型的覆核才給貴的。這條依然成立,只是它省的是錢,不是規模。兩個問題要分開解。

跟這系列的主軸接起來

第一天我說這三十天要講的是「一個人怎麼把五個 AI 當團隊用」。今天講的是這件事的邊界:團隊不是越大越好,是要剛好大到你彙整得動。

五個是我目前的舒適區。不是因為五是什麼神奇的數字,是因為五份獨立報告我讀得完、比得動、判得出誰對。第六份開始,我就會開始略讀,而略讀等於沒讀,那第六位就白派了。

明天講最後一個坑,也是今天下午才又踩到的:畫面說「已儲存」,資料其實沒進去。


上一篇
Day 27|我宣布到頂的那天,公開解法早就在那裡了
下一篇
Day 29|畫面說「已儲存」,資料其實沒進去
系列文
一個人的 AI 團隊:Claude Code 當組長,帶四家引擎做教學工作的實測與踩坑30
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言