Databricks 推出 Agent Memory：讓過往工作可重複使用
Databricks 推出測試版 agent memory，挑戰企業代理每次對話都要重新發掘早前所學的做法。公司於 10 月 20 日發布的《Introducing Agent Memory on Databricks》，將持久化情境置於其代理開發平台 Agent Bricks 之內。實際問題在於：保留經驗能否在不斷變化的業務工作中帶來可靠改進。
核心比較在於受管理記憶，與重複重新發掘及自建記憶基礎設施之間的取捨。企業開發人員必須決定，維護自家系統是否仍值得其工程成本。Amazon 的 AgentCore 已提供受管理記憶，因此 Databricks 加入了一場既有競爭：代理累積的知識應存放在哪裏。
對買方而言，這項公告帶來的問題比助理是否記得偏好的回應格式更具體。平台能否保留有用的修正、在適當時候套用，並說明記憶中的資訊何時影響了回答？這個組合決定了記憶會成為營運優勢，還是另一個錯誤來源。
Databricks 推出的 Agent Memory 讓情境得以持久保存
Databricks 將跨工作階段記憶包裝成營運服務，把部分實作負擔從應用程式團隊轉移出去。
該公司的 agent memory 公告描述了受管理的對話歷史、持久記憶，以及整合代理應保留內容的背景程序。該服務在 Lakebase 上運行，後者是 Databricks 的受管理 Postgres 資料庫。Databricks 表示，開發人員可檢視、匯出及刪除已記憶的條目。
這改變了企業應用程式的起點。過去，自行建立持久化機制的團隊必須把儲存空間連接到選取及擷取有用資訊的規則。受管理選項讓團隊可先評估現有實作，再決定是否投入建立自家方案。
這個分別很重要，因為保留對話記錄並不會自動產生有用記憶。記錄會保存曾發生的事情，包括錯誤、已放棄的方法及暫時性的假設。有用記憶需要判斷哪些部分值得影響未來工作。
以一個示例分析助理為例，它收到有關收入定義的修正。該修正可能只適用於某個部門、報告期間或特定儀表板。若只記住句子而沒有其適用範圍，便有可能把昨天的答案套用到不同問題上。
正是在這裏，公告的意義超越了個人化。對語調的偏好影響呈現方式；已記憶的業務定義則影響答案的實質內容，以及其後可能採取的行動。
因此，工程決策涉及的不只是儲存，也涉及責任。即使開發人員採用受管理記憶，仍要決定哪些保留資訊適合納入其應用程式。他們亦需要有方法質疑看似權威、但已不再適用的條目。
Databricks 推出的 Agent Memory 為這些團隊提供了一個基礎設施選項。但這並不代表每段對話都應產生持久知識。選擇性保留仍然是產品決策，尤其當用戶把長期偏好與臨時要求混在一起時。
應用程式可以合理地記住用戶偏好的報告格式，同時拒絕保留暫定預測。兩種說法都透過對話傳達，但承載着不同期望。把它們一視同仁，會令持久化較易實作，卻較難取得信任。
因此，眼前的改變具體但有限。Databricks 現在為開發人員提供受管理的位置，以在不同對話之間保存經驗。這些經驗是否值得重用，取決於應用程式的規則及每項記憶背後的證據。
這個界線塑造了商業層面的影響。團隊可把基礎設施工作轉移至平台，但無法轉移其對何謂有效業務知識的理解。
企業團隊面對不同的自建或採購決策
承受壓力的是那些在維護記憶基礎設施之餘，亦要維護依賴它的代理的團隊。
對內部平台團隊而言，自建記憶意味着持續承諾。必須有人調查遺漏的條目、不當的擷取、互相衝突的修正，以及更新失敗。即使最初的示範成功，這些責任仍會持續存在。
受管理服務把比較從功能是否可用，轉變為營運價值。問題變成自訂實作能否提供足夠控制力或專門性，以證明其維護成本合理。這比單純展示代理能儲存資訊要求更高。
保留自訂方案有合理原因。機構可能需要專門的保留規則、不尋常的部署邊界，或可在既有系統之間共用的記憶格式。這些要求值得評估，而非假設受管理基礎設施必然勝出。
相反，要求傳統的團隊，若只是因為已擁有應用程式而重建熟悉的底層機制，收穫可能不大。其稀缺的工程資源，或可透過更佳評估或更清晰的用戶控制帶來更多價值。
Databricks 的加入亦為企業買方提供另一個比較點。Amazon 的 AgentCore 記憶類型文件描述了原始互動儲存，以及透過背景程序擷取的長期記錄，亦描述了跨後續工作階段的整合與擷取。
這種重疊建立了競爭基準。持久記憶已是另一家大型供應商提供的平台能力。Databricks 必須透過實作品質、營運配適度，以及與客戶實際運行工作負載的整合來競爭。
現有文件並不足以判定這些服務誰的效能較佳。架構說明解釋預期行為，卻不能取代等效測試。公平比較應保持工作、模型、歷史記錄及評分規則一致。
對買方而言，這代表供應商選擇應依循應用程式的失敗模式。會忘記偏好的支援助理，與反覆選錯來源的分析代理，有不同要求。記憶品質必須針對買方希望解決的具體問題衡量。
採購討論亦需區分便利性與依賴性。整合基礎設施可減少機構要營運的系統數量；當累積情境成為應用程式行為的一部分時，亦會令遷移變得更具影響。
可匯出的條目固然有幫助，但單靠匯出並不保證在其他地方有等效行為。另一個系統可能選取不同記憶，或以不同方式解讀相同的保留文字。可攜性既值得進行行為測試，也值得進行資料轉移測試。
因此，採購受管理記憶最有力的理由在於實際成效：服務應在保留應用程式所需控制力的同時減少維護工作。買方應在把基礎設施整合視為改進之前，要求這兩方面的證據。
壓力同時落在自訂實作與受管理供應商身上。兩者都必須說明其方法如何改善已完成的工作，而非只是增加代理可保留的資訊量。
機制取決於選取值得重用的內容
核心設計問題是決定哪些經驗應影響下一項工作。
Databricks 的 記憶管道文件描述背景處理如何擷取持久資訊、合併重疊條目，以及重組已儲存記憶。開發人員可提供關於保留內容的指示。文件所述設計傾向於可重用的事實及程序，而非應從即時來源取得、可能變動的數值。
這個分別對企業分析有直接影響。記住指標的計算方式，可協助代理重複有效工作流程；記住指標先前的數值，則可能在底層業務變化時產生過時答案。
一個示例銷售助理清楚說明其中分別。它可以保留某團隊在特定報告中排除已取消合約的規則；但在準備下一份報告時，仍應取得目前的合約資料。
保留規則可減少重新發掘，卻不會取代最新證據。不過，若機構改變該規則，記憶便需要得到適當修正。因此，成功重用取決於保存及修訂兩者。
背景處理帶來另一個決策界線。管道文件允許手動執行，或約每 24 小時排程執行。因此，應把排程整合理解為延遲處理，而非保證每項新修正都會立即重塑所有未來互動。
對應用程式設計人員而言，啟示很直接。用戶下一項要求便需要的修正，應與可等待日後整合的知識採取不同處理。用戶不應必須理解處理排程，才能知道修正是否已生效。
文件亦指出，維護作業可更改代理直接儲存的條目。這意味着已儲存記憶是對對話不斷演變的詮釋的一部分，未必是原始陳述的永久副本。
這為產品團隊帶來問責問題。若已記憶的指示在整合期間改變，應用程式應有足夠證據解釋由此產生的行為。否則，用戶只會看到助理改變了理解，卻沒有可理解的原因。
一個有用的比喻是分析師維護工作筆記。筆記只有在保留相關條件，並能與已核實的來源資料區分時才有用。代理所保留的摘要也應接受類似審視。
同樣的分別也見於 個人知識管理：收集資訊與令資訊發揮作用是相關但不同的工作。對企業代理而言，有用性亦取決於保留資訊是否仍適合目前要求。
這個機制令記憶成為應用程式行為的活躍部分。它在下一項工作開始前選取、壓縮及更新經驗。評估這項服務的團隊應判斷這些轉換，而非把成功儲存視為終點。
基準測試支持一項有限的效能主張
Databricks 報告其企業基準測試有所改善，但這些結果並不能證明具普遍性的增益。
該公司的 MemCurrent research 說明了這次發布背後的架構。在其內部基準測試中，Databricks 報告指出，使用 MemCurrent 的通過率為 68.4%，相比之下，不使用記憶功能時為 22.3%。該公司亦報告指，所需 token 減少 31%，執行速度提升 26%。
該內部基準測試包含 114 宗案例，涉及 29 名用戶及 2,233 個歷史工作階段。Databricks 表示，評估是根據企業數據對話構建，並已審閱這些案例。這些是公司自行報告的結果，並非對每項部署的獨立驗證。
研究亦報告了一項示例性的工作流程改善：在較早前一項工作需進行 11 次工具呼叫及接近六分鐘後，相關的後續工作只需兩次工具呼叫及 41 秒。這個例子支持避免重複探索這一建議機制，但並未確立客戶應預期的平均改善幅度。
區分示例與預期成果相當重要。具備可重用背景資料的重複工作，為記憶功能提供了有利的應用機會。需求不相關的新工作，則未必能從歷史資訊中獲益多少。
同樣地，較低的 token 數量衡量的是某一特定資源，而非整體營運負擔。團隊仍須計及產生、維護、檢查及評估記憶所需的工作。部署決策應考慮整個應用程式。
這些發現最適合作為測試特定假設的理由。若代理程式不斷重新發現穩定的業務知識，保留過往經驗應可減少這種重複。當過往對話幾乎不提供相關資訊時，這項假設便會變得較弱。
評估亦應包括記憶理應維持未使用狀態的工作。否則，系統可以透過在每個答案中加入歷史背景資料而看似成功。選擇性十分重要，因為不相關的回憶本身亦會造成干擾。
獨立研究提供了更廣泛的評估框架。在 ICLR 2025 發表的 LongMemEval benchmark，測試擷取、跨工作階段推理、時間推理、知識更新及棄答。棄答是指在現有證據不足以支持回應時，拒絕作答。
這些類別揭示了為何單純回憶並非完整的衡量方式。助手可以準確檢索舊有陳述，卻仍在錯誤的時間套用它。當其記憶中沒有相關證據時，它亦可能自信地回答而失敗。
因此，對企業買家而言，有用的問題比「記憶是否改善基準測試分數」更為狹窄。它是否改善員工實際執行的工作，包括定義已變更或指令互相衝突的情況？
Introducing Agent Memory on Databricks 為使用受管基礎架構進行這項比較創造了機會。已公布的結果足以值得關注，但應用程式本身的評估必須判斷所報告的機制能否轉移。
這是對證據的一種可辯護詮釋。該公司已提出一項可量度的主張，並說明其評估方法。客戶仍需要反映自身歷史、權限及業務決策的結果。
記憶擁有權不僅需要用戶識別碼
由於被記住的資訊可能比產生它的對話存續更久，持續性背景資料需要明確的安全及刪除規則。
Databricks 的 memory and sessions documentation 指出，刪除工作階段並不會刪除記憶。文件亦區分了用戶分區與存取控制。行為者識別碼會選擇某項操作使用哪些人的項目，但擁有儲存庫存取權的主體可以讀取屬於其他行為者的項目。
文件建議在受信任的應用程式碼中，從已驗證身分衍生該識別碼。若需嚴格的租戶隔離，則建議使用獨立儲存庫。文件亦警告，beta 版本的介面及行為可能有所變更。
對正在評估這次發布的買家而言，這些都是影響深遠的實作細節。以用戶標示資訊的欄位，並不會自動強制建立安全邊界。應用程式必須正確連結身分、權限及儲存架構。
一個示例性的客戶支援部署顯示了相關顧慮。在客戶自己的帳戶內，被記住的偏好或許無害，但在另一名客戶的對話中則可能不恰當。正確檢索要求應用程式在模型請求任何記憶前，先確立正確身分。
刪除帶來另一個問題。用戶可能合理地相信，移除一段對話便會移除助手從中學到的內容。若衍生資訊仍然存在，產品便需要清楚說明這種區別。
這是應用程式設計上的含義，而非某個特定部署處理刪除不當的證據。文件所列出的分離情況，使其成為團隊必須回答的問題。完整的刪除政策應涵蓋原始互動及從中保留的資訊。
更正同樣值得關注。取代錯誤記憶應影響日後行為，但團隊亦需要理解該更正如何與餘下歷史資料互動。否則，同一組底層證據可能再次支持錯誤詮釋。
記憶亦可能保留本不應獲得持久權威的指令。設想一份包含具誤導性營運指示的示例文件。若代理程式將該指示概述為已獲接受的做法，錯誤便可能影響原始文件審閱以外的後續工作。
這種情況需要評估來源權威性及保留行為。不應將其描述為 Databricks 已被發現的漏洞。相關問題是，應用程式是否能區分用戶已批准的偏好，以及工作期間遇到的不受信任內容。
產品體驗在這方面與後端同樣重要。用戶需要易於理解的方法，以檢查重要記憶、更正它們及要求移除。若控制項仍無法讓受影響人士存取，一項技術能力的實際價值便有限。
對開發人員而言，營運層面的啟示很具體。記憶引入了另一條資訊進入答案的途徑。因此，除錯需要考慮代理程式記住了甚麼、為何檢索該資訊，以及應用程式是否授權其使用。
這些責任不會因受管儲存而消失。它們會成為決定受管服務是否符合應用程式信任邊界的一部分。
Beta 公告後值得關注的事項
下一批證據應把受管記憶與可重複的客戶成果及更清晰的營運限制連繫起來。
第一個訊號是針對重複性企業工作、由獨立機構或客戶公開的評估。有用的結果應比較同一應用程式在有及沒有記憶功能下的表現，同時涵蓋更正、事實變動及無關請求。這類證據可測試保留背景資料是否能在公司所選案例以外改善工作。
具說服力的評估應同時說明失敗與成功。若效能只在高度重複的問題上改善，效益仍較持久的業務理解狹窄。若增益能持續出現在相關但不同的工作上，重用經驗的理據便會更強。
第二個訊號是圍繞營運限制及用戶控制的產品發展。買家應留意有關排程、規模、隔離、檢查及刪除行為的文件化變更。這些細節決定哪些應用程式可依賴該服務，而毋須建立大量配套基礎架構。
這些控制項的進展會強化自建或採購的論據。若團隊仍需大量自訂機制來管理一般記憶行為，營運優勢便會變得較不吸引。相關衡量標準是該服務實際卸除多少責任。
第三個訊號是競爭對手如何令其自身的記憶主張更易驗證。Amazon 現有的產品意味著該類別已有其他選擇。更清晰的比較評估有助客戶分辨行為差異與術語差異。
單靠競爭回應不足以確立 Databricks 的優勢。它們會顯示受管記憶已成為平台選擇的另一個維度。顯示應用程式能跨服務保留有用行為的證據，亦會釐清買家可預期多少可攜性。
這些訊號應一併看待，因為採購涉及的是持續運作的系統。缺乏控制的效能會帶來棘手的營運問題。缺乏有用工作改善的控制，則令買家維護另一項價值仍未確定的功能。
對知識工作者而言，成果應在日常使用中清晰可見。助手應需要較少重複更正，同時在情況改變時仍能作出回應。更一致地記住過時假設，便偏離了重點。
對開發人員而言，這次公告創造了一項聚焦實驗。選擇一個存在可識別記憶相關失敗、且會重複出現的工作流程，然後在一致條件下比較成果。將即時證據與已記住的指引分開，並檢視歷史資訊應避免出現在答案中的情況。
Introducing Agent Memory on Databricks 為企業團隊提供了一項可針對現有方法評估的具體服務。先從代理程式反覆出錯或不必要地重複的工作開始。識別哪些更正值得持續保留，以及哪些事實必須維持與目前來源掛鈎。然後檢視保留背景資料是否能改善後續決策，同時不會把過時假設帶到未來。詢問誰可以檢查記憶、誰可以更改它，以及移除在整個應用程式中代表甚麼。將已公布的基準測試視為值得針對自身工作測試的假設。在擴大採用前，你的團隊能否證明代理程式記住了正確的教訓，並在該教訓不再適用時停止使用它？
