# How Memory Works in a Multi-Agent System: Inside Multica
**作者**: mem0
**日期**: 2026-04-08T20:03:44.000Z
**来源**: [https://x.com/mem0ai/status/2045519377655890111](https://x.com/mem0ai/status/2045519377655890111)
---
Recently, managed agents like Paperclip, Multica, and Claude Managed Agents have made it easier for developers to assign specific tasks to systems like Claude, Hermes, OpenClaw, or Codex.
@MulticaAI, an open-source project just crossed 15,400 GitHub stars. Its memory system is particularly interesting. Here’s how it works.
## What are managed agents?
Managed agents let you run multiple AI agents inside one workflow. You assign a task to Claude. The next one to Hermes. A bug to Codex. An action item to OpenClaw. The platform routes the work, tracks state, keeps everyone coordinated.
It's the layer above individual CLIs. You stop thinking about which tool to open and start thinking about which agent gets which job.
## My personal experience with multi agent system
I've been using Claude Cowork. It's good, but it hits limits fast when you want multiple agents on shared state. You end up copy-pasting context between sessions.
Then Anthropic released Claude Managed Agents. Better. Still limited toward Claude.
There is Paperclip. Impressive, but heavier than I needed. Org charts, approval workflows, spend controls. Built to simulate an enterprise.
Multica is an open-source managed agents platform.
Multica stuck for 3 reasons.
1. I can mix agents. Claude, Codex, Hermes, OpenClaw, Gemini, Pi, Cursor Agent. All on the same board, all pulling from the same skills library. Vendor-neutral.
Agent's Snapshot
2. Human in the loop. Agents propose changes, comment on issues, flag blockers. I stay in the decision loop. Human + AI, not operator + tool.
3. Clean UI/UX. I like how simple it is I could create issue, agent, assign different runtime. easily
Multica Issue Board
Once I committed, I dug into the source to understand the memory model.
I had found something unexpected: zero vector embeddings.
## How memory flows through a task
Here's what actually happens when you assign an issue to an agent, traced from the schema:
Step 1. A human creates an issue with a title, description, and optional context_refs to related issues.
Step 2. The row is inserted into issue, scoped by workspace_id.
Step 3. The issue is assigned to an agent / user.
Step 4. Backend assembles a snapshot: workspace.context + target issue + related issues + attached skills.
Packs it into one JSONB blob, writes to agent_task_queue with status = 'queued'.
Step 5. Daemon polls via a partial index (idx_agent_task_queue_pending) that covers the exact polling query.
Step 6. Daemon claims the row, reads the JSONB, spawns the right CLI (claude, codex, gemini, hermes, openclaw, cursor, etc.) with the snapshot + skill files on disk.
Step 7. Agent streams updates back.
Row updates + inserts into comment and activity_log, fanned out via WebSocket. One source of truth for real-time and historical reads.
Step 8. On done, the resolution becomes a new or updated skill row. Next similar task pulls it via agent_skill.
The memory compounds. When you start, the agents start with an empty skills table. By the end of the day your agents can inherit everything the team has shipped.
## The six tables that make up agent memory in Multica
Multica's memory
Multica's memory is six tables, all scoped by workspace_id:
workspace.context (TEXT)
workspace-wide prompt every agent inherits. Added in migration 006.
issue with context_refs + acceptance_criteria (JSONB)
the task unit, carrying related issue IDs and done-conditions.
agent_task_queue.context (JSONB)
point-in-time snapshot the daemon reads once. No DB roundtrips during inference. Added in migration 003.
skill + skill_file + agent_skill
reusable capabilities, workspace-scoped, attached per agent via the join table. Added in migration 008.
comment
threaded working memory during a task. Every row is either from a member or an agent, never ambiguous.
activity_log
append-only audit trail of every state transition.
Six tables. No vector similarity. No embedding store.
## How the agent memory is retrieved?
Each agent is connected to a skill.
Skills aren't retrieved by similarity. They're attached to agents explicitly through agent_skill rows. The query is just:
No cosine similarity. No top-K. Just a join.
For coding agents, curated relevance beats learned similarity. A migration runbook needs the exact runbook, not the statistically-closest one. Curation is cheaper than a retrieval miss.
Different story for chat assistants, product search, or research synthesis. That's not what Multica is for.
## Workspace isolation is the actual primitive
Every table has workspace_id UUID NOT NULL REFERENCES workspace(id) ON DELETE CASCADE.
Every query is filtered by it. Every index leads with it.
That's what makes the design deployable. A team offboarding is one DELETE FROM workspace WHERE id = $1 and everything cascades.
You can't retrofit this onto a vector-DB-first architecture without rebuilding from scratch.
Multica got it right by starting with relational. I could still see this relational approach can be combined with AI agent memory system for a better agentic experience for its agent.
## The JSONB snapshot pattern
The most copy-worthy pattern here is agent_task_queue.context JSONB.
Most multi-agent systems either query the database live during execution or stuff everything into one giant prompt. Multica does neither. It assembles a purpose-built snapshot at dispatch, hands it off, and the database stays cold during inference.
## What this tells us about managed agents in 2026
1. Memory systems can live in various forms, depending on the use case.
Multica's 15,400+ stars on pure relational + JSONB prove the "you need embeddings" narrative is not a MUST from infra + harness perspective. Though it’s needed downstream on agent context, i.e chat-assistant use cases.
2. Memory that compounds is as important as memory that retrieves.
A curated skill library keeps getting more valuable. Chat history needs a memory layer to support these skills and context collection.
3. Human-in-the-middle is a schema choice. author_type, assignee_type, actor_type. Every message and state transition is attributable. Not a UX veneer, a foundational primitive.
## The limitations
No fuzzy recall. Untagged skills are invisible at dispatch.
Snapshots go stale. Agents miss new comments mid-task.
Skills quality == team discipline. Skip write-ups, the skills library rots.
Snapshots grow with the library. 200 skills, 200 summaries per blob.
No cross-workspace memory. Team A's solution can't help Team B.
If the memory is portable, this would be great.
## Where I think it could be better
The relational structured boundaries are great. Workspace isolation, cascading deletes, audit trails. That part is solid.
But I think the agent experience and memory context could have been better with a context layer built for agents.
PostgreSQL is the right choice for the harness of the system: managing skills, issues, tasks, state. That's what relational databases are good at.
What I'm less sure about is using the same layer for agent context.
An agent's context is more than a skill. It's prior decisions, the patterns it's learned, the history of how it worked with a teammate, the style it's developed over time. Skill_file row and an agent_skill join are not enough.
A context layer built specifically for agents, with fuzzy recall and contextual retrieval, could sit alongside Multica's schema and do the work the schema isn't designed for.
The schema is the harness. The context layer would be the nervous system.
In my next article, I'm plugging mem0 into the managed-agents stack to be able to answer these limitations.
Stay tuned!
In Context #6
This blog is part of In Context, a mem0 blog series covering AI Agent memory and context engineering.
mem0 is an intelligent, open-source memory layer designed for LLMs and AI agents to provide long-term, personalized, and context-aware interactions across sessions.
- Get your free API Key here: app.mem0.ai
- or self-host mem0 from our open source github repository
## 相关链接
- [mem0](https://x.com/mem0ai)
- [@mem0ai](https://x.com/mem0ai)
- [292](https://x.com/mem0ai/status/2045519377655890111/analytics)
- [@MulticaAI](https://x.com/@MulticaAI)
- [Multica](https://multica.ai/)
- [Apr 9](https://x.com/jiayuan_jy/status/2041970269372518877)
- [433K](https://x.com/jiayuan_jy/status/2041970269372518877/analytics)
- [mem0](https://mem0.ai/?utm_source=x_article_mem0&utm_medium=incontext_article&utm_campaign=multica_memory&utm_content=multica_memory)
- [app.mem0.ai](https://app.mem0.ai/?utm_source=x_article_mem0&utm_medium=incontext_article&utm_campaign=multica_memory&utm_content=multica_memory)
- [github repository](https://github.com/mem0ai/mem0)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:06 PM · Apr 18, 2026](https://x.com/mem0ai/status/2045519377655890111)
- [292 Views](https://x.com/mem0ai/status/2045519377655890111/analytics)
---
*导出时间: 2026/4/18 23:30:57*
---
## 中文翻译
# 多智能体系统中的记忆是如何工作的：走进 Multica
**作者**： mem0
**日期**： 2026-04-08T20:03:44.000Z
**来源**： [https://x.com/mem0ai/status/2045519377655890111](https://x.com/mem0ai/status/2045519377655890111)
---
最近，像 Paperclip、Multica 和 Claude Managed Agents 这样的托管型智能体让开发者更容易将特定任务分配给 Claude、Hermes、OpenClaw 或 Codex 等系统。
@MulticaAI 是一个开源项目，刚刚在 GitHub 上突破了 15,400 颗星。它的记忆系统尤为有趣。下面是它的工作原理。
## 什么是托管型智能体？
托管型智能体让你可以在一个工作流中运行多个 AI 智能体。你可以把一个任务分配给 Claude。下一个任务给 Hermes。一个 bug 给 Codex。一个行动项给 OpenClaw。平台负责路由工作、追踪状态，保持所有智能体协调一致。
它是位于单个 CLI 之上的层。你不再需要思考要打开哪个工具，而是开始思考哪个智能体适合哪项工作。
## 我使用多智能体系统的个人经历
我一直在使用 Claude Cowork。它不错，但当你想让多个智能体共享状态时，它很快就遇到瓶颈。你最终不得不在会话之间复制粘贴上下文。
后来 Anthropic 发布了 Claude Managed Agents。更好了，但仍然只偏向 Claude。
还有 Paperclip。令人印象深刻，但比我需要的更重。组织架构图、审批工作流、支出管控。它是为模拟企业而构建的。
Multica 是一个开源的托管型智能体平台。
Multica 让我留下来有 3 个原因。
1. 我可以混用智能体。Claude、Codex、Hermes、OpenClaw、Gemini、Pi、Cursor Agent。全部在同一个看板上，全部从同一个技能库中拉取。厂商中立。
智能体快照
2. 人在回路中。智能体提出变更建议、在问题上评论、标记阻碍。我始终留在决策环节中。人类 + AI，而不是操作员 + 工具。
3. 简洁的 UI/UX。我喜欢它的简单，我可以轻松创建 issue、智能体，并分配不同的运行时。
Multica Issue 看板
一旦我决定使用它，我就深入源码来理解它的记忆模型。
我发现了一些出乎意料的东西：零向量嵌入。
## 记忆如何在一个任务中流转
当你把一个 issue 分配给一个智能体时，实际发生的事情如下，这是从模式中追踪出来的：
第 1 步。人类创建一个 issue，包含标题、描述，以及可选的指向相关 issue 的 context_refs。
第 2 步。该行被插入到 issue 表中，以 workspace_id 划分作用域。
第 3 步。该 issue 被分配给一个智能体/用户。
第 4 步。后端组装一个快照：workspace.context + 目标 issue + 相关 issue + 附带的技能。
将其打包成一个 JSONB blob，写入 agent_task_queue，状态设为 'queued'。
第 5 步。守护进程通过一个部分索引（idx_agent_task_queue_pending）进行轮询，该索引恰好覆盖轮询查询。
第 6 步。守护进程认领该行，读取 JSONB，在磁盘上使用快照 + 技能文件启动相应的 CLI（claude、codex、gemini、hermes、openclaw、cursor 等）。
第 7 步。智能体将更新流式传回。
行更新 + 插入到 comment 和 activity_log 表中，并通过 WebSocket 扇出。实时读取和历史读取共用一个唯一事实来源。
第 8 步。完成后，解决方案成为一条新的或更新的 skill 行。下一个类似任务通过 agent_skill 拉取它。
记忆不断累积。刚开始时，智能体从一张空的技能表开始。到一天结束时，你的智能体可以继承团队交付的一切。
## 构成 Multica 智能体记忆的六张表
Multica 的记忆
Multica 的记忆由六张表组成，全部以 workspace_id 划分作用域：
workspace.context（TEXT）
每个智能体都会继承的工作区级提示词。在迁移 006 中添加。
issue 表，含 context_refs + acceptance_criteria（JSONB）
任务单元，携带相关 issue ID 和完成条件。
agent_task_queue.context（JSONB）
守护进程只读取一次的时点快照。推理期间不进行数据库往返。在迁移 003 中添加。
skill + skill_file + agent_skill
可复用的能力，以工作区为作用域，通过连接表附加到每个智能体。在迁移 008 中添加。
comment
任务期间的线程式工作记忆。每一行要么来自成员，要么来自智能体，绝不含糊。
activity_log
只追加的审计日志，记录每一次状态转换。
六张表。没有向量相似度。没有嵌入存储。
## 智能体记忆是如何检索的？
每个智能体都连接到一个技能。
技能不是通过相似度检索的。它们是通过 agent_skill 行显式附加到智能体上的。查询就是：
没有余弦相似度。没有 top-K。只有一个连接。
对于编码智能体来说，人工筛选的相关性胜过学习到的相似度。一份迁移操作手册需要的是确切的那份手册，而不是统计上最接近的那份。人工筛选比检索失误更便宜。
对于聊天助手、产品搜索或研究综合来说，情况则不同。那不是 Multica 的用途所在。
## 工作区隔离才是真正的基础原语
每张表都有 workspace_id UUID NOT NULL REFERENCES workspace(id) ON DELETE CASCADE。
每个查询都按它过滤。每个索引都以它开头。
这就是让这个设计可部署的关键。一个团队的离场清理只需一条 DELETE FROM workspace WHERE id = $1，一切都会级联删除。
你无法在以向量数据库为先的架构上通过改造实现这一点，只能从头重建。
Multica 从关系型起步，做对了。我仍然可以看到这种关系型方法可以与 AI 智能体记忆系统相结合，为其智能体带来更好的智能体体验。
## JSONB 快照模式
这里最值得借鉴的模式是 agent_task_queue.context JSONB。
大多数多智能体系统要么在执行期间实时查询数据库，要么把所有东西塞进一个巨大的提示词。Multica 两者都不做。它在分发时组装一个专门构建的快照，交出去，然后数据库在推理期间保持“冷”状态。
## 这告诉我们 2026 年托管型智能体的什么趋势
1. 记忆系统可以以多种形式存在，取决于使用场景。
Multica 在纯关系型 + JSONB 架构上获得了 15,400+ 星标，这证明“必须使用 embeddings”的说法从基础设施 + 框架的角度来看并不是必须的。不过在下游的智能体上下文（如聊天助手用例）中，embeddings 仍然是必要的。
2. 可累积的记忆与可检索的记忆同样重要。
一个精心维护的技能库会不断增值。聊天历史需要一个记忆层来支持这些技能和上下文的收集。
3. 人在回路（Human-in-the-middle）是一种 schema 设计选择。author_type、assignee_type、actor_type。每条消息和每次状态转换都是可归因的。这不是 UX 表层装饰，而是一种基础原语。
## 局限性
没有模糊召回。未被标记的技能在调度时不可见。
快照会过时。智能体在任务执行过程中会错过新评论。
技能质量 == 团队纪律。跳过文档编写，技能库就会腐化。
快照随技能库增长。200 个技能，每个 blob 中就有 200 条摘要。
没有跨工作区的记忆。A 团队的解决方案无法帮助 B 团队。
如果记忆是可移植的，那就太好了。
## 我认为可以改进的地方
关系型结构化边界非常棒。工作区隔离、级联删除、审计追踪。这部分很稳固。
但我认为，如果有一个专为智能体构建的上下文层，智能体体验和记忆上下文本可以做得更好。
PostgreSQL 是系统框架的正确选择：管理技能、问题、任务、状态。这正是关系型数据库所擅长的。
我不太确定的是，将同一层用于智能体上下文。
智能体的上下文不仅仅是技能。它包括先前的决策、学到的模式、与队友协作的历史、随时间形成的风格。一个 skill_file 行和一个 agent_skill 连接是不够的。
一个专为智能体构建、具备模糊召回和上下文检索能力的上下文层，可以与 Multica 的 schema 并存，完成 schema 并非为其设计的那些工作。
Schema 是框架。上下文层则是神经系统。
在我的下一篇文章中，我将把 mem0 接入托管智能体技术栈，以解决这些局限性。
敬请期待！
In Context #6
本博客是 In Context 系列的一部分，这是 mem0 的博客系列，涵盖 AI 智能体记忆和上下文工程。
mem0 是一个智能的开源记忆层，专为 LLM 和 AI 智能体设计，可在跨会话中提供长期、个性化和上下文感知的交互。
- 在此获取您的免费 API Key：app.mem0.ai
- 或从我们的开源 github 仓库自托管 mem0
## 相关链接
- [mem0](https://x.com/mem0ai)
- [@mem0ai](https://x.com/mem0ai)
- [292](https://x.com/mem0ai/status/2045519377655890111/analytics)
- [@MulticaAI](https://x.com/@MulticaAI)
- [Multica](https://multica.ai/)
- [4月9日](https://x.com/jiayuan_jy/status/2041970269372518877)
- [433K](https://x.com/jiayuan_jy/status/2041970269372518877/analytics)
- [mem0](https://mem0.ai/?utm_source=x_article_mem0&utm_medium=incontext_article&utm_campaign=multica_memory&utm_content=multica_memory)
- [app.mem0.ai](https://app.mem0.ai/?utm_source=x_article_mem0&utm_medium=incontext_article&utm_campaign=multica_memory&utm_content=multica_memory)
- [github 仓库](https://github.com/mem0ai/mem0)
- [升级到 Premium](https://x.com/i/premium_sign_up)
- [2026年4月18日 23:06](https://x.com/mem0ai/status/2045519377655890111)
- [292 次浏览](https://x.com/mem0ai/status/2045519377655890111/analytics)
---
*导出时间: 2026/4/18 23:30:57*
