050 · 一人管理三機 agent 艦隊的教訓
Kyle 獨自維運三台機器上的 AI coding agent 艦隊，從一人扛三角色到分層管理、跨機協調的實戰整理。
原標題：I Run a Fleet of AI Agents Across Three Machines. Here's What Broke. - Kyle Jaejun Lee, KRAFTON
重點摘要
- 從人肉排程到組織階層Kyle 一開始靠終端機與 tmux 同時盯好幾個 agent 對話，自己身兼排程、記憶、審核三個角色，撐不住之後，借鏡高階主管管理上千人的方式，把 agent 群改造成 CEO、VP、manager、worker 的階層，每層只看自己那塊 context，他只審最上層的結果。
- 把 state 搬出模型、放到磁碟每個 entity 有自己的磁碟工作區，共用內容放 shared、機器專屬狀態放 machines；視窗塞滿時不再靠系統自動摘要，而是直接在 Claude 裡清空 context，讓 agent 讀回自己寫的 handoff 檔案接著做，即使當機也能靠檔案接續。
- 審核閘道統一把關任何一層要動作都要先送出計畫並卡住等待，Kyle 核准後 hook 才會自動觸發執行，不用再逐一走進每個工作視窗盯進度；這個閘道還是艦隊裡的一個 infra team agent 自己做出來的。
- 單機撐不住的五個失敗agent 該分派卻自己動手、worker 視窗擠到讀不出內容、記憶體被行程吃光、憑證跨工作區混用、筆電斷電讓在途工作全部消失，逼他不得不加機器。
- 擴成三台機器仍要對齊長任務給常駐的 Linux A、短任務給 Linux B，機器間用 git 交換 context、tmux 加 ssh 互相喚醒；各機專屬狀態分開放、共用內容只能靠 pull request 改，審核閘道也收斂成放在常駐機器上的同一個，再用 Discord bot 當統一遙控入口。
- 還沒解決、轉向借用 Kubernetes跨機一致性、卡在 Mac 上的本機工具、憑證安全交接、資源分配四個問題還沒解，Kyle 打算不重造這些底層，改把任務調度、審核流程與 context 管理疊在 Kubernetes 之上。
時間軸
時碼點下去會跳到影片的那一段。
| 時碼 | 段落 | 重點 |
|---|---|---|
| 00:00 | 開場：三機分工 | Kyle 說明自己每天靠三台機器跑一支 AI coding agent 艦隊：MacBook 做重度 coding 與個人專案且會睡眠，兩台常駐的 Linux 機器一台跑長時間任務、另一台是串起整體的控制平面。 |
| 00:57 | 一人分飾三角撐不住 | 一開始只靠終端機與 tmux 同時開好幾個並行的 agent 對話，他要同時當排程、記憶與審核三個角色，自己的注意力先撐不住。 |
| 01:32 | 借鏡公司治理設計階層 | 從高階主管怎麼管理上千人得到靈感，把 agent 群改造成 CEO、VP、manager、worker 的階層，每層都是獨立 agent、只看自己那塊 context，結果逐層往上送給他審。 |
| 02:04 | state 搬出模型視窗 | agent 的 state 原本活在模型的 context window 裡、窗口一定會塞滿，於是他把 state 搬到磁碟：每個 entity 有自己的 workspace，共用內容放 shared、機器專屬狀態放 machines，裡面還有 mission、目前狀態與交接用的 handoff 資料夾。 |
| 02:37 | 用重置取代壓縮 | 視窗塞滿時不再依賴系統內建的自動摘要，而是直接在 Claude 裡把 context 整個清空，讓 agent 讀回自己寫的 handoff 與歷史檔案接著做；因為 state 本來就在檔案裡，就算 context 被清空或機器當機，工作也不會跟著消失。 |
| 03:29 | 建立審核閘道 | 為了解決計畫逐層下傳會走樣的問題，他做了一個審核閘道：任何一層要動作都得先送出計畫並卡住等待，他核准後 hook 才會自動觸發執行，不用再自己走進每個工作視窗盯進度。 |
| 04:04 | 失敗一：該分派卻自己動手 | 單機一開始運作得很好，後來卻不夠用，五個問題陸續浮現：第一個是 orchestrator 該把工作分派給 worker，卻自己捲起袖子把任務做完，後來靠 CLI harness 逼它只能走分派這條路。 |
| 04:36 | 失敗二：worker 視窗擠到讀不出內容 | 隨著丟給 manager 的任務愈來愈多，它們在同一個視窗裡開出愈來愈多 worker 面板，擠到面板小到讀不出字，連原本拿來讀面板內容的工具都抓不出東西。 |
| 04:55 | 失敗三：記憶體被吃光 | activity monitor 被 Claude Code 與 MCP 相關的行程徹底佔滿，swap 幾乎見底，工作階段一路疊上去，直到機器快撐不住。 |
| 05:15 | 失敗四：憑證跨工作區混用 | 原本期待每組憑證對應一個 workspace，結果卻互相碰撞、串線，綁到錯的 workspace 上；修法是幫每個 workspace 準備完全獨立分開的環境。 |
| 05:31 | 失敗五：筆電斷電工作全滅 | MacBook 畢竟是筆電，一旦斷電或斷網，所有在途工作就跟著消失；有一次 worker 塞太多，整台機器直接掛掉，回來時它已經自己重開機，原本在跑的東西全部不見，之後他才做出一鍵開機指令，靠檔案化的 state 把整支艦隊叫回來。 |
| 06:05 | 加機器分攤長短任務 | 這五個失敗都指向同一個答案：機器不夠。他把長時間 coding 任務移到常駐的 Linux A、短的個人專案移到 Linux B，兩台都全天開著，MacBook 不再扛全部負擔，控制平面仍然只有一個。 |
| 06:37 | 跨機同步靠 git 與 ssh | context 要在機器間搬動，他用 git 把 context 檔案 commit、push，再用 tmux 的 send-keys 透過 ssh 叫醒另一台機器去 pull、讀檔接手；為避免兩台機器同時改同一份東西互相衝突，機器專屬狀態分開放，共用內容只能靠 pull request 修改。 |
| 07:12 | 審核閘道收斂成一個 | 加了機器之後，每台機器各自有一個審核閘道，他又要分頭盯好幾個收件匣；於是把所有機器的審核請求都經 ssh 送進放在常駐 Linux 機器上的同一個主閘道，因為 Mac 會睡眠，控制點不能設在會睡著的機器上。 |
| 07:44 | Discord 變成統一遙控入口 | 有一次他想不起某個功能是在哪台機器上做的，才意識到自己需要一個統一的根據點；於是在每台機器各接一支 Discord bot，讓手機變成整個艦隊的遙控器。 |
| 08:03 | 還沒解決，轉向借用 Kubernetes | 還沒解決的有四件事：跨機器的一致性、還困在 Mac 上的本機限定工具（像 MCP 伺服器與瀏覽器）、instance 之間的憑證安全交接、資源該怎麼分配；他發現這些正是 Kubernetes 已經回答過的問題，決定不重造運算、密鑰與工具這些底層，改把任務調度、審核流程與 context 管理疊在 Kubernetes 之上。 |
值得記的話
名詞與人物
| Kyle Jaejun Lee（KRAFTON） | 這場的講者，任職於 KRAFTON，獨自維運橫跨三台機器的 AI coding agent 艦隊。 |
|---|---|
| tmux | 終端機多工工具，Kyle 一開始用它同時開好幾個 agent 對話視窗，後來也靠它的 send-keys 功能跨機器喚醒 agent。 |
| CLI harness | Kyle 為了逼 agent 只能把工作分派給 worker、而不是自己動手做，設計出的一套只能透過 CLI 呼叫的技能限制。 |
| Discord | 這場提到的最終統一遙控入口，Kyle 在每台機器各接一支 bot，讓手機變成整支艦隊的遙控器。 |
| Kubernetes | Kyle 最後決定把任務調度、審核流程與 context 管理疊在它上面，不重造運算、密鑰與工具這些底層。 |
| MCP | 這場提到的伺服器類型之一，被列為還卡在 Mac 上、還沒抽象化掉的本機限定工具。 |
延伸
- Kyle 提到自己在 LinkedIn 與 X 上，想找同樣在大規模跑 agent 的人交流，但沒有進一步展開細節。
- 審核閘道其實是艦隊裡的一個 infra team agent 自己做出來的，這個 infra team 怎麼組成、怎麼運作，講者沒有多說。
- 憑證安全交接被列為還沒解決的四個問題之一，但只點出方向，沒有講具體怎麼做。