做了一年 Agent 基础设施，踩了无数坑，我终于想明白了一件事：好的 Agent 架构不是把所有功能塞进一个进程，而是让每一层都能独立演化。
2026 年初，OpenClaw 爆火——一个自托管的 AI 助理。它本质是一个跑在你自己机器上的 Agent 网关（Gateway），通过 Telegram、Discord、Slack、飞书等聊天软件接入，能替你干活：收发邮件、管日程、浏览器自动化、执行命令。
OpenClaw 支持多端接入、记忆系统、技能市场（ClawHub）、多 Agent 协作，甚至 A2A（Agent-to-Agent）。为了让 500 多个用户用上 OpenClaw，我做了个托管服务，跑在云端 K8S 集群上。
在自用和做托管服务的过程中，我对 OpenClaw 的架构越来越了解，也发现了很多问题。为了解决这些问题，必须从底层架构全新设计，而不是在 OpenClaw 上魔改。
我决定做一个更好的 Agent 框架：FastClaw，面向云原生多租户场景设计，更快、更轻量、更好用。
这篇文章记录了我对 OpenClaw 架构的理解，以及我对 FastClaw 架构设计的经验总结。
一、OpenClaw 做对了什么
OpenClaw 虽然有不少问题，但它在产品方向上的探索是超前的。有几个创新点是真正有价值的。
1. 多端接入：随时随地和 Agent 交互
OpenClaw 支持极广的 IM 接入——Telegram、Discord、Slack、WhatsApp、Signal、飞书、Matrix、Teams 等，外加 Web Chat 和 CLI。核心洞察是：Agent 不应该被困在一个 App 里。你写代码的时候用终端，开会的时候用飞书，摸鱼的时候用 Telegram——Agent 应该无处不在。
2. SOUL 机制：让 Agent 有「人味」
OpenClaw 引入了 SOUL.md 的概念——一个定义 Agent 人格、语气、价值观的配置文件。这带来了两个好处：
- 用户粘性暴涨：当 Agent 有了固定人设，用户会产生情感连接，留存率比纯工具型 Agent 高几倍
- Agent 可复制：同一套 SOUL 文件可以给不同模型用，换模型不换人设
3. 记忆检索：越用越懂你
记忆系统分两层：
- 长期摘要：MEMORY.md，精简的长期记忆摘要，作为 project context 注入
- 每日明细：memory/*.md，平时不进上下文，靠工具按需检索，不占 token
配合 SOUL.md、USER.md，Agent 可以记住你的偏好、习惯，真正做到「越用越懂你」。
4. 主动通知：从被动响应到主动服务
加了 Cron Job 和心跳机制后，Agent 可以每天发天气和日程提醒、监控 GitHub PR 状态、定期检查博客评论。这是 Agent 从工具进化为助理的关键一步。
5. 对话式安装：养成式体验
Skill 安装不是「去应用商店下载」，而是在对话中直接说「帮我装一个翻译技能」，Agent 自己去搜索、安装、配置。
6. 多 Agent 协作：团队模式
支持同时运行多个 Agent，每个有独立的 workspace、状态目录和会话历史，通过 multi-agent routing 把消息分发给对应的 Agent。
二、OpenClaw 的架构
OpenClaw 采用的是 Node.js 单体架构：
配置方式：一个 openclaw.json 文件管所有——LLM Provider、Channel Token、Plugin 配置、Skill 列表。
存储方式：文件系统为主，Session 存 JSON 文件，Memory 存 Markdown。
运行方式：openclaw start 启动一个 Node.js 进程，Gateway 挂载所有 Channel 和 Plugin，一荣俱荣一损俱损。
三、OpenClaw 的不足
作为个人助理工具，OpenClaw 是够用的。但作为生产级 Agent 平台，它有致命缺陷。
1. 缺少平台级多租户：隔离粒度太粗
OpenClaw 的隔离是围绕「Agent」设计的，但没有「用户（account）」这层抽象。做托管只能给每人单开一套，成本高、浪费大。
2. Gateway 是单点故障
所有 Channel、所有 Plugin、所有 Agent 的运行时都挂在同一个 Node.js 进程里。一个 Plugin 内存泄漏，整个 Gateway 崩溃。
3. 默认上下文偏重，Token 容易失控
每轮都会把 SOUL.md、MEMORY.md、AGENTS.md、工具说明注入提示词。文件一多、对话一长，system prompt 越堆越大。
4. 资源占用大
Node.js + npm 依赖 + 文件系统 I/O，idle 状态就吃 500MB+ 内存。加上 Docker 沙盒，一台 4GB 的小机器跑得喘不过气。
5. 云原生不友好
- 配置和状态落在本地文件系统，多 Pod 之间没法共享
- 存储是文件系统，没法水平扩展
- 部署形态是「一个有状态进程」，缩容、迁移都得小心翼翼地保住本地数据
6. 安全模型只为「单机单操作者」设计
默认 exec 全开、沙盒关闭，Agent 能直接在宿主机跑任意命令。要做成多人平台，exec 沙盒、密钥加密、租户级 RBAC、注入防护，每一层都得从头补。
四、如何设计更好的 Agent 框架
FastClaw 的设计原则很明确：轻量、快速、云原生。
1. 云原生优先
- 没有本地配置文件：Bootstrap 参数走环境变量，运行时配置写入数据库
- SQLite → Postgres：一个环境变量切换存储后端，本地用 SQLite，生产切 Postgres
- S3 对象存储：多 Pod 共享 Skills 和文件
2. 多租户与 RBAC
OpenClaw 是「一个人的工具」，FastClaw 是「一群人的 Agent 平台」。
四层配置继承：system → user → agent → (user, agent)。内层覆盖外层，互不干扰，天然多租户。
3. 会话隔离
每个 Session 的 key 是 (user_id, agent_id, channel_type, chat_id) 四元组。同一个 Agent 被 100 个用户使用，每人看到的都是自己的记忆和历史。
4. 高并发
Go 的 goroutine 天然适合高并发场景。Session 是无状态的，状态在数据库里。每次请求从 DB 加载上下文，处理完写回。这意味着任意 Pod 可以处理任意请求，水平扩展只需加 Pod。
5. 单二进制分发
编译产物就是一个约 30MB 的二进制文件。没有 node_modules，没有运行时依赖。下载、chmod、运行，三步搞定。
6. 内存占用低
| 场景 | OpenClaw | FastClaw |
|---|---|---|
| Idle（空载） | ~500MB | ~30MB |
| 1 个活跃会话 | ~600MB | ~50MB |
| 100 个并发会话 | OOM | ~200MB |
Go 编译为原生机器码，没有 GC 停顿，没有 JIT 预热。同样的硬件，能扛 10 倍流量。
7. 插件隔离
FastClaw 的 Plugin 通过 JSON-RPC 子进程隔离运行。Plugin 崩溃不影响 Gateway，自动重启子进程。还提供了 openclaw-plugin-bridge 兼容 OpenClaw 的 TypeScript Plugin 生态。
8. 工具 Provider 的 Fallback 机制
Web Search 配置了 Tavily 为主、SerpAPI 为备，Tavily 限流了自动切 SerpAPI，用户无感知。
五、FastClaw 的架构设计
1. 存算分离
计算层（Gateway）：无状态，可以水平扩展，处理 LLM 调用、工具执行、Session 管理。
存储层（Database + Object Store）：SQLite（单机）或 Postgres（集群），S3 存储 Skills 和文件。
这意味着数据持久化不依赖进程生命周期，多 Pod 共享同一个数据库，天然支持水平扩展。
2. 基于 Scope 的配置继承
管理员设置全局默认模型，用户偏好覆盖一层，Agent 需要特定模型再覆盖一层。不需要代码变更，不需要重启。
3. Fallback 容错
LLM Provider Fallback：主模型 → 备用模型 → 最后防线（本地 ollama）
Tool Provider Fallback：Web Search: Tavily → SerpAPI，Image Gen: Replicate → 本地 SD
Sandbox Fallback：Docker（本地）→ E2B（云端）→ 无沙盒模式（受限）
六、FastClaw 的定位与使用场景
1. Assistant：更好的个人助理
一行命令安装，可视化配置，替代 OpenClaw 日常使用。
可接入常用的 IM 软件：
2. Factory：Agent 制造工厂
在云平台创建自己的 Agent，自定义 SOUL、技能、模型。
3. Runtime：Agent 运行时
把 FastClaw 作为 Agent Runtime，导出 API 给其他 Agent 产品使用。
比如 weclaw.im 就是把 FastClaw 作为 Backend 的一个 Agent 应用，只做前端交互，一小时上线。
4. Platform：Agent 协作平台
作为团队版的 OpenClaw，搭建 Agent 协作平台。团队共享知识库、Skills。
七、多 Agent 框架设计经验总结
1. 先做单租户，但架构要预留多租户
OpenClaw 一开始只做单租户，后来想加多租户发现要改的东西太多，几乎等于重写。多租户不是功能，是架构决策。越早做越省事。
2. 存储决定一切
永远用数据库存状态。文件系统只存「内容」（代码、文档、配置文件），不存「状态」（Session、用户、权限）。
3. 隔离是可靠性的前提
OpenClaw 所有功能跑在一个进程里，一个组件出问题全盘崩溃。如果两个组件的故障域不同，就不要让它们共享进程。
4. Fallback 不是可选项，是必需品
生产级 Agent 必须对所有外部依赖做 Fallback。没有例外。
5. Token 是钱，上下文是金
- SOUL 文件要精简：500 token 以内
- Memory 按需检索：不要全量注入
- Session 要摘要：长对话定期压缩
- Tools 说明要分层：常用工具详细说明，不常用的只放名字
上下文管理是 Agent 的核心竞争力。会省 token 的 Agent 才能活下去。
结语
从 OpenClaw 到 FastClaw，本质上是从「做一个很酷的开源项目」到「做一个能跑在生产环境的平台」的思维转变。
OpenClaw 验证了方向——多端接入、SOUL 机制、记忆系统、多 Agent 协作，这些都是对的。FastClaw 解决了工程问题——单租户、单点故障、资源浪费、不可扩展，这些都是要修的。
好的架构不是设计出来的，是迭代出来的。在迭代之前想清楚存算分离、多租户隔离、Fallback 容错这三件事，你会省下很多时间。
