# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：mem0 (@mem0ai) · 平台：X (Twitter) · 日期：2026-04-18

> 原始來源：https://x.com/mem0ai/status/2045519377655890111

## 中文摘要

# 多 Agent 系統中的記憶運作原理：深入剖析 Multica

近期，像 Paperclip、Multica 和 Claude Managed Agents 這類託管型 Agent 讓開發者能更輕鬆地將特定任務指派給 Claude、Hermes、OpenClaw 或 Codex 等系統。

@MulticaAI 是一個剛在 GitHub 上突破 15,400 顆星的開源專案。它的記憶系統特別有趣，以下是它的運作方式。

---

## 什麼是託管型 Agent (Managed Agents)？

託管型 Agent 讓你能在同一個工作流程中執行多個 AI Agent。你可以將任務指派給 Claude，下一個任務給 Hermes，Bug 修復給 Codex，行動項目則交給 OpenClaw。該平台負責路由工作、追蹤狀態，並確保所有 Agent 協調一致。

這是位於個別 CLI 之上的層級。你不再需要思考該開啟哪個工具，而是思考哪個 Agent 適合哪項工作。

## 我對多 Agent 系統的個人經驗

我一直在使用 Claude Cowork。它很不錯，但當你希望多個 Agent 在共享狀態下運作時，很快就會遇到瓶頸。你最終會發現自己不斷在不同工作階段間複製貼上 context。

後來 Anthropic 發布了 Claude Managed Agents，情況有所改善，但仍侷限於 Claude 生態系。

接著是 Paperclip。它令人印象深刻，但比我需要的更笨重。它包含了組織架構圖、審核工作流程和支出控制，設計目標是模擬企業環境。

而 Multica 是一個開源的託管型 Agent 平台。

Multica 讓我留下的原因有三點：

1. 我可以混合使用不同的 Agent。Claude、Codex、Hermes、OpenClaw、Gemini、Pi、Cursor Agent，全部都在同一個看板上，並從同一個技能庫中提取能力。它是供應商中立的。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776545104344-ediaHGKReSakAApNjjpg.jpg)

2. 人類參與機制 (Human in the loop)。Agent 會提出變更建議、針對問題發表評論並標記阻礙因素。我始終處於決策迴圈中。這是「人類 + AI」的協作，而非「操作員 + 工具」的關係。

3. 簡潔的 UI/UX。我喜歡它的簡潔，我可以輕鬆建立問題、指派 Agent 並設定不同的執行環境。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776545104355-iaHGKRKKUb0AAQWXujpg.jpg)

在深入使用後，我查看了原始程式碼以了解其記憶模型。
結果我發現了一些意想不到的東西：零向量嵌入 (Zero vector embeddings)。

## 記憶如何在任務中流動

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776545104747-iaHGKPAicaMAALtVhpng.png)

當你將問題指派給 Agent 時，實際發生的流程如下（根據 Schema 追蹤）：

步驟 1. 使用者建立一個問題，包含標題、描述以及指向相關問題的選填 `context_refs`。

步驟 2. 該列被插入到 `issue` 資料表中，並以 `workspace_id` 進行範圍限制。

步驟 3. 問題被指派給特定的 Agent 或使用者。

步驟 4. 後端組裝一個快照 (Snapshot)：`workspace.context` + 目標問題 + 相關問題 + 附加的技能。

將其打包成一個 JSONB blob，並寫入 `agent_task_queue`，狀態設為 'queued'。

步驟 5. Daemon 透過部分索引 (Partial index, `idx_agent_task_queue_pending`) 進行輪詢，該索引涵蓋了精確的輪詢查詢。

步驟 6. Daemon 領取該列，讀取 JSONB，並啟動對應的 CLI（claude、codex、gemini、hermes、openclaw、cursor 等），同時載入快照與磁碟上的技能檔案。

步驟 7. Agent 將更新串流回傳。
資料列進行更新並插入到 `comment` 和 `activity_log` 中，透過 WebSocket 廣播出去。這是即時讀取與歷史紀錄的單一事實來源 (Source of truth)。

步驟 8. 完成後，解決方案會成為一個新的或更新後的技能列。下一個類似的任務會透過 `agent_skill` 提取它。

記憶會不斷累積。當你開始時，Agent 的技能表是空的；但到了當天結束時，你的 Agent 就能繼承團隊所產出的所有成果。

## 組成 Multica Agent 記憶的六個資料表

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776545104477-diaHGKaJYaYAEeAAQpng.png)

Multica 的記憶由六個資料表組成，全部以 `workspace_id` 進行範圍限制：

1. `workspace.context` (TEXT)
每個 Agent 都會繼承的全工作區 Prompt。於 Migration 006 加入。

2. `issue` (包含 `context_refs` + `acceptance_criteria`) (JSONB)
任務單元，攜帶相關問題 ID 與完成條件。

3. `agent_task_queue.context` (JSONB)
Daemon 讀取一次的時間點快照。在推論過程中無需進行資料庫往返。於 Migration 003 加入。

4. `skill` + `skill_file` + `agent_skill`
可重複使用的能力，以工作區為範圍，透過關聯資料表 (Join table) 附加到每個 Agent。於 Migration 008 加入。

5. `comment`
任務期間的執行緒工作記憶。每一列不是來自成員就是來自 Agent，絕無模糊地帶。

6. `activity_log`
僅供追加 (Append-only) 的稽核軌跡，記錄每一次狀態轉換。

六個資料表。沒有向量相似度。沒有嵌入儲存庫。

## Agent 記憶是如何檢索的？

每個 Agent 都連接到一個技能。
技能並非透過相似度檢索，而是透過 `agent_skill` 資料列明確地附加到 Agent 上。查詢方式非常簡單：

```sql
SELECT * FROM skill s
  JOIN agent_skill a_s ON a_s.skill_id = s.id
 WHERE a_s.agent_id = $1
   AND s.workspace_id = $2
```

沒有餘弦相似度 (Cosine similarity)。沒有 Top-K。就只是一個 Join。

對於程式開發 Agent 而言，經過策劃的相關性勝過學習到的相似度。執行手冊 (Runbook) 需要的是精確的那一份，而不是統計上最接近的那一份。策劃的成本遠低於檢索失敗的代價。

對於聊天助理、產品搜尋或研究綜述來說，情況則不同。但那並非 Multica 的用途。

## 工作區隔離 (Workspace isolation) 是真正的核心原語

每個資料表都有 `workspace_id UUID NOT NULL REFERENCES workspace(id) ON DELETE CASCADE`。
每個查詢都以此進行篩選。每個索引都以此為開頭。

這就是讓該設計具備可部署性的原因。團隊離職時，只需執行 `DELETE FROM workspace WHERE id = $1`，所有相關資料都會自動級聯刪除。

你無法在不從頭重構的情況下，將此功能強行套用到以向量資料庫為優先的架構上。

Multica 從關聯式資料庫開始做起，這點非常正確。我認為這種關聯式方法仍可與 AI Agent 記憶系統結合，為其 Agent 帶來更好的體驗。

## JSONB 快照模式

這裡最值得參考的模式是 `agent_task_queue.context` 的 JSONB 欄位。

大多數多 Agent 系統要麼在執行期間即時查詢資料庫，要麼將所有東西塞進一個巨大的 Prompt 中。Multica 兩者皆不採用。它在派發任務時組裝一個專用的快照，然後將其交出，資料庫在推論期間保持冷卻狀態。

## 這對 2026 年的託管型 Agent 有何啟示

1. 記憶系統可以有多種形式，取決於使用場景。

Multica 在純關聯式資料庫 + JSONB 的基礎上獲得 15,400 多顆星，證明了從 infra 與 harness 的角度來看，「你必須使用嵌入 (Embeddings)」並非絕對必要。儘管在 Agent context 的下游應用（如聊天助理場景）中仍有其需求。

2. 累積型的記憶與檢索型的記憶同樣重要。

一個經過策劃的技能庫價值會不斷提升。聊天紀錄需要一個記憶層來支援這些技能與 context 的收集。

3. 人類參與機制 (Human-in-the-middle) 是一種 Schema 選擇。`author_type`、`assignee_type`、`actor_type`。每一則訊息與狀態轉換都是可歸因的。這不僅是 UX 的表層裝飾，更是基礎原語。

## 侷限性

1. 沒有模糊回憶 (Fuzzy recall)。未標記的技能在派發時是不可見的。

2. 快照會過期。Agent 在任務執行中途無法得知新的評論。

3. 技能品質取決於團隊紀律。如果跳過撰寫步驟，技能庫就會腐壞。

4. 快照會隨著技能庫擴大而變大。如果有 200 個技能，每個 blob 就會有 200 個摘要。

5. 沒有跨工作區的記憶。A 團隊的解決方案無法幫助 B 團隊。
如果記憶是可攜式的，那會非常棒。

## 我認為可以改進的地方

關聯式的結構邊界非常棒。工作區隔離、級聯刪除、稽核軌跡，這些部分都很穩固。

但我認為，如果能有一個專為 Agent 打造的 context 層，Agent 的體驗與記憶 context 會更好。

PostgreSQL 是系統 harness 的正確選擇：管理技能、問題、任務與狀態。這正是關聯式資料庫的強項。

我不確定的是，是否應該將同一層用於 Agent 的 context。

Agent 的 context 不僅僅是技能。它還包含先前的決策、學到的模式、與隊友合作的歷史，以及隨著時間發展出的風格。僅靠 `skill_file` 資料列和 `agent_skill` 的 Join 是不夠的。

一個專為 Agent 打造、具備模糊回憶與情境檢索能力的 context 層，可以與 Multica 的 Schema 並存，並處理 Schema 本身不擅長的任務。

Schema 是 harness，而 context 層將會是神經系統。

在下一篇文章中，我將把 mem0 整合進託管型 Agent 的堆疊中，以解決這些侷限性。

敬請期待！

---

In Context #6

本部落格是「In Context」系列的一部分，這是 mem0 的部落格系列，涵蓋 AI Agent 記憶與 context 工程。

mem0 是一個智慧型開源記憶層，專為 LLM 與 AI Agent 設計，旨在跨工作階段提供長期、個人化且具備情境感知能力的互動。

- 在此取得免費 API Key：app.mem0.ai

- 或從我們的開源 GitHub 儲存庫自行託管 mem0

## 標籤

Agent, 開源專案, 記憶系統, Multica, Claude, OpenClaw