多Agent系統(tǒng)最容易制造一種錯(cuò)覺Agent越多任務(wù)完成得越快。于是一個(gè)Agent分析需求一個(gè)Agent修改后端一個(gè)Agent處理前端還有Agent負(fù)責(zé)編寫測試、審查代碼和更新文檔。任務(wù)確實(shí)同時(shí)開始了但運(yùn)行一段時(shí)間后新的問題會(huì)出現(xiàn)誰已經(jīng)完成了什么哪些結(jié)論只是推測哪個(gè)任務(wù)正在等待上游結(jié)果兩個(gè)Agent為什么修改了同一份代碼任務(wù)中斷后應(yīng)該從哪里繼續(xù)最終由誰判斷整個(gè)需求已經(jīng)完成真正的問題不是Agent數(shù)量不夠而是系統(tǒng)缺少一份持續(xù)記錄目標(biāo)、狀態(tài)、證據(jù)和責(zé)任的任務(wù)賬本。一、聊天記錄為什么不能代替任務(wù)狀態(tài)很多Agent工作流把聊天記錄當(dāng)作任務(wù)記錄。開發(fā)者認(rèn)為只要對話還在Agent就能知道之前發(fā)生了什么。但聊天記錄本質(zhì)上是按照時(shí)間排列的信息流其中混合了用戶需求Agent的分析工具調(diào)用結(jié)果測試日志錯(cuò)誤信息被放棄的方案臨時(shí)討論最終結(jié)論。隨著任務(wù)持續(xù)運(yùn)行真正重要的狀態(tài)會(huì)被大量過程信息淹沒。Codex為了支持長時(shí)間任務(wù)會(huì)在上下文過長時(shí)對歷史內(nèi)容進(jìn)行壓縮用較小的內(nèi)容表示之前發(fā)生的過程。壓縮可以讓任務(wù)繼續(xù)但它也說明會(huì)話上下文并不適合充當(dāng)永久、精確的項(xiàng)目狀態(tài)庫。聊天記錄回答的是我們之前討論過什么任務(wù)賬本回答的是當(dāng)前目標(biāo)是什么已經(jīng)完成什么下一步由誰做兩者不是同一種信息。二、多Agent為什么會(huì)放大狀態(tài)混亂單Agent任務(wù)即使?fàn)顟B(tài)不清開發(fā)者通常還能通過當(dāng)前Diff和最近幾輪對話大致判斷進(jìn)度。多Agent協(xié)作時(shí)每個(gè)Agent都擁有自己的上下文、工具調(diào)用和執(zhí)行路徑。一個(gè)Agent可能認(rèn)為接口已經(jīng)確定另一個(gè)Agent卻仍在按照舊結(jié)構(gòu)編寫測試。如果系統(tǒng)沒有統(tǒng)一狀態(tài)常見結(jié)果包括重復(fù)分析相同問題同時(shí)修改同一個(gè)模塊使用不同版本的需求下游任務(wù)提前開始已失敗任務(wù)被誤認(rèn)為仍在運(yùn)行一個(gè)Agent的臨時(shí)假設(shè)被另一個(gè)Agent當(dāng)成最終結(jié)論。OpenAI公開的Symphony實(shí)踐沒有把多個(gè)Agent簡單放進(jìn)多個(gè)聊天窗口而是把項(xiàng)目管理看板作為控制平面。每個(gè)任務(wù)擁有明確狀態(tài)系統(tǒng)持續(xù)觀察開放任務(wù)、重新啟動(dòng)卡住的Agent并根據(jù)依賴關(guān)系決定哪些任務(wù)可以開始。這背后的關(guān)鍵不是看板本身而是Agent共享的不是一段聊天歷史而是一套結(jié)構(gòu)化任務(wù)狀態(tài)。三、任務(wù)賬本至少應(yīng)該記錄什么任務(wù)賬本不需要把所有過程原樣保存。它至少應(yīng)該包含六類信息。任務(wù)目標(biāo)當(dāng)前任務(wù)到底要解決什么問題明確不處理什么。當(dāng)前狀態(tài)任務(wù)處于待處理、分析中、執(zhí)行中、等待驗(yàn)證、阻塞、失敗還是已完成。責(zé)任歸屬哪個(gè)Agent負(fù)責(zé)實(shí)現(xiàn)哪個(gè)Agent負(fù)責(zé)驗(yàn)證哪個(gè)節(jié)點(diǎn)需要人工判斷。依賴關(guān)系當(dāng)前任務(wù)需要等待哪個(gè)接口、分支、測試或?qū)徟Y(jié)果。執(zhí)行證據(jù)修改了哪些文件運(yùn)行了哪些命令哪些測試已經(jīng)通過。剩余風(fēng)險(xiǎn)哪些結(jié)論還沒有確認(rèn)哪些步驟失敗哪些內(nèi)容需要人工處理。一條簡單任務(wù)記錄可以寫成**目標(biāo)**修復(fù)訂單重復(fù)提交。**狀態(tài)**等待驗(yàn)證。**負(fù)責(zé)人**Backend Agent。**依賴**等待測試Agent完成并發(fā)測試。**已完成**增加冪等校驗(yàn)修改兩個(gè)文件。**證據(jù)**單元測試通過集成測試尚未運(yùn)行。**風(fēng)險(xiǎn)**舊客戶端重試邏輯仍需確認(rèn)。這種記錄遠(yuǎn)比“任務(wù)差不多完成了”更容易繼續(xù)執(zhí)行和審查。四、任務(wù)、會(huì)話和Pull Request必須分開很多團(tuán)隊(duì)會(huì)把一個(gè)Codex會(huì)話等同于一個(gè)任務(wù)再把一個(gè)任務(wù)等同于一個(gè)Pull Request。這種關(guān)系在簡單修改中成立但在大型Agent工作流中很快會(huì)失效。一個(gè)業(yè)務(wù)任務(wù)可能經(jīng)歷多次Agent會(huì)話也可能生成多個(gè)倉庫中的多個(gè)Pull Request另一些任務(wù)只進(jìn)行調(diào)查和方案設(shè)計(jì)根本不會(huì)修改代碼。Symphony明確把任務(wù)與Agent會(huì)話、Pull Request分離。任務(wù)是需要完成的工作單位會(huì)話只是其中一次執(zhí)行過程Pull Request則只是可能產(chǎn)生的交付物。因此任務(wù)賬本應(yīng)該圍繞“工作目標(biāo)”組織而不是圍繞聊天窗口組織。更合理的關(guān)系是一個(gè)任務(wù)→ 多次Agent執(zhí)行→ 若干中間結(jié)果→ 一個(gè)或多個(gè)交付物→ 最終驗(yàn)收狀態(tài)這樣即使某個(gè)Agent會(huì)話中斷任務(wù)本身也不會(huì)丟失。五、任務(wù)賬本怎樣支持Agent交接多Agent系統(tǒng)里最容易丟失信息的地方是任務(wù)交接。一個(gè)分析Agent完成調(diào)用鏈調(diào)查后把任務(wù)交給實(shí)現(xiàn)Agent。如果它只回復(fù)一句“問題出在緩存”實(shí)現(xiàn)Agent仍然需要重新閱讀大量代碼。有效交接應(yīng)該包含已確認(rèn)的事實(shí)尚未確認(rèn)的推測相關(guān)文件和代碼位置已嘗試但失敗的方案下一步建議當(dāng)前權(quán)限和限制。OpenAI Agents SDK支持Agent之間的handoff、sessions、tracing以及可恢復(fù)的審批流程。這些能力的共同目標(biāo)就是讓控制權(quán)發(fā)生變化時(shí)任務(wù)狀態(tài)和執(zhí)行軌跡仍然可以被繼續(xù)使用。交接不是把全部聊天復(fù)制給下一個(gè)Agent而是生成一份可執(zhí)行摘要我確認(rèn)了什么我做過什么你接下來應(yīng)該做什么哪些事情不要重新做沒有這一步多Agent只是把重復(fù)勞動(dòng)分配給更多模型。六、失敗恢復(fù)為什么必須依賴任務(wù)賬本Agent執(zhí)行失敗并不可怕。真正危險(xiǎn)的是失敗后不知道任務(wù)處于什么狀態(tài)。例如Agent運(yùn)行到一半后崩潰開發(fā)者需要判斷修改是否已經(jīng)寫入文件測試是否運(yùn)行過當(dāng)前分支是否可以繼續(xù)使用重新啟動(dòng)會(huì)不會(huì)重復(fù)修改是否應(yīng)該回滾到上一個(gè)檢查點(diǎn)。長時(shí)間Codex任務(wù)通常會(huì)跨越多個(gè)步驟甚至多次執(zhí)行。OpenAI關(guān)于長周期任務(wù)的實(shí)踐強(qiáng)調(diào)持續(xù)保存進(jìn)度、管理復(fù)雜工作流并讓工作能夠跨越單次提示繼續(xù)推進(jìn)。因此每完成一個(gè)關(guān)鍵階段都應(yīng)該更新任務(wù)賬本需求已確認(rèn)→ 接口已確定→ 實(shí)現(xiàn)已完成→ 測試已運(yùn)行→ 審查待處理→ 人工已批準(zhǔn)這相當(dāng)于給任務(wù)建立檢查點(diǎn)。Agent失敗后不需要重新理解全部歷史只需要從最近一個(gè)可信狀態(tài)繼續(xù)。七、任務(wù)賬本還必須記錄“為什么”如果賬本只記錄“完成”或“失敗”它仍然不夠。工程系統(tǒng)真正需要的是決策依據(jù)。例如已完成修改認(rèn)證邏輯。這條記錄價(jià)值很低。更有價(jià)值的寫法是已完成在服務(wù)端增加Token過期檢查。原因現(xiàn)有客戶端檢查可以被繞過。驗(yàn)證認(rèn)證單元測試和接口測試通過。未驗(yàn)證舊版本客戶端兼容性。決策等待人工確認(rèn)后合并。OpenAI Agents平臺提供Tracing與Observability能力用于查看Agent執(zhí)行路徑、工具調(diào)用和handoff過程并據(jù)此調(diào)試和優(yōu)化工作流。這說明Agent系統(tǒng)的可信度不僅來自最終答案還來自過程是否能夠被追蹤。任務(wù)賬本不是流水賬而是一條簡化后的決策證據(jù)鏈。八、誰負(fù)責(zé)維護(hù)任務(wù)賬本任務(wù)賬本不能完全依賴人工填寫否則Agent越多人工維護(hù)成本越高。更合理的分工是Agent自動(dòng)記錄當(dāng)前執(zhí)行步驟修改文件工具調(diào)用測試結(jié)果錯(cuò)誤與重試阻塞原因。主Agent整理匯總子Agent結(jié)果更新任務(wù)整體狀態(tài)判斷依賴是否解除生成交付報(bào)告。人類確認(rèn)修改真實(shí)目標(biāo)處理需求沖突批準(zhǔn)高風(fēng)險(xiǎn)操作判斷任務(wù)是否正式完成。人類不需要記錄每一條命令但必須控制狀態(tài)變化中的關(guān)鍵節(jié)點(diǎn)。例如Agent可以自動(dòng)把任務(wù)從“實(shí)現(xiàn)中”改為“等待審查”但不能在涉及權(quán)限、支付或生產(chǎn)部署時(shí)擅自把任務(wù)標(biāo)記為“已交付”。九、任務(wù)賬本會(huì)成為Agent系統(tǒng)的基礎(chǔ)設(shè)施當(dāng)團(tuán)隊(duì)只有一個(gè)Agent時(shí)任務(wù)賬本看起來像額外負(fù)擔(dān)。當(dāng)Agent數(shù)量增加、任務(wù)執(zhí)行時(shí)間延長、工作跨越多個(gè)倉庫和設(shè)備后它會(huì)變成必需品。Codex應(yīng)用正在支持開發(fā)者跨項(xiàng)目管理多個(gè)長期任務(wù)OpenAI也把項(xiàng)目看板、共享工作空間和Agent編排視為管理持續(xù)工作的重要入口。未來Agent平臺之間的差異不只在于模型能力還在于能不能保存真實(shí)任務(wù)狀態(tài)能不能恢復(fù)中斷工作能不能追蹤Agent交接能不能識別依賴和阻塞能不能證明結(jié)果如何產(chǎn)生能不能讓人類在正確節(jié)點(diǎn)介入。模型決定Agent能不能執(zhí)行任務(wù)。任務(wù)賬本決定多個(gè)Agent能不能圍繞同一個(gè)目標(biāo)持續(xù)協(xié)作。結(jié)語多Agent系統(tǒng)最危險(xiǎn)的誤區(qū)是認(rèn)為只要每個(gè)Agent都足夠聰明協(xié)作就會(huì)自然發(fā)生。事實(shí)上Agent越多狀態(tài)、依賴、責(zé)任和交接問題越嚴(yán)重。一個(gè)可靠的多Agent工作流應(yīng)該形成這樣的閉環(huán)創(chuàng)建任務(wù)→ 明確目標(biāo)→ 分配Agent→ 記錄執(zhí)行狀態(tài)→ 保存驗(yàn)證證據(jù)→ 處理失敗與交接→ 人工確認(rèn)交付→ 關(guān)閉任務(wù)聊天記錄保存討論過程代碼倉庫保存修改結(jié)果任務(wù)賬本保存整個(gè)工作的真實(shí)狀態(tài)。沒有任務(wù)賬本多Agent只是同時(shí)運(yùn)行的多個(gè)對話。有了任務(wù)賬本Agent才可能從臨時(shí)助手變成能夠持續(xù)協(xié)作、可以恢復(fù)、可以審計(jì)的工程執(zhí)行系統(tǒng)。