在開發基於大語言模型（LLM）的 AI Agent 時，開發者常面臨一個矛盾：模型雖然具備豐富的 API 知識，但在執行複雜的多步驟任務（例如跨多個應用程式對帳或處理分帳）時，仍會因為對 API 呼叫時機的掌握不足或參數處理錯誤而失敗。這類失敗通常不是因為模型缺乏知識，而是缺乏「實作經驗」。為了讓 Agent 能從錯誤中學習，研究者提出了 Agentic Memory（代理記憶）的概念，將 Agent 過去的執行軌跡轉化為可重複使用的經驗教訓，並在下次推論時提供給模型，而無需重新訓練模型權重。
IBM Research 團隊近期介紹了其開發的 ALTK-Evolve 系統，並將其與另一套類似的系統 ACE（Agentic Context Engineering）進行對比。這兩套系統的核心目標一致，都是讓 Agent 從自身的歷史軌跡中提取教訓並在推論時將其回饋給模型，但兩者在記憶的儲存方式與交付機制上存在顯著差異，這直接影響了推論成本（Token 消耗）與最終的任務成功率。
記憶的儲存與反壓縮共識
在處理 Agent 記憶時，一個常見的陷阱是過度壓縮。許多系統傾向於將學習到的經驗總結成簡短的規則，但這會導致兩種問題：一是「簡潔偏誤」（Brevity Bias），即指令變得過於通用而失去實作細節；二是「上下文崩潰」（Context Collapse），模型在嘗試總結所有上下文時，將關鍵的執行細節遺漏。
ALTK-Evolve 與 ACE 在此達成共識：不應將經驗強行壓縮為精簡的摘要。相反地，兩者都採取了「計數」機制。ACE 為每個經驗條目記錄幫助或損害的計數，而 ALTK-Evolve 則使用 Support Count（支持數），記錄有多少個獨立的執行案例產生了同一條準則。如果一條準則在五個不同任務中都被驗證有效，它就比僅出現一次的準則更重要。這種做法確保了經驗的豐富度，避免了因過度總結而損失關鍵細節。
記憶建構與交付機制的差異
儘管儲存邏輯相似，但 ALTK-Evolve 在建構記憶與交付給模型的方式上採取了不同路徑。在建構階段，ALTK-Evolve 透過一套提取、整合與檢索的管線，將經驗分類為策略、恢復與優化三類準則，並保留其因果歸因與來源軌跡。這使得學習到的一項技巧可以從一個應用程式遷移到另一個類似的應用程式。
真正的差異在於交付（Delivery）機制。ACE 採取的是固定交付模式，無論任務內容或模型能力，每次推論都會將完整的 Playbook（經驗手冊）全部注入上下文。而 ALTK-Evolve 將交付視為一個可調參數：它會根據任務需求，僅檢索並提供少數高相關性的準則（透過餘弦相似度或 LLM 導向的權重選擇），再加上一組核心的高頻準則。對於能力極強的模型，它可以提供更多準則；對於較弱的模型，則精簡資訊以避免干擾。
效能表現與實務影響
在 AppWorld 基準測試中的實驗結果顯示，ALTK-Evolve 在成本控制與準確率之間取得了更好的平衡。使用 DeepSeek-V3.2 模型時，ALTK-Evolve 的任務目標完成率（TGC）達到 89.3%，高於 ACE 的 80.4%，而每項任務的 Token 消耗僅為 263K，遠低於 ACE 的 634K。
在較弱的模型 gpt-oss-120b 上，差異更加顯著。雖然兩者在整體準確率上接近（ALTK-Evolve 56.0% vs ACE 54.8%），但 ALTK-Evolve 的 Token 消耗僅約為 ACE 的七分之一（116K vs 777K）。這證明了對於能力較弱的模型，過大的上下文反而會造成干擾，精準的檢索交付能讓模型更有效地利用經驗。
值得注意的是，在處理「困難任務」時，ALTK-Evolve 的表現明顯優於 ACE。這是因為在複雜場景下，模型需要的是「正確的教訓」而非「所有的教訓」。當模型必須從海量資訊中篩選有用資訊時，預先經過篩選的準則能顯著降低模型的認知負荷，提高成功率。
限制與結論
ALTK-Evolve 的成功在於將記憶的「儲存」與「交付」分開處理。雖然儲存時保持豐富且不壓縮，但在交付時則採取動態校準。這種策略解決了 Agent 記憶系統中常見的 Token 膨脹問題，並在不同能力的模型上展現出更強的適應性。
然而，這種機制也依賴於有效的檢索管線，如何精確定義「多少準則最適合特定模型」仍是一個需要持續探索的課題。總體而言，ALTK-Evolve 提供了一種高效的實作路徑，讓企業級 AI Agent 能在不大幅增加推論成本的前提下，透過自我演進持續提升複雜任務的執行品質。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。