Brain:作為知識維基的代理式記憶
一個結構化、可追蹤、自我完善的 Markdown 檔案系統,離線編譯並按需導覽。
Computer 使用者執行的工作跨越數月和數百個工作階段。到了第十個工作階段,系統的生產力應該遠高於第一個工作階段。它應該累積關於使用者、他們的偏好以及已經完成的工作的內容。
例如,當被要求繪製使用者先前解釋過的工作流程圖時,Computer 應回憶細節並用它們來建立和輸出使用者偏好風格的圖形。使用者不需要重新解釋工作流程的細節或重申他們對 PDF 勝過 PNG 成品的偏好;系統應該能夠從過去的工作階段中準確恢復該內容並自動套用它。
記憶體是代理程式持續改進的基礎。一個有效的記憶體系統應該是結構化的、可追蹤的和具適應性的,使代理程式能夠為每個任務搜尋正確的廣度和深度,同時將每一個決定根基於最新資訊中。
簡介
為代理程式灌輸相關內容是一個多面向的問題。首先,代理程式需要知道存在什麼以及如何存取它。其次,當它們找到有用的資訊片段時,它們需要確信它是完整、準確且最新的。除非代理程式能夠找到相關資訊、驗證它來自受信任的來源,並確保它不需要用最新的觀察結果進行更新,否則孤立的事實價值有限。
將靜態記憶體檔案直接塞入模型內容中可以最大化代理程式的可存取性,但也呈現了經典的精確度-召回率權衡。過多的資訊會用越來越小的相關性項目充斥代理程式的內容視窗,而過少則會由於缺乏相關內容而降低答案品質。相比之下,按需存取外部資料庫更具彈性,但將導覽的負擔轉嫁給了代理程式。向量資料庫通常儲存斷開的片段,而圖形資料庫則要求代理程式知道如何有效地查詢。
最近,我們推出了 Brain,這是 Computer 記憶體系統的核心元件,兼具兩者的優點。Brain 是一個結構化的知識維基,位於靜態記憶體檔案和證據之上。引用將斷言連結到其來源,而相關的資訊片段則橫向連接。組織化的知識維基使內容能夠按需導覽,同時詳細的成品保留在下方的層中。
Brain 連接到一個包含三個關鍵元件的綜合記憶體系統:持久記憶體儲存、使用記憶體來回答查詢的前景代理程式,以及更新和改善記憶體的背景代理程式。下圖描繪了這些位於 Brain 整體系統架構中的元件。
在本文中,我們將深入描述每一層,解釋 Brain 如何組織記憶體、代理程式如何使用它,以及背景程序如何保持其最新狀態。我們也呈現了驗證 Brain 設計的內部評估結果,證明它能以較低的成本提高代理程式效能。
記憶組織與儲存
記憶體需要一種能夠擴展到使用者完整歷史記錄的表示法,而無需將每個內容片段強行塞入提示中。Computer 的記憶體系統將持續內容表示為檔案系統。Brain 綜合了跨原始來源的知識,連接相關主題,並將宣告連接回支援它們的工作階段和檔案。這種結構在下面詳細說明,使我們能夠以非常適合代理程式的形式組織記憶體。
基於檔案系統的記憶體
工作階段已經存在於具備檔案系統、殼層和 I/O 公用程式的沙箱中。在設計 Brain 時,我們希望在模型與代理程式記憶之間的介面中,盡可能減少引入新的機械裝置。這就是為什麼我們在檔案系統原生內容層之上建構 Brain。記憶體在沙箱中的 memory/ 目錄下具體化為檔案,而代理程式只需對記憶體檔案使用它已經用於所有其他事物的相同工具。
在記憶體樹狀結構的根部坐落著三個頂層目錄,它們維護不同抽象層級的內容。knowledge/ 是 Brain 本身,一個連結實體、概念、活躍專案和過去學習成果的綜合知識維基;notes/ 包含組織為主題資料夾的精簡程式碼片段;而 sessions/ 則保存索引、摘要和完整抄本作為原始歷史記錄。下圖顯示了版面的簡化視圖。
這些表面是刻意重複的。對於簡單的單跳問題,在 /notes 中搜尋關鍵字的程式碼片段通常就足夠了,而 /knowledge 層最適用於需要跨越數週或數月 Computer 工作階段來拼湊證據的問題。
Brain:知識維基
Brain 的格式為 LLM 維基,這是一個由連結的 Markdown 檔案組成的系統。這種輕量結構化的 Markdown 形式提供了現有內容的整體檢視,以便代理程式可以輕鬆了解有哪些記錄可用、它們如何關聯以及在哪裡可以找到它們。每個頁面都是一個主題的維護視圖;當單獨閱讀時,它應保持有用,同時透過連結使進一步探索變得容易。
連結有兩種。「[[wikilinks]]」是內容邊。它們橫向連接頁面;專案可以連結到其擁有者、客戶或它所依賴的概念。追蹤它們可以回答「我還需要知道什麼?」。[cite:N] 參考是證據邊。它們將宣告向下連接到支援它們的原始工作階段或連接器來源。追蹤它們可以回答「我怎麼知道這是真的?」。
下圖描繪了 Brain 的一部分對於綜合人物誌(一位名為 Nadia 的無障礙研究人員)的外觀。她的 Brain 包含一個關於範例專案的頁面(日本的通用設計衝刺),綜合了來自工作階段和連接器的知識。圖形視圖展示了頁面中存在的內容和證據邊如何連結相關實體和來源。
Brain 具有 Git 備份以保留版本歷史記錄,從而支援其不斷演進的性質。隨著時間的推移可以編輯頁面,而變更日誌則記錄關鍵更新,並允許代理程式輕鬆檢查過去的版本和 diff。這也支援代理程式協調,這至關重要,因為多個代理程式可能會同時使用和更新 Brain。
使用 Brain
在回答使用者查詢時,代理程式需要能夠在正確的細節層級找到正確的內容。Brain 的結構使代理程式能夠輕鬆探索記憶體。代理程式可以在可行的步驟之間進行選擇,例如追蹤內容連結以尋找相關資訊、追蹤證據連結以驗證宣告,或呼叫子代理程式以取得並綜合額外的內容。我們以多種方式引導代理程式探索過程,旨在最大化代理程式存取相關資訊的便利性。
探索策略
我們在初始使用者訊息中包含了 Brain 的精簡索引,因此代理程式以現有內容的工作知識開始。然後,代理程式使用熟悉的的操作與 Brain 互動:讀取索引引用的特定項目、使用 grep 搜尋跨頁面內容、追蹤連結和檢查引用、比較 Git 修訂版本,以及深入到工作階段或原始軌跡中。下方的程式碼區塊描繪了綜合人物誌的範例命令。
# 1. Orient: the index is a map of everything known
cat memory/knowledge/index.md
# 2. Target: find pages that touch the question
grep -Ril "kyoto\|sendai" memory/knowledge/
# 3. Read the page; follow context edges as needed
cat memory/knowledge/projects/japan-universal-design-sprint.md
cat memory/knowledge/entities/sora-city-laboratory.md # via [[wikilink]]
cat memory/knowledge/entities/sapphir-mobility-coop.md # via [[wikilink]]
# 4. Only if the claim must be verified: resolve evidence
# city bases → [cite:1], [cite:10] → pplx://sessions/<id>
#
# Example (pseudo, replace with your real tool):
# pplx-session-fetch 1eaf53d4-09e0-5823-bb96-c8662f582708 --slice <slice-id>
# 5. Some evidence lives outside the sessions
# meeting slots → [cite:15] → connector://google-calendar
#
# pplx-connector-fetch google-calendar --query "japan-sprint"代理程式透過自我導向的迴圈來探索此內容,而不是固定的管線。因此,代理程式可以繼續搜尋,直到對找到的內容滿意為止。代理程式還可以選擇何時檢查引用和證據以尋找或驗證細節。一項微小的偏好事項可以直接從單一 Brain page 採用,而一項重大的決定或來源之間的衝突則可能證明追蹤引用和閱讀原始記錄是合理的。基於圖形的結構讓代理程式能夠在具體下一步之間進行選擇,而不是漫無目的地搜尋相關資訊。
檔案具體化
為了讓代理程式探索能夠運作,代理程式需要透過沙箱檔案系統存取整個 memory/ 樹狀結構。每次啟動沙箱時在本地複製整個樹狀結構既昂貴又沒有必要,因為代理程式不會觸碰絕大多數的這些檔案。另一種選擇是使用遠端檔案系統,以便代理程式可以存取任何檔案而無需在本地複製它們。然而,代理程式經常在單一命令中執行數千次檔案系統操作;如果每一次都變成網路請求,往返成本就會開始主導探索迴圈。在內部測試中,透過遠端 FUSE 支援路徑執行的簡單 grep 工作負載比透過本地檔案執行的對應操作慢了大約 400 到 500 倍。
相反地,我們建構了具體化檔案的本地工作集,而較大的語料庫則位於記憶體檢索系統後面。Computer 在開機時將初始對應圖(取自最近的記憶體、工作階段、摘要和可用知識)預載到沙箱上。Computer 代理程式可以存取記憶體代理程式,這是一個可以執行語意搜尋並載入新檔案集的子代理程式。當缺少所需的內容時,Computer 可以使用對所需資訊的描述來呼叫記憶體代理程式。記憶體代理程式跨檔案搜尋,傳回即時文字綜合,並將支援記錄具體化為記憶體樹狀結構下的檔案。透過這種方式,工作集隨著時間自然且逐漸地擴展,為已經存在的證據保留了穩定的路徑和來源關係。
這個設計乾淨俐落地解決了延遲瓶頸。在本地儲存相關檔案可確保探索所需的檔案系統操作保持高速,而批次檢索允許具體化檔案池增長,而無需為每個檔案發出單獨的呼叫或載入大量不相關的檔案。巢狀代理程式設計也為 Computer 帶來了代理程式檢索的好處,而不需要主代理程式每次都直接搜尋完整的後端語料庫,從而保留其自身的內容視窗以容納最高價值的資訊。
維護 Brain
使用者不斷從他們所做的工件和進行的對話中學習,因此代理程式記憶體也需要如此。為了讓 Brain 保持有用,它應該是最重要知識的簡潔表示法。應該為重要的全新實體建立新頁面,應該將新資訊新增至相關的 Brain 頁面,並且應該適時移除過時的內容。例如,如果使用者的工作發生了變化,Brain 應該反映該變化;它應該包含使用者的少數新工作,並優先考慮與其新職責和專案相關的資訊。
Brain 由我們稱為 Dream 的背景代理程式維護。Dream 代理程式在基於檔案的記憶體上離線執行,將新資訊綜合到 Brain 更新中。我們仔細定義了 Dream 代理程式的範圍和行為,以有效地執行此任務,以及 Dream 特定的護欄,以確保 Brain 更新一致且準確。
Dream:用於記憶體精簡的背景代理程式
Dream 代理程式在沙箱中執行,可以存取互動式 Computer 工作階段將擁有的相同檔案系統和唯讀工具,但它們唯一的目標是改善未來工作階段的內容。每次執行都從早期執行所產生的 Brain 開始,而不是從頭重建使用者的內容。然後它使用該當前的 Brain 來定位自己,並為未來的執行產生一個更新的 Brain 來使用。
Dream 代理程式接收環境並決定如何探索它,而不是接收扁平化為單一提示的固定輸入。它可以導覽基於檔案的記憶體、使用核准的唯讀連接器工具來驗證知識片段,並將工作的有限部分委派給子代理程式(包括記憶體代理程式)。Dream 程式的範圍和職責指定為 Skill。
大體而言,Dream 執行包含 4 個階段:
- 定位:代理程式完成有序的定位程序。它識別權威範圍、固定指令、刪除日誌、額外輸入和停止條件。
- 摘要工作階段:對於自上次更新以來為新(或有新輪次)的每個工作階段,代理程式會寫入(或更新)該工作階段的簡短摘要。
- 將事實附加到主體:代理程式將它認為重要的每個觀察結果新增到其適當的歸宿中,通常是維基頁面。它在可用時探查並查詢經過身份驗證的連接器。
- 更新知識維基:代理程式根據其發現更新維基。它可以為持久的主題產生新頁面、當目前的綜合改變時修訂頁面,或者新增支援事實宣告的新連結或引用。當目前的圖形已經正確時,它也可以選擇不進行任何變更。
為了確保對 Brain 的任何更新都是完整且一致的,代理程式將提出的狀態寫入暫存輸出樹狀結構中。在代理程式做出它認為必要的所有更新之前,不會進行任何永久變更。在一個代理程式進程中協調這些決定,使得將圖形作為一個整體進行更新成為可能,而不是作為不相關的頁面進行更新。
任何變更都必須透過兩種類型的驗證檢查。確定性驗證檢查確保頁面格式良好且符合客觀標準,例如必要的 frontmatter 和引用格式。語意驗證檢查確保提出的綜合受到收集到的證據的支援,並且與圖形的其餘部分保持一致。在代理程式成功完成後,受控同步步驟會將暫存輸出與先前狀態進行比較,並將變更套用到儲存機制。當同步步驟完成時,最終的一組編輯可以透過 Git 版本歷史記錄進行檢查。
驗證 Brain
有用的記憶系統必須保留相關證據,在需要時呈現它,並幫助代理程式將該證據轉換為正確的答案。因此,我們在多個層級評估 Brain:受控離線消融、持續配對重播以及隨機生產實驗。
離線評估
我們的主要離線評估使用包含 44 個綜合人物誌的 640 個問題的內部資料集。這些人物誌重現了工作階段韻律、輪次計數、主題組合和事實密度中源自生產的模式,同時不包含任何生產查詢文字以維護使用者隱私。每個帳戶都是透過生產記憶體管線填入的,包括記憶體提取、對話摘要以及 Dream 對知識維基的編譯。對於每個問題,正確答案都機械性地與帳戶歷史記錄中存在的特定證據綁定。
例如,對於先前介紹的無障礙研究人員綜合人物誌 Nadia,資料集包含以下問題:「我在京都和仙台會見哪些組織?」答案(京都的 Sora City Lab 和仙台的 Sapphir Mobility Coop)直接出現在對應的維基頁面上。
我們將啟用與停用編譯知識維基時的相同問題和帳戶進行比較。其他記憶體表面在兩種情況下均保持可用。這隔離了 Brain 的增量貢獻,而不是將記憶體與無記憶體進行比較。總體而言,Brain 將答案正確性從 0.600 提高到 0.661(增幅 6.1 個百分點),證據召回率從 0.573 提高到 0.625(增幅 5.2 個百分點)。對於關於偏好(+10.2 個百分點)、時間推理(+8.6 個百分點)以及從先前活動中提取細節(+6.9 個百分點)的問題,其影響最大。在 84% 的問題中,代理程式可驗證地觸碰了繫結至黃金證據的來源。
我們也在兩個公共基準的部分子集上執行了匹配的 Brain 消融。在 LoCoMo 上,移除維基使答案正確性平均降低了 4.6 個百分點(跨越使用不同模型的三次執行)。在 LongMemEval-S 上,它沒有產生統計上顯著的變化。此結果與 Brain 的預期角色一致。LongMemEval-S 主要測試從個別工作階段中恢復事實,其中底層抄本為答案提供了重複的路徑。LoCoMo 更強調分散在對話、說話者和日期中的證據,為維基的跨工作階段綜合貢獻創造了更多機會。
總體而言,在啟用了 Brain 的情況下,生產代理程式在 LongMemEval-S 上達到了 0.91 的答案正確性,在 LoCoMo 上達到了 0.83。由於這些實驗使用了基準子集,因此它們不是決定性的基準結果。然而,消融仍然提供了強烈的信號,表明維基確實提高了效能,特別是當必須跨對話整合證據時。由於 Brain 是 Computer 的一部分,而不是一個最佳化的、特定於基準的檢索系統,我們相信其競爭力只會隨著更類似於生產工作流程的任務而增加。
線上評估
離線資料集無法捕捉真實使用者歷史記錄的每個特徵,因此我們也會針對新鮮的源自生產的同類群組執行每日配對評估。針對啟用和停用 Brain 的匹配使用者狀態回答相同的固定問題,然後對正確性、時效性和召回率進行評審。
6 月 18 日報告的初步結果表明,Brain 將答案正確性提高了 25%,召回率提高了 16%。這些效能提升持續保持;在過去 30 天裡,啟用了 Brain 的工作階段在每次執行和每個評審維度上都表現優於對照組。在絕對值方面,Computer 使用者享有的改進包括:正確性提升 9.3 點、時效性提升 8.0 點,以及召回率提升 8.9 點。啟用了 Brain 的軌跡也大約少使用了 15% 的權杖、成本降低 10%,且生成速度加快 10%。
持續改進
我們持續精簡 Brain,為使用者帶來最佳的記憶體驗。最近的一項變更將 Brain 的精簡索引直接放在代理程式的初始內容中,而不是要求代理程式稍後發現並讀取它。在隨機實驗中,這種預填處理增加了 Brain 的使用率,並將與記憶體相關的不滿減少了 6.9%。
離線評估工具同時也是自主改進管線的一部分。對 Brain 的記憶體子代理程式、檢索技能和提示提出的變更會透過我們內部資料集和公共基準上的匹配消融來執行。Computer 代理程式可以自主迭代結果,將每次迭代的變更、增量和成本保留為持久記錄,並且只保留推動數字變動的變更。結果是一個系統,其中的 Brain 評估器同時也是其最佳化器,推動未來的改進。
結論
持續學習是建立在數週和數月內運作的代理程式系統的決定性挑戰之一。我們認為,最好將記憶體架構公開為代理程式可以使用其普通工具集直接探索的環境。將記憶體公開為檔案系統,並以 Brain 作為頂層的結構化知識維基,可透過簡單且熟悉的工具使內容易於導覽。
Brain 旨在實現自我完善,以便隨著用法的增加,記憶系統可以不斷變得更好。Dream 背景代理程式將新資訊蒸餾到 Brain 更新中,確保前景代理程式始終以組織化的最新內容檢視畫面啟動新的工作階段。評估工具同時也是核心記憶體架構和代理程式導向介面上自動研究迴圈的測試場。
Brain 已經帶來了更準確且高效能的代理程式工作階段,同時減少了花費的權杖。我們對 Brain 與 Computer 生產堆疊的精心共同設計,確保了這些收益直接轉化為使用者的真實利益。
我們將繼續建立更多功能,以提高 Computer 記憶體的品質。同時,對於啟用了 Brain 的使用者,記憶體將隨著每個工作階段而改善。
引文
@online{perplexity2026BrainAgenticMemoryAsAKnowledgeWiki,
author = {{Perplexity} and Nicholas Bien and Se Won Jang and Haomiao Li and Kate Jung and Ishbir Singh and Kartik Kapur and Kevin Lau and Peter Hart and Sidhant Rajadnya and Yan Shu and Phi Hoang and Claire Beamer and Jeremy Yang},
title = {{Brain: Agentic memory as a knowledge wiki}},
date = {2026-08-19},
url = {https://perplexity.coolkeypoint.com/hub/blog/brain-agentic-memory-as-a-knowledge-wiki}
}