一個人用10個AI代理運營整套系統

2026年1月，吉爾吉斯斯坦比什凱克的一間公寓里，一位.NET開發者開始搭建一個叫phleet的多代理系統。沒有團隊，沒有融資，只有一臺Mac Studio和十個持續運行的AI代理。這些代理每天自動巡檢服務器、審查代碼、運營新聞聚合站點——全部無人值守。

為什么現有框架不夠

作者嘗試過市面上的代理框架，發現兩個極端：要么太抽象，要用Python裝飾器定義一切；要么太簡陋，只是API調用的包裝腳本。

他想要的是生產級分布式系統的架構思路——容器、消息隊列、持久化工作流——但跑的是AI進程而非微服務。

「我想要能一直待著的AI代理。不是每天關掉的聊天窗口，而是持續運行、互相協調、記得上周發生了什么的進程。」

技術選型：熟悉的工具鏈

作為有多年RabbitMQ、Redis、Elasticsearch經驗的開發者，他選擇用.NET 10開發。原因很直接：這里思考最快，能復用已經驗證過的生產模式。

最終架構：

? 每個代理是一個Docker容器，運行Claude CLI或OpenAI Codex的持久化進程

? RabbitMQ負責消息協調

? Temporal處理持久化工作流

? MySQL數據庫由編排器管理

? React儀表板展示運行狀態

三個真實場景

運維自動化。健康檢查每天兩次：代理SSH登錄服務器，檢查Docker狀態、驗證API端點、審查錯誤日志，然后發布摘要。內存備份每小時運行。Prometheus指標被消化成帶圖表的日報。

代碼審查。開發者代理提交PR后，共識審查工作流并行分發給三四個審查代理。各自獨立審查，再由合成代理協調反饋。全體通過則進入合并隊列；有分歧則將推理過程返回給開發者迭代。

新聞管道（fuddy-duddy.org）。這是代理運行完整生產系統的最佳案例：抓取十余個吉爾吉斯新聞源，生成AI摘要，按語義相似度聚類相關報道，向Telegram和社交媒體推送熱點。代理處理完整運營生命周期——定時健康檢查、部署驗證工作流、指標日報。凌晨3點出問題，運維代理在下次檢查中捕獲并推送到群聊。常規操作無需人工介入。

個人項目背后的信號

phleet的架構選擇揭示了一個被忽視的需求：AI代理的基礎設施層，應該像傳統微服務那樣可觀測、可編排、可恢復——而不是被鎖在某個廠商的聊天界面里。

當單個開發者能用十個容器化的AI代理運營整套系統時，「AI團隊」的定義正在松動。關鍵問題變成：你的業務邏輯，有多少能被表達成持久化、可編排、可審計的工作流？