Skip to main content

AI 代理記憶力完全攻略：持久化上下文的模式與工具

· 閱讀時間約 9 分鐘
Felo AI
Felo AI
Operations

AI 代理擅長單次任務，但缺乏記憶力就無法處理持續性工作。本文介紹如何為程式碼審查、研究與專案管理代理實現持久化記憶。

AI 代理擅長單次任務。但在持續性工作上——程式碼審查、研究整合、專案管理——沒有記憶力就會崩潰。

問題不在能力。Claude Code 代理的程式碼審查能力不輸任何工具。問題在於每次執行都從零開始。它不記得上週審查了什麼、標記了哪些模式、團隊對那些模式做了什麼決定。

本指南介紹如何為代理賦予持久化記憶——以及讓記憶真正發揮作用的模式。

AI 代理記憶力——情節記憶、語意記憶與程序記憶模式實現持久化代理上下文

為什麼代理記憶不同於聊天機器人記憶​

聊天機器人的記憶問題是：「它忘了我在對話中說過的內容。」

代理的記憶問題是：「它忘了過去 50 次執行的所有內容。」

代理的設計目的是自主完成任務——通常按排程執行或由事件觸發。對於在同一領域重複執行的代理（每日程式碼審查、每週研究整合、專案狀態更新），無狀態意味著它們無法在自己的工作基礎上累積。

一個記不住上週已標記相同模式的程式碼審查代理，會再次標記。一次又一次。沒有記憶，它就不是程式碼審查代理——而是一個產生冗餘輸出的程式碼審查產生器。

代理真正需要的記憶類型：

  • 情節記憶 — 先前執行中發生了什麼事、做了什麼決定、觀察到什麼結果
  • 語意記憶 — 關於專案的領域知識：編碼標準、架構模式、團隊慣例
  • 程序記憶 — 在這個特定上下文中，哪些方法有效、哪些無效
  • 工作記憶 — 與當前執行相關的內容（每次從持久化儲存中重新載入）

常見代理類型的記憶模式​

程式碼審查代理​

需要記住的內容：

  • 編碼標準和團隊慣例
  • 過去的審查決定及其理由
  • 此程式碼庫中已知的反模式
  • 經常出問題的檔案或模式

回寫格式：

Add to workspace: [DATE] REVIEW PATTERN
File: src/middleware/auth.ts
Issue: Direct DB queries in route handlers
Decision: Flag as blocking — violates Repository Pattern convention
Reasoning: Established 2026-01-15, all DB access must go through /lib/repositories/

代理啟動時載入：

Load the [Project] workspace
I'm running the weekly code review. Load the coding standards and recent review decisions.

Claude 讀取工作區後，會根據團隊的實際慣例審查程式碼——而非可能與程式碼庫現有做法相矛盾的通用最佳實踐。

研究代理​

需要記住的內容：

  • 研究問題及其當前狀態
  • 已評估的資料來源及品質評估
  • 已得出的結論
  • 死路——這是最關鍵的
Add to workspace: [DATE] RESEARCH DEAD END
Topic: Distributed caching for the checkout flow
Approach tried: Redis with write-through cache
Result: Race conditions in webhook handler — idempotency keys weren't respected
Do not retry: This approach has a fundamental incompatibility with our webhook architecture

死路記錄是研究代理能做的最有價值的事。沒有它，每次新執行都會重新探索相同的失敗方法。

代理啟動時載入：

Load the [Project] workspace
I'm continuing research on [topic]. What have we already explored? What were the dead ends?

專案狀態代理​

需要記住的內容：

  • 專案目���和成功標準
  • 已做的決定及推理過程
  • 當前阻礙及其負責人
  • 利害關係人的偏好與限制

回寫格式：

Update workspace status: [DATE]
Sprint 8 status: checkout flow 80% complete, webhook handler done, retry logic pending
Blocker: waiting on Stripe's updated idempotency key documentation
Owner: Marcus following up with Stripe support
Next milestone: retry logic done by 2026-04-14

使用 MemClaw 實現代理記憶​

在 Claude Code 上安裝 MemClaw：

/plugin marketplace add Felo-Inc/memclaw
/plugin install memclaw@memclaw
export FELO_API_KEY="your-api-key-here"

為每個代理領域建立工作區：

Create a workspace called Code Review Agent
Create a workspace called Research Agent
Create a workspace called Project Status

工作階段開始模式：

Load the Code Review Agent workspace
I'm running the weekly review for [repo]. Load the coding standards and any decisions from recent reviews.

工作階段中查詢：

Check the workspace — have we already reviewed how auth middleware handles JWT validation?
What patterns have we flagged as blocking in the past?

工作階段結束時回寫：

Add to the workspace: flagged three instances of direct DB queries in the new payment routes.
Team convention is Repository Pattern for all DB access. These need to be fixed before merge.
Save this as a review decision for the payment module.

回寫問題​

自動記憶萃取並不可靠。被指示「記住所有重要的事」的代理，要麼過度儲存雜訊，要麼遺漏真正重要的決定。可靠的模式是明確回寫。

將回寫指示建入你的代理系統提示詞或工作階段開始指令中：

At the end of every run, before finishing:
1. Summarize what you did and what you found
2. List any decisions made and the reasoning
3. List any approaches tried that didn't work
4. Update the workspace status
5. Add all of this to the workspace with today's date

每次執行花 30-60 秒。數週的累積效應使其成為任何代理工作流程中投資報酬率最高的習慣之一。

評估代理記憶品質​

三個問題揭示你的代理記憶是否正常運作：

代理能準確回答「上次我們試了什麼？」嗎？ 如果能，情節記憶運作正常。

代理是否會重新探索已經排除的方法？ 如果會，死路記錄壞了或根本沒在做。

代理是否隨時間進步——更具針對性、更符合團隊慣例、更快識別相關模式？ 如果是，記憶正在累積。如果代理使用六個月後感覺和第一天一樣，記憶就沒有被有效利用。

開始使用​

  1. 找出工作流程中哪些代理在同一領域重複執行
  2. 為每種代理類型建立工作區（memclaw.me）
  3. 在工作區中注入代理需要的基礎知識
  4. 每次代理執行時在開始載入工作區
  5. 在每次工作階段結束時建入明確回寫

從第一次回寫有用上下文的執行開始，累積效應就啟動了。

取得 MemClaw →

相關指南​