夜雨聆风
多 Agent 架构的成人礼:从 OpenClaw 到 FastClaw→我看到的不是升级,而是架构换代
最近看到一篇关于 OpenClaw 和 FastClaw 的技术梳理。
表面看，它在讲两个 Agent 项目的差异；但更值得拿出来讲的，其实是一个更普遍的问题：
这不是功能列表的升级，而是工程思维的升级。
一、个人助理和平台运行时，不是同一种系统
个人版 Agent 很像“一个医生自己电脑里的小助手”：能帮我查资料、写代码、跑命令、记住偏好，就已经很有用。
但如果要把它托管给很多人使用，它就更像“全院信息系统”：必须考虑账号隔离、权限、审计、稳定性、扩容、容灾。
所以 OpenClaw 到 FastClaw 的核心问题不是：
•哪个功能更多；
•哪个看起来更酷；
•哪个模型回答更聪明。
真正的问题是：
•多用户的数据能不能隔离？
•一个插件崩了会不会拖垮整个系统？
•状态是不是绑死在本地文件系统？
•API 限流、搜索超时、沙盒失败时有没有 fallback？
•Token 和上下文是不是有预算，而不是每轮都把所有东西塞进去？
这些问题一旦从个人使用进入平台场景，就会变成基础设施问题。
二、OpenClaw 做对了什么？
先不要急着否定 OpenClaw。
它先验证了一组很重要的产品方向：Agent 不应该只待在一个 App 里，而应该出现在用户已经工作的地方。
OpenClaw 的价值在于：
•支持多端接入，比如 Telegram、Discord、Slack、飞书、CLI、Web Chat；
•用 SOUL.md 固定 Agent 的人格、语气和工作方式；
•用长期记忆和按需检索，让 Agent 不必每次从零开始；
•用 Cron Job 和心跳机制，让 Agent 从“问答工具”变成“会主动提醒的助理”；
•支持多个专长 Agent 协作，比如写代码、写文档、Code Review、部署。
这些都是个人 AI 助理非常关键的产品验证。
但问题也埋在这里：当 Channel、Plugin、Agent Runtime、Memory、Session 都挂在一个 Gateway 进程里时，个人使用很方便，平台托管就会变得脆弱。
三、为什么单体 Agent 不适合直接变成平台？
个人使用时，单体架构有很多优点：
•部署简单；
•调试直接；
•文件都在本机；
•用户就是操作者本人；
•安全边界相对清楚。
但多人托管后，问题会同时出现：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
一句话：
这不是 OpenClaw “不好”，而是它验证的是另一个阶段的问题。
四、FastClaw 想解决什么？
FastClaw 的目标，是把 Agent 变成更轻、更快、更适合云原生部署的运行时。
它重点引入了几个平台化设计。
第一，多租户和 RBAC。
系统不再只问“哪个 Agent 在运行”，还要问：
•谁创建了 Agent；
•谁能调用 Agent；
•谁能使用哪个模型；
•谁能读写哪些记忆；
•谁能执行哪些工具。
第二，配置和状态不再绑在本机。
本地开发可以用 SQLite，生产环境应把用户、Session、Memory、配置、技能包等状态放进数据库和对象存储。
这很像医疗信息系统：医生可以轮换，病历不能丢；Gateway 可以扩容，状态必须稳定保存。
第三，Gateway 尽量无状态。
无状态 Gateway 的好处是：
•任意 Pod 都可以处理任意请求；
•某个 Pod 挂了不丢数据；
•扩容就是增加 Pod；
•迁移和升级更安全。
第四，插件和核心运行时隔离。
插件是不可信、易变化、易出错的扩展点；Gateway 是核心运行时。两者不应该共享同一个故障域。
第五，Provider Fallback 变成默认设计。
生产级 Agent 必须默认假设：
•LLM API 会限流；
•搜索 API 会超时；
•图像生成会排队；
•沙盒服务会失败；
•外部服务价格和可用性会变化。
所以 fallback 不是锦上添花，而是可靠性的基础设施。
五、判断一个 Agent 框架是不是平台级，看这 8 件事
以后看到一个 Agent 框架，可以先问这 8 个问题。
1.有没有用户模型？
只有 agent_id 不够，至少要有 user/account 抽象。
2.Session key 怎么设计？
多用户、多渠道场景下，至少要考虑 user_id + agent_id + channel_type + chat_id。
3.状态放在哪里？
文件系统适合模板、静态资源、临时缓存；生产状态应该进数据库。
4.Gateway 是否无状态？
杀掉一个 Gateway Pod，新 Pod 能不能从数据库恢复 Session 和配置？
5.插件是否隔离？
插件崩溃、权限越界、依赖冲突，是否会影响核心运行时？
6.外部能力有没有 fallback？
LLM、搜索、图像、TTS/STT、沙盒、Embedding，都不应该只有一条路径。
7.Token 有没有预算？
长期记忆、工具说明、上下文摘要、检索结果，应该分层注入，而不是全部塞进 prompt。
8.权限和密钥如何管理？
RBAC、密钥加密、租户隔离、工具审批，是平台级 Agent 的底线能力。
这 8 个问题回答不清楚，就还不是生产级多 Agent 架构。
六、最小改造路线：从单体 Agent 走向平台型 Agent
如果你手里有一个单体 Agent 项目，最小改造不要一上来做复杂控制台。
更合理的顺序是：
1.重新定义 Session key；
2.把状态从文件系统迁到数据库；
3.把 Gateway 做成无状态；
4.给插件和代码执行加隔离；
5.给每个外部能力配置 fallback chain。
这里有一个可以直接交给 Codex 的检查提示词：
重点检查：
1.是否有平台级多租户模型，而不是只有 Agent 级隔离；
2.Session key 是否至少包含 user_id、agent_id、channel_type、chat_id；
3.状态是否进入数据库，文件系统是否只保存内容或缓存；
4.Gateway 是否无状态，能否水平扩展；
5.Plugin / Tool / Code Execution 是否和主进程隔离；
6.LLM、搜索、图像、沙盒等外部依赖是否有 Fallback Chain；
7.Token 是否有预算、摘要、按需检索和工具说明分层；
8.权限是否有 RBAC，密钥是否加密，租户之间是否隔离；
9.是否存在为了“以后可能需要”而过度设计的模块，如有请按 YAGNI 删除；
10.输出结果请分为：现状证据、风险等级、最小改造方案、需要用户确认的高风险操作。
原则：KISS、YAGNI、DRY、SOLID。先读后写，不要默认提交 git，不要删除文件，不要批量改动。
七、几个容易误解的地方
第一个误解：多 Agent 就等于多租户。
不是。
多 Agent 解决的是“不同助理分工”；多租户解决的是“不同用户隔离”。
你可以有 coder、reviewer、writer 三个 Agent，但如果它们都在同一个账号、同一个文件系统、同一个权限域里运行，那仍然不是平台级多租户。
第二个误解：文件系统简单，所以更可靠。
个人使用时，文件系统确实简单。
但平台场景下，文件系统会让状态和机器绑定。多实例、迁移、容灾、审计都会变难。
第三个误解：fallback 会让系统复杂，所以以后再加。
如果系统已经进入生产，fallback 不是可选优化，而是可靠性设计的一部分。
第四个误解：Token 优化只是省钱。
Token 优化当然能省钱，但更重要的是注意力管理。Agent 长期运行时，如果每轮都背着过量上下文，它会变慢、变贵，也更容易抓错重点。
最后
OpenClaw 证明了 Agent 助理应该“无处不在、有人味、能记住你、能主动做事”。
FastClaw 进一步提醒我们：如果要让 Agent 服务很多人，就必须从第一天开始考虑多租户、存算分离、故障隔离、fallback 和 Token 预算。
这不是功能升级，而是从个人工具到生产平台的工程思维升级。
来源与边界：
•本文基于本地技术笔记《从 OpenClaw 到 FastClaw：多 Agent 架构分层解读与实践指南》改写。
•公开来源核验包括 FastClaw GitHub/官网、OpenClaw GitHub/官网，以及作者 @idoubicc 的公开帖摘要。
•文中“判断表”和“改造路线”是面向开发者的架构学习建议，不构成特定项目的官方评测或生产部署承诺。
•医疗安全边界：本文不涉及患者资料，不替代临床诊断、治疗或用药决策；文中的医院系统类比只用于解释工程架构。