不用工作流引擎，GitHub Issues標(biāo)簽讓AI自主接力開發(fā)

周三下午三點(diǎn)，我盯著屏幕上的五個(gè)終端窗口，每個(gè)里面都跑著一個(gè)AI代理。一個(gè)在分析需求，一個(gè)寫后端代碼，一個(gè)生成前端界面，一個(gè)做代碼審查，還有一個(gè)準(zhǔn)備跑自動(dòng)化測(cè)試。單看哪個(gè)都很厲害，但只要想把它們串成一條流水線，馬上就會(huì)變成災(zāi)難現(xiàn)場(chǎng)。

后端代理不知道分析階段什么時(shí)候才算結(jié)束。前端代理得有人通知它“你可以開始了”。審查一打回代碼，接收方就得原地消失，重新排隊(duì)。更別說人類想中途插手看一眼，整條流水線立馬斷裂，一切重來。那些天我在這些排隊(duì)、觸發(fā)、回退的問題里反復(fù)橫跳，腦子里只盤旋著一個(gè)問題：難道非得再搭一套調(diào)度系統(tǒng)才能讓它們好好合作嗎？

我試過把 Temporal 拉進(jìn)來寫編排，也畫過狀態(tài)機(jī)圖準(zhǔn)備自己搞一個(gè)帶數(shù)據(jù)庫的調(diào)度器。可越做越覺得不對(duì)勁——這根本不是缺少基礎(chǔ)設(shè)施，而是在給自己制造額外的麻煩。有一天我打開 GitHub Issues，準(zhǔn)備像平常一樣給某個(gè)任務(wù)打標(biāo)簽，突然意識(shí)到：每個(gè)團(tuán)隊(duì)的項(xiàng)目管理工具里，早就跑著一臺(tái)天然的狀態(tài)機(jī)。每個(gè) Issue 都是一個(gè)任務(wù)載體，每次打標(biāo)簽都是一次狀態(tài)轉(zhuǎn)移，每條評(píng)論都自帶時(shí)間戳和責(zé)任人。我需要的不是什么新平臺(tái)，而是一種設(shè)計(jì)思路上的轉(zhuǎn)變：把標(biāo)簽從“分類標(biāo)記”升級(jí)成“分布式狀態(tài)機(jī)的狀態(tài)”。

于是映射關(guān)系變得極其簡單：Issue 就是任務(wù)，標(biāo)簽就是當(dāng)前狀態(tài)。不再需要單獨(dú)的數(shù)據(jù)庫去記錄進(jìn)度，也不需要有中心化的編排器來叫醒下一個(gè)代理。每個(gè) AI 代理只做一件事——定時(shí)輪詢項(xiàng)目里的 Issue 列表，只要發(fā)現(xiàn)某個(gè) Issue 帶著自己的專屬標(biāo)簽，就拉取上下文、執(zhí)行工作，完成后把標(biāo)簽改掉，交給下游的代理。如果失敗了，它會(huì)打上另一個(gè)標(biāo)簽，把問題暴露出來，甚至能把控制權(quán)交還給人類介入。

我后來用一個(gè)拼圖比喻來給團(tuán)隊(duì)解釋這個(gè)架構(gòu)。每個(gè)代理都是一塊獨(dú)立的拼圖片，它只負(fù)責(zé)自己邊界內(nèi)的事。每一片都包含四個(gè)零件：系統(tǒng)提示詞定義它的身份和行為邊界，比如“你是后端代理，禁止觸碰前端文件”；技能集標(biāo)明它能做什么，比如寫接口、跑測(cè)試、生成數(shù)據(jù)庫遷移腳本；工具連接指的是它通過 MCP 這類協(xié)議能調(diào)動(dòng)的外部資源，比如 GitHub 的 Issue 接口、Slack 通知、數(shù)據(jù)庫的模式檢查工具；最后是轉(zhuǎn)移規(guī)則，也就是觸發(fā)它的標(biāo)簽、完工后打上的標(biāo)簽、出問題時(shí)打上的標(biāo)簽。把這些拼圖片首尾相接一拼，一條完整的開發(fā)流水線就自動(dòng)運(yùn)轉(zhuǎn)起來，沒有中心節(jié)點(diǎn)，沒有單點(diǎn)故障。

最讓人興奮的是它的可替換性。如果你想換個(gè)后端模型，從 Claude 換到 Gemini，只需要換下那塊拼圖片，其他部分完全不受影響。想增加一道安全檢查關(guān)卡，就在“審查”和“合并”之間插入一個(gè)安全審計(jì)代理，其他流程照樣跑。每一塊拼圖片都可以由不同團(tuán)隊(duì)、用不同技術(shù)棧獨(dú)立開發(fā)和維護(hù)，只要它們遵守同一套標(biāo)簽協(xié)議。這正是我對(duì)抗編排系統(tǒng)復(fù)雜性的最優(yōu)解：把流程的復(fù)雜度分散到有限的角色里，而不是塞進(jìn)一個(gè)越來越重的調(diào)度內(nèi)核里。