I Run a Fleet of AI Agents Across Three Machines. Here's What Broke. - Kyle Jaejun Lee, KRAFTON
三句話摘要
大規模 AI 編碼代理舰隊的架構設計與跨機器編排的實戰經驗 大規模代理管理的核心不在單台機器的優化，而在通過層級組織、狀態持久化和統一控制點實現人類注意力的解放，未來應該建立在 Kubernetes 等已驗證的基礎設施上。 層級組織而非平面堆疊：借鑒企業管理模式，建立具有不同作用域和審批邊界的代理層級，使個人只需關注頂層結果而非每個代理的細節。
重點整理
重點- 1
層級組織而非平面堆疊：借鑒企業管理模式，建立具有不同作用域和審批邊界的代理層級，使個人只需關注頂層結果而非每個代理的細節。
- 2
狀態持久化脫離模型上下文：代理狀態存儲在文件系統而非模型窗口，即便模型上下文滿溢或機器崩潰，工作進度也能通過讀取文件恢復，徹底解決窗口溢出問題。
- 3
單一審查網關作為控制點：所有層級的計劃提交到同一個審查入口等待批准，避免人工逐個檢查多個窗口，提高決策效率與一致性。
- 4
跨機器時的分離策略：機器特定的狀態各自保存，共享內容通過 pull request 同步，使用 Discord bot 作為統一的遠程控制入口，讓 MacBook 睡眠時系統仍可運作。
實用技巧與重點
乾貨- 架構層級：CEO、VP、Manager、Worker（真實的代理實體類型，非隱喻）
- 狀態存儲位置：
- shared/：多代理共享的全局上下文
- machines/：機器特定的狀態
- 各代理工作區：mission、current status、handoff folder
- 故障修復方案：
- 強制代理委派工作（CLI harness with skills）
- 限制單窗口內的 pane 數量（Tmux 顯示問題）
- 分離機器特定狀態目錄（內存碰撞）
- 隔離憑證環境（跨工作區污染）
- 啟動命令恢復全舰隊（overlord boot）
- 機器分工：
- MacBook：個人項目（可睡眠）
- Linux A：長期運行的編碼任務
- Linux B：短期個人項目
- 主網關：Linux box（always-on）
- 跨機器同步：使用 git commit + push + SSH tmux send-keys 拉取
- 遠程控制：每台機器一個 Discord bot，手機作為舰隊遠程控制器
結論
結論“大規模代理管理的核心不在單台機器的優化，而在通過層級組織、狀態持久化和統一控制點實現人類注意力的解放，未來應該建立在 Kubernetes 等已驗證的基礎設施上。”
完整解析
詳細Kyle 的故事始於一個看似簡單的問題：他用 AI 代理自動化日常工作，但很快發現自己成了系統的瓶頸。當同時管理 6 個代理時，他不再是在運行代理，而是在做三重角色——調度決策、上下文記憶、工作審查。這種認知負荷是不可持續的，關鍵的洞察來自企業管理學：高管不會將所有細節都存在腦裡，而是通過分離上下文、每個人只看自己的職責來解決這個問題。
基於這個想法，Kyle 建立了一個層級化的代理組織。CEO 代理接收任務，委派給 VP，VP 委派給 Manager，Manager 最終委派給具體執行的 Worker。每一層只需持有自己需要的上下文，結果向上流動。這不是一個比喻——這些是系統中真實的實體類型。為了避免代理狀態被困在單個模型的上下文窗口中，Kyle 將所有狀態移出模型，存儲在文件系統裡。每個代理有自己的工作區，當上下文滿時，他不再使用傳統的摘要壓縮（那會丟失信息），而是完全清空上下文，代理通過讀取它自己寫入的文件恢復進度。
隨著系統逐漸複雜，Kyle 遇到了更多問題：代理有時直接做工作而不是委派，Tmux 窗口擁擠到無法讀取，記憶體溢出。更關鍵的是，從單台 MacBook 擴展到多台機器時，新問題接踵而至——跨機器的上下文一致性、憑證污染、MacBook 意外睡眠導致任務丟失。逐一解決這些後，他意識到需要一個統一的控制入口。最後的創意是用 Discord bot 成為每台機器的控制代理，整個舰隊可以從手機遠程操作。
展望未來，Kyle 認識到他在重新發明的問題——任務編排、跨機器調度、資源管理——正是 Kubernetes 已經完美解決的。他計劃將 Kubernetes 的計算、憑證、工具管理作為基礎層，在其上構建自己的編排管理器和審查流程，這樣就不用重複造輪子。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
