向量數據庫的語意搜尋在實際使用中有哪些常見的失敗案例？如何判斷搜尋結果的可靠性？
向量語意搜尋的工作原理是「找語意最相似的記憶」，這個機制在大多數情況下很有效，但有幾個已知的失敗模式：
第一，語意相似但內容不相關（False Positive）：你問的是「Compound 的 USDC 利率」，搜索結果拉出了「Compound 的安全事件」——兩者在語意空間上都和 Compound 相關，但一個是利率數據，一個是安全事件。解法：在記憶的元數據裡加入清楚的「記憶類型」標籤，查詢時同時過濾記憶類型（「只搜 type=rate_data 的記憶」）。
第二，語意漂移（Semantic Drift）：不同時期存入的記憶，用的 Embedding 模型可能有差異，導致同樣的語意在不同時期的記憶裡有不同的向量表示，搜尋時找不到相關記憶。解法：定期對整個向量數據庫做 Re-embedding（用當前的 Embedding 模型重新向量化所有記憶），保持一致性。
第三，近因偏差（Recency Bias）：如果你不加任何時間加權，向量搜尋不會自動偏向最近的記憶——它找的是語意最相似的，可能拉出 6 個月前的記憶。解法：在 similarity score 上乘以時間衰減係數，最近的記憶得分更高。
判斷搜尋結果可靠性的方法：每次向量搜尋都應該輸出相似度分數（通常 0-1），設定一個「可信閾值」（例如 0.75），低於閾值的結果不進入 Agent 的 context，而是標記為「未找到可靠相關記憶，需要用戶補充」。不要讓 Agent 基於相似度只有 0.4 的模糊記憶做出重要判斷。
記憶系統在多 Agent 架構裡怎麼共享？Orchestrator 和 Sub-agents 應該共用同一個記憶庫嗎？
記憶共享設計是多 Agent 系統裡一個需要謹慎決策的問題，沒有一個對所有場景都最好的答案。
完全共享記憶庫（一個向量數據庫，所有 Agent 都讀寫）：優點是信息不重複，一個 Sub-agent 學到的東西所有 Agent 都能用到。缺點是一個 Sub-agent 存入的記憶可能被 Orchestrator 誤讀（Sub-agent 的「分析草稿」被當成「最終結論」），安全邊界難以維持（一個被 Prompt Injection 的 Sub-agent 可以污染整個共享記憶庫）。
分層記憶庫（推薦方案）：每個 Agent 有自己的私有記憶（只有它自己能寫，其他 Agent 不能直接讀）；共享記憶庫只存「已通過 Orchestrator 確認的、可公開給所有 Agent 的結論」，不存中間的推理過程。Orchestrator 從 Sub-agent 的私有記憶摘要中提取關鍵結論，審查後寫入共享記憶庫，形成受控的知識傳播。
分層記憶庫的實作：用不同的向量數據庫命名空間（namespace）或不同的 collection 名稱區分私有和共享記憶；Sub-agent 寫入自己的 namespace，讀取自己的 namespace + 共享 namespace；Orchestrator 有權讀取所有 namespace，但只向共享 namespace 寫入已審查的結論。
對加密 Agent 特別重要：安全相關的記憶（用戶的最大支出設定、白名單地址）應該完全隔離——不存在任何 Sub-agent 可以讀寫的 namespace，只存在 Orchestrator 自己的最高信任 namespace，且只接受用戶直接更新。
記憶衰減（Memory Decay）怎麼設計？什麼樣的記憶應該衰減，什麼不應該？
記憶衰減是防止 Agent 被「過時的記憶誤導」的關鍵設計，但設計不當也可能讓 Agent 忘掉仍然有效的重要信息。
應該設計衰減的記憶：市場狀態類記憶（「當前 ETH 趨勢偏多」——這個判斷在幾天後可能完全改變）；特定時點的分析結論（「Aave 本週 USDC 利率的分析」——一週後這個分析可能已經過時）；基於特定市場條件的策略建議（依賴當時的宏觀環境，環境變了策略也需要更新）。建議的衰減機制：為這類記憶設定「有效期」（例如市場分析 7 天、策略建議 30 天），過期後自動降低重要性分數，不直接刪除（保留歷史參考），但不再主動拉入 context。
不應該衰減的記憶：用戶的核心設定（風險偏好、支出上限——這些是用戶的明確意願，不應該因為時間流逝而降低重要性，只有用戶主動更新才改變）；重要的操作歷史事實（「2026/06/10 發生了一次 $200 的 Gas 費超支事件，原因是網路擁塞」——這是已發生的事實，不管多久後都有審計價值）；學到的教訓（「在 Gas 費超過 $50 時執行移倉會損失超過預期，應該等待費用下降」——這是從過去操作提取的規律，長期有效）。
實作建議：在記憶存入時就給每條記憶設定 decay_type（time-sensitive / permanent / fact），衰減機制只對 time-sensitive 類型的記憶生效。
Agent 的記憶系統和 RAG（檢索增強生成）有什麼不同？它們可以結合使用嗎？
這是一個很好的問題，因為兩者都用向量搜尋，容易混淆。
RAG（檢索增強生成）：RAG 是讓 LLM 在回答問題前，先從一個外部知識庫裡搜尋相關信息，把搜到的內容加入 context，再讓 LLM 基於這些信息回答。知識庫裡存的是靜態的、預先整理好的知識文件（DeFi 協議文件、白皮書、市場研究報告）。知識庫不會隨著 Agent 的使用而自動更新——它是你事先整理好放進去的文件。
Agent 記憶系統：記憶系統存的是 Agent 在使用過程中產生的動態記憶——用戶告訴 Agent 的偏好、Agent 做過的操作和結果、學到的教訓。記憶庫會隨著 Agent 的使用持續增長和更新。
兩者的本質差別：RAG 是靜態外部知識庫（你主動放進去的文件）；記憶系統是動態個人化記憶（Agent 使用過程中自動積累的）。
可以結合使用，而且應該：一個完整的加密 Agent 應該同時有 RAG（協議文件庫、市場知識庫）和記憶系統（個人化偏好、操作歷史）。搜尋時分兩個來源：從 RAG 知識庫搜「這個 DeFi 協議的清算機制是什麼」（靜態知識）；從記憶系統搜「我之前在類似市況下做了什麼操作」（個人化歷史）。LangChain 在實作上對兩者有不同的工具（RAG 用 VectorStoreRetriever、記憶系統用 Memory 類），但底層都可以用同一個向量數據庫，用不同的 collection 分開管理。
「你上次說你在研究 Aave 的利率策略，這週有進展嗎？」——讓 AI Agent 說出這句話，需要的不是更聰明的 LLM，而是正確設計的記憶系統。記憶系統是讓 Agent 從「每次對話都從零開始的工具」進化成「有延續性的協作夥伴」的核心基礎設施。
在加密場景，記憶系統的重要性還有一個額外維度：Agent 的操作歷史是它能做出更好判斷的基礎——記得上次在這個市況下做了什麼操作、結果如何，才能改進下一次的策略。但記憶系統也引入了新的風險——如果記憶被污染（攻擊者讓 Agent 記住錯誤的信念），Agent 的長期判斷可能系統性地偏向攻擊者期望的方向。
LLM 本身沒有跨對話的記憶——每次呼叫 LLM 都是一次全新的推理，它只知道這次 API 呼叫傳入的 context，不知道上次對話說了什麼。這對「一次性任務」沒問題，但對「需要持續運作的 Agent」來說是根本性的限制。
沒有記憶系統的 Agent 面臨三個問題：第一，它無法從過去的操作中學習（每次都重複相同的分析流程，不會因為「上次這個市況操作虧了」而調整策略）。第二，它無法維持跨會話的一致性（用戶上次告訴 Agent「我的風險偏好是保守型」，下次 Agent 已經忘了）。第三，在多輪任務裡，它需要每次都重新輸入所有背景信息（操作歷史、策略參數、用戶偏好），讓 context window 很快被佔滿。
記憶系統解決這三個問題，讓 Agent 有「過去」可以參考。
短期記憶是當前對話的 context——所有在這次 API 呼叫裡傳給 LLM 的文字（System Prompt、對話歷史、工具回傳結果）。它的容量有上限（模型的 context window 大小），超過上限的部分就被截掉。
短期記憶的設計有幾個常見策略。滑動視窗（Sliding Window）：只保留最近 N 輪對話在 context 裡，超過 N 的歷史被丟棄。實作簡單，但丟棄的歷史就真的丟了，如果之前說的重要資訊被截掉，Agent 不知道它曾經發生過。摘要壓縮（Summary Compression）：在對話歷史快滿之前，讓 LLM 把前面的對話壓縮成一個摘要，把摘要放在 context 最前面，繼續新的對話。摘要比完整歷史佔的 token 少很多，但細節會損失。重要性過濾：不是等比例截斷歷史，而是標記重要訊息（例如用戶的風險偏好設定、已確認的策略參數）永遠保留，只截掉低重要性的中間過程對話。
在加密 Agent 的短期記憶設計裡，有一個特別需要注意的點：Agent 在一次任務執行過程中讀取的工具回傳數據（價格、利率、鏈上狀態）應該被標記為「這次執行的即時數據」，不應該作為長期記憶存儲——否則 Agent 下次執行時可能用舊的數據做判斷。
長期記憶是跨越多次對話保存的記憶，通常存在向量數據庫（Pinecone、PGVector、Weaviate）裡。它的工作原理：每段需要長期保存的記憶（一次對話的摘要、用戶的設定參數、一次操作的結果）被轉換成嵌入向量（Embedding），存入向量數據庫。當 Agent 需要查詢相關記憶時，把當前的 query 也轉成向量，在數據庫裡做語意近似度搜尋，找到最相關的歷史記憶，拉入當前 context。
長期記憶的設計需要決定幾個關鍵問題。存什麼：不是所有東西都值得存入長期記憶。推薦存的：用戶的策略偏好和風險設定（「你傾向保守的倉位管理，單次操作不超過總倉位的 10%」）、重要的操作決策和結果摘要（「2026/06/15 執行了 USDC→Aave 的移倉，Gas 費 $4.8，當時 APY 7.2%，執行後持倉 6 天 APY 維持在 6.8%-7.5% 之間」）。不建議存的：即時的市場數據（已過時）、中間的推理過程。
怎麼組織：向量數據庫的記憶應該有元數據標籤（時間戳、記憶類型、重要性分數），讓搜尋時可以過濾（「只搜最近 30 天的操作記錄」「只搜策略設定類的記憶」）。
記憶的衰減和清理：不是所有記憶都永遠有效。過時的市場判斷（6 個月前的 ETH 看法）應該被降低重要性分數或刪除，避免 Agent 被舊的、可能已經不正確的記憶誤導。設計一個定期的記憶清理任務，降低或刪除超過一定時間且沒有被引用過的記憶。
記憶污染是一個在加密 Agent 安全設計裡常被忽略的攻擊面。如果攻擊者能讓 Agent「記住」一個錯誤的信念，Agent 的長期判斷就會被系統性地誤導。
記憶污染的場景：攻擊者透過 Prompt Injection 讓 Agent 在長期記憶裡存儲一個錯誤的「用戶設定」（例如「用戶的策略是激進型，允許單次操作使用 90% 倉位」）。下次 Agent 執行任務時，它從長期記憶裡搜到這個設定，認為這是用戶的真實偏好，執行了遠超實際風險偏好的操作。
防禦設計：設計記憶的信任等級——用戶直接輸入的設定（最高信任）和 Agent 從對話/工具結果推斷的設定（較低信任）分開存儲，關鍵的安全設定（最大單次操作金額）只允許從「最高信任來源」更新，不允許 Agent 自己修改。定期讓用戶確認重要的記憶內容（「你的當前策略設定是保守型，確認嗎？」），給用戶機會發現記憶被污染。對「超出正常範圍的記憶更新請求」觸發警報（Agent 突然想存儲一個「允許 100% 倉位操作」的新偏好，這不正常）。
幾個加密 Agent 記憶系統的實際設計建議。第一，操作日誌和策略記憶分開存：操作日誌（什麼時候執行了什麼，結果如何）用時序數據庫（如 TimescaleDB 或 PostgreSQL with time-series extension），策略記憶（用戶偏好、學到的模式）用向量數據庫。兩者的查詢模式不同，混在一起查詢效率低。
第二，記憶的版本控制：每次重要記憶被更新，保留上一個版本（不直接覆蓋）。這讓你在發現記憶被污染後可以回滾到攻擊前的狀態。
第三，記憶系統的可解釋性：在 Agent 使用某條記憶做決策時，讓它在 Thought 步驟裡明確說明「我使用了記憶 ID #xxx，內容是 [...]，基於這條記憶，我的判斷是……」。這讓你在審計 Agent 的決策時，能追蹤每個決策的記憶來源。
第四，記憶的備份和恢復：向量數據庫的內容需要定期備份。如果向量數據庫出現故障或數據損壞，Agent 會失去所有長期記憶，退化成「每次都從零開始」的狀態——在有資金操作的場景，這可能導致 Agent 做出不符合你的策略設定的操作。
記憶系統的設計質量直接影響加密 Agent 的兩個核心能力：長期策略一致性（Agent 是否始終按照你設定的風險偏好和策略框架操作），以及學習能力（Agent 是否能從過去的操作結果中積累有用的經驗，而不是每次都重新發現同樣的規律）。沒有記憶系統的 Agent 只能做簡單的即時任務；有設計不良記憶系統的 Agent 可能因為記憶污染做出你完全預料不到的操作；有設計良好記憶系統的 Agent 才能成為真正可以長期信任的自動化夥伴。記憶系統的設計複雜度通常被低估——許多人在部署 Agent 時才發現記憶管理是比 Tool Use 設計更難的工程問題。