基于OpenClaw的企业级 AI 中台的 3 个关键问题

年前 OpenClaw 横空出世，把个人 AI 助手的体验拉到了新高度——session 记忆、工具调用、多 agent 协作，开箱即用。而且它开源。这时候就有个很自然的衍生需求，这一套能不能用在企业场景？

最近确实有两个客户和我聊了，想用 OpenClaw 搭建企业级 AI 服务。

一个是内部使用场景——企业多个部门共享一套 AI 助手，需要数据隔离和权限管理。

另一个是对外服务平台——想给下游商家提供 AI 客服能力，每个商家独立运营，互不干扰。

需求很明确，但 OpenClaw 本来是为单用户设计的。怎么改造成多用户？

我们的设计思路很简单：一个用户对应一个 Agent。OpenClaw 的 agent 天然就是用户标识，session、workspace、memory 都跟着 agent 走。多个用户共享一套 OpenClaw，靠 agentId 来区分和隔离。

但具体怎么实现？我们调研了三种技术路线。

三种技术路线对比

路线一：OpenClaw + mem0

复用 OpenClaw 完整能力，接入 mem0 做长期记忆。开发快、风险低、功能完整，但多用户是”后加”的，扩展性受限。

路线二：拆 OpenClaw

把 Gateway 和 Agent 运行时拆开，自研多用户层。灵活度高，但工作量大，团队要求高。

路线三：Pi 自研

完全自研 Agent 运行时（基于Pi 的架构）。多用户天然支持，但所有功能都要自己建。

我们的选择：OpenClaw + mem0

理由很简单——客户要的是快速验证，不是完美架构。OpenClaw + mem0 能最快上线，验证产品价值后再决定要不要重构。

但选这条路不代表没有问题。多个用户跑在同一个 Gateway 里，我们在调研中发现了三个关键问题。

第一个问题：多用户共享时，agent 是不是足够的安全边界？

多用户共享一个 OpenClaw Gateway，第一个要确认的是：agent 能不能当作安全边界？

一开始我们的假设很简单：

> 一个用户 = 一个 Agent = 一个独立的数据分区。

用户 A 用 agent:user-a，用户 B 用 agent:user-b。他们各自的 session、workspace、memory 都存在不同目录，这不就天然隔离了吗？

但调研后发现，根本不是这么回事。

OpenClaw 的隔离是”软隔离”。默认配置下，一个 agent 调用 sessions_list，是能扫到其他 agent 会话的。如果 agentToAgent 还开着，A 甚至能给 B 发消息。

更关键的是 exec 工具。没开 sandbox 的话，agent 理论上可以执行：

cat /home/ubuntu/.openclaw/agents/user-b/sessions/...

直接读到别人的对话历史。

所以第一个发现：OpenClaw 的 agent 是数据分区，不是安全沙箱。必须额外加固。

我们梳理了必要的加固措施：

• tools.sessions.visibility: self
  
   —— agent 只能看自己的会话
• tools.agentToAgent.enabled: false
  
   —— 禁止跨 agent 发消息
• tools.fs.workspaceOnly: true
  
   —— 文件工具只能操作自己 workspace
• agents.defaults.sandbox.mode: all
  
   —— exec 严格限定在 workspace 里

加固后，隔离性大幅提升。但也要清醒认知：大家都在同一个 Gateway 进程里，日志、内存、全局状态还是共享的。如果要做完全互不信任的 SaaS 多用户，后面还得换方案。

第二个问题：多用户场景下，长期记忆和Session 怎么迁移？

第二个问题跟记忆有关。

多用户共享一套系统，每个用户的记忆怎么管理？长期记忆和短期上下文要不要分开处理？

我们评估了 mem0 做长期记忆。mem0 的好处很明显：记忆存在云端，不绑定机器，换实例也能召回。

于是团队里有人提出：

> “反正 mem0 能记住用户，那 session 迁不迁移也无所谓吧？”

但深入分析后，发现这个逻辑有问题。

mem0 存的是”知识”，session 存的是”上下文”。

如果你是问答系统，每次问完就结束，那确实可以不要 session 迁移。每次新建 session，靠 mem0 回忆用户是谁就行。

但如果你是助手系统，用户说”接着刚才的说”，agent 必须知道”刚才”讲到哪了。这种东西 mem0 不会存，也存不了。

所以第二个发现：产品形态决定架构。问答靠 memory，助手必须保留 session。

我们的方案是两种模式都支持：

• Stateless
  
  ：每次新 session，适合问答场景
• Stateful
  
  ：客户端传 sessionKey，加载历史，适合助手场景

OpenClaw 的 /v1/chat/completions 支持 x-openclaw-session-key header，技术上没问题。但 Stateful 模式下，session 文件还在本地机器上，迁移问题并没有彻底解决。

所以 mem0 解决的是长期记忆的迁移，不是 session 的迁移。

第三个问题：多用户怎么分配到不同 Gateway 实例？

第三个问题最隐蔽。

用户多了，Gateway 怎么扩展？能不能像普通微服务一样加机器就行？

我们一开始的想法是：OpenClaw Gateway 前面加一个负载均衡，后面跑多个实例，用户请求轮询分发，不就水平扩展了吗？

但调研后发现不行。

OpenClaw Gateway 是有状态服务。它内部维护了一大堆进程内状态：

• WebSocket 客户端连接
• Session 订阅关系
• Agent 运行状态
• Chat abort 控制器

如果用户第一次连到实例 A，下一次请求被负载均衡打到实例 B，状态就完全对不上了。

所以第三个发现：OpenClaw Gateway 不能当普通微服务做无状态扩展。

我们的方案是：

• 按用户分片：每 N 个用户跑一个 OpenClaw Gateway 实例，实例之间不共享连接

这样扩展性是有的，但不是完全弹性的。每个实例都是个”小岛”。

我们当前的架构方案

综合调研结果，我们目前的架构方案是这样的：

前端 web/app    ↓业务 API Gateway（自研）    ├── 用户认证    ├── userId → (openclawHost, agentId) 路由    └── 业务语义封装    ↓OpenClaw Gateway 实例（按用户分片）    ├── 一个用户一个 agent    ├── session / workspace 本地    └── 长期记忆 → mem0 Platform    ↓mem0 Platform

这个架构不是最完美的，但是当前最合适的：

• 快
  
  ：复用 OpenClaw 完整能力，不用自研 Agent 引擎
• 可验证
  
  ：能支撑 MVP 快速上线
• 可演进
  
  ：产品验证后，可以按用户分片继续扩展，也可以逐步迁移到更自研的架构

三点建议

如果你也在调研类似的需求，三个建议：

1. 别把 agent 当成安全边界

Agent 是数据分区，不是沙箱。多用户场景下，必须加固 session visibility、agentToAgent、exec sandbox、文件工具限制。

2. 先定产品形态，再定架构

问答系统和助手系统对 session 的要求完全不同。产品形态不确定前，别过度设计 session 迁移。

3. 接受 Gateway 的有状态现实

别幻想 OpenClaw Gateway 像普通微服务一样无状态扩展。要么做 sticky session，要么按用户分片。

写在最后

OpenClaw 是个很好的单用户 多Agent 平台，但多用户不是它的原生设计。

“一个用户一个 Agent”是个巧妙的折中方案，能解决大部分问题，但也要有清醒认知：

> 它是软隔离，适合信任基础较好的多用户场景；如果要做完全不可信用户之间的强隔离，最终还是要走自研 Agent 运行时那条路。

目前方案还在验证阶段。我们整理了三种技术路线对比、安全加固清单、实施路线图。如果你也在做类似的事，欢迎交流。