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

前言

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

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

为了体验OpenClaw，买了一台Mac Mini，日常通过手机发指令做项目，效率确实提升了不少。

后来为了让更多人用上，还做了个托管服务，帮500多个用户部署了专属的“龙虾”，跑在云端的一套K8S集群上。

自用和做托管的过程中，对OpenClaw的架构设计越来越熟悉，也发现了不少问题。要解决这些，必须从底层架构全新设计，而不是在OpenClaw的基础上打补丁。

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

这篇文章记录了对OpenClaw架构的理解，以及FastClaw架构设计中的经验总结——希望对同样在做Agent基础设施的朋友有帮助。

一、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. 云原生优先

# 一行命令安装，单二进制文件
curl -fsSL https://raw.githubusercontent.com/fastclaw-ai/fastclaw/main/install.sh | bash
# 零配置启动（纯环境变量）
FASTCLAW_PORT=18953 fastclaw
# K8s 部署就是一个 Deployment + Secret

• 没有本地配置文件：Bootstrap参数全部走环境变量，运行时配置通过Dashboard或CLI写入数据库
• SQLite → Postgres：FASTCLAW_STORAGE_DSN 一个环境变量切换存储后端，本地用SQLite，生产切Postgres
• S3对象存储：FASTCLAW_OBJECT_STORE_* 环境变量接入S3，多Pod共享Skills和文件

2. 多租户与RBAC

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

用户模型：
├── super_admin — 平台管理员，全权限
├── user — 普通用户，管理自己的Agent
├── app_user — 应用端用户（通过API懒创建）
└── channel_user — IM渠道用户（Telegram/Discord登录）

四层配置继承：

system (全局默认)
→ user (用户级覆盖)
→ agent (Agent级覆盖)
→ (user, agent) (特定用户对特定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. 单二进制分发

# 编译产物就是一个二进制文件，约30MB
make build
ls -lh bin/fastclaw
# -rwxr-xr-x  1 user  staff   30M  fastclaw
# 交叉编译
make release-local
# → dist/fastclaw-darwin-amd64
# → dist/fastclaw-linux-amd64
# → dist/fastclaw-windows-amd64.exe

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

6. 内存占用低

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

场景	OpenClaw	FastClaw
Idle（空载）	~500MB	~30MB
1个活跃会话	~600MB	~50MB
10个并发会话	~1.2GB	~80MB
100个并发会话	OOM	~200MB

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

7. 插件隔离

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

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

FastClaw Gateway ←→ JSON-RPC (stdin/stdout) ←→ Plugin Process

• Plugin崩溃不影响Gateway，自动重启子进程
• Plugin没有文件系统访问权限（除非显式授权）
• 还提供了 openclaw-plugin-bridge，可以兼容OpenClaw的TypeScript Plugin生态

8. 工具Provider的Fallback机制

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

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

五、FastClaw 的架构设计

整体架构

┌──────────────────────────────────────────────────────┐
│                  FastClaw Gateway (Go)               │
│                                                      │
│  ┌──────────────────────────────────────────────┐   │
│  │              HTTP API Layer                    │   │
│  │   /v1/chat/completions (OpenAI 兼容)          │   │
│  │   /api/chat/stream (SSE 流式)                 │   │
│  │   /api/agents (Agent CRUD)                    │   │
│  │   /api/config (Provider 管理)                 │   │
│  │   /api/skills/install (Skill 安装)            │   │
│  │   /api/apikeys (API Key 管理)                 │   │
│  └───────────────────┬──────────────────────────┘   │
│                      │                               │
│  ┌───────────────────▼──────────────────────────┐   │
│  │           Scope Resolution                    │   │
│  │  system → user → agent → (user, agent)       │   │
│  │  四层继承，内层覆盖外层                       │   │
│  └───────────────────┬──────────────────────────┘   │
│                      │                               │
│  ┌───────────────────▼──────────────────────────┐   │
│  │              Agent Runtime                    │   │
│  │  ┌────────┐  ┌────────┐  ┌────────────────┐  │   │
│  │  │Session │  │ Memory │  │Tool Providers  │  │   │
│  │  │Manager │  │(MD+DB) │  │(Fallback Chain)│  │   │
│  │  └────────┘  └────────┘  └────────────────┘  │   │
│  │  ┌────────┐  ┌────────┐  ┌────────────────┐  │   │
│  │  │ Skills │  │ Sandbox │  │ Plugin System  │  │   │
│  │  │ Loader │  │(Docker │  │(JSON-RPC子进程)│  │   │
│  │  │        │  │ /E2B)  │  │                │  │   │
│  │  └────────┘  └────────┘  └────────────────┘  │   │
│  └──────────────────────────────────────────────┘   │
│                                                      │
│  ┌───────────────────▼──────────────────────────┐   │
│  │              Channel Layer                    │   │
│  │  Telegram │ Discord │ Slack │ Feishu │ Web   │   │
│  └──────────────────────────────────────────────┘   │
└──────────────────────┬───────────────────────────────┘
                       │
            ┌──────────┼──────────┐
            ▼          ▼          ▼
        ┌─────────┐ ┌──────────┐ ┌──────────┐
        │ SQLite  │ │ Postgres │ │   S3     │
        │ (本地)  │ │ (生产)   │ │ (对象存储)│
        └─────────┘ └──────────┘ └──────────┘

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：

主模型 (claude-sonnet) → 备用模型 (gpt-4o) → 最后防线 (本地 ollama)

Tool Provider Fallback：

Web Search: Ta vily → SerpAPI → 直接抓取
Image Gen: Replicate → 本地 SD
TTS: ElevenLabs → Fish Audio

Sandbox Fallback：

Docker (本地) → E2B (云端) → 无沙盒模式 (受限)

每一层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基础设施，希望这篇文章能帮你少走一些弯路。