北京
周三下午三點，我盯著屏幕上的五個終端窗口，每個里面都跑著一個AI代理。一個在分析需求，一個寫后端代碼，一個生成前端界面，一個做代碼審查，還有一個準備跑自動化測試。單看哪個都很厲害，但只要想把它們串成一條流水線，馬上就會變成災難現場。
后端代理不知道分析階段什么時候才算結束。前端代理得有人通知它“你可以開始了”。審查一打回代碼，接收方就得原地消失，重新排隊。更別說人類想中途插手看一眼，整條流水線立馬斷裂，一切重來。那些天我在這些排隊、觸發、回退的問題里反復橫跳，腦子里只盤旋著一個問題：難道非得再搭一套調度系統才能讓它們好好合作嗎？
我試過把 Temporal 拉進來寫編排，也畫過狀態機圖準備自己搞一個帶數據庫的調度器?？稍阶鲈接X得不對勁——這根本不是缺少基礎設施，而是在給自己制造額外的麻煩。有一天我打開 GitHub Issues，準備像平常一樣給某個任務打標簽，突然意識到：每個團隊的項目管理工具里，早就跑著一臺天然的狀態機。每個 Issue 都是一個任務載體，每次打標簽都是一次狀態轉移，每條評論都自帶時間戳和責任人。我需要的不是什么新平臺，而是一種設計思路上的轉變：把標簽從“分類標記”升級成“分布式狀態機的狀態”。
于是映射關系變得極其簡單：Issue 就是任務，標簽就是當前狀態。不再需要單獨的數據庫去記錄進度，也不需要有中心化的編排器來叫醒下一個代理。每個 AI 代理只做一件事——定時輪詢項目里的 Issue 列表，只要發現某個 Issue 帶著自己的專屬標簽，就拉取上下文、執行工作，完成后把標簽改掉，交給下游的代理。如果失敗了，它會打上另一個標簽，把問題暴露出來，甚至能把控制權交還給人類介入。
我后來用一個拼圖比喻來給團隊解釋這個架構。每個代理都是一塊獨立的拼圖片，它只負責自己邊界內的事。每一片都包含四個零件：系統提示詞定義它的身份和行為邊界，比如“你是后端代理，禁止觸碰前端文件”；技能集標明它能做什么，比如寫接口、跑測試、生成數據庫遷移腳本；工具連接指的是它通過 MCP 這類協議能調動的外部資源，比如 GitHub 的 Issue 接口、Slack 通知、數據庫的模式檢查工具；最后是轉移規則，也就是觸發它的標簽、完工后打上的標簽、出問題時打上的標簽。把這些拼圖片首尾相接一拼，一條完整的開發流水線就自動運轉起來，沒有中心節點，沒有單點故障。
最讓人興奮的是它的可替換性。如果你想換個后端模型，從 Claude 換到 Gemini，只需要換下那塊拼圖片，其他部分完全不受影響。想增加一道安全檢查關卡，就在“審查”和“合并”之間插入一個安全審計代理，其他流程照樣跑。每一塊拼圖片都可以由不同團隊、用不同技術棧獨立開發和維護，只要它們遵守同一套標簽協議。這正是我對抗編排系統復雜性的最優解：把流程的復雜度分散到有限的角色里，而不是塞進一個越來越重的調度內核里。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
