多智能体协作新范式：用图数据库取代提示词传递上下文

多智能体系统的演示往往很惊艳，但落地时总绕不开一个尴尬的事实：智能体之间传递上下文的方式，基本靠提示词接力。一个智能体调研后生成摘要，摘要被粘贴进下一个智能体的提示词，下一个智能体再补充内容、生成更长的摘要继续往下传。这套做法在单次会话、演示规模下勉强能用，但上下文又长又有损——每经过一跳就丢失一层信息——而且进程一结束，记忆就蒸发了。第二天开新会话，整个团队对之前发生的事一无所知。

这正是 Graph Hacks 黑客松（由 WeMakeDevs 围绕 FalkorDB 作为 AI 智能体上下文层举办）中，Lusavio 构建 Crew Memory Graph 的出发点。他们的方案很直接：给三个智能体（Planner、Researcher、Executor）一个共享的图数据库作为“笔记本”，而不是让它们互相粘贴摘要。

设计原则：移除 FalkorDB，什么都不剩

黑客松的核心要求是 FalkorDB 必须承担关键作用，而不是装饰品。Lusavio 把这条要求变成了写代码前的设计规则：移除 FalkorDB，系统里不应该剩下任何东西。

没有跨会话记忆，没有智能体间的共享状态，没有公司知识库，也没有答案。这条规则倒逼出一个诚实的架构：智能体在设计中是无状态的。部署时，所有状态——团队学到的、计划的、决定的、交接的一切——只存在于一个地方：每个租户一个 FalkorDB 图，且只能通过参数化的 Cypher 遍历访问。

这解决了提示词接力的三个根本问题：上下文不再有损（图里的数据是精确的，不是摘要的摘要）、不再蒸发（图是持久化的，跨会话存在）、不再需要“粘贴”这个动作（智能体通过遍历读取同一份数据）。

FalkorDB 是一个基于稀疏矩阵的图数据库，专为低延迟的图遍历和路径查询设计，兼容 openCypher 查询语言，并原生支持向量索引，因此常被用作 AI 应用的上下文存储层。与将状态保存在进程内存或向量库中不同，图数据库以节点和边的形式持久化实体间关系，使得多跳推理（例如“谁决定了什么，依据哪份文档”）可以通过一次遍历完成。在智能体场景中，这意味着记忆不是一段可被摘要的文本，而是一组可被精确查询的结构化事实。FalkorDB 的租户隔离通常通过独立图实例或命名空间实现，这也是本文中“每个租户一个图”能够成立的基础。

三层记忆，一个图

Crew Memory Graph 的记忆组织方式对应了 Track 02 的要求，分为三层。

情景记忆：发生了什么

会话、情节和交接，按顺序记录，每次写入都携带来源信息：哪个智能体、哪个会话、何时、来自什么源。这层记忆让系统能回答“之前发生了什么”，而不是依赖当前会话的上下文窗口。

语义记忆：什么是真的

公司本身的结构——人、团队、项目、文档、工单、决策、话题、聊天线程——加上团队沿途学到的每个事实，都链接到它们涉及的实体上。这层记忆是公司知识的骨架。

程序记忆：我们怎么做

计划和流程存储为步骤图，所以一个智能体写的计划是另一个智能体能执行的结构，而不是一段需要重新解读的段落。这层记忆让协作从“传文本”变成“传结构”。

演示公司 Meridian Labs 是全合成的——基于固定种子程序化生成，核心部分手工固定，并在 UI 中标注为合成数据。这一点很关键：每个问题都有精确、可核验的标准答案。演示的 impressiveness 不在于答案听起来合理，而在于答案对已知图来说是对是错。

交接才是真正的演示

核心亮点是一个跨会话交接。

会话 1 中，Researcher 被教会一份关于 Beacon 移动应用的发布简报——发布日期、beta 测试人数、一个阻塞项。Planner 把简报转换成步骤计划，并向 Executor 发起一个交接。交接本身不包含简报内容，而是引用精确的记忆节点。智能体之间不传递任何文本，因为没有东西可传——只有图。

会话 2 中，一个全新的 Executor 启动。不同的进程，空的上下文。它通过遍历找到未完成的交接，顺着 REFERENCES 边找到会话 1 写入的记忆，回答交接中的问题——Beacon 什么时候发布，beta 测试人数是多少——用的是一段它从未见过被写入的记忆。然后它执行下一步计划，关闭交接，把自己的结果作为新情节写回图中。

同一流程也以无头模式运行，作为两个真正独立的进程——因为只在一个进程内有效的交接不叫交接，那叫变量。

在智能体系统中，交接（handoff）指一个智能体将未完成的任务及其上下文转移给另一个智能体继续处理。传统实现往往把上下文序列化为自然语言或 JSON 塞进下一个智能体的提示词，这会导致信息压缩和失真。基于图的交接则不同：交接本身是一个节点，它通过 REFERENCES 等边指向记忆中具体的实体和事件，新智能体只需从交接节点出发遍历图，就能获取精确的原始信息。这种方式使交接天然具备进程无关性——无论新智能体运行在同一个进程、另一个进程还是另一台机器上，只要它能访问同一个图，就能完整恢复上下文。这也是文中强调“两个真正独立的进程”才能证明交接有效的原因。

答案能展示推理过程

同一个图也能回答公司问题：谁负责 X？谁决定了 Y，为什么？谁知道 Z？这个项目依赖什么？种子公司包含 48 人、6 个团队、8 个项目、32 份文档、48 个工单、20 个聊天线程，以及 8 个带理由和源文档的决策。两个设计选择承担了主要工作：

证据路径是查询结果，不是装饰。 问公司为什么对 Atlas 采用基于用量的定价，答案会组合出实际的链条：Project —HAS_DECISION→ Decision —MADE_BY→ Person —DOCUMENTED_IN→ Document，UI 会在图可视化中高亮这条路径。引用就是遍历本身，不是事后附上的参考文献。

专业度是计算出来的，不是手写的。 KNOWS_ABOUT 的强度在数据摄入时从两个输入计算：合成数据集中的种子专业度断言为“人-话题”对设定最低强度，而制品证据——撰写的文档、做出的决策、解决的工单——在最低值之上增加强度；每条边保留其证据计数，包括种子断言本身。这就是为什么排名答案能展示某个人为什么排在那个位置。

第三个选择是他们最坚持的：查询路径中没有 LLM。 一个确定性的、基于模式的规划器根据图自身的实体解析问题，并将其编译为遍历。当图不知道某件事时，系统会礼貌地返回“无证据”——这是故意的。一个编造答案的记忆系统比一个承认空白的系统更糟，因为你会基于它告诉你的任何内容继续构建。

多跳查询（multi-hop query）指需要沿着图中多条边连续遍历才能回答的问题，例如“谁负责的项目做出了某个决策，该决策记录在哪份文档里”。这类查询的难度在于每一步都可能分支，且路径长度不固定。在本文的基准中，8 个多跳问题按证据路径长度评分，意味着系统不仅要给出答案，还要返回支撑答案的完整节点和边序列。将问题编译为参数化 Cypher 遍历的确定性规划器，其核心挑战在于实体解析——把自然语言中的名称、代词和指代映射到图中唯一节点，再根据 schema 选择正确的边类型和遍历方向。由于路径本身即证据，UI 高亮路径就等于展示推理链，无需额外生成解释文本。

可测量，而非断言

以上所有内容都是可核验的，这正是这样构建的目的：

• 发布仓库中 25 个测试通过；唯一的跳过是 2 个实时 FalkorDB 集成测试，需要配置服务器才能运行——这是处理无法伪造的依赖的诚实方式。还有一个测试证明租户隔离：一个租户的图看不到另一个租户的任何记忆。
• 14 个问题的冻结基准——其中 8 个是多跳问题，按证据路径长度评分——得分 14/14。
• 应用在真实的 FalkorDB Cloud 实例上在线运行；其 /api/status 端点报告后端和图的大小（最近一次检查为 206 个节点、616 条边），所以“它真的连接到了 FalkorDB”是可以获取的事实，而不是必须信任的声明。
• 并发情况按实测陈述：向在线演示同时发送 10 个问题，10 个得到回答——在免费层托管上，答案中位数耗时约 21 秒。功能可用，但不快，并且如实报告。

下一步

同一组遍历计划上的 MCP 工具接口，让其他智能体框架可以使用这个图作为记忆层，而不必采用他们的智能体。为真实文档、工单和聊天源提供摄入连接器，背后是同一套 schema。以及在一个租户图上的多团队协调——交接协议已经是进程无关的，团队只是有更好品牌包装的进程。

诚实的脚注

数据集是合成的，并且在出现的每个地方都标注了这一点。构建过程使用了 AI 编程助手，这是活动规则明确允许的；架构、图 schema、诚实性约束以及每个验证步骤都是参赛者自己的责任，本文中的每个声明都限于测试套件和基准实际测量的内容。

一个范围说明，因为代码是公开的：仓库还附带一个标注为内存开发后端，用于测试和离线开发。它不持有部署状态——在部署系统中，FalkorDB 是唯一的状态存储：在线部署仅运行 FalkorDB，没有智能体在进程内存中保持状态。

如果你的智能体在互相传摘要，它们不是在协作——它们在玩传话游戏。给它们一个都能读的笔记本。把它做成图，笔记本就能回答——还带着收据。