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 打造具備持久記憶的 AI 代理程式

Perplexity 的 Agent API 並不提供像 Brain 那樣會自我維護的記憶系統，我們寧願先說清楚。但它確實為你提供所需的記憶組件：存放程序的地方、在對話輪次之間延續上下文的方法，以及讀寫由你控制的儲存空間的工具。

從程序記憶開始

自訂技能會將指示、程序及輔助檔案以版本號碼打包。平台團隊只需編寫一次部署檢查、回滾準則及報告格式，便可讓各應用程式引用同一個技能。當程序有變，團隊上載新版本即可。

放大

來源：X

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

我們在九月同時推出了這兩項功能，並一併推出代管連接器，讓專案管理員只需設定一次已核准的 GitHub 或 Slack 連線，各應用程式便可直接引用，毋須另行儲存憑證。當存取權限有變，管理員只需在一處更新連線。

為何這也算是記憶？再回到那個有人用微波爐翻熱魚的廚房。下一個來的人即使沒有親眼目睹那些投訴，也能遵守「NO FISH」的告示。

技能為 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 代理程式的輸出及擷取的佐證、根據預期行為加以檢查，並在更改指示或模型後比較各次執行結果。

比較有記憶與沒有記憶的執行結果時，請固定模型、Profile 及技能的版本。每次比較都應從儲存庫的已知快照開始；否則，一項測試可能會讓 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 代理程式完成任務、套用修正，以及淘汰過時的指引。