一个真实的多 Agent 困境

你的团队部署了 5 个 AI Agent，各司其职：Agent A 做代码审查，需要了解编码规范和架构约定；Agent B 做客户支持，需要理解产品功能和常见问题；Agent C 生成文档，需要知道 API 规范和业务逻辑；Agent D 做数据分析，需要了解指标定义和计算规则；Agent E 管项目，跟踪任务状态和团队分工。

这 5 个 Agent 在很多知识上有交集。拿"用户管理模块的业务规则"来说——代码审查 Agent 需要知道实现约束，客户支持 Agent 需要知道功能边界，文档 Agent 需要知道 API 细节，数据分析 Agent 需要知道指标含义，项目管理 Agent 需要知道负责人和进度。

问题来了：这些共享的知识应该存在哪里？

隔离还是共享，怎么选都有毛病

每个 Agent 各自维护自己的记忆，你会遇到三个问题。同一个业务规则在 5 个 Agent 中存了 5 份，内容可能不一致。Agent A 刚搞清楚的一个概念，Agent B 还得重新学一遍。业务规则变更时，你得确保 5 个 Agent 都更新了，漏掉任何一个都会出事。

那让所有 Agent 共享同一个记忆池呢？毛病换成另外三个。客户支持 Agent 不该看到内部的代码审查记录。数据分析 Agent 的对话记忆可能干扰代码审查 Agent 的判断。某些对话涉及敏感信息，不该对所有 Agent 可见。

这本质上是隔离与共享之间的矛盾。大多数现有的 Agent 框架对这个问题要么装看不见，要么只给了个粗糙的解决方案。

根源：缺少"边界感"

传统的 Agent 记忆方案通常走两个极端。

完全隔离：每个 Agent 有自己的 Memory，互不干扰。安全，但知识没法流通。Agent A 花了一晚上搞明白的技术细节，Agent C 明天还得从头研究。

完全共享：所有 Agent 共用一个 Memory Store。知识流通了，但边界消失了。面向客户的 Agent 可能把内部讨论的内容透露给客户，负责测试的 Agent 可能把未发布的功能信息泄露出去。

真正需要的是一种有边界感的共享机制——某些知识公开，所有 Agent 可以访问；某些知识受限，只有特定 Agent 可以看；某些知识私有，只属于特定 Agent。

其实这个思路在人类组织中早就存在——公司的公共 Wiki、部门文档、个人笔记，就是一套天然的分级知识治理模型。问题是，怎么把它搬到 Agent 世界？

Workspace：有权限边界的知识空间

我在 RDS ContextDB 中见过一种实现方式：用 Workspace（工作空间）来模拟这种分级治理。每个 Workspace 不是传统意义上的"文件夹"，更像是一个有权限边界的知识空间，包含一组实体卡片、一组原子事实、以及实体之间的关联关系。

关键在于：不同的 Agent 可以属于不同的 Workspace，同一个 Agent 也可以同时属于多个 Workspace。

回到 5 Agent 场景，可以这样划分：

Workspace: 公共知识库├── 权限：所有 Agent 可读写├── 内容：产品功能描述、业务规则、组织架构└── Agent 成员：A, B, C, D, EWorkspace: 技术知识库├── 权限：Agent A, C 可读写；Agent D 只读├── 内容：编码规范、架构设计、API 文档└── Agent 成员：A, C (读写), D (只读)Workspace: 客户知识库├── 权限：Agent B 可读写；Agent E 只读├── 内容：客户反馈、常见问题、话术模板└── Agent 成员：B (读写), E (只读)Workspace: Agent A 私有空间├── 权限：仅 Agent A 可读写├── 内容：代码审查对话记录、审查意见草稿└── Agent 成员：A

这样每个 Agent 都能拿到它需要的知识，同时不会越界。

权限精细到操作级别

Workspace 解决了"哪些知识对哪些 Agent 可见"的问题。多 Agent 协作还需要更细的控制。

这套系统的权限模型支持四种操作级别：读取（检索和查看）、写入（添加新知识）、修改（更新已有知识）、管理（修改权限设置）。

你可以设这样的规则：代码审查 Agent 对"技术知识库"有读写权限，对"客户知识库"只有只读权限。客户支持 Agent 对"公共知识库"有读写权限，对"技术知识库"完全没有访问权限。项目管理 Agent 对"公共知识库"有管理权限，可以调整其他 Agent 的权限。

查询时自动按权限过滤

当某个 Agent 发起查询，系统会自动根据权限做过滤。

举个例子。Agent A 问："用户管理模块有哪些已知的性能问题？"系统会在 Agent A 有权限的所有 Workspace 中检索，过滤掉它无权访问的内容。结果可能包含公共知识库里的功能描述和已知问题列表、技术知识库里的代码审查评论，但不会包含客户知识库里的客户投诉——Agent A 无权访问那块。

Agent 只看到该看的，不会因为缺少跨域知识而"失忆"。

跨 Workspace 的知识关联

Workspace 之间权限隔离，但知识之间的关联不会因此断裂。

记忆图谱（Memory Graph）维护了实体之间的关联关系，即使两个实体分属不同的 Workspace。"用户管理模块"在公共知识库有一个实体卡片，在技术知识库里有更详细的技术描述，在客户知识库里有客户反馈相关的信息。

Agent A 查询"用户管理模块"时，系统基于 Agent A 的权限聚合来自不同 Workspace 的信息，但只展示它有权访问的部分。关联关系帮助系统更好地理解查询意图，提高检索准确率。

接入方式

curl -fsSL 'https://context-database-client.oss-cn-hangzhou.aliyuncs.com/install.sh' | bash -s -- --agent <agent> --api-key <api-key>

支持 Qoder、Claude Code、Codex、OpenClaw、OpenCode、Hermes 和 QoderWork。接入后通过 API 创建 Workspace、设置 Agent 与 Workspace 的映射关系就行了。

怎么做到共享但不乱

回到开头的问题：5 个 Agent 共享同一份业务理解，怎么做到既共享又不乱？

我的经验是四个字：划清边界。公共知识放在共享 Workspace，所有 Agent 可以访问。领域知识放在专业 Workspace，按角色授权。私有对话留在个人 Workspace，不对外暴露。权限控制精细到操作级别，读写分离。

当然，这个方案也有自己的问题。Workspace 的权限配置在 Agent 数量多的时候会变得复杂——5 个 Agent 还好管理，如果是 20 个 Agent，权限矩阵的设置和维护成本会明显上升。另外目前这套模型只在 RDS MySQL 上可用，不支持其他数据库引擎。

不过思路本身不新鲜——人类组织早就在这么干了。ContextDB 做的事情是把这套治理模式搬到了 Agent 世界，提供了一个可参考的实现。如果你也在做多 Agent 协作，不妨从这个角度想想：不是 Agent 变聪明了，是它们终于学会了怎么正确地共享知识。

参考链接

• RDS ContextDB 快速入门