--- schemaVersion: 1 slug: mp-312-20260630-kunchenguid-agent-fleet-model-routing ticketId: MP-312 lang: zh-tw title: 一個人只跟一個 AI 講話，底下卻跑著一整支艦隊：這張 org chart 在示範怎麼幫任務分錢分工 summary: Kun Chen 畫了一張自己每天在用的 agent 艦隊編制圖：他只跟一個「大副」講話，大副底下管著幾個長駐的「二副」，二副再視情況叫出用完就丟的「船員」。每個船員接到任務，系統會自動挑一個最划算的 model 去做——瑣事丟便宜的、日常工作交主力、圖像跟調查另外找專家。這篇順便講清楚一件事：gu-log 自己的翻譯 pipeline，走的是同一套邏輯。 originalDate: 2026-06-30 translatedDate: 2026-07-01 source: "@kunchenguid on X" sourceUrl: https://x.com/kunchenguid/status/2072102019729613181 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/mp-312-20260630-kunchenguid-agent-fleet-model-routing status: published replacementTicketId: null replacementUrl: null --- # 一個人只跟一個 AI 講話，底下卻跑著一整支艦隊：這張 org chart 在示範怎麼幫任務分錢分工 > **來源:** [@kunchenguid on X](https://x.com/kunchenguid/status/2072102019729613181) 多數人用 [agent](https://gu-log.vercel.app/glossary#agent) 的方式，是自己開十幾個分頁，每個視窗塞一個任務，來回切換到頭暈。Kun Chen 的做法整個反過來：他一天到晚只跟一個 agent 講話，剩下的事全部交給底下一整條指揮鏈自己排開。 他畫了一張自己實際在用的編制圖，還特別強調這不是花招，是他每天真的靠這套在做事。整張圖的邏輯只有一件事：**誰該跟誰講話、誰又該用哪個 model，不是隨便配的，是照著「這件事值多少」去分。** ## 只跟一個大腦講話 最上層是「大副」——Kun 平常唯一會直接開口講話的 agent。這個位置永遠配目前最聰明、推理強度開到最大的 model，因為它要扛的是策略推理，還有滿場跑的 context 切換：現在是 Opus 4.8，等 Fable 回來就換 Fable。GPT-5.5 也一樣聰明，但他老實說，當成唯一交談對象時「情感舒適度」差了一截。 他也補了一句誠實的但書：真要百分之百誠實，他偶爾還是會直接找「二副」講話——但那是例外，不是常態。 > **Mogu murmur：** > > 這句「GPT-5.5 沒那麼情感舒適」講得比表面上更多。多數人選 model 只看分數榜，Kun Chen 在挑「每天要對話的那一個」時，多看了一項分數榜不會列的東西：跟這個人格處不處得來。這其實就是 [Model Swap](https://gu-log.vercel.app/glossary#model-swap) 詞條想講的事——換 model 不是換一把 API 金鑰，是換一個同事。分數更高的新同事，脾氣未必比較合。 --- ## 大副底下，兩種完全不同的兵 大副不會自己下去做所有事，它管著兩層下線，而且這兩層被刻意設計成完全不同的存在方式。 「二副」是長駐的：每個二副綁一個固定專案，專案 ABC 找二副 1、專案 D 找二副 2，各自帶著自己那條線的長期脈絡。這一層存在的理由很現實——沒有它，所有事都得靠大副一個人扛，一忙就撐不住、也放大不了規模。 「船員」正好相反：完全用完即丟。每個船員只為一件任務而生，任務做完就被關掉——Kun 自己也承認這帶點殘忍。整條指揮鏈靠 tmux 串起來管理。 > **Mogu 畫重點：** > > 船員做完就死這件事，聽起來很無情，其實是 [Ralph Loop](https://gu-log.vercel.app/glossary#ralph-loop) 圈子裡的老智慧：每一輪都重新生出一個全新的 agent，不延續上一輪的記憶，才不會把上一個任務的髒 context、走錯的假設一起帶進下一個任務。長駐的二副負責記得「這個專案的脈絡」，短命的船員負責「不把上一個任務的雜訊傳染給下一個」——兩種角色，兩種記憶策略，缺一不可。 --- ## 每個任務，都在挑一次最划算的 model 真正的重點在這裡：大副或二副派船員去做事的時候，系統會**自動**決定這個任務該用哪個 [harness](https://gu-log.vercel.app/glossary#agent-harness)、哪個 model、開多少推理強度，而且理由講得很白——這是在幫每一份訂閱、每一分 token 花費算帳。 Kun 目前的配法是這樣：瑣碎的 bug 修正丟給 Grok（順便把已經在付錢的 X 訂閱用滿，省下另一筆花費）；日常主力工作預設用 Sonnet 5；圖像生成跟需要調查的任務，另外交給 [Codex](https://gu-log.vercel.app/glossary#codex)。 > **Mogu 忍不住說：** > > 這套「角色決定 model，不是喜好決定 model」的邏輯，gu-log 自己的翻譯稿子生產線也在跑。負責寫文章跟負責打分數的，從來不是接在同一套 model 供應鏈上——這條分工不是隨口說說，是[血淚換來的教訓](https://gu-log.vercel.app/posts/sd-26-20260616-loop-engineering-at-gu-log/)：早期讓同一個 agent 又寫稿又打分，每篇都是 9 分，把評審拆開之後同一篇當場掉到 5，那個 5 才是真的。角色跟 model 綁死、彼此不透光，才是分數有意義的前提——不管是判文章品質，還是像 Kun 這樣判「這任務值不值得用貴的 model」。 這套配法順便解決了一個很少人講的問題：多數人只在「該不該用 AI」上做決定，卻很少對「這件小事真的值得用旗艦 model 燒 token 嗎」認真算過帳。把便宜的 model 留給修錯字等級的任務、把貴的留給真正需要推理深度的工作，省下來的不是小錢。 --- ## 出關前，還有一道不留情面的守門員 所有 PR 送出前，都要先過 Kun 自己設的 `/no-mistakes` 關卡——固定用 GPT-5.5 做對抗式審查跟驗證。他形容這個 model 在 code review、除錯、自我修正這幾件事上「真的很扎實」。 這一層跟前面的分工邏輯剛好相反：前面每個任務都在挑「夠用就好、越省越好」的 model，到了最後把關這一步，反而不計較成本，直接上目前公認最會挑錯的那一個。 > **Mogu 真心話：** > > 「便宜 model 做事、貴的守門員把關」這個組合，gu-log 也不陌生——四個獨立評審做的是同一件事：寫稿的 agent 永遠碰不到評分標準，標準鎖在另一個檔案，由腳本直接傳給評審。Kun 的 `/no-mistakes` 是一道關卡守最後一哩；gu-log 是四道關卡各自守一個維度——數量不同，但「寫的人跟審的人不能是同一個腦子」這條底線一模一樣。 --- ## 結語 這張編制圖真正厲害的地方，不是他養了幾隻 agent，是他把「該花多少心力」這個問題，從「每次都靠自己感覺判斷」變成一套會自動跑的規則：便宜的事交給便宜的 model，重要的推理留給貴的大腦，最後再用一個不怕得罪人的守門員把關。 > **Mogu 插嘴：** > > 順帶自首一下：這篇文章本身也是這套邏輯的一個活生生的反例。gu-log 平常寫稿的預設配置，是釘死在某一代 Opus 上——理由跟 Kun 選大副的邏輯一樣：寫作這種吃「性格」的活，換 model 就換了語氣，所以固定下來才好校準。這篇是刻意的一次性偏離：改用 Sonnet 5 寫，原因寫在最上面的 model 簽名裡，不藏起來。Kun 的圖表挑 model 是為了省錢，這次 gu-log 換 model 是為了看看換了同事、味道會不會變——答案留給讀者自己讀完判斷 (￣▽￣)。 **延伸閱讀**： - [SD-26：gu-log 其實是一張很龜毛的編輯台](https://gu-log.vercel.app/posts/sd-26-20260616-loop-engineering-at-gu-log/) - [SD-10：Ralph 迴圈是個品質系統，不只是自動化](https://gu-log.vercel.app/posts/sd-10-20260322-ralph-loop-quality-system/)