VibeCoding
← 返回首頁

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

mem0
mem0
@mem0ai
♥379🔁 43
𝕏 (Twitter)🔥🔥
查看原文 ↗

AI 語音朗讀 · Edge TTS

多 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，全部都在同一個看板上，並從同一個技能庫中提取能力。它是供應商中立的。

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

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

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

記憶如何在任務中流動

當你將問題指派給 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 記憶的六個資料表

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 上。查詢方式非常簡單：

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 的下游應用（如聊天助理場景）中仍有其需求。

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

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

  1. 人類參與機制 (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

在 X 上閱讀原文 ↗Gemini 翻譯