Stash：讓 AI Agent 擁有真正記憶的開源方案，台灣開發者能怎麼用？

「你是誰？你的專案叫什麼名字？我們上次討論到哪裡？」

如果你用過 ChatGPT 或 Claude 的 web 版，大概不會被問這些問題——它們記得你。但如果你用的是自己搭建的 AI Agent、API 串接的模型、或是開源自架的 LLM，那每次新對話都是一場「自我介紹」的輪迴。

這個問題，台灣不少中小企業正面臨著。

一、AI 的失憶症，正在拖慢你的團隊

先不談理論。

想像你是一家台灣電商公司的技術負責人，為了提升客服效率，你搭建了一個 AI Agent，串接了 GPT API，餵了幾十份產品文件和 FAQ。前三天效果不錯——Agent 能回答「這個商品有沒有保固」「退貨流程是什麼」這類問題。

但到了第四天，客戶問：「我昨天才問過退貨處理進度，今天又要重講一次？」你的 Agent 啞口無言。因為每一次對話，對它來說都是一張白紙。

這不是電商才有的問題。任何導入 AI Agent 的團隊，遲早會撞上這堵牆：AI 能推理、能生成、能做邏輯推導——但它沒有記憶。每次會話結束，所有學到的東西就全部歸零。

過去大家怎麼解決？最常見的做法是把整段對話歷史塞進 prompt——也就是所謂的「context stuffing」。但這種做法有明顯的限制。對話一長，token 成本直線上升。而且遲早會碰到模型的 context window 上限。更糟的是，Agent 不會從失敗中學習。上週犯過的錯誤，這週換個 session 又重來一次。

Claude.ai 和 ChatGPT 的 web 版為什麼沒有這個問題？因為它們有內建記憶功能——用戶偏好、專案細節、歷史對話都在後台留存。但這些記憶是封閉的，只服務自家的模型。你的自架 Agent、你串接 Cursor 的本地 LLM、你寫的自動化腳本——全都沒有這個待遇。

「記憶不該是平台特權。」這是 GitHub 上一個名為 Stash 的開源專案的核心主張。

二、Stash 到底是什麼？

Stash 的全稱是「Persistent Memory for AI Agents」，翻譯過來就是「AI Agent 的持久化記憶層」。它不是一個新的 AI 模型，也不取代任何 LLM——它是一個夾在 AI Agent 和資料庫之間的中介層，負責替 Agent 記住所有該記住的事情。

專案作者 alash3al 用一句話總結：「你的 AI 是大腦，Stash 是人生經驗。」

聽起來有點抽象，我們來拆開看。

2.1 從「episode」到「wisdom」

Stash 的記憶機制分為五個層級：

• Episodes（原始經驗）：每一次對話、每一次操作，以 append-only 的方式寫入。不做修改，只追加。這是最原始的記憶素材。
• Facts（提煉事實）：從原始經驗中萃取出來的具體事實。例如「使用者 Alice 偏好繁體中文介面」「專案 X 的上線日期是六月」。每個 fact 都帶有 confidence 分數。
• Relationships（知識圖譜）：事實之間建立關聯。例如 Alice 是專案 X 的 PM，專案 X 使用了 PostgreSQL。
• Patterns（行為模式）：更高層次的抽象。例如「使用者通常在週末提出修改需求」「專案 X 的 bug fix 平均需要兩天完成」。
• Goals / Failures / Hypotheses（目標·失敗·假設）：這是 Stash 最特別的地方。它不只是記錄事實，還能追蹤目標、記錄失敗原因、形成假設。這讓 Agent 有某種程度的「反思能力」。

2.2 命名空間：像資料夾一樣組織記憶

Stash 的另一個巧妙設計是命名空間（Namespaces）。它把記憶組織成類似檔案系統的樹狀結構：

/
├── /users/alice        # Alice 的個人資訊和偏好
├── /projects
│   ├── /restaurant-saas  # 餐廳 SaaS 專案的記憶
│   └── /mobile-app       # 手機 app 專案的記憶
└── /self
    ├── /capabilities     # Agent 知道自己擅長什麼
    ├── /limits           # Agent 知道自己不擅長什麼
    └── /preferences      # Agent 自己的工作偏好

為什麼這個設計重要？因為不同的記憶應該被分開管理。Agent 在 /projects/restaurant-saas 中學到的東西，不應該污染到 /projects/mobile-app 的記憶。但當你查詢 /projects 時，所有子節點的內容都會被遞迴讀取——不需要手動指定。

2.3 Stash vs RAG：不是替代，而是升級

如果你熟悉 RAG（Retrieval-Augmented Generation），你可能會問：「這不就跟 RAG 一樣嗎？」

不一樣。作者用一個比喻來說明：

RAG 像一個效率極高的圖書館員——你給他一份文件，他能快速找出你要的段落。但他不會從對話中學習，不會記住你的偏好，不會追蹤目標。每一次查詢都是獨立事件。

Stash 像一個從第一天就參與專案的同事——他看著專案從零長大，參與過每一次決策，知道為什麼 A 方案被放棄而 B 方案被採用。他不是從文件裡搜尋答案，而是從經驗中回憶。

RAG 擅長的是「搜尋已知文件中的資訊」。Stash 擅長的是「從互動經驗中學習和成長」。兩者可以共存——RAG 搜文檔，Stash 記經驗。

三、實際安裝與使用

Stash 的安裝過程相當簡單。它採用 PostgreSQL + pgvector 作為底層儲存，對已經在使用 PostgreSQL 的團隊來說幾乎無痛。

安裝

# 使用 Docker 一鍵啟動
docker run -d \
  --name stash \
  -p 8080:8080 \
  -e DATABASE_URL=postgres://user:pass@host:5432/stash \
  alash3al/stash:latest

MCP 整合

Stash 原生支援 MCP（Model Context Protocol），這是 Anthropic 提出的標準協議，讓 AI Agent 和外部工具之間有標準化的溝通方式。只要你的 Agent 支援 MCP，接上 Stash 只需幾行設定。

以 Claude Code 為例：

{
  "mcpServers": {
    "stash": {
      "command": "npx",
      "args": ["@stash/mcp-server"],
      "env": {
        "STASH_URL": "http://localhost:8080",
        "STASH_API_KEY": "your-key"
      }
    }
  }
}

接上之後，你的 Agent 就多了 28 個 MCP tools——從「寫入記憶」到「查詢事實」到「建立關聯」都可以透過標準介面操作。

支援的後端

Stash 底層支援 PostgreSQL + pgvector，這代表它可以直接使用你現有的 PostgreSQL 資料庫，不需要額外引入向量資料庫。對於已經有 PostgreSQL 基礎設施的團隊，部署成本極低。

四、對台灣中小企業的實際意義

回到台灣的場景。中小企業導入 AI 時，最常面臨的不是模型能力不夠，而是持續性不足。

場景一：客服系統

一家 20 人規模的電商公司，導入 AI 客服後前兩週很順利。但隨著客戶反覆追問「我上次的訂單處理到哪裡了」「我之前說要改地址你記得嗎」，AI 開始答非所問——因為它根本不記得。導入 Stash 後，每一次客戶對話的上下文被自動保留。客戶說「我昨天問過」，Agent 真的記得昨天問了什麼。

場景二：內部知識管理

一家小型軟體工作室，用 AI Agent 協助開發者查詢技術文件。但每個開發者有不同的偏好：有人用 React 有人用 Vue、有人偏好 REST 有人用 GraphQL。沒有記憶的 Agent 每次都要從頭確認。有了 Stash，Agent 會記住每個開發者偏好，甚至能從歷史對話中推斷出「這個團隊最近在轉移到 TypeScript，回答時應該優先提供 TypeScript 範例」。

場景三：持續迭代的專案管理

這是 Stash 最有價值的場景。想像一個長期維護的 SaaS 產品，AI Agent 協助 PM 追蹤需求、記錄決策、提醒遺漏的事項。沒有記憶的 Agent，每次開新 sprint 都是從零開始。有了 Stash，Agent 會記得「上個 sprint 為什麼決定延後支付功能」以及「客戶 A 的客訴處理到哪一步了」。

五、限制與需要注意的地方

Stash 雖然概念漂亮，但離「完美」還有距離。

首先，它的底層依賴 PostgreSQL + pgvector。雖然 PostgreSQL 是成熟可靠的方案，但對於沒有資料庫基礎設施的小團隊來說，依然需要一定的運維能力。Docker 一鍵安裝解決了部署問題，但資料備份、效能調校、擴容規劃這些事情不會憑空消失。

其次，Stash 目前還是一個相對新的專案。28 個 MCP tools 涵蓋了記憶操作的方方面面，但文檔還在完善中。非技術背景的使用者，可能需要一些時間理解命名空間和事實提煉的概念。

第三，記憶的品質取決於 Agent 的使用方式。Stash 會自動從對話中萃取事實，但萃取的準確度受到底層模型能力的影響。如果模型本身缺乏理解力，寫進 Stash 的「事實」可能是錯的。好在 Stash 的 fact 系統帶有 confidence 分數，錯誤的事實會隨著時間被修正。

六、開源生態的態度

Stash 選擇開源這條路，本身就是一個訊號。

Claude.ai 和 ChatGPT 的記憶功能很好用，但它們是封閉的、鎖在各自的平台生態裡。你的資料存在 OpenAI 的伺服器上，你的記憶無法帶到其他工具。如果你同時使用 Cursor、Claude Code、和自定義 Agent，每一個都要重新建立對你的理解。

Stash 的開源模式解決了這個問題。你的記憶資料存在你自己的 PostgreSQL 資料庫中——你擁有它、控制它、決定誰可以存取它。切換模型時，記憶層不需要重新建立。從 GPT 換到 Claude、從商業模型換到開源模型——Stash 在背後提供一致的記憶體驗。

這種「資料所有權回歸使用者」的做法，呼應了過去幾年開源社群一直強調的價值。AI Agent 的能力越來越強，但能力越強，對個人化記憶的依賴就越大。如果記憶被平台綁架，使用者的主控權就會被侵蝕。

七、結語

AI Agent 的記憶問題，本質上是「現在的 AI 非常聰明，但沒有任何生活經驗」。它可以解微積分，但記不住你叫什麼名字。它可以寫一篇論文，但忘了自己五分鐘前說了什麼。這些能力放在一起，形成了一種奇怪的矛盾：聰明的工具，笨拙的使用體驗。

Stash 試圖解決的，正是這個矛盾。它不是讓 AI 變得更聰明——它是讓 AI 不再那麼健忘。聽起來很基本，但做到了這件事，對於實際使用體驗的提升，可能比模型升級幾個百分點的準確率更加有感。

對台灣的開發者和中小企業來說，Stash 提供的不是什麼石破天驚的技術突破，而是一個非常務實的工具：讓你打造 AI Agent 時，不需要從「如何讓 AI 記住事情」這個基礎問題開始煩惱。你可以專注在真正的業務邏輯上，把記憶這種基礎設施交給開源社群。

未來幾年，我們會看到更多像 Stash 這樣的基礎設施工具出現。因為 AI 的發展已經過了「哪個模型更強」的階段，進入了「如何讓這些強模型真正被用起來」的階段。而記憶，是所有應用最根本的起點。

參考資料：
– Stash GitHub Repository
– Stash 官方文件
– MCP（Model Context Protocol）規範