5個(gè)AI員工同時(shí)開(kāi)工，4倍效率背后的3次翻車現(xiàn)場(chǎng)

47個(gè)任務(wù)，30小時(shí)監(jiān)督，120小時(shí)工作量被壓縮到4分之1。這組數(shù)字來(lái)自一個(gè)真實(shí)的Rust項(xiàng)目——不是Demo，是5.1萬(wàn)行代碼、有真實(shí)用戶的生產(chǎn)環(huán)境。

作者用5個(gè)AI編程代理并行工作了一周。結(jié)果既驗(yàn)證了多代理協(xié)作的可能性，也暴露了當(dāng)前技術(shù)邊界里那些容易被忽視的暗礁。

架構(gòu)師是唯一的"人"，其他全是"手"

每天早上前30分鐘，架構(gòu)師代理只做一件事：讀需求 backlog，把模糊的目標(biāo)拆解成獨(dú)立、可測(cè)試的任務(wù)單元。

這個(gè)環(huán)節(jié)決定了全天是順暢推進(jìn)還是陷入沖突地獄。作者對(duì)比了兩種拆解方式——"重構(gòu)消息路由系統(tǒng)"這種表述，三個(gè)代理同時(shí)開(kāi)工必然撞車；而"提取投遞重試邏輯到獨(dú)立模塊""給消息投遞加超時(shí)配置""給Maildir原子重命名寫(xiě)測(cè)試"，三個(gè)任務(wù)互不干擾。

架構(gòu)師的質(zhì)量輸出，是整套系統(tǒng)的隱形天花板。

這有點(diǎn)像工廠里的IE工程師。產(chǎn)線工人可以有很多，但能把復(fù)雜工序拆成不打架的工位，才是稀缺能力。目前這個(gè)環(huán)節(jié)還離不開(kāi)人的判斷，或者說(shuō)，離不開(kāi)一個(gè)"懂業(yè)務(wù)且會(huì)寫(xiě)提示詞"的人。

測(cè)試門(mén)：12次攔截與3次"差點(diǎn)出大事"

每個(gè)代理提交代碼后，必須先過(guò)測(cè)試門(mén)。作者記錄了12次"代理宣稱完成但測(cè)試失敗"的情況——沒(méi)有這扇門(mén)，12個(gè)帶病的分支會(huì)直接進(jìn)入主干，引發(fā)級(jí)聯(lián)故障。

典型故障模式：代碼能編譯、看起來(lái)對(duì)、主流程跑得通，但漏了邊界條件、搞壞了既有測(cè)試、或者引入隱蔽回歸。測(cè)試門(mén)把失敗日志扔回去，代理通常能在第一次重試時(shí)修復(fù)。

三次嚴(yán)重?cái)r截包括：合并鎖的競(jìng)爭(zhēng)條件、配置解析的空值檢查缺失、以及一個(gè)因硬編碼路徑導(dǎo)致"本地通過(guò)CI掛"的測(cè)試。作者估算，任何一次漏進(jìn)主干，調(diào)試成本都是小時(shí)級(jí)。

測(cè)試門(mén)在這里不是質(zhì)量錦上添花，是系統(tǒng)能運(yùn)轉(zhuǎn)的前提條件。

這也解釋了為什么很多AI編程工具演示看起來(lái)很炫，落地就翻車——Demo往往跳過(guò)"驗(yàn)證"環(huán)節(jié)，直接展示生成代碼的快感。

零文件沖突的秘密：工作樹(shù)隔離+串行合并

5個(gè)代理同時(shí)編輯同一代碼庫(kù)，作者用了兩個(gè)機(jī)制避免混亂。

每個(gè)代理在獨(dú)立的git工作樹(shù)（worktree）和分支上工作。活躍開(kāi)發(fā)階段，文件層面的沖突是零——代理們可以無(wú)意識(shí)地在同一文件上并行修改。

沖突只出現(xiàn)在合并時(shí)刻。47個(gè)任務(wù)總共產(chǎn)生4次合并沖突，全部容易解決，因?yàn)楹喜⒈晃募i串行化了，同一時(shí)間只有一個(gè)分支在進(jìn)主干。

這個(gè)設(shè)計(jì)犧牲了部分并行度，換取了可預(yù)測(cè)性。作者沒(méi)有嘗試真正的并行合并，那需要更復(fù)雜的沖突預(yù)測(cè)或自動(dòng)解決機(jī)制，目前還不是這5個(gè)代理的能力范圍。

上下文窗口：3次撞墻與拆解藝術(shù)

三次代理中途撞上上下文限制，模式高度一致：任務(wù)看起來(lái)簡(jiǎn)單，實(shí)際需要讀大量文件才能理解全貌。

最慘的一次是"全量改用類型化錯(cuò)誤"。代理開(kāi)始讀錯(cuò)誤類型定義，順著用到這些類型的模塊繼續(xù)讀，再讀調(diào)用這些模塊的代碼……等終于摸清范圍，上下文窗口快滿了，實(shí)際改動(dòng)只能草草收?qǐng)觥?/p>

解法是把"全量"拆成"按模塊"。給投遞模塊加類型化錯(cuò)誤，一個(gè)窗口能裝下；給全倉(cāng)庫(kù)加，裝不下。

這個(gè)教訓(xùn)對(duì)用人的人來(lái)說(shuō)更直接：別讓AI做"理解整個(gè)系統(tǒng)再動(dòng)手"的事，把大目標(biāo)切成窗口能吞下的粒度。

換句話說(shuō)，當(dāng)前AI代理的"閱讀理解能力"受限于窗口大小，而不是模型本身的推理深度。這是工程約束，不是智能問(wèn)題。

4倍效率從哪來(lái)，又去哪了

120小時(shí)→30小時(shí)的壓縮比，前提是作者作為監(jiān)督者每天投入6小時(shí)。這6小時(shí)花在：審閱架構(gòu)師的拆解、處理合并沖突、診斷測(cè)試失敗、以及最重要的——識(shí)別代理的"完成幻覺(jué)"。

代理會(huì)說(shuō)"完成了"，但完成的是編譯通過(guò)，不是需求滿足。作者需要像產(chǎn)品經(jīng)理驗(yàn)收需求一樣，逐個(gè)核對(duì)任務(wù)定義和實(shí)際輸出。

這個(gè)模式目前適合什么？作者給出的畫(huà)像很清晰：積壓的需求清單、相對(duì)獨(dú)立的模塊改造、有完善測(cè)試覆蓋的代碼庫(kù)。不適合的是：架構(gòu)級(jí)重構(gòu)、需要跨系統(tǒng)聯(lián)調(diào)的功能、以及測(cè)試缺失的老代碼。

一個(gè)細(xì)節(jié)值得玩味：作者提到代理在修復(fù)測(cè)試失敗時(shí)"通常第一次重試就能解決"。這說(shuō)明錯(cuò)誤信息作為反饋信號(hào)足夠明確時(shí)，AI的自我修正能力相當(dāng)可靠。但反饋模糊時(shí)——比如"這個(gè)實(shí)現(xiàn)不夠優(yōu)雅"——代理就會(huì)陷入無(wú)效迭代。

如果監(jiān)督成本能從每天6小時(shí)降到2小時(shí)，這套流程的邊際收益會(huì)再上一個(gè)臺(tái)階。但那個(gè)臨界點(diǎn)在哪，作者沒(méi)有答案——這也是留給下一個(gè)實(shí)驗(yàn)者的問(wèn)題。