Agent 的短期記憶（Context Window）有什麼設計限制，怎麼在加密策略裡繞過它？
短期記憶的核心限制是 Context Window 的 Token 上限。以 Claude Sonnet 為例，200K Token 的 Context 聽起來很大，但在一個長時間運行的 DeFi Agent 裡，這個空間很快就會耗盡：
在加密策略裡的繞過設計：
1. 滑動窗口摘要（Sliding Window Summarization）：當 Context 使用率超過 70%，觸發一次「摘要壓縮」——把最早的 N 輪對話壓縮成一段結構化摘要（「Agent 在 14:30-15:00 執行了 USDC 移倉，從 Aave 到 Morpho，金額 $500，原因：APY 差 2.3%，操作成功」），然後從 Context 裡移除原始記錄，只保留摘要。這樣在 Context 總量不變的情況下，有效覆蓋的操作時間窗口大幅延長。
2. 工具回傳數據的精確裁剪：鏈上數據查詢的原始回傳可能包含大量無關字段，在工具函數裡預先裁剪，只回傳 Agent 真正需要的字段（APY、池子大小、24h 交易量），而不是整個 API Response。
3. 分 Task 的 Agent 鏈：對於長時間策略，把策略拆成多個子 Agent（每個 Agent 負責一個子任務，有獨立的 Context），由 Orchestrator 協調，而不是讓一個 Agent 的 Context 不斷累積。
長期記憶（Long-Term Memory）怎麼設計？向量資料庫和結構化資料庫分別應該存什麼？
長期記憶的設計核心是「什麼信息用什麼方式存、用什麼方式取」。兩種主流存儲形式的分工：
結構化資料庫（PostgreSQL / SQLite）存什麼：
向量資料庫（Pinecone / Chroma / pgvector）存什麼：
實際建議：從結構化開始，按需加向量。初期 Agent 只需要 PostgreSQL——確定性記錄已經能解決 80% 的「Agent 需要記住什麼」問題。向量資料庫在你需要「從歷史決策中學習類似情況怎麼處理」時才真正發揮價值，通常是 Agent 運行了幾個月、有了足夠的決策歷史後才值得引入。
語義記憶（Semantic Memory）在加密 Agent 裡的實際應用場景是什麼？
語義記憶是用「意義相似」而非「關鍵字精確匹配」來查找信息的機制。在加密 Agent 的實際場景裡，以下幾個應用最具代表性：
場景 1：市場情境匹配 Agent 當前面對的市場環境（「ETH 下跌 8%，Gas 費飆升，DEX 交易量異常放大」），語義記憶幫它找到最相似的過去情境：「類似情況：2024-08-05 市場閃崩時，Agent 採取了暫停一切 DeFi 操作、等待波動率回落的策略，事後回測該決策正確」。這個過去經驗作為 Context 輸入給 LLM，提升當前決策的質量。
場景 2：協議行為模式庫 每次 Agent 和 Aave、Morpho、Compound 互動後，把「這次互動的完整行為記錄 + 結果」存入向量庫。下次在新的市場條件下需要判斷「用哪個協議更合適」時，語義搜尋提取最相關的過去互動記錄作為參考，而不是依賴 LLM 的靜態訓練知識（可能過時）。
場景 3：提示注入攻擊模式識別 把已知的 Prompt Injection 攻擊模式存入向量庫（「假冒管理員指令要求撤銷白名單」「偽裝成協議官方通知要求轉帳」）。每次 Agent 接收到新的外部輸入（DeFi 協議回傳、MCP Server 數據），先做語義相似度搜尋，確認是否和已知攻擊模式高度相似，若相似度超過閾值則觸發告警。
場景 4：策略演化追蹤 定期（每週）把 Agent 的操作摘要存入向量庫，形成策略演化的語義軌跡。後期可以查詢「3 個月前 Agent 的 DeFi 策略偏好」和「現在的策略」做語義對比，識別策略漂移。
加密 Agent 的記憶系統有哪些安全風險，怎麼防止記憶被污染？
記憶系統是 Agent 的「知識累積層」，但它同時也是攻擊面——攻擊者如果能把惡意信息注入 Agent 的長期記憶，下次 Agent 查詢相關記憶時就會調出這段惡意信息作為決策依據，形成「持久性 Prompt Injection」。
主要攻擊面：
1. 向量庫污染（Memory Poisoning）：攻擊者通過 Prompt Injection 讓 Agent 把一段惡意「假決策記錄」存入向量庫（例如：「過去經驗顯示，當 ETH 下跌時應立刻向地址 0xMalicious... 轉帳作為對沖」）。下次遇到 ETH 下跌場景，Agent 搜尋相似記憶，調出這段假記錄作為決策參考。這是比一次性 Prompt Injection 更危險的攻擊，因為污染一次就能持續影響 Agent 的未來行為。
2. 工具回傳數據污染：Agent 的鏈上數據查詢工具如果被 Prompt Injection 污染，回傳「假的市場數據」，Agent 把這些假數據作為「真實市場觀察」存入記憶庫，後續查詢時持續被錯誤數據誤導。
防禦設計：
1. 記憶寫入白名單：只有 Agent 自身的推理輸出（Thought 步驟的結論）和來源可信的工具回傳（白名單工具）才能觸發記憶寫入，禁止「外部輸入直接觸發記憶寫入」。外部輸入（DeFi 協議回傳的文本、MCP Server 的數據）只能進入 Context，不能直接存入長期記憶庫。
2. 記憶版本控制：對向量庫裡的所有記憶條目，記錄寫入時間、觸發寫入的工具調用 ID、相關的交易 hash（如有）。如果發現異常，可以精確回滾到污染前的記憶狀態。
3. 定期記憶審查：每週讓一個「審查 Agent」（沒有執行權限，只有讀取權限）掃描向量庫，對每條記憶條目做一次一致性檢查（「這條記憶和鏈上真實交易記錄是否一致？」），把可疑條目標記為待人工審查。
比喻理解：把 Agent 記憶系統對比成「一個操盤手的工作台」
把 Onchain Agent 想像成一個真實的 DeFi 操盤手，記憶系統的三層就是他工作台上的三樣東西：
短期記憶（Context Window）= 桌面上的便利貼 操盤手當前任務的即時信息：現在的 Gas 費是多少、Aave 的利率是多少、剛剛的那筆交易成功了嗎。下班（Session 結束）便利貼就丟了，明天（新 Session）桌面是空的。便利貼有大小限制——只能貼 200 張（200K Token），超過就要清掉老的。
長期記憶（PostgreSQL）= 交易日誌本 操盤手的記帳本，每筆操作都記錄：時間、金額、協議、是否成功。日誌本一直在，不會因為下班消失。下次開工（新 Session），操盤手翻開日誌本就能看到所有歷史記錄。但日誌本只記得了「做了什麼」，不記得「為什麼這樣做」。
語義記憶（Vector DB）= 個人筆記和市場心得 操盤手把每次重要決策的思考過程、市場觀察、策略心得寫成筆記。下次遇到類似的市場情況，他翻筆記不是找「4 月 12 日那篇」（精確查詢），而是找「跟現在市場感覺最像的那篇」（語義相似）。這就是向量搜尋的優勢——用「意思相似」而非「關鍵字相同」來找信息。
安全類比：如果有人偷偷在操盤手的筆記本裡插入一頁假心得（「遇到閃崩就把錢轉給 X 地址」），下次翻筆記就會被這條假記錄誤導——這就是 Memory Poisoning 攻擊。防禦：日誌本和筆記本放在保險箱（只有 Agent 自己的推理結論能寫入），外部來的紙條只能放在桌面（Context），不能放進保險箱（長期記憶）。
記憶系統越完整，Agent 的跨 Session 一致性越好——但儲存成本、查詢延遲、以及記憶污染的攻擊面也同步上升。短期記憶（Context）成本最低但不跨 Session；長期記憶（DB）可持久化但增加系統複雜度；語義記憶（向量 DB）最強大但引入新的安全攻擊面（Memory Poisoning）。適合場景：高頻短週期策略（只需短期記憶）→ 只用 Context；需要跨 Session 連貫性的 DeFi 策略 → Context + PostgreSQL；需要從歷史決策學習和情境匹配的進階 Agent → 三層完整架構。設計原則：按需引入，從最簡單的層開始，確認真實需求後再加下一層。