别整 openclaw 了，spacebot 才是你的梦中情 bot

核心结论：openclaw 串行阻塞，执行时对话冻结，内部状态黑盒；spacebot 五层进程并发互不阻塞，知识图谱记忆带可信度评分，Worker 在跑时你照样能聊天。同等自托管场景下，spacebot 响应更快、记忆更可靠、部署更简单——开源免费，单一二进制，cargo build 后直接跑。

你以为自建 AI bot 难，其实是你选错了工具

折腾族有一种通病：看到 GitHub 上 star 数够多、README 写得够长，就默认”这个应该可以”，然后一头扎进去，花两个周末配环境、踩坑、debug，最后跑起来一个勉强能用的东西，告诉自己”差不多够用了”。

openclaw 就是这种故事的标准剧本。

它的主页看起来非常有诚意：支持 WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage、Microsoft Teams、Matrix、Zalo……十几个平台，密密麻麻地列在 README 里，让人产生一种”这就是我要找的全能助手”的幻觉。

npm install -g openclaw，一行装好，文档齐全，社区活跃。

然后你真的开始用了。

你发一条消息，让它帮你搜点资料。

Bot 回了”好的，正在处理……”

然后——沉默。

你等了五秒。又发了一条”还在吗？”

没有回应。

等到它终于回来，你已经开了三个新标签页自己去查了。

这不是个例，这是 openclaw 的工作模型决定的：它是串行的，执行任务时对话是冻结的。你在等一个不知道进展到哪里的黑盒跑完。

这个体验有个名字，叫做：令人窒息的等待感。

如果你也有过这种感受，我们聊聊 spacebot。

openclaw 的问题，比你想的更根本

先说清楚，openclaw 不是”差”，它是”将就”。将就在当你需求简单的时候，它的确够用。但一旦你想真正把 AI bot 作为生产力工具，它的天花板会让你很快撞头。

问题一：Node.js 的历史包袱

openclaw 的整个技术栈建在 Node.js + TypeScript 上。这个选择最大的优点是”开发者熟悉”，最大的缺点也是同一套技术栈带来的：运行时重，内存占用高，单线程事件循环决定了它的并发上限。

你装好之后会发现，光是 node_modules 目录就能让你磁盘占用跳一下。启动时间也不短，尤其在低配 VPS 上，第一次冷启动会让你怀疑它是不是挂了。

问题二：本地网关是个甜蜜陷阱

openclaw 的架构核心是一个本地 WebSocket 网关，跑在 ws://127.0.0.1:18789。听起来”轻量”，实际上意味着所有的进程管理、端口管理、崩溃重启，都得你自己搞。

想多设备接入？你要额外配 Tailscale 或者反代。进程挂了？你要写 systemd service 或者 pm2 配置。端口冲突？祝你排查顺利。

这是一种把复杂度下推给用户的架构设计，包装成了”灵活可定制”。

问题三：执行时的感知断裂

这是最核心的问题。当 openclaw 在执行一个工具调用时，整个响应链路是阻塞的。

你不知道它在做什么，是在搜索？是在写文件？是卡死了？是网络超时了？全部未知。你唯一能做的就是等，等到它自己回来，给你一个结果，或者一个报错。

更糟的是，在它执行期间你发的消息，很可能就消失在时间线里了，等 bot 回过头来，它不知道你问过什么。

这不叫 AI agent，这叫”定时轮询的自动回复机器”。

认识 spacebot：团队的 AI 操作系统

先说一个细节：spacebot 的官网标题不是 “AI Bot”，也不是 “AI Assistant”，而是：

Spacebot — AI Operating System for Teams

这个定位差异很重要。它不是帮你回几条消息的玩具，而是把 AI agent 当成一个操作系统级的基础设施来做——有调度器、有内存管理、有进程隔离、有权限系统，缺的只是一个内核 logo。

它用 Rust 写成，部署形态是单一二进制，面向团队和多用户并发场景设计。

官方给的核心承诺只有一句话：

Thinks, executes, and responds — concurrently, not sequentially. Never blocks. Never forgets.

翻译过来就是：思考、执行、响应，同时进行，互不阻塞，永不遗忘。

这不是营销文案，是对架构的约束。下面逐层拆解。

亮点一：流畅——它从不让你等

三层 Agent 模型，各司其职

spacebot 内部把一个对话拆成三大类进程，共五个角色：

Channel（频道层）：和用户直接交互的那个”人格”。永远在线，永远响应，有自己的 soul 和 identity，绝对不会因为后台在跑任务而失联。职责是接收消息、维持对话人格、调度后续动作。

Branch（分支层）：当 Channel 判断一个问题需要更深度的推理时，它会克隆出一个 Branch。Branch 继承完整对话上下文，独立思考，不阻塞 Channel。可以同时有多条 Branch 并发运行——谁先完成，谁的结果优先被采用，其余自动丢弃。

Worker（工作层）：执行具体任务的进程，有两种模式：

• 一次性模式：发出去，有结果回来，任务完成。适合搜索、总结、文件操作。
• 交互式模式：支持 follow-up 输入，有 LSP 感知的编码会话。适合需要来回确认的复杂任务。

Worker 和 Channel 完全独立运行，Worker 在跑，Channel 照样接你的消息。

另外还有两个后台进程：

• Compactor（压缩层）：监控上下文长度，>80% 后台压缩，>85% 积极压缩，>95% 紧急截断，全程不打扰主对话
• Cortex（皮层）：全局监督，稍后详细介绍

消息合并：它读得懂你的节奏

当你连续快速发多条消息时，spacebot 不会傻傻地对每条消息单独生成回复，而是把它们批量合并成一个 LLM 请求，连同时间戳上下文一起发出去，让 agent 读懂你在说什么。

这个设计防止了”回复风暴”——你在打字的时候，bot 不会不停地插嘴说”好的”、“收到”、“明白了”。系统可以自动检测 DM 场景并绕过合并，保证私聊的即时感。

实际体验差距

有一个官网用户评价说得很直接：

“spacebot replies so much faster than openclaw”

这不是空话。openclaw 执行任务时你只能盯着光标发呆，发的消息也不知道有没有被接收。spacebot 执行任务时，你们还能继续聊，甚至可以插入新的任务，它会排好队依次处理。

亮点二：透明——你知道它在干什么的每一秒

AI agent 的信任危机

用 AI agent 最让人抓狂的时刻，是你不确定它是不是”真的在干活”。

转圈动画可以是真实处理，也可以是程序挂死后的假动作。“正在思考…”可以是深度推理，也可以是 API 超时后的等待。你没有任何依据区分这两种状态。

这种不确定感，是对 AI agent 不信任的根本来源。

spacebot 选择了完全相反的路子：把 agent 的内部状态完整暴露给用户。

你在 UI 里能看到什么

打开 spacebot 的 Web UI，你会看到的不是一个简洁的聊天框，而是一个可观察的 agent 控制台：

进程状态：当前有几个 Worker 在跑、每个 Worker 在做什么任务、有多少条 Branch 还在推理中。不是一个模糊的”处理中”，是实实在在的进程列表，你可以一眼看到整个系统的负载状态。

知识图谱记忆：spacebot 的记忆系统不是把聊天记录堆在一起，而是一个结构化的知识图谱，包含 8 种具体类型：

每条记忆不是孤立的，而是通过图边连接：RelatedTo（相关）、Updates（更新）、Contradicts（矛盾）、CausedBy（因果）、PartOf（从属）。这意味着 agent 不只是”记住了这件事”，而是知道这件事和其他事情的关系。

更关键的是，每条记忆都带有可信度评分和信息来源。你可以清楚地看到 agent 的某个判断是高度确定的还是存疑的，这个判断是从哪次对话里提取出来的。

openclaw 是个黑盒，你不知道它记住了什么。spacebot 是个透明箱，记忆列表就摆在你面前，每条都有出处。

Cortex：那个每小时都在整合的大脑

Cortex 是 spacebot 里最有意思的设计之一，官网单独给它列了出来：

它是一个持久运行的全局智能层，每小时对所有对话做一次跨对话知识合成，生成一份”记忆简报”（memory bulletin），然后把这份简报注入到每个 agent 对话的上下文里。

这意味着什么？

假设你今天上午在某个频道问过 bot 一个问题，下午在另一个频道提到了相关的事，Cortex 会在下一次合成时把这两条信息关联起来，形成一条新的图谱边。你甚至不用”提醒”它，它自己会发现这个连接。

Cortex 还负责：

• 监控所有 Channel / Worker / Branch 的运行状态
• 杀死卡死的进程，清理僵尸 Branch
• 维护记忆图谱的 decay 和 pruning（陈旧记忆逐渐降权清除）
• 检测跨对话的行为模式

通过 admin chat 可以直接问 Cortex：“你现在的全局目标是什么？你观察到了什么跨对话的规律？当前有哪些待办？“它会如实汇报，因为这本来就是它的职责：做全局的记忆管家和系统守卫。

记忆召回不靠运气

openclaw 那类方案的记忆大多是简单的”把最近 N 条对话塞进 context”，或者最多做个基础向量检索。时间一长，context 撑满了，该记住的忘了，不重要的反而占着位置。

spacebot 的记忆召回使用混合检索（Hybrid Recall）：向量相似度搜索 + 全文关键词搜索，通过 Reciprocal Rank Fusion 算法融合排序。两种检索互补——向量搜索找语义相关的，全文搜索找精确匹配的，融合之后你得到的是”既相关又准确”的记忆，而不是”勉强相关”的噪声。

另外，spacebot 还支持文件直接摄入记忆：把你的 markdown、日志、YAML、JSON 文件丢给它，它自动提取结构化记忆，写进知识图谱。你的项目文档、历史记录、配置文件，都可以成为 agent 的知识来源。

顺便一提：模型路由和提供商支持

spacebot 支持 10 个 LLM 提供商：Anthropic、OpenAI、OpenRouter、Groq、Mistral、DeepSeek、Fireworks、Together、xAI、Zhipu。

不是那种”我也支持这个”的表面兼容，而是内置了四层自动路由系统：

1. 进程类型默认：Channel 对话用中等模型，Worker 执行用快模型，Compactor 压缩用最便宜的
2. 任务类型覆盖：写代码这类专业任务自动升级到更强的模型
3. 提示词复杂度评分：简单问题路由到省钱模型，复杂推理路由到强模型
4. Fallback 链：某个模型返回限速或报错，自动切换到下一个候选

你不用手动管”这个问题用哪个模型”，系统在质量和成本之间自动找平衡。

安全：你的凭据不会乱跑

用 agent 执行任务，最让人担心的是”它会不会把我的 API key 发出去”。

spacebot 的安全设计非常细致：

• 文件系统隔离：Linux 用 bubblewrap 挂载命名空间，macOS 用 SBPL 沙箱，工作区外只读
• Secret 泄露检测：扫描工具参数和输出，覆盖明文、URL 编码、base64、hex 四种格式，发现 API key 立刻拦截
• 危险环境变量拦截：LD_PRELOAD、DYLD_INSERT_LIBRARIES 等注入类变量直接拒绝
• SSRF 防护：浏览器工具屏蔽云元数据地址、私有 IP、回环地址
• 凭据加密存储：所有 secrets 用 AES-256-GCM 加密

定价与部署

托管方案（无需自己维护服务器）：

自托管（开源免费）：

如果你只是个人用，自托管免费版就够了。如果是团队使用，$29/月的 Pod 方案性价比不错。

快速上手：3 分钟跑起来

方式一：一键托管脚本

curl -sSf https://spacebot.sh | sh

按向导走完就能用，无需自己维护服务器。

方式二：本地自托管

git clone https://github.com/spacedriveapp/spacebot
cd spacebot
cargo build --release
./target/release/spacebot start

单一二进制，无运行时依赖，无 node_modules，无 Python 虚拟环境。一个文件，扔哪里都能跑。

方式三：Docker

docker run -v spacebot-data:/data ghcr.io/spacedriveapp/spacebot

挂卷持久化，重启不丢记忆。

技能管理：

spacebot skill add owner/repo   # 从社区注册表安装技能
spacebot skill list             # 查看已安装技能

技能系统和 openclaw 生态兼容，已有的 openclaw 技能可以直接迁移，迁移成本几乎为零。

两者对比，一目了然

结语

openclaw 能跑，但你用它的体验是：等待 + 猜测。等它执行完，猜它在干什么。

spacebot 给你的是另一种工程哲学：流畅 + 透明。

它干活的时候你还能聊天。它的每一个决策都摆在你面前。它记住的每一件事都有出处和可信度。它的 Cortex 每小时在帮你整合跨对话的知识，你甚至不需要提醒它”上次我们聊过这个”。

这才是一个真正能用的 agent 应该有的样子。

弃坑不丢人，选对工具才是正事。

spacebot：github.com/spacedriveapp/spacebot · 1.5k stars · Rust · spacebot.sh openclaw：github.com/openclaw/openclaw · Node.js