OpenClaw 进阶学习笔记 06:从＂双公司隔离＂到＂集团化协同＂,我怎么设计多 Agent 的记忆治理

大家好，我是靓汤（Edwin）。

这是 OpenClaw 进阶学习笔记的第 6 篇。

在上一篇笔记中，我们聊到了 Agent 的工具链整合。而随着系统复杂度的提升，我最近在实战中撞上了一堵“墙”：多 Agent 协作时的记忆（Memory）管理。

最开始，为了图省事和安全，我采用了简单粗暴的“双 Workspace”物理隔离方案。但随着业务场景的深入，这种架构的弊端开始显现。今天这篇笔记，我想复盘一下我是如何从“双公司隔离”模式，演进到“单 Workspace + 多团队”的集团化协同模式，以及在这个过程中，我是如何设计记忆治理策略的。

为什么一开始我选择了“双公司”架构？

在 OpenClaw 的早期搭建阶段，我有两个截然不同的业务场景：

1. 开发测试场景：Agent 需要大胆尝试，允许出错，记忆库里充满了各种调试日志和临时代码。

2. 生产交付场景：Agent 需要严谨、准确，记忆库必须是“黄金数据”。

为了防止测试数据污染生产环境，我当时最直观的反应就是：物理隔离。

我建立了两个完全独立的 Workspace。这就像开了两家独立的公司，一家叫“实验室”，一家叫“工厂”。它们有各自的门禁、各自的档案室（Vector Store），老死不相往来。

当时的逻辑是：

• 安全性 Max：测试 Agent 就算发疯，也读不到生产环境的客户数据。

• 管理简单：不需要复杂的权限配置，一把梭，切个 API Key 就能换环境。

痛点爆发：当“两家公司”需要合并报表时

随着系统演进，我引入了一个新的角色：“架构师 Agent”。它的职责是既要参考生产环境的历史最佳实践，又要指导开发环境的新功能设计。

这时候，“双公司”架构的噩梦开始了：

• 记忆孤岛：架构师 Agent 无法同时连接两个 Workspace 的记忆库。它要么只能看到“过去”（生产库），要么只能看到“现在”（开发库）。

• 上下文搬运成本极高：我不得不手动把生产环境的优质 Case 导出，再灌入开发环境。这就像两家公司合作，非得靠老板（我）每天背着硬盘跑腿。

• 协作断层：当开发环境验证了一个新方案，想同步给生产环境的客服 Agent 时，链路是断的。

我意识到，物理隔离虽然解决了安全问题，但扼杀了协作的灵魂。我需要的不是两家独立的公司，而是一个“集团化”的组织架构——大家在同一栋大楼（Workspace）里办公，但不同部门（Team）有不同的门禁卡。

架构重构：从物理隔离到逻辑治理

于是，我将架构迁移到了 Single Workspace + Multi-Team 的模式。

在这个新架构下，所有 Agent 都在同一个 Workspace 中，共享底层的向量数据库基础设施，但通过逻辑层（Logical Layer）进行隔离。

这带来的最大挑战是：记忆治理。既然大家都在一个池子里，如何确保 Agent A 不会误读 Agent B 的隐私记忆？如何确保通用的知识能被所有 Agent 共享？

经过几轮踩坑，我总结了一套“三级记忆治理模型”。

核心实战：设计“集团化”的记忆权限

我将记忆的可见范围（Scope）划分为了三个层级，这非常像我们在企业微信或飞书里的权限设计：

为什么这么设计？

1. Global 层解决“对齐”问题：无论哪个 Agent，都需要遵循最基本的原则（比如“不能输出种族歧视言论”或“必须使用 Python 3.10”）。这部分记忆下沉为全局只读，确保了所有 Agent 的基准线一致。

2. Team 层解决“协作”问题：这是本次重构的核心。比如“客服 Agent”和“质检 Agent”属于同一个 Team，质检 Agent 可以直接读取客服 Agent 产生的对话记录进行评分，无需数据搬运。

3. Private 层解决“干扰”问题：Agent 在处理具体任务时的中间状态，不应该污染公共知识库。

治理策略的三板斧：Metadata 是关键

在 OpenClaw 的实现中，单纯分层还不够，还需要配合具体的检索策略。这里我分享三个实战中的技术细节：

1. 强制元数据（Mandatory Metadata）

在单 Workspace 架构下，写入任何一条记忆（Memory Fragment），都必须打上 Tags。我强制要求包含 team_id 和 scope 两个字段。

{
"content":"用户反馈登录接口报错 500...",
"metadata":{
"team_id":"dev_ops_team",
"scope":"team",
"timestamp":1708848000,
"source":"slack_alert"
}
}

如果没有这些标签，数据就像扔进了大海，捞都捞不回来。

2. 动态检索路由（Dynamic Retrieval Routing）

Agent 在检索记忆时，不再是全库扫描。Prompt 中会动态注入当前的上下文权限。

例如，一个 Dev Team 的 Agent 发起检索时，系统会自动构建如下的 Filter：filter = (scope == 'global') OR (team_id == 'dev_team' AND scope == 'team')

这样，它既能看到公司的通用规范，又能看到自己组的技术文档，但绝对看不到 Sales Team 的客户报价单。

3. 记忆的“遗忘”机制

在“双公司”模式下，硬盘满了我就直接把测试库删了重建。但在“集团化”模式下，不能随便删库。所以我引入了 TTL（Time To Live）机制。对于 scope=private 的记忆，默认设置 7 天过期；对于 scope=team 的记忆，设置 90 天归档。只有 global 的记忆是永不过期的。

写在最后

从“双 Workspace”到“单 Workspace 多团队”，看似只是配置的改变，本质上是对 Agent 组织关系的重构。

• 物理隔离适合完全不信任、无协作需求的场景（比如服务两个竞争对手客户）。

• 逻辑治理适合需要高频协作、知识共享的内部协同场景。

这次重构后，我的“架构师 Agent”终于可以一边读取生产环境的真实案例，一边指导开发环境的代码编写了。虽然前期配置权限稍微麻烦了一点，但带来的协作效率提升是指数级的。

希望这篇笔记能给正在搭建多 Agent 系统的你一点启发。如果你也在做类似的记忆治理，欢迎在评论区交流你的方案。

下篇笔记，我们聊聊更硬核的：如何让 Agent 自己学会整理和压缩记忆。

保持好奇，我们下期见。