90%的AI智能體都在假裝有記憶，Git日志式管理正在拖垮整個行

開發者花了三年時間訓練大模型寫代碼、訂機票、處理客服工單，卻發現一個荒誕的事實：這些號稱"智能"的Agent（智能體），連自己三分鐘前干了什么都記不清楚。

不是內存不夠。是狀態管理根本沒做。

Git日志當文檔：行業集體踩的坑

現在的Agent框架普遍在干一件事：把對話歷史打包扔給模型，然后管這叫"狀態"。

原文作者打了個精準的比方——這就像給程序員一份Git提交記錄，然后說"這就是項目文檔"。提交記錄確實發生過，但誰看了能知道系統現在跑在什么版本、哪些功能已上線、哪些模塊在互相打架？

真正的狀態不是"我說了什么"，而是"我知道什么、做到哪了、卡在哪了、接下來該干什么"。

當前主流框架的狀態管理，本質上是隱式的。Agent通過對話流被動積累信息，像一個人邊走路邊丟紙條，走到岔路口才發現關鍵路標早被風吹走了。

狀態漂移（State Drift）是長任務殺手。一個處理復雜工作流的Agent，運行20分鐘后可能還以為自己停在第3步，實際上外部環境已經變了——API返回了錯誤、用戶取消了訂單、數據庫被其他進程改了。它繼續按舊地圖導航，結果只能是撞墻或繞圈。

更隱蔽的問題是狀態序列化。Agent跑在會話里，會話會崩潰、會超時、會被殺掉。大多數框架沒解決跨會話持久化，今天干了一半的活，明天打開是個全新的開始。用戶以為在跟"同一個助手"對話，其實是每天換一個新臨時工。

多Agent協作：共享狀態的地獄難度

單一Agent的狀態已經夠亂了，多個Agent協同直接開啟噩夢模式。

想象一個場景：客服Agent接了投訴，轉給技術排查Agent，同時通知退款Agent走流程。三個進程各自為政，每個都有一份自己的"對話歷史"，沒有統一的真相來源。客服Agent以為問題已解決，技術Agent還在復現，退款Agent已經把錢打出去了。

共享狀態在分布式系統里是老難題，但Agent的特殊性在于它要"理解"狀態——不是機械同步數據，而是讓模型知道"這個字段變了意味著什么"。

現有方案要么是消息總線式的廣播（信息過載），要么是數據庫式的集中存儲（模型讀不懂），兩頭不靠。

解藥：把狀態變成契約

原文給出的有效模式很樸素：顯式狀態對象。

不再把整個對話塞給模型，而是維護一個結構化狀態：

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

Agent每輪只讀這個對象，執行動作，更新對象。狀態成為回合之間的契約，而不是需要從聊天記錄里考古的遺跡。

這個設計的妙處在于分離了"記憶"和"認知"。對話歷史可以存，但那是審計日志，不是工作內存。模型拿到的是精簡后的當前態勢圖，像棋手看棋盤而不是復盤每一步棋譜。

狀態顯式化還解決了另一個痛點：可觀測性。開發者能直接檢查Agent"腦子里在想什么"，調試時不用逐行翻幾百輪對話去猜它為什么做了那個離譜決定。

為什么這事現在才有人認真說

Agent概念火了一年多，大家的注意力都在模型能力上——更強的推理、更長的上下文、更好的工具調用。狀態管理被默認當成"工程細節"，等Demo跑起來再補。

但Demo和生產的差距就在這里。一個能訂一張機票的Agent，和能處理"改簽失敗→聯系航司→同步新行程→通知接送機"完整鏈路的Agent，中間隔著一個狀態管理系統。

原文作者的身份背景（Dev.to社區的技術寫作者）也暗示了這事的分量：這不是某個大廠的營銷話術，是一線開發者在生產環境里摔過跟頭后的復盤。

有個判斷標準很鋒利：如果你的Agent回答"我目前做到哪了"需要重放整個對話，那你沒有狀態管理，只有日志。

這個區分正在變成Agent賽道的分水嶺。做聊天機器人的可以糊弄，做自動化工作流的糊弄不過去——用戶不會容忍同一個任務重復執行三次，每次都在不同環節翻車。