--- schemaVersion: 1 slug: gp-199-20260513-manthanguptaa-memory-in-voice-agents-is-a-harder-problem-than-you-think ticketId: GP-199 lang: zh-tw title: 語音 Agent 的記憶，比想像中更難 summary: 語音 Agent 不能把文字 Agent 的記憶架構直接搬過來用。Manthan Gupta 拆解語音記憶的核心難題：延遲預算太小、語音轉錄太髒、通話身份常常冷啟動，真正可行的做法是把昂貴的記憶工作移出回應路徑。 originalDate: 2026-05-12 translatedDate: 2026-05-13 source: "@manthanguptaa on X" sourceUrl: https://x.com/manthanguptaa/status/2054184627854877176 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-199-20260513-manthanguptaa-memory-in-voice-agents-is-a-harder-problem-than-you-think status: published replacementTicketId: null replacementUrl: null --- # 語音 Agent 的記憶，比想像中更難 > **來源:** [@manthanguptaa on X](https://x.com/manthanguptaa/status/2054184627854877176) 語音 [Agent](https://gu-log.vercel.app/glossary#agent) 的記憶系統，最可怕的地方不是「記不住」。最可怕的是它為了記住，慢了幾百毫秒。 幾百毫秒放在文字聊天裡，像電梯門慢半拍，煩但可以忍。放在電話裡，整個氣氛直接變成「喂？還在嗎？」把記憶層第一次接進語音 Agent 時，最容易踩到的坑就是照搬文字 Agent 的架構：同步查向量資料庫、做一小段重排，再丟給 LLM。聊天介面沒人會發現；語音介面每一輪都像對方在緩衝。這個坑特別刺眼，因為它不是「不懂記憶」才會犯的錯；就算研究過 ChatGPT 與 Claude 的記憶行為，做過分層記憶框架，也做過使用者自有記憶層，語音那條 800 毫秒的時鐘還是會把文字世界的習慣全部打回重練。 「語音 Agent 也需要記憶」當然正確，但真正殘酷的是下一句：**語音記憶不是文字記憶加速版。它的時鐘緊到整條讀寫路徑都要倒過來設計。** > **Mogu 內心戲：** > > 文字聊天像寄信，晚一秒還能說是系統在思考。語音聊天像兩個人面對面講話，停頓 800 毫秒就開始尷尬。記憶系統在文字介面是圖書館員，在語音介面比較像便利商店店員：客人話剛講完，資料最好已經在手邊，不能說「等一下，我去地下室查檔案」。 ## 語音沒有等待的奢侈 文字 Agent 天生有緩衝。使用者打完字、看到載入圖示，等個一到三秒還算合理。這段空白可以塞很多工作：向量檢索、語意搜尋、摘要、重排、從過去對話挖相關片段。使用者早就被訓練成「打完字要等一下」。 語音沒有這個禮物。 語音 Agent 從使用者停止說話，到第一段音訊回來，通常希望落在 **500 到 800 毫秒**。這段時間還不是留給記憶系統爽爽用，而是 VAD、STT、記憶檢索、LLM 第一個 [Token](https://gu-log.vercel.app/glossary#token)、TTS 第一段音訊，最後連音訊送到使用者耳邊的時間都要一起分： 先不要被縮寫嚇到。這裡其實只是在拆一通電話裡的「接球動作」：先判斷使用者講完了，再把聲音變文字，再找必要記憶，再讓模型開口，最後把文字變回聲音。每一段都很短，短到像在切一塊 800 毫秒的蛋糕，刀歪一點就沒了。 - VAD 判斷使用者講完，大約 100 毫秒。 - 串流 STT 送出最終文字稿，大約再 50 毫秒。 - 記憶檢索插在中間，理想上只能吃 50 到 100 毫秒。 - LLM 開始吐第一個 Token，大約 300 毫秒。 - TTS 合成第一段音訊，大約 100 毫秒。 - 音訊傳送也算在同一包延遲預算裡，不能假裝免費。 也就是說，記憶系統如果一上來就打一趟雲端向量資料庫，光網路來回就可能 20 到 80 毫秒。再加上向量化、近似最近鄰搜尋、重排、格式化，LLM 還沒看到 [Prompt](https://gu-log.vercel.app/glossary#prompt)，記憶預算已經爆炸。Mem0 自家文件把語意搜尋描述成會依向量庫與基礎設施落在約 50 到 200 毫秒；另外兩個語音記憶整合案例則主打 P95 檢索低於 250 毫秒，單獨檢索的 P95 也可能低於 200 毫秒。這些數字對聊天產品很漂亮，對語音產品就是站在懸崖邊自拍。 換成白話：文字聊天可以慢慢去倉庫翻資料；語音電話只能伸手拿桌上的資料。任何需要「送出去、算一下、排一下、再送回來」的記憶動作，都不是不能做，而是最好別卡在使用者等回話的那一秒。 更不用說當輪摘要。LLM 摘要如果插在當輪回應前，可能吃掉 300 到 800 毫秒。這不是超時一點點，是整個語音回應預算被一口吞掉。 真正穩的路徑反而很無聊：本機快取或 Redis 做鍵值查詢，1 到 5 毫秒，預測性高，幾乎無感。 > **Mogu 內心戲：** > > 向量資料庫在語音回應路徑裡常常像拿攻城器械處理桌上的小麻煩。器械很帥，問題也確實會消失，但校準、裝載、後座力一起來，整通電話的節奏也被轟爛了。(╯°□°)╯ 語音 Agent 第一原則：會讓人聽到沉默的聰明，通常不如快速的笨。 --- ## 語音輸入本身就比較髒 延遲只是第一刀。第二刀是輸入格式。 文字 Agent 拿到的是使用者整理過的句子。語音 Agent 拿到的是人類即興說話的殘酷現場：嗯、呃、講到一半重來、代名詞沒有指涉對象、前一句否定後一句修正。原本在聊天介面跑得很漂亮的事實抽取，搬到語音稿上可能開始亂記。 第三刀是每輪資訊密度。語音對話每一輪通常短、快、資訊密度低，大約 10 到 30 個英文詞。一通 10 分鐘電話很容易有 40 到 60 輪，文字稿大約 1500 到 2000 個 Token。聽起來不多，直到模型直接吃音訊。 OpenAI 即時語音 API 範例文件的說法很直白：同一句話，用音訊表示時，實務上常常會比文字多出約 10 倍 Token；同份文件也寫到 `gpt-realtime` 支援 32k Token 視窗。32k 看起來很大，但語音 Token 膨脹後，一通普通客服電話就可能把系統推到不舒服的位置。 第四刀最常被忽略：冷啟動。 聊天產品通常一開始就知道使用者是誰，因為有登入狀態。電話不一定。很多語音系統起手只有一組電話號碼，還要在前幾百毫秒內判斷來電者身份。任何預設「第一輪就知道使用者是誰」的記憶架構，在電話世界都很脆。比較健壯的設計會把未知來電者當成主路徑，而不是邊角案例。 --- ## 三種真正重要的記憶 語音 Agent 的記憶可以拆成三層。這個切法很實用，因為每層的延遲要求、儲存方式、失敗代價都不同。它也對得上更廣的 Agent 記憶文獻：有些研究把演進講成儲存、反思、經驗；有些產品文件則切成核心記憶、回想記憶、封存記憶。名稱不同，但核心問題一樣：哪一些資訊要立刻在手上，哪一些可以慢慢查，哪一些應該變成長期經驗。 **第一層是通話記憶。** 這是目前通話中的逐字稿、輪次順序、當前上下文，通常住在 LLM 的 [上下文視窗](https://gu-log.vercel.app/glossary#context-window) 裡。問題是長通話會比想像中更快撞到實務限制：實務上 4k 到 8k 的可用視窗可能很快就被塞滿，就算現代模型名義上支援 128k 以上 Token，也不代表可以把整段逐字稿硬塞進去。那會拖慢生成，注意力也會開始散掉。長上下文很像大冰箱，能塞很多東西，不代表每次找蛋都找得到。 **第二層是通話事實。** 這是當前通話中已經建立、後面還需要用到的工作記憶。例如來電者叫小雅、帳號是 4821、目前很生氣、正在處理某個未解決問題。這一層沒做好，Agent 五輪後又問一次名字，信任感會瞬間蒸發。電話裡的金魚記憶特別致命，因為使用者沒有聊天紀錄可回看，只會感覺「這客服是不是完全沒在聽」。 **第三層是使用者檔案。** 這是跨通話保存的長期資料：姓名、偏好、上次通話摘要、未結案件、關係脈絡。這一層做得好，回訪者會覺得被認得；做不好，每次都像重開遊戲新手村。 真正難的是中間兩層：如何在一通電話內抓住通話事實，又如何在多通電話之間讀寫使用者檔案，而且不能拖慢對話節奏。 > **Mogu 內心戲：** > > 記憶不是越多越好。語音 Agent 亂記一堆沒用細節，效果像客服打開十個試算表分頁，然後在使用者面前一格一格找。聰明的記憶系統不是倉庫，是秘書：只把未來真的會改變回應方式的東西留下來。 --- ## 四個問題決定整套架構 任何語音記憶架構最後都會回到四個問題。這一段最容易寫成架構報告，所以先把畫面拉回電話現場：每個問題其實都在問同一句話，**到底誰要為那 800 毫秒負責？** **什麼時候寫入？** 可以每一輪對話後抽取事實，也可以通話結束後一次批次整理。通話後整理比較便宜，也比較乾淨，因為模型看得到完整脈絡。但電話很常異常中斷：WebRTC 連線掛掉、使用者直接掛電話、通話結束抽取失敗。只靠通話後整理，可能整通電話什麼都沒留下。多數正式上線的語音部署最後會接受成本，採用逐輪寫入，因為「通話紀錄整包遺失」是非常難看的失敗模式。 **寫入什麼？** 過濾問題可以很簡單：這個事實會不會改變未來通話的回應方式？不會，就只是噪音。使用場景越專門，過濾越要兇。一般助理可以讓 LLM 抽取比較泛用的記憶；醫療收案 Agent 應該寫進型別明確的資料格式，不符合格式的內容直接拒絕。 **怎麼取回？** 結構化的使用者檔案用鍵值查詢就好。過去通話這種情節式記憶，才需要語意檢索、圖譜或其他比較重的路徑。但重點仍然是：不要在使用者等回應的那一刻才做昂貴檢索。 **工作在哪裡發生？** 放在回應路徑裡、跟語音流程平行跑，或通話後再處理。語音世界的答案通常是：寫入平行做，讀取先預載，只有最小必要內容留在阻塞路徑上。 實務上會看到很多名字，但不用急著背。先抓住一件事：每種架構都只是在替電話現場分工，決定哪些記憶要在桌上、哪些可以放倉庫、哪些乾脆等客人掛電話再整理。 --- ## 四種工具箱，不是四份考卷 接下來名字會變多，但這裡不是要讀者背架構考古。把它想成四個工具箱：第一箱管「這通電話現在講到哪」、第二箱管「把記憶交給外部服務」、第三箱管「把人與事整理成關係圖」、第四箱管「讓系統在電話之外慢慢反思」。名字只是品牌貼紙，真正要看的是每箱解哪個電話現場的痛。 第一種是 **框架內建狀態**。每個正經語音 Agent 框架都會在通話期間維持對話狀態，端到端語音 API 也會在自己那側保留通話上下文，通常還會內建截斷策略。這一層能處理「通話內」狀態，但通話結束就沒有了。它是地板，不是房子。 端到端語音模型把 STT、LLM、TTS 收進同一個有狀態的通話，可以直接解掉串接式管線本身的延遲問題，但不會自動解決長期記憶。OpenAI 的即時語音 API 有 32k Token 的通話限制；Google 的即時語音模型狀態也不是跨通話持久化的記憶系統。原本串接式管線外面需要接的讀寫架構，端到端模型外面還是要接。比較真實的好處是 [多模態模型](https://gu-log.vercel.app/glossary#multimodal) 能直接處理音訊，事實抽取不必完全依賴文字稿，這對語氣、停頓、情緒會影響回應的場景很重要。 第二種是 **外掛式記憶服務**。很多團隊起步會走這條路：把第三方記憶服務接進語音流程，設定使用者或實體 ID，讓它處理讀寫。先不用比較每個名字，核心形狀比較重要：它們通常在背景寫入，讀取則盡量預先載入。差異在底層用向量、圖、SQL，還有抽取事實時有多積極。電話現場只在乎一件事：這些服務不能每輪都讓使用者聽見等待。 第三種是 **知識圖譜記憶**。這一派最有意思，因為它改變的不只是查得快不快，而是「記憶」本身的形狀。傳統向量檢索像在一堆紙條裡找相似句；知識圖譜比較像把人、事件、偏好和時間寫成關係表。模型看到的不是三段鬆散對話，而是「阿明從 2024-01-15 起最喜歡某首老歌」這種結構化事實。 正式上線環境裡常見的是圖譜型記憶服務；學術上也有把每段記憶寫成類似 [Zettelkasten](https://gu-log.vercel.app/glossary#zettelkasten) 卡片的做法，新的記憶會更新舊記憶。翻成產品語言就是：系統不只記「阿明說過某件事」，還會在新資訊進來時改寫「阿明現在到底偏好什麼」。代價也很現實：圖譜更難除錯、更難淘汰舊資料、建置成本也比扁平向量索引高。但如果同一個使用者會跟語音 Agent 講好幾年電話，長期答案很可能在這裡。 第四種是 **認知式架構**。這一派不把記憶當資料庫，而是當認知過程。幾篇經典 Agent 記憶研究給出的形狀很像：先保留一條記憶流，再定期反思，最後用新近程度、重要性、相關性挑出值得帶回來的記憶。大家最愛抄的是反思，因為它讓 Agent 看起來不是鸚鵡複誦，而是真的逐漸理解一個人。 也有研究加入類似艾賓浩斯遺忘曲線，讓老舊且少用的記憶淡出；還有做法讓系統每輪決定要查記憶、先反思，還是直接回答。這些名字本身不是重點；可以偷的是三個習慣：定期反思、重要記憶加權、太久沒用的記憶慢慢降權。正式上線時，它們通常會接回前面那幾箱工具，而不是單獨變成一套魔法產品。 --- ## 真正可行的模式：把讀寫路徑倒過來 語音記憶在正式上線環境裡反覆出現的有效模式，是把所有工作分成兩類：回應前必須完成的讀取，以及回應後才做的寫入。 回應前只留最必要的讀取，而且最好在通話開始前就預載。 電話接起來、WebRTC 連線、音訊初始化、編解碼協商，這些連線準備期間其實有幾百毫秒可用。這段時間應該拿來抓使用者檔案、上次通話摘要、未結案件，放進通話本地快取。第一輪真正到來時，所謂「記憶檢索」只是查一個已經在手邊的表，不是打一趟遠端服務。 冷啟動是這個設計的考驗。如果來電者匿名，系統沒有使用者專屬檔案可預載。這時只能在前一兩輪內完成身份確認，例如帳號、電話號碼查 CRM，或接受第一通電話上下文比較薄，並讓 Prompt 優雅處理未知身份。最常見的錯誤，是把已驗證來電者當正常路徑，把匿名來電者當例外。電話系統裡，匿名常常是熱路徑。 寫入則反過來：每次 Agent 回答完，就丟一個不用等結果的背景任務，從最新一輪抽取新事實並持久化。通話結束時，用 2 到 3 秒逾時上限等正在跑的任務收尾，因為使用者已經掛了，這時沒有回應延遲要守。最後再對完整逐字稿做一次總結，存成權威紀錄：這通電話在講什麼、是否解決、關鍵事實、後續追蹤。 這份通話摘要會成為下次預載的 `last_interaction`。它是語音記憶系統裡最被低估的產物。ChatGPT 與 Claude 的文字記憶系統也可以讀成同一種精神：檢索時，一份整理過的摘要，通常比原始逐字稿更好用。 > **Mogu murmur：** > > 原始逐字稿像監視器錄影，什麼都有，但每次要找重點都痛苦。通話摘要像值班主管交接本：誰打來、氣在哪、事情卡哪、下次誰接手。語音 Agent 真正需要的是交接本，不是把整捲錄影帶塞進腦袋。 --- ## 兩個上線後才會咬人的問題 第一個問題是預載可能跟上一通電話的寫回賽跑。 假設使用者上一通電話說「之後請稱呼 Alex」。逐輪抽取抓到了，正在寫入。結果下一通電話太快進來，預載讀到的是幾秒前的舊快照，Agent 開口又叫舊名字。這種錯比完全沒有記憶更糟，因為它看起來像系統記得，但記錯版本。 修法聽起來很直覺：永遠優先服務最新寫回，即使快照比較舊。但這種失敗模式往往要有真實使用者才會浮出來。 第二個問題是成本。逐輪抽取等於每一輪多一次 LLM 呼叫。以 40 到 60 輪的 10 分鐘電話來算，如果每輪抽取都要花幾美分，光抽取就可能到幾美元。高價值客服電話可以接受，免費消費者助理大規模跑起來會哭。 比較誠實的做法是：事實抽取用便宜的蒸餾模型，像 7B 到 8B 通常就夠；或把抽取改成較長的滑動視窗；低毛利場景則偏向通話後抽取。技術架構不能脫離商業模型，不然就是把成本藏在 Prompt 裡，月底帳單再出來復仇。 --- ## 通話內歷史要壓縮，不要全塞 就算只看單通電話，也很快會撞到實務上的上下文限制。一般 10 分鐘通話文字稿大約 1500 到 2000 Token；原生語音通話又有音訊 Token 膨脹問題。名義上的大上下文視窗不等於可以無腦塞全部。 可行做法是 **滑動視窗加摘要**：最近 N 輪保留全文，更早的輪次壓成摘要。例如逐字稿到 20 輪時，非同步壓縮前 10 輪成 3 到 4 句。這種工作可以用小模型，像同機 GPU 上的蒸餾 1B 到 3B 模型，或 CPU 上微調過的摘要器。50 到 150 毫秒的壓縮延遲放在非同步流程可以接受，放在回應路徑就會變痛。 另一個槓桿是選擇性保留。不是每一輪都有價值。「好」「了解」「嗯嗯」這種低訊號回合幾乎沒有保存意義。簡單的長度與停用詞規則，或小分類器，就能丟掉很多噪音。逐字稿應該被整理，不是被當神主牌供起來。 --- ## 長期情節式記憶要慢一拍 結構化的使用者檔案，例如姓名、偏好、已知案件，用鍵值儲存是正解。無聊、快速、可預測，這種無聊很珍貴。 非結構化的情節式記憶就不同了。過去某通電話的細節、歷史互動、特定脈絡，遲早需要語意檢索。但問題不是要不要檢索，而是什麼時候檢索。答案仍然是：不要在使用者等回應時檢索。 可行模式是 **背景相關性準備**。系統維護目前對話主題的表示方式，實務上可能是最近一兩輪使用者話語合成一個查詢向量，再加上一個小分類器產生的主題標籤。每 3 到 5 輪，或主題向量明顯漂移時，非同步去過去對話裡查相關內容。找到的內容不是塞進當前回合，而是先暫存，下一輪再注入上下文。 這會讓情節式上下文慢一拍，但通常是對的取捨。使用者不太會注意 Agent 晚一輪提到過去對話；但每輪多停 200 毫秒，電話另一端一定會感覺到。 真正麻煩的是快速轉換主題。使用者每一輪都轉彎，暫存好的檢索結果就會一直過期。務實修法是用便宜方式偵測主題轉移，例如連續查詢向量的餘弦相似度大幅下降，就走「沒有情節式上下文」路徑。過期上下文比沒有上下文更糟，因為它會讓 Agent 很有自信地講昨天的事。 --- ## 睡眠時計算：把整理工作移到通話之外 逐輪寫入加通話結束摘要可以處理基本盤。更進階的做法，是在通話之間、系統閒置時做記憶整併。 這種做法可以稱為睡眠時計算：另外開一個背景 Agent，跟面向使用者的 Agent 共享記憶區塊，在背景整理、合併、重組記憶。相關論文頁面提到，在選定評測上，睡眠時計算可以用約 5 倍較少的 [測試時運算](https://gu-log.vercel.app/glossary#test-time-compute) 成本達到相同準確率，並在可預測查詢上帶來 13% 到 18% 準確率提升。這些是論文在特定任務上的數字，不應直接拿來保證語音產品成效。對電話系統來說，重點簡單很多：白天不要邊接客邊整理倉庫，晚上整理好，明天查起來就順。 同一條線索也出現在 [GP-191：Claude Dreams 怎麼整理 Agent 記憶垃圾山](https://gu-log.vercel.app/posts/gp-191-20260507-danizhu-claude-dreams-agent/)：文字 Agent 可以離線清理記憶；語音場景的限制更尖，因為白天多停 200 毫秒，使用者就會聽見那個尷尬。 語音情境的直覺很簡單：逐輪寫入會累積成一條事實流水帳。幾週、幾個月後，裡面一定會有重複、矛盾、過期資訊。例如「使用者偏好電子郵件」跟「使用者要求改成電話聯絡」同時存在。夜間整併可以合併重複、用較新的訊號解決矛盾、刪掉低重要度記憶，甚至整理出更高階的判斷，例如「這位使用者通常是在東西壞掉時才打來，不是來問一般問題」。 這對語音特別重要，因為這類整理絕對不能放在回應路徑。睡眠時計算是整個架構唯一幾乎沒有延遲預算壓力的地方。白天電話裡不該做的事，晚上慢慢做。 --- ## 乾淨訊號：逐字稿與多人說話 前面所有設計都有一個隱含前提：記憶管線拿到的輸入還算乾淨。現實通常不是。 第一個問題是逐字稿髒。使用者會停頓、重啟句子、說「那個上次講的東西」。原始逐字稿很容易讓事實抽取變吵。解法是一個輕量的逐字稿清理步驟：移除語助詞和口吃式重啟，正規化指涉，然後再送進記憶管線。這一步非同步跑，不碰回應流程。LLM 回應仍看原始逐字稿，因為清理會加延遲；記憶抽取才看清理後版本。 第二個問題更麻煩：房間裡常常不只一個人。 家裡打客服電話時，旁邊可能有配偶或小孩；醫療電話可能有照護者在場；小公司打進客服時，也可能有人從辦公室另一端補充資訊。說話者分離，也就是分辨誰說了什麼，會直接影響記憶準確度。沒有說話者分離，事實抽取器可能把「來電者配偶討厭現在方案」寫進來電者檔案。下次 Agent 自信地提起這件事，信任感當場裂開。 開源工具與較新的 LLM 輔助系統都在改善重疊語音，但即時分辨說話者的成本很真實，阻塞路徑每輪可能多 200 到 400 毫秒。因此，多數正式上線的語音 Agent 不會在即時路徑裡做這件事。 比較能落地的折衷是：通話中接受一定歸因噪音；通話後對錄音非同步跑說話者分離，再把事實歸到正確說話者後持久化。這種錯誤不一定常發生，但一旦發生會很傷，所以系統至少要有應對故事。 --- ## 三層正式上線架構 把整篇拼起來，語音記憶系統不是按資料類型分層，而是按延遲分層。 **第一層：熱快取，1 到 5 毫秒。** 通話開始時預載，內容包含使用者檔案、上次通話摘要、未結案件。它住在行程記憶體裡，服務每一輪幾乎即時查詢。 **第二層：背景檢索，50 到 150 毫秒，非同步。** 在回合之間做情節式搜尋，結果先暫存，下一輪再注入。它永遠不阻塞回應。 **第三層：非同步寫入，延遲不重要。** 事實抽取、使用者檔案更新、通話結束摘要、睡眠時計算的記憶整併都在這裡。每輪之後、通話之後、系統閒置時處理，餵回第一層給下一通電話使用。 核心不對稱非常清楚：**阻塞路徑上只剩快取查詢。** 向量化、檢索、摘要、寫回、整併這些昂貴工作，全都被推到回合之間、通話之後，或系統閒置時。 > **Mogu 想補充：** > > 這套架構的精神很像餐廳備料。客人點菜時才開始洗米、切菜、熬高湯，廚師再神也會被客訴。語音 Agent 的記憶也是一樣：該熬的湯在前一天晚上熬，現場只負責舀。 --- ## 研究座標，不要讀成書單 語音記憶不是單點經驗談，背後其實踩著一串 Agent 記憶研究。但這一串不該讀成書單。讀成書單就會開始數名詞；讀成四個老問題，才會回到電話裡那個 800 毫秒。 第一個問題：**長上下文真的能救一切嗎？** 經典的長上下文研究答案是不能。模型就算名義上吃得下很長輸入，也不保證能穩定抓到中間那段關鍵資訊。這解釋了為什麼語音 Agent 不能把整通電話逐字稿當成萬靈丹硬塞進去。 第二個問題：**記憶要怎麼像經驗，而不是像資料夾？** 認知式 Agent 研究給了一個經典答案：記憶流、定期反思，再用新近程度、重要性、相關性幫候選記憶打分。另一條研究線接上遺忘曲線，提醒系統不是只有記住，也要懂得讓舊記憶淡出。 第三個問題：**正式上線時要怎麼查、怎麼寫？** 有些系統代表可產品化的記憶層；有些研究把記憶寫成會互相更新的卡片網路；也有做法讓系統每一輪決定要查記憶、先反思，還是直接回答。這些名字各自很硬，但放在語音場景裡，核心都在問同一件事：哪個記憶值得現在拿，哪個記憶可以晚點整理。 第四個問題：**整理工作能不能移到通話之外？** 睡眠時計算說可以，另一份綜述則把整條演進整理成一句話：好的 Agent 記憶不是倉庫容量競賽，而是把原始紀錄慢慢變成可用經驗。 下一個自然問題是語音 Agent 評估，因為一般 LLM 評測與長記憶評測，通常抓不到語音實務部署裡最痛的東西：每輪多停 200 毫秒造成的遲疑感、錯把旁邊的人當成使用者、前一通電話寫入還沒完成就被下一通讀到。語音 Agent 的評估不能只問答對幾題，還要問「節奏有沒有像真人」。 --- ## 結語 語音 Agent 的記憶仍然沒有被完全解決。跨很多次對話、像人一樣自然回想的能力，還是很難。但工程基礎已經很清楚：快取、非同步抽取、結構化使用者檔案、通話後摘要、知識圖譜、睡眠時計算的記憶整併，都已經是今天可以做的東西。語音 Agent 框架加上外部記憶服務，也讓團隊不必從零手刻讀寫迴圈。 真正的手藝不在「把資料存起來」，而在判斷什麼值得記、什麼時候拿出來、怎麼講得像理解脈絡，而不是照著檔案唸。這件事靠的是 Prompt 設計、記憶篩選與嚴格整理，不是更大的向量資料庫。 最後那句可以直接刻在語音 Agent 架構圖旁邊： > In a voice agent, the speed of memory is set by what you have already prepared, not by what you can fetch in the moment. 在語音 Agent 裡，記憶的速度不是取決於當下能抓多快，而是取決於前面準備得多好。 電話那端的沉默，不會等架構師解釋。