Agent架构：从单体到多租户

来源：X @idoubicc

2026 年初，自托管 AI 助理 OpenClaw 走红 ^[0]，其 SOUL.md 架构形成的生态被描述为”病毒式成功”^[5]。素材作者从事 Agent 基础设施一年，为 500 多个用户提供托管，最终选择不修改 OpenClaw，而是从底层重写框架 FastClaw ^[0]。将这次演进理解为”Node.js 换成 Go”会遗漏关键：OpenClaw 的局限源于它默认”单机单操作者”信任模型——文档写明 Gateway 主机上 exec 默认安全级别为 full、审批提示默认关闭 ^[26]，沙盒默认不启用 ^[28,35]——FastClaw 的设计则围绕”在互不信任的用户之间隔离”这一目标展开 ^[0]。

五个被验证的产品方向

OpenClaw 在产品层面的探索被证明有效，素材总结了五个方向 ^[0]。

多端接入。OpenClaw 通过网关接入 Telegram、Discord、Slack、WhatsApp、Signal、iMessage、飞书、Matrix、Microsoft Teams 等 IM，以及 Web Chat 和 CLI ^[0]。渠道并非简单转发器：在 openclaw.json 中，Bindings 机制可以精确控制哪个渠道的消息流向哪个 Agent ^[66]，实现”飞书上是严谨的工作流助手、Telegram 上是毒舌树洞”的区分 ^[66]。

SOUL.md 人格机制。SOUL.md 用自然语言定义 Agent 的人格、语气与价值观，每次会话启动时自动加载 ^[3,13,9]。模板鼓励 Agent 自我修改：“This file is yours to evolve”^[9,3]。人设与底层模型解耦，同一份 SOUL 可配不同模型 ^[0]。素材声称这会带来”留存率比纯工具型 Agent 高几倍”^[0]，但公开讨论中无数据支撑该数字；讨论集中在两个实际问题：token 成本（每个 token 每次消息都会进上下文，建议控制在 400-500 token 以内 ^[4]）和攻击面（见下文）^[3]。

分层记忆。长期记忆收敛在 MEMORY.md，逐日明细存于 memory/YYYY-MM-DD.md ^[11,5,13]。社区常用 SOUL 模板要求每个会话先读 SOUL.md、USER.md 及当天和昨天的日记，主会话再读 MEMORY.md ^[11]；按 token 估算，读当天和昨天的日记各需 1500-3000 token ^[5]。素材主张将每日明细移出上下文，靠检索按需取用以节省 token ^[0]。workspace 中还有 IDENTITY.md（身份）、TOOLS.md（环境）、AGENTS.md（行为规则）、HEARTBEAT.md（定时任务清单）等文件 ^[7,13]。

主动通知与对话式安装。HEARTBEAT.md 是一份 cron 检查清单 ^[13]，配合定时任务使 Agent 从”你问我答”变为主动提醒 ^[0]。技能安装发生在对话中，例如说”帮我装个翻译技能”，Agent 会自行搜索、安装、配置 ^[0]。

多 Agent 协作。不同 Agent 拥有独立的记忆、灵魂文件与认证/模型绑定，互不混淆 ^[66,8]，解决单 Agent 模式下的上下文污染、人设混乱与 token 浪费 ^[70]。Agent 之间可通过 sessions_send 等内线机制协作 ^[66]。

单体进程、本地文件系统与”单操作者”默认值

OpenClaw 是 Node.js 应用 ^[40]，所有 Channel、Plugin、Agent 的运行时挂在同一个 Node.js 进程里 ^[0]。一个插件内存泄漏会拖垮整个 Gateway，一个渠道超时会卡住所有渠道 ^[0]。

配置与状态都保存在本地。~/.openclaw/openclaw.json 管理所有 Provider、渠道、插件与 Skill 配置 ^[30,0]；Session 存 JSONL，媒体与 cron 运行记录持续增长 ^[41]。素材指出，多 Pod 无法共享这份本地配置与会话，部署形态是”有状态进程”，缩容、迁移、滚动更新都得保留本地数据 ^[0]。

资源占用具体表现为：Gateway 进程空闲时占用 400-800MB ^[46]；openclaw-message 子命令在 4GB 服务器上可能占用 500MB+ 后 OOM（v2026.3.7 起的回归）^[38]；典型配置合计约 630MB ^[44]；多 Agent 加本地视觉模型时基线可达 4-8GB ^[47]。素材自测 node_modules 超过 800MB、构建需要 3 分钟 ^[0]，官方也以”预集成 Node.js 运行时与全部依赖”的整包形式分发 ^[43]。

隔离粒度以 Agent 为单位，而非用户。OpenClaw 的隔离（记忆、工作区、会话历史）围绕 Agent 设计 ^[66,8]，但没有”account”这层抽象。若要让两个互不信任的用户共享部署，只能”一人一 Agent”单独开实例，成本随用户数线性上涨 ^[0]。

安全默认值反映了信任模型。文档显示：Gateway 主机上 exec 默认安全级别为 full、审批提示默认 off ^[26]；沙盒默认关闭，只有显式配置 agents.defaults.sandbox 才启用 ^[28,35]；另有提升权限模式可在策略宽松时跳过审批 ^[27]。开箱即用的 OpenClaw 允许 Agent 在宿主机上执行任意命令，这在只有一人操作时是合理设计 ^[0,26]，但若多人平台，exec 沙盒、密钥加密、租户级 RBAC、注入防护每一层都需要补齐 ^[0]。

攻击面来自该信任模型：SOUL.md 每次会话自动加载，Agent 又有自我修改权限，攻击者可通过诱导 Agent 将恶意指令写入 SOUL.md，植入跨会话的持久后门 ^[3]。安全研究对公开网关的测试中，91% 的系统提示词与记忆文件可被成功提取 ^[3]；让 Agent 自行修改动态 system prompt 的模式被社区普遍认为存在注入风险 ^[10]；学界已开始对 OpenClaw 做系统化的黑盒攻防基准 ^[50]。

FastClaw：无状态与隔离优先的重构

FastClaw 是 Go 编写的轻量 Agent 运行时，单二进制、cloud-ready、内置沙盒与多 Agent 支持 ^[2]。安装脚本只做一件事：按平台下载一个二进制放入 ~/.local/bin ^[1]。每个 Agent 有自己的 SOUL.md、记忆、技能与工具，FastClaw 负责 LLM 通信、工具执行、沙盒隔离与会话管理 ^[2]；平台层管理 agents/models/skills/users/API keys，并支持按 Agent 裁剪模型、技能、渠道与调度器 ^[2]。仓库里还带一个 openclaw-plugin-bridge 目录，用于兼容 OpenClaw 的 TypeScript 插件生态 ^[2,0]。

存算分离：让状态离开进程。Gateway 无状态，任意 Pod 可处理任意请求；状态统一进数据库（本地 SQLite、生产 Postgres，一个环境变量切换），Skills 与文件进 S3 由多 Pod 共享 ^[0]。这直接回应了”配置和会话锁死在本地文件系统”的问题 ^[0]。

多租户从第一行代码开始。会话以 (user_id, agent_id, channel_type, chat_id) 四元组为 key，同一个 Agent 被 100 个用户使用时，各自看到自己的记忆与历史 ^[0]。配置按 Scope 四层继承、内层覆盖外层，管理员配置一个默认模型，用户可按需覆盖 ^[0]。X-Fastclaw-End-User 头让 SaaS 层透传终端用户身份，FastClaw 自动为每个 (api_key, external_id) 组合创建内部隔离用户 ^[0]。

插件与外部依赖的容错。插件改为以 JSON-RPC 子进程运行，崩溃不会拖垮 Gateway，可自动重启，默认没有文件系统访问权限 ^[0]。对外部依赖（LLM、Web Search、图片生成等）统一做 Provider + Fallback Chain：主 Provider 限流或宕机时自动切换备用 ^[0]。这种”失败自动转移”在 LLM 网关产品中已有标准做法：同一 API 调用内自动换 Provider 重试 ^[60]、按能力匹配 fallback 模型在主模型故障时接管 ^[61]、按置信度等信号决定是否升级模型 ^[63]，商业平台的 LLM 智能路由同样内置 Failover 机制 ^[57]。素材作者自述”同样的硬件能扛 10 倍流量”^[0]，这是作者的经验性主张。

A2A：官方仍是 feature request

素材将 A2A（Agent-to-Agent）列为 OpenClaw 的既有能力 ^[0]，但更准确的说法是：OpenClaw 官方仓库中”添加 A2A 协议支持”仍是一则未指派开发者的 feature request ^[14]。当前能用的实现全部来自社区：一个 A2A Gateway 插件实现了 A2A v0.3.0 协议（由 Google 于 2025 年 4 月提出，现由 Linux Foundation 托管）^[22,19,16]，支持 Agent Card 发布、任务创建/取消/结果流式、双向通信与自动发现 ^[22]，可让不同机器上的 bot 点对点通信 ^[15]；另一个 openclaw-a2a Skill 实现的是”受 Google A2A 项目启发”的自研轻量变体 openclaw-a2a-lite-v1 ^[20]；还有社区直接在 OpenClaw 上按 Google A2A 的消息信封（Envelope）与签名校验接入 ^[21]。因此，OpenClaw 生态的 A2A 能力由插件拼出，实现口径不一 ^[14,20,22]。协议定位上，MCP 解决 Agent 与工具之间（纵向）的通信，A2A 解决 Agent 与 Agent 之间（横向）的协作，两者互补 ^[14,18]。

作者沉淀的四条原则

素材作者将这次重构的教训总结为四条可迁移的原则 ^[0]：

多租户必须在架构层面设计。OpenClaw 单租户起步、后期补多租户近乎重写；FastClaw 从第一行代码就设计了 (user_id, agent_id) 隔离模型 ^[0]。

状态与内容分离存储。状态（Session、用户、权限）进数据库，文件系统只存”内容”（代码、文档、配置）^[0]。

外部依赖必须配置 Fallback。任何外部依赖挂掉就瘫痪的 Agent 无法用于生产 ^[0]；这也是 LLM 网关产品的通用设计 ^[60,61]。

控制 Token 成本。SOUL 要精简、记忆按需检索、长对话定期摘要 ^[0]；素材引用的实践把 SOUL 压到 400-500 token 以内 ^[4]。

原文更正：素材称 OpenClaw 支持 A2A 协议，实际官方仓库仅有一则未实现的 feature request（issue #6842），现有 A2A 能力全部来自社区插件，实现口径不一（Google A2A v0.3 完整实现与自研轻量变体并存）。^[14]