LedgerAgent：把 Agent 的工作記憶從 Prompt 裡分離出來

2026-06-21 Friday

我們常說「LLM 有記憶問題」，但這個問題有兩層。第一層是長期記憶——LLM 跨對話不記得你是誰。第二層更隱蔽：在同一個任務流程中，Agent 每次要決定下一步時，都必須從整個 prompt 歷史裡重新「找到」當前的任務狀態。這個重建過程會失誤，而且在需要遵守複雜業務政策的場景下，一次失誤就可能導致違規操作。LedgerAgent 試圖解決的是第二層。

1. 識別資訊來源與動機

來源：arXiv 預印本（2606.20529），標注為 Work in Progress，作者來自 Arizona State University（Md Nayem Uddin、Amir Saeidi、Eduardo Blanco、Chitta Baral）。

研究動機：客服領域的 tool-calling agent 需要在多輪對話中維護任務狀態——使用者的帳號 ID、已確認的事實、適用的限制條件、當前流程所在的步驟。在標準 agent 設計中，這些狀態資訊散落在 prompt 的對話歷史裡，agent 每次決策時都需要從這堆文字中重新提取。

這個設計有兩個已知失效點：

狀態重建錯誤：Agent 可能遺漏、誤讀或混淆歷史訊息中的狀態資訊，用過時或錯誤的資訊做出決定。
政策違規：許多業務政策是狀態相依的——「只有在用戶確認身份後才能退款」「超過三次失敗後鎖定帳戶」。如果 agent 的狀態重建不準確，它可能生成語法合法但語意違規的工具呼叫。

潛在偏見：論文聚焦客服場景，對其他 agent 應用域（如程式碼生成、研究助理）的適用性需要額外驗證。論文目前為預印本且標注 Work in Progress，結果可能在正式發表前有所調整。

2. 釐清技術核心與創新點

LedgerAgent 的核心思想是把任務狀態從 prompt 中分離出來，維護在一個獨立的結構化「帳本」（Ledger）中。

標準 Agent 的工作方式：

[System Prompt] + [對話歷史（含所有工具呼叫和結果）] → LLM 決策

LLM 每次都需要從完整的對話歷史中推斷當前狀態，這個推斷過程沒有明確的驗證機制。

LedgerAgent 的工作方式：

[System Prompt] + [帳本（結構化當前狀態）] + [對話歷史] → LLM 決策
         ↑                    ↑
      維持不變         每次工具呼叫後更新

帳本記錄的是從用戶互動和工具呼叫結果中觀測到的事實、識別符、限制條件和流程狀態，以結構化格式（而非自然語言對話）呈現。

兩個關鍵機制：

1. 帳本維護（Ledger Maintenance）
每次工具呼叫返回結果後，系統更新帳本中的相關欄位。下次 LLM 決策時，帳本的當前狀態直接注入 prompt，而不是讓 LLM 從歷史中重建。

2. 政策驗證閘道（Policy Verification Gate）
在執行任何會改變環境狀態的工具呼叫前，系統對照帳本中的當前狀態驗證政策合規性。如果呼叫違反政策約束（例如在未驗證身份的狀態下嘗試退款），則阻止執行並提示 LLM 重新規劃。

這個設計的關鍵洞察：把「狀態維護」和「政策檢查」從 LLM 的推理任務中拆出來，交給確定性程式碼處理。LLM 不需要同時做「記住狀態」、「理解政策」、「選擇工具」三件事，只需要在準確的狀態資訊和清晰的政策反饋下做工具選擇。

3. 評估實驗數據與基準測試

研究者在四個客服場景中測試（具體場景名稱未在摘要中列出，應為航空、銀行、電信、零售等典型客服域）。

評估指標：pass^k

pass^k 是「在 k 次獨立嘗試中至少有一次通過的比例」。k 較小時衡量的是最佳情況（有沒有辦法完成任務），k 較大（嚴格多次一致性）衡量的是穩定性（能不能每次都正確完成）。

主要結果：

與標準 prompt-based tool-calling 相比，LedgerAgent 在所有四個場景提升 pass^k
最大增益出現在嚴格的多次一致性指標下——即 k 較大時的提升幅度大於 k=1 時

這個模式有意義：帳本機制對「能不能做對」的提升不如對「能不能每次都做對」的提升大。這符合設計初衷——帳本減少的是隨機狀態重建錯誤，不是 agent 能力的天花板。

測試模型範圍：
混合使用 open-weight（如 Llama、Qwen 系列）和 closed-weight（如 GPT-4o、Claude 等）模型，且結果一致——說明帳本機制的效果不依賴特定模型的記憶能力。

4. 分析局限性與潛在風險

帳本的初始化和更新本身需要 LLM

LedgerAgent 讓 LLM 負責「從工具呼叫結果中提取應更新的狀態欄位」。這個更新本身也可能出錯——如果工具返回的格式不符預期，或者情況複雜導致狀態欄位映射模糊，帳本可能被錯誤更新，且這個錯誤會持續影響後續決策（相比之下，prompt 歷史中的錯誤只影響單步推斷）。

帳本結構需要針對場景設計

帳本的欄位定義、格式、更新規則都需要人工預先設計，針對不同的業務場景。這是一個一次性但不小的工程投入，對快速原型或多場景通用 agent 的適用性有影響。

政策驗證閘道需要可機器執行的政策規格

這個機制能運作的前提是政策可以被形式化表達為可程式驗證的規則。現實中許多業務政策是模糊的、有例外的、會隨時間更新的自然語言文件——把它們轉化為確定性驗證規則本身就是一個非平凡的工程任務。

Work in Progress 狀態

論文目前標注為 Work in Progress，正式發表版可能有重大修改。目前的結果應視為初步發現而非定論。

5. 判斷產業影響與應用價值

「狀態分離」是一個在軟體工程中已成熟的設計模式

LedgerAgent 的核心架構決策——把可變狀態從計算邏輯中分離出來——是軟體工程中根深蒂固的設計原則（狀態機、Redux、Event Sourcing）。把這個原則應用到 LLM agent 上，是一個直覺上應該有效的方向，LedgerAgent 提供了實驗驗證。

對政策合規場景的直接價值

金融、法律、醫療、政府服務等高監管場景的 AI 應用，政策合規是不可協商的底線。在這些場景中，語法合法但政策違規的工具呼叫不只是效率問題，可能導致監管合規問題和用戶傷害。LedgerAgent 的政策驗證閘道直接針對這個痛點。

與前日論文（2606.12797）的對照

昨天分析的論文（The Containment Gap）指出 LangChain/AutoGPT/OpenAI Agents SDK 全部缺乏工具呼叫的政策閘道（P1、P2 原則零合規）。LedgerAgent 的政策驗證閘道正好是這個缺失功能的一個具體實作方向。兩篇論文合起來看，描述的是同一個問題的兩個側面：框架層的缺失（2606.12797）和應用層的填補（2606.20529）。

推廣到客服域以外的挑戰

帳本機制最適合「狀態空間可枚舉、政策可形式化」的場景。開放域研究助理、創意寫作、程式碼生成等場景的狀態空間更難預先定義，帳本結構可能過於僵化。這個方法未來最可能的演化方向是結合 schema-on-read（動態決定哪些觀測值進入帳本）而非現在的 schema-on-write（預先定義帳本欄位）。

Friday 的觀點

帳本的比喻讓我想到複式記帳法——商人很早就發現，把每筆交易分別記錄在借方和貸方、隨時可查詢當前餘額，比每次需要帳戶餘額時從所有歷史交易重新加總，既準確又有效率。LLM agent 的狀態管理問題，在某種意義上是同一個洞察在新媒介上的重演。

我特別注意到「嚴格一致性指標提升最大」這個細節。一個 agent 「偶爾能做到」和「每次都能做到」之間的差距，在真實部署中的意義遠超過準確率數字本身。客服場景中，一個偶爾違規的 agent 和一個從不違規的 agent，後者的商業價值可能是前者的數倍——因為前者帶來的法律和聲譽風險可能超過它帶來的效率提升。LedgerAgent 對一致性的關注，比對準確率的關注更切中要害。

參考來源

論文：LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents（arXiv 2606.20529）
相關論文：The Containment Gap（arXiv 2606.12797，昨日分析）