谷歌工程師撕破AI代理遮羞布：90%產品連"剛才干了啥"都答不上

去年有個測試在圈內傳瘋了——讓市面上主流的AI代理連續執行5步任務，第6步問它"第一步做了什么"，73%的代理要么瞎編，要么直接崩潰。不是內存不夠，是壓根沒有狀態管理這個概念。

這就像一個實習生，你讓他去訂會議室、發邀請、準備材料、會后整理紀要。他每一步都執行了，但問"會議室訂的幾樓"，他得把聊天記錄翻一遍才能回答。這不是記性差，是工作方法有問題。

狀態≠記憶：行業最大的概念偷換

幾乎所有框架都在混淆這兩個詞。它們給代理塞一段對話歷史，就宣稱"支持狀態管理"。原文作者打了個精準的比方：這就像給程序員一個Git提交記錄，然后說這是項目文檔。

真正的狀態是什么？是代理做決策所需的全部上下文：哪些任務已完成、哪些卡住了、為什么卡住、做過什么關鍵決策、依據是什么。這些需要結構化存儲，而不是藏在幾十輪對話的犄角旮旯里。

LangChain、AutoGPT早期版本都栽在這個坑里。用戶看著代理跑得很熱鬧，一旦任務超過10步，行為就開始詭異——重復執行已完成的步驟、對同一問題給出矛盾答案、在錯誤的前提上繼續推進。2023年AutoGPT的GitHub issue區，"forgot what it did"標簽下有超過400條未關閉的反饋。

四大暗礁：為什么狀態管理這么難搞

第一個坑叫隱式狀態累積。代理通過對話"自然"記住東西，但要用的時候找不著。就像你把鑰匙隨手放，要用時得把全屋翻一遍。顯式狀態管理要求代理明確知道自己知道什么——這對當前的大模型架構是個反直覺的設計。

第二個坑是狀態漂移。任務越長，代理對當前狀態的認知和世界真實狀態的偏差越大。原文作者指出，代理"以為自己處于狀態A，但世界已經移動到狀態B"。一個典型的場景：代理檢查庫存時說"還剩50件"，兩小時后實際庫存變了，它仍按舊數據做采購決策。

第三個坑是序列化斷層。代理跑在會話里，會話會結束。服務器重啟、API超時、用戶關閉頁面——狀態說沒就沒。大多數框架沒解決跨會話持久化，導致"續傳"成了奢侈品。某頭部RPA廠商的內部數據顯示，因會話中斷導致的任務失敗占其客服工單量的31%。

第四個坑最隱蔽：多代理共享狀態。企業級場景往往需要多個代理協作，但每個代理是隔離進程，共享狀態需要額外的協調層。沒有這層，就會出現A代理標記"等待用戶確認"，B代理不知道，直接覆蓋為"繼續執行"的災難。

解法的輪廓：狀態即契約

原文給出了一個被驗證有效的模式。不再傳遞整段對話，而是傳遞一個結構化的狀態對象：

已完成任務清單、待處理隊列、阻塞項及原因、相關上下文數據、關鍵決策記錄。

代理讀取狀態→執行動作→更新狀態。狀態成為輪次之間的契約。這個設計讓代理能直接回答"我目前做到哪了"，而不需要回放整個對話歷史。

一些團隊已經開始實踐。CrewAI在0.5版本后引入了顯式狀態層，多代理任務的完成率從62%提升到89%。LangGraph干脆把狀態流作為核心抽象，用圖結構定義狀態轉換規則。這些不是炫技，是解決真問題的工程選擇。

國內也有跟進者。某大廠智能體平臺在2024年Q3的更新中，把"狀態快照"作為付費功能推出，企業客戶續費率環比漲了17個百分點——說明有人愿意為可靠性買單。

從"能動"到"能協調"

原文的結語很鋒利：狀態是"能動"和"能協調"的分水嶺。沒有狀態管理，代理只是按順序執行動作的腳本；有了狀態管理，它才能處理依賴關系、應對中斷、協作分工。

這個區分正在重塑產品選型標準。去年企業客戶問的是"支持哪些模型"，今年變成"狀態持久化怎么實現""多代理沖突怎么解決"。一個做智能客服的CTO跟我吐槽：POC階段各家都差不多，一上生產環境，狀態管理沒做好的廠商直接出局。

更深層的影響在架構層面。狀態管理需要顯式設計，意味著產品經理得想清楚業務流程的每個決策點、每種異常分支。這逼退了只想套殼大模型賺快錢的玩家，也讓真正理解業務的人有了護城河。

那個測試還有后續——同一批代理，給它們加上顯式狀態層后，5步任務成功率從27%跳到94%。技術問題有時候就這么樸素：不是模型不夠聰明，是基礎設施沒搭對。

你現在用的AI工具，能準確說出它上一步做了什么、為什么這么做嗎？