从 OpenClaw 到 FastClaw：如何设计优秀的多 Agent 架构

做了一年 Agent 基础设施，踩了无数坑，我终于想明白了一件事：好的 Agent 架构不是把所有功能塞进一个进程，而是让每一层都能独立演化。

前言

2026 年初，OpenClaw 爆火 —— 一个自托管的 AI 助理。它本质是一个跑在你自己机器上的 Agent 网关（Gateway），通过 Telegram、Discord、Slack、飞书等你已经在用的聊天软件接入，能真正替你干活：收发邮件、管日程、浏览器自动化、执行命令。

OpenClaw 支持多端接入、记忆系统、技能市场（ClawHub）、多 Agent 协作，甚至 A2A（Agent-to-Agent）——功能很全。

为了用上 OpenClaw，我买了台 Mac Mini，日常通过手机发指令，做了很多项目，效率很高。

为了让其他人也用上 OpenClaw，我做了个托管服务，帮 500 多个用户部署了专属的龙虾，跑在云端的一套 K8S 集群上。

在自用和做托管服务的过程中，我对 OpenClaw 的架构设计越来越了解，也发现了很多问题。为了解决这些问题，我认为必须从底层架构全新设计，而不是在 OpenClaw 的基础上魔改。

我决定做一个更好的 Agent 框架：FastClaw，面向云原生多租户场景设计，更快、更轻量、更好用。

这篇文章记录了我对 OpenClaw 架构的理解，以及我对 FastClaw 架构设计的经验总结。

一、OpenClaw 做对了什么

OpenClaw 虽然有不少问题，但它在产品方向上的探索是超前的。回头看，有几个创新点是真正有价值的。

1. 多端接入：随时随地和 Agent 交互

OpenClaw 支持极广的 IM 接入——Telegram、Discord、Slack、WhatsApp、Signal、iMessage、飞书、Matrix、Microsoft Teams 等，外加 Web Chat 和 CLI。用户可以在任何地方和自己的 Agent 对话。

这个设计的核心洞察是：Agent 不应该被困在一个 App 里。你写代码的时候用终端，开会的时候用飞书，摸鱼的时候用 Telegram——Agent 应该无处不在。

2. SOUL 机制：让 Agent 有“人味“

OpenClaw 引入了 SOUL.md 的概念——一个定义 Agent 人格、语气、价值观的配置文件。不是冷冰冰的 system prompt，而是一份精心调教的“灵魂“。

这带来了两个意想不到的好处：

• 用户粘性暴涨：当 Agent 有了固定人设，用户会产生情感连接，留存率比纯工具型 Agent 高几倍

• Agent 可复制：同一套 SOUL 文件可以给不同模型用，换模型不换人设

3. 记忆检索：越用越懂你

OpenClaw 的记忆系统分两层：

• 长期摘要：MEMORY.md，一份精简的长期记忆摘要，作为 project context 注入提示词

• 每日明细：memory/.md 每日文件，平时不进上下文，靠 memory_search / memory_get 工具按需检索，不占 token

配合 SOUL.md（人设）、USER.md（用户信息）等文件，Agent 可以记住你的偏好、习惯、常用工具，真正做到“越用越懂你“。

4. 主动通知：从被动响应到主动服务

传统 Agent 是“你问我答“。OpenClaw 加了 Cron Job 和心跳机制后，Agent 可以：

• 每天早上 8 点给你发天气和日程提醒

• 监控 GitHub PR 状态，有更新自动通知

• 定期检查博客评论，筛选有价值的反馈

这是 Agent 从工具进化为助理的关键一步。

5. 对话式安装：养成式体验

OpenClaw 的 Skill 安装不是“去应用商店下载“，而是在对话中直接说“帮我装一个翻译技能“，Agent 自己去搜索、安装、配置。

这种对话即操作的范式降低了使用门槛，也让 Agent 有了一种“养成“的感觉——你在训练它、给它装新技能。

6. 多 Agent 协作：团队模式

OpenClaw 支持同时运行多个 Agent，每个 Agent 有不同的专长：

• 一个负责写代码

• 一个负责写文档

• 一个负责 Code Review

• 一个负责部署上线

这些 Agent 在单个 Gateway 进程内相互隔离运行，每个有独立的 workspace、状态目录（agentDir）和会话历史，通过 multi-agent routing 把消息分发给对应的 Agent。

二、OpenClaw 的架构

OpenClaw 采用的是 Node.js 单体架构，核心组件包括：

配置方式：一个 ~/.openclaw/openclaw.json 文件管所有——LLM Provider、Channel Token、Plugin 配置、Skill 列表、默认参数……全在一个 JSON 里。

存储方式：文件系统为主，Session 存 JSON 文件，Memory 存 Markdown，Skills 存目录。

运行方式：openclaw start 启动一个 Node.js 进程，Gateway 挂载所有 Channel 和 Plugin，一荣俱荣一损俱损。

三、OpenClaw 的不足

作为一个个人助理工具，OpenClaw 是够用的。但作为一个要服务多人的生产级 Agent 平台，它有致命缺陷。

1. 缺少平台级多租户：隔离粒度太粗

OpenClaw 的隔离是围绕“Agent“设计的——Session、Memory 都按 agent / workspace 隔离，但没有“用户（account）“这层抽象。要真正隔离，得“一人一 Agent”。

也就是说，同一个 Agent 没法安全地服务多个互不信任的用户——做托管只能给每人单开一套，成本高、浪费大。缺的不是会话隔离，而是平台级多租户。

2. Gateway 是单点故障

所有 Channel、所有 Plugin、所有 Agent 的运行时都挂在同一个 Node.js 进程里。一个 Plugin 内存泄漏，整个 Gateway 崩溃；一个 Channel 的 API 超时，所有 Channel 都卡住。

没有隔离，就没有可靠性。

3. 默认上下文偏重，Token 容易失控

OpenClaw 每轮都会把一组 bootstrap 文件——SOUL.md、MEMORY.md、AGENTS.md、工具说明——注入提示词。文件一多、对话一长，system prompt 越堆越大。

它也做了优化（memory/.md 按需检索、cron 用隔离 session 把每轮压到 ~2-5K token），但默认配置对 token 不够敏感，bootstrap 写得啰嗦，账单就很可观。钱烧得心疼。

4. 资源占用大

Node.js + 一堆 npm 依赖 + 文件系统 I/O，idle 状态就吃 500MB+ 内存。加上 Sandbox（Docker 容器），一台 4GB 的小机器跑得喘不过气。

5. 云原生不友好

• 配置和状态都落在本地文件系统（~/.openclaw/），多 Pod 之间没法共享同一份配置和会话，天然单机

• 存储是文件系统，没法水平扩展

• 部署形态是“一个有状态进程“，缩容、迁移、滚动更新都得小心翼翼地保住本地数据

6. 臃肿的 npm 依赖树

node_modules 有 800MB+，构建时间 3 分钟+。每次更新依赖都像开盲盒——不知道哪个包会炸。

7. Web UI 体验差

OpenClaw 的 Control UI 和 CLI 其实共享同一份 ~/.openclaw/openclaw.json（都走 config.get / config.set / config.apply，还有 base-hash guard 防并发覆盖），配置层面是一致的——这点没问题。

问题在体验：Web UI 界面粗糙，配置项藏得深，想在网页上完整跑通一次 Agent 配置并不顺手。对一个想拿出去给用户用的产品来说，“能用但不想用“就是劝退。

8. 安全模型只为“单机单操作者“设计

OpenClaw 的安全边界是“信任操作者本人“，不是“在不可信用户之间做隔离“。默认值都是按这个前提来的：

• 宿主机执行默认全开：exec 默认 full + 免审批、沙盒默认关闭，Agent 能直接在宿主机跑任意命令、读写文件——文档也承认这是“单操作者场景的有意 UX“

• Prompt injection 未解决：system prompt 只是软提示，一条恶意消息就可能让 Agent dump 文件、跑命令

• 密钥明文、Session 不加密、Plugin 主进程内运行、无 per-user RBAC

自己单机用足够安全；但要做成多人平台，exec 沙盒、密钥加密、租户级 RBAC、注入防护，每一层都得从头补。

四、如何设计更好的 Agent 框架

FastClaw 的设计原则很明确：轻量、快速、云原生。

1. 云原生优先

• 没有本地配置文件：Bootstrap 参数全部走环境变量，运行时配置通过 Dashboard 或 CLI 写入数据库

• SQLite → Postgres：FASTCLAW_STORAGE_DSN 一个环境变量切换存储后端，本地用 SQLite，生产切 Postgres

• S3 对象存储：FASTCLAW_OBJECT_STORE_* 环境变量接入 S3，多 Pod 共享 Skills 和文件

2. 多租户与 RBAC

OpenClaw 是“一个人的工具“，FastClaw 是“一群人的 Agent 平台“。

四层配置继承：

内层配置自动覆盖外层，同名 Provider 配置整条替换。这意味着：

• 管理员配一个默认的 OpenAI Key，所有用户直接用

• 某个用户想用自己的 Key，覆盖一层就行

• 某个 Agent 需要特定模型，再覆盖一层

• 互不干扰，天然多租户

3. 会话隔离

每个 Session 的 key 是 (user_id, agent_id, channel_type, chat_id) 四元组。同一个 Agent 被 100 个用户使用，每人看到的都是自己的记忆和历史。

X-Fastclaw-End-User Header 让 SaaS 层可以透传终端用户身份，FastClaw 自动为每个 (api_key, external_id) 对创建隔离的内部用户。零代码改造，接入即多租户。

4. 高并发

Go 的 goroutine 天然适合高并发场景。FastClaw 的 Session Manager 可以同时处理数千个会话而不会互相阻塞。

关键设计：Session 是无状态的，状态在数据库里。 每次请求从 DB 加载上下文，处理完写回。这意味着：

• 任意一个 Pod 可以处理任意一个请求

• 水平扩展只需加 Pod

• 单个 Pod 挂了不影响其他会话

5. 单二进制分发

没有 node_modules，没有运行时依赖，没有构建步骤。下载、chmod、运行，三步搞定。

6. 内存占用低

对比 OpenClaw（Node.js）和 FastClaw（Go）的 idle 内存占用：

Go 编译为原生机器码，没有 GC 停顿，没有 JIT 预热。同样的硬件，能扛 10 倍流量。

7. 插件隔离

OpenClaw 的 Plugin 跑在主进程里，一个 Plugin 崩了整个 Gateway 挂。

FastClaw 的 Plugin 通过 JSON-RPC 子进程 隔离运行：

• Plugin 崩溃不影响 Gateway，自动重启子进程

• Plugin 没有文件系统访问权限（除非显式授权）

• 还提供了 openclaw-plugin-bridge，可以兼容 OpenClaw 的 TypeScript Plugin 生态

8. 工具 Provider 的 Fallback 机制

FastClaw 对外部工具（Web Search、Image Gen、TTS 等）设计了统一的 Provider + Fallback Chain 架构。

比如 Web Search 配置了 Tavily 为主、SerpAPI 为备，Tavily 限流了自动切 SerpAPI，用户无感知。

五、FastClaw 的架构设计

整体架构

1. 存算分离

FastClaw 最核心的架构决策是存算分离：

计算层（Gateway）：

• 无状态，可以水平扩展

• 处理 LLM 调用、工具执行、Session 管理

• 任意 Pod 可以处理任意请求

存储层（Database + Object Store）：

• SQLite（单机）或 Postgres（集群）

• S3 存储 Skills、Agent 文件等二进制数据

• 数据库是唯一真相源

这意味着：

• 数据持久化不依赖进程生命周期

• 可以随时换存储后端（SQLite → Postgres 一行配置）

• 多 Pod 共享同一个数据库，天然支持水平扩展

2. 基于 Scope 的配置继承

FastClaw 基于 Scope 实现配置的链式继承

这带来了极高的灵活性：

• 管理员设置全局默认模型为 gpt-5，所有新用户直接能用

• 用户 A 偏好 claude-opus，覆盖一层

• 用户 A 的“写作助手“Agent 需要 claude-fable5，再覆盖一层

• 不需要代码变更，不需要重启，不需要额外配置文件

3. Fallback 容错

FastClaw 对所有外部依赖都做了 Fallback：

LLM Provider Fallback：

Tool Provider Fallback：

Sandbox Fallback：

每一层 Fallback 对上层透明，LLM 不知道具体用的是哪个 Provider，用户也不需要关心。

六、FastClaw 的定位与使用场景

FastClaw 不只是一个“更好的 OpenClaw“。它有四个递进的定位：

1. Assistant：更好的个人助理

你可以在电脑上一行命令安装 FastClaw👇

curl -fsSL https://raw.githubusercontent.com/fastclaw-ai/fastclaw/main/install.sh | bash

可视化配置 FastClaw，替代 OpenClaw，Hermes Agent 日常使用。

可接入常用的 IM 软件：

适合：个人用的 AI 助手、Telegram Bot、Discord Bot、飞书机器人、微信 ClawBot。

2. Factory：Agent 制造工厂

你可以在 cloud.fastclaw.ai 云平台创建自己的 Agent

自定义 Agent 的 SOUL、技能、模型。

适合：Skills 创作者、提示词工程师，创建个性化 Agent，自用或分享给朋友使用。

3. Runtime：Agent 运行时

你可以把 FastClaw 作为 Agent Runtime，导出 API 给其他 Agent 产品使用。

比如 weclaw.im 就是把 FastClaw 作为 Backend 的一个 Agent 应用，只做前端交互，一小时上线。

适合：想快速开发 Agent 产品的开发者，无需实现 Agent Loop、Sandbox 等运行时逻辑。

4. Platform：Agent 协作平台

可以把 FastClaw 作为团队版的 OpenClaw，搭建 Agent 协作平台。团队共享知识库、Skills。

适合：需要私有化部署 Agent 平台的企业。只需一台内网服务器，快速部署，无限多开 Agent。

七、多 Agent 框架设计经验总结

在做 FastClaw 的过程中，我总结了几条经验。

1. 先做单租户，但架构要预留多租户

OpenClaw 一开始就做单租户，后来想加多租户发现要改的东西太多，几乎等于重写。FastClaw 从第一行代码就设计了 (user_id, agent_id) 的隔离模型，即使一开始只有一个人用，后续扩展也不需要改架构。

多租户不是功能，是架构决策。越早做越省事。

2. 存储决定一切

OpenClaw 用文件系统存数据，简单直接。但当你要做多实例部署、水平扩展、数据备份时，文件系统就是噩梦。

FastClaw 用数据库作为唯一真相源（SQLite 本地开发，Postgres 生产），文件系统只存 Skills 目录（可以通过 S3 共享）。

永远用数据库存状态。文件系统只存“内容“（代码、文档、配置文件），不存“状态“（Session、用户、权限）。

3. 隔离是可靠性的前提

OpenClaw 所有功能跑在一个进程里，一个组件出问题全盘崩溃。FastClaw 用子进程隔离 Plugin，用 Docker/E2B 隔离代码执行，用数据库事务隔离并发写入。

如果两个组件的故障域不同，就不要让它们共享进程。

4. Fallback 不是可选项，是必需品

LLM API 会限流、会宕机、会涨价。Web Search API 会超时。Image Gen 会排队。如果你的 Agent 在任何一个外部依赖挂掉时就完全不能用，那你的 Agent 就是玩具。

FastClaw 的每个 Tool Category 都有 Fallback Chain，主 Provider 挂了自动切备用，用户无感知。

生产级 Agent 必须对所有外部依赖做 Fallback。没有例外。

5. Token 是钱，上下文是金

OpenClaw 把所有上下文一股脑塞进每次请求，token 消耗居高不下。后来我学到：

• SOUL 文件要精简：500 token 以内够了，不需要把整本说明书塞进去

• Memory 按需检索：不要全量注入，用 embedding 检索相关记忆

• Session 要摘要：长对话定期压缩，保留关键信息丢弃冗余

• Tools 说明要分层：常用工具详细说明，不常用的只放名字

上下文管理是 Agent 的核心竞争力。会省 token 的 Agent 才能活下去。

结语

从 OpenClaw 到 FastClaw，本质上是从“做一个很酷的开源项目“到“做一个能跑在生产环境的平台“的思维转变。

OpenClaw 验证了方向——多端接入、SOUL 机制、记忆系统、多 Agent 协作，这些都是对的。

FastClaw 解决了工程问题——单租户、单点故障、资源浪费、不可扩展，这些都是要修的。

好的架构不是设计出来的，是迭代出来的。在迭代之前想清楚存算分离、多租户隔离、Fallback 容错这三件事，你会省下很多时间。

如果你也在做 Agent 基础设施，希望这篇文章能帮你少走一些弯路。

欢迎体验 fastclaw.ai，免费开源。

https://github.com/fastclaw-ai/fastclaw

欢迎 fork，感谢 star。