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