AI 代理程式記憶：如何建立具備持久脈絡的 AI 代理程式

如果你得連續六個月每天早上陪一位新同事走去印表機，你應該會開始擔心。如果對方能把之前每一趟路程背誦得鉅細靡遺，卻仍然需要有人陪同，那他的記憶力確實一流……但你還是得從座位上起身。

目前的 AI 代理程式記憶，就有點像這種永無止境的印表機陪走。Letta 執行長 Charles Packer 在 The New Stack 上表示，記憶基準測試已經飽和，因為它們衡量的是回想能力，而他認為這個問題已經解決。真正尚待解決的問題，是讓代理程式透過其保留的脈絡在工作上不斷進步，而且完全不需要重新訓練。

他的共同創辦人 Sarah Wooders 把這比喻成不斷開始一份新工作——基準測試會提供代理程式所需的一切脈絡——接連處理一個又一個彼此無關的任務，這與人們實際的工作方式截然不同。新進員工或許需要有人帶去印表機。但三年後，你會希望只要交代一句話就好，不必從座位上起身。

這正是我們努力追求的標準，也是 Brain 背後的目標。Brain 是我們為 Perplexity Computer 打造的自我改進記憶系統，能將過去的工作與修正整理成一個不斷演進的知識 wiki。

我們將探討代理程式應該記住什麼，以及如何測試記憶是否有助於代理程式把工作做得更好。

什麼是 AI 代理程式記憶？

AI 代理程式記憶是指代理程式從先前互動和工作中保留的資訊，以及更新和運用這些資訊的機制。持久性記憶脈絡會在不同工作階段之間延續這些資訊，因此結束一段對話，並不代表下一個任務就得從頭開始。

大多數以此為名推出的功能，記住的是使用者：你的偏好、你的聯絡人、你的職位，以及你想要 PDF 而不是 PNG 這件事。這是比較容易的那一半。

我們在打造 Brain（Perplexity Computer 背後的記憶系統）時，把重點放在工作本身。哪種方法成功了？哪個來源浪費了二十分鐘？代理程式宣稱完成後，你還得修正什麼？這些歷程能讓下一個任務有更好的起點。

Brain 會將這些資訊以檔案形式儲存在代理程式的沙箱中，並分為三層：

• sessions/ 存放原始對話記錄及其摘要。
• notes/ 存放依主題整理的精煉資訊。
• knowledge/ 存放 wiki 本身，也就是彼此連結、涵蓋人物、專案與概念的 Markdown 頁面。

這些內容都不會自行改善。我們稱為「Dream」的背景代理程式會在夜間讀取當天的工作階段、加以摘要，並在情況有所變化之處修訂 wiki。我們會先暫存並檢查這些編輯，再透過 Git 提交，因此一旦有地方看起來不對勁，就有 diff 可以檢查。

這能讓代理程式把工作做得更好嗎？在我們為期 30 天的配對評估中，啟用 Brain 的工作階段正確率提升了 9.3 個百分點，回想率提升了 8.9 個百分點，同時使用的 token 減少約 15%。

放大

來源：X

代理式記憶有哪些類型？

大致可分為兩種，分法和我們看待人的方式很像：你此刻腦中正在處理的事，以及下個月仍會記得的事。

短期記憶

短期記憶保存目前對話或任務的脈絡：你的請求、最近的訊息、工具呼叫的結果，以及代理程式剛開啟的文件。這些資訊足以讓它判斷下一步該做什麼。

你也會看到它被稱為工作記憶。對 LLM 而言，脈絡視窗保存的是特定一次模型呼叫期間可用的資訊。應用程式可能會另外維護任務狀態，並決定在每個步驟提供哪些部分。

而且短期並不一定代表用完即丟。框架可以儲存對話狀態並在隔天繼續——它仍然屬於那個討論串。但其他任務能否使用這些資訊，則是另一個設計決策。

長期記憶

長期記憶讓資訊能跨工作階段使用。CoALA 論文借用了認知科學中的三個類別，為代理程式開發者提供了一套描述經驗與專業知識的詞彙：

• 情節記憶是發生過的事：包括過去的工作階段、代理程式採取的步驟，以及它得到的結果。在 Brain 中，sessions/ 透過原始對話記錄及其摘要提供這段歷程。
• 語意記憶是代理程式認定為真的事：可能是從對話中提煉出、關於使用者及其專案與世界的事實。Brain 的 knowledge/ wiki 就保存這類資訊，並附有連回證據的連結。
• 程序記憶是做事的方法：包括提示、可重複使用的工作流程，以及 Perplexity 打造的技能，為代理程式提供完成工作所需的指示和工具。你可能早就擁有其中一些，只是沒有把它稱為記憶。

真正有趣的工作發生在各層之間。某個工作階段記錄了你拒絕一張 PNG。你要求使用 PDF 的指示，成為代理程式可以延續下去的偏好。對匯出流程的一次修正，則成為它下次可以遵循的做法。

這種從「發生了這件事」到「這是真的」，再到「我們就是這樣做」的轉換，正是我們開頭提到的學習問題的一部分，也是 Brain 的夜間 Dream 代理程式執行時投入心力之處。

假設有人在共用廚房裡用微波爐加熱魚。有人抱怨，有人打開窗戶。最後，出現了一張告示：嚴禁魚類。

六個月後，肇事者已經搬走了，但告示還在。這就是持久性。你可以從留存下來的東西來解釋各種記憶類型：

• 工作記憶是你做午餐時要隨時留意的事，例如湯需要攪拌。
• 情節記憶是那次魚的事件，也就是那股一路跟著大家飄進走廊的氣味。
• 語意記憶是你從中得到的知識——在共用廚房加熱魚，可能會留下久久不散的氣味。
• 程序記憶是規範接下來該怎麼做的指示：不要在這裡用微波爐加熱魚。這張告示讓完全錯過整起事件的人也能遵守規則。

還有另一項區別值得一提，因為它會改變我們要打造的東西。2025 年 12 月首次發表的調查論文《Memory in the Age of AI Agents》指出，只區分短期與長期還不夠——它也依形式來分類記憶：

• Token 層級：這是代理程式讀取的明確內容，例如檔案、儲存的記錄、檢索到的區塊。
• 參數式：這是編碼在學習所得權重中的資訊。更新它需要透過訓練或模型編輯方法。
• 潛在式：這是保留在內部表示中、未被寫成可讀文字的資訊。

這裡我們聚焦於 token 層級記憶，也就是儲存在模型之外、需要時再讀入其脈絡的資訊。Brain 的 Markdown wiki 就是一個例子。

放大

當我們更新頁面時，改變的是代理程式在下一個任務中能讀取的內容，但其底層權重維持不變。這正是前言中 Packer 的觀點：透過代理程式保留的脈絡變得更好，而不需要重新訓練。

各種代理程式記憶類型如何協同運作？

代理程式可以回顧先前的嘗試，看看哪裡出了錯，並載入你事後給它的指示。同一個任務會涉及好幾種記憶，而且它們不需要輪流運作，也不需要各自獨立的資料庫。

在這裡，持久性決定對話結束後還有哪些內容可用，而檢索則決定代理程式是否會再次看到這些內容。

在 Brain 中，我們保留了從經驗教訓回溯到證據的這條路徑。假設你請 Computer 接續上週的一個專案：

• Brain 的索引會告訴它有哪些記憶頁面，以及在哪裡可以找到。
• Brain 會開啟專案頁面，讀取已儲存的決策和指示。
• 如果某則筆記提到你曾否決某種做法，代理程式可以循著它的引用回到那段對話，查明原因。

透過連往相關頁面的連結，它可以查詢涉及的人員或其他專案。代理程式是透過讀取和搜尋檔案來做到這一點。例如，grep 可以讓它依名稱找出提及某個專案的地方。

我們也測試了代理程式能從探索檔案的能力中獲得什麼。在一項包含 150 道財務文件問題的內部基準測試中，使用標準檔案工具的探索代理程式答案得分達到 0.627，而在相同語料庫上使用語意搜尋的得分約為 0.37。

放大

來源：X

如何改善 AI 代理程式記憶？

Orogat 與 Mansour 於 2026 年 5 月發表的論文指出代理程式記憶中四種反覆出現的失誤：儲存內容不斷增長、過時的認知未被修正、空間不足時資訊遭到遺忘，以及檢索只讀取內容，卻沒有從這次存取中學到任何東西。

他們提出的解決方法，是不再把代理式記憶當成儲存空間，而是將其視為一種透過四種操作不斷演進的「狀態」：攝取、修訂、遺忘、檢索。這也是本節的檢查清單。

慎選要記住的內容

一旦「不良」記憶被存入，之後的每個步驟都會承襲它。

Workday AI Research 以 LoCoMo 基準測試中約 1,500 則候選記憶測試了一種選擇性方法，在保留任何一則之前都先問五個問題：

• 它有用嗎？之後有可能再次用到嗎？
• 它可信嗎？對話中真的這麼說過，還是模型自行補上的？
• 它是新的，還是已經儲存過了？
• 它是最新的嗎？
• 它是持久的事實，還是暫時的狀態？

只有第一個問題需要呼叫模型。其餘四個以規則執行，合計不到 65 毫秒。這個方法在保留或捨棄的決策上，精確度提高了 12%，同時保留了 97% 的相關記憶。

影響最大的是最後一個問題——如果去掉持久資訊與暫時資訊的區別，決策品質會下降約 18%。

修訂答案，但不遺失歷程

記錄某項事實何時開始成立、由哪個來源佐證，以及它取代了什麼。如果來源之間有分歧，就讓分歧保持可見，直到有足夠證據加以釐清。最新的文件也可能是錯的。

Brain 會根據來源文件、連接器結果和使用者修正來更新 wiki。每筆記憶項目都會連回其來源。我們需要代理程式能找到目前的答案，並在答案看起來可疑時有地方可以查證。

刻意遺忘

這篇論文將其中一種失誤模式稱為「容量驅動的遺忘」：資訊被移除是為了符合儲存上限，而不是因為它已不再有用。

回到共用廚房。六個月後，沒有人在乎是誰微波了魚，或窗戶開了多久。但那張告示仍然有它的用處。

下一個人做午餐時，規則依然在那裡。你只需要把那些抱怨歸檔就好。

Workday 的新鮮度與資訊類型檢查在儲存之前就開始了，用來篩選哪些內容值得成為記憶。在 Brain 中，我們也會隨著來源文件變動和使用者提出修正，重新檢視既有知識。無論哪種情況，都是內容本身讓介入變得必要。

讓檢索回饋到下一次更新

代理程式檢索一項事實、加以使用，然後讓儲存區維持原樣。這時，除非系統記錄下接下來發生的事，否則沒有任何紀錄能顯示這項事實究竟是有幫助，還是又把代理程式帶進另一條死路。

記錄結果、來源以及任何修正。我們在打造 Brain 時，將這段工作歷程納入它記憶的內容：哪種方法成功了、哪個來源徒勞無功，以及代理程式宣稱完成後使用者修正了什麼。Brain 會將這些經驗納入定期的 wiki 更新，讓之後的任務能夠加以運用。

然而，這些都不會反映在回想基準測試上。要知道這個循環是否有效，方法是交給代理程式一項只有靠記憶才能完成的任務，並計算它完成的頻率，同時附上成本與延遲。這正是 DolphinBench 的做法，也是為什麼最高分至今仍只有七十幾分。

如何使用 Perplexity 打造具備持久記憶的代理程式

Perplexity 的 Agent API 並未提供像 Brain 這樣能自我維護的記憶系統，我們想先把話說清楚。但它確實提供了你所需的記憶元件：一個存放程序的地方、一種在多輪對話之間延續脈絡的方式，以及讓你讀取和寫入自己所控管儲存區的工具。

從程序性記憶開始

自訂技能會將指示、程序和輔助檔案打包，並標上版本號碼。平台團隊可以一次寫好部署檢查、復原條件和報告格式，再讓各個應用程式引用同一個技能。程序有所變更時，團隊只需上傳新版本。

放大

來源：X

設定檔則更進一步。設定檔會將 AI 代理程式的模型、指示、工具、技能、連接器和執行設定，儲存在單一的版本化 ID 之下。

我們在 9 月同時推出了這兩項功能，並一併推出代管連接器，讓專案管理員只需設定一次經核准的 GitHub 或 Slack 連線，應用程式即可直接引用，不必各自儲存憑證。存取權限有所變更時，管理員只要在一處更新連線即可。

為什麼這算是記憶？讓我們再回到那間有人微波魚的茶水間。下一個進來的人，即使沒有親眼見到那些抱怨，也能遵守「禁止微波魚」的規定。

技能為 AI 代理程式發揮同樣的作用，而且還能容納微波爐門上寫不下的步驟、例外情況和檢查項目。技能會以文字記錄下來、加上版本，並在下次遇到相同任務時隨時可用。

我們也使用技能來引導 Dream 的記憶更新。但技能無法做到的，是自行學習。只有在上傳新版本時，指示才會改變，無論上傳者是人還是自動化流程。

如果你希望 AI 代理程式注意到某項服務的復原檢查一再失敗並自行調整，那就是前面提到的「從工作階段到 wiki」循環。

你需要保留發生過的事、判斷哪些地方應該改變，並讓修正在下次可供使用。這就需要接下來的兩個部分。

在對話輪次之間延續工作記憶

AI 代理程式執行了一次部署檢查。你問：「那個為什麼失敗了？」這是合理的追問，前提是 AI 代理程式仍能看到「那個」指的是什麼。

我們的 Agent API 支援兩種延續對話脈絡的方式：

• 自行重播對話：將先前的訊息加入下一個請求的 input 陣列中。你可以在傳送前決定要保留、摘要、遮蔽或捨棄哪些內容。
• 從已完成的回應繼續：儲存該回應的 ID，並在下一則訊息中將其作為 previous_response_id 傳入。我們會在伺服器端保留對話狀態，因此你的應用程式不必重新傳送先前的輪次。你可以從回應鏈中最新的回應繼續。

重播讓你能掌控 AI 代理程式看到的內容，而透過 ID 繼續則省去重新組合對話的工夫。無論採用哪種方式，都請提供下一個回應所需的任何新指示、工具或模型設定。

自備情節記憶與語意記憶儲存庫

這部分是 Agent API 留給你自行處理的。

其中一種途徑是函式呼叫。你定義工具，AI 代理程式提出呼叫請求，再由你的應用程式執行並傳回結果。就記憶而言，一個簡單的起點是在 AI 代理程式行動前進行讀取操作，並在之後進行寫入操作。

如果只記錄 AI 代理程式擷取到的事實，你仍然無法得知它是否有幫助。若記錄結果、來源以及使用者修正的任何內容，你就有了情節記憶層的雛形。

我們的 MCP 支援提供了另一種途徑。如果相容的遠端 MCP 伺服器提供了你需要的操作，AI 代理程式就能直接呼叫，你不必將每項操作包裝成自訂函式。

我們的連接器讓 AI 代理程式能夠存取記憶背後的證據。GitHub、Slack、Google Drive、Datadog、Linear 和 Notion 都在我們的代管目錄中，你也可以為內部系統新增自訂連接器。

最後，決定何時審查歷史紀錄，以及何時修訂目前的記載。

測試哪些內容能在全新工作階段中留存

現在關閉對話。開始一個新的請求，不重播舊訊息，也不傳入 previous_response_id，但讓 AI 代理程式能存取相同的記憶儲存庫。在不重複提供修正內容的情況下，請它執行相關工作。

如果它還需要提醒，就代表你還沒完成。

針對部署 AI 代理程式，圍繞應該延續下去的內容建立幾項測試：

• 修正得以留存：它會擷取並使用受影響服務經過驗證的復原指令。
• 修正維持在適用範圍內：它不會更動其他服務的程序。
• 新資訊取代舊指引：當指令再次變更時，它會使用目前的版本，並能將變更追溯到其來源。

我們的回歸測試實作指南說明如何儲存 AI 代理程式的輸出和擷取到的證據、對照預期行為進行檢查，並在變更指示或模型後比較各次執行結果。

比較有記憶與無記憶的執行結果時，請固定模型、設定檔和技能的版本。每次比較都從儲存庫的已知快照開始；否則，前一項測試可能會讓 AI 代理程式學到下一項測試的答案。

發生失敗時，請保存該案例。下一次變更必須通過它。

或者略過建置：Computer 中的 Brain

如果你想要的是完整的循環而非個別零件，那就是 Computer。Brain 在其底層運作，從四種來源學習：你的工作階段、已連接的工具、你建立的檔案和成品，以及你的修正。Brain 的背景更新會強化仍然成立的內容、修訂已變更的內容，並標記過時的資訊。

你不必自己建立這個循環，只要專心工作就好。

記憶會保留你分享過的偏好與細節。Brain 則會將專案、人員、決策和未完成的工作，與其背後的證據連結起來。

你可以在記憶檢視中查看它學到的內容、追溯各個項目的來源，並編輯或刪除它們。Brain 會使用你自己的活動、排除無痕工作階段，並有專屬的開關。

放大

以 Rho 為例，某個發票專案的決策分散在 Slack、Notion、Jira、Figma 和 Google Docs 中。團隊設定 Computer 在夜間審查變更、標示不一致之處，並在 Slack 中發布晨間摘要。

他們的軟體工程師 Oktawian Jurkiewicz 注意到，Computer 也在為這個專案建立記憶。「我們並沒有定義它。」他說：「Computer 自己判斷出應該從每個來源儲存哪些資料點。」

該團隊表示每週會議時間從 2.5 小時縮短到 15 分鐘，並估計在為期 12 週的專案中節省了 120 個工時。

這 120 小時歸功於整個工作流程：連接器、夜間執行和 Slack 摘要。省下的時間中有多少單純來自記憶？我們目前還無法量化。

但我們可以建議的是，在你自己的建置中，回到前面提到的測試——在開啟與關閉記憶層的情況下執行同等的任務，然後比較完成率、成本和時間，包括有人花在修正結果上的時間。

AI 代理程式記憶常見問題

AI 代理程式能擁有記憶嗎？

可以。AI 代理程式可以透過儲存的對話、事實、偏好和可重複使用的程序，在不同工作階段之間保留資訊。系統必須在相關時擷取這些資訊，並在情況改變時加以更新。

例如，Perplexity Computer 中的 Brain 會從工作階段、已連接的工具、檔案和使用者修正中建立工作脈絡。

AI 代理程式會使用多少 RAM？

沒有單一的需求標準。如果你的 AI 代理程式透過 Perplexity Agent API 呼叫託管模型，就不必將該模型載入你自己的 RAM。不過，你的應用程式和本機工具仍然需要記憶體。

在本機執行模型則是另一回事。以每個參數 4 位元計算，80 億個參數大約相當於 4 GB 的原始權重資料。若再加上量化開銷、脈絡處理以及執行模型的軟體，實際所需的記憶體會更高。

AI 代理程式最適合使用哪種記憶？

最佳設定取決於 AI 代理程式需要延續哪些內容。對話狀態支援後續追問；情節記錄保存發生過的事；語意記憶存放目前的知識；程序性記憶則提供可重複使用的指示。

大多數持續進行的工作都能受益於多種記憶的組合。我們為 Brain 使用一個相互連結、有來源佐證的 wiki。在你自己的建置中，請測試這套設定是否有助於 AI 代理程式完成任務、套用修正，以及淘汰過時的指引。