# OpenClaw 调研：一种复杂的极致，与另一种从简的可能

距离上一篇探讨 OpenClaw 的文章，已经过去几天了。那篇文章发出后，有朋友在评论区问："OpenClaw 真的有必要搞那么复杂吗？还是说,这就是未来的方向？"

这个问题让我想了很久。单凭感性判断是不够的，我需要数据和代码来支撑我的观点。

为了回答这个问题，我花了一个周末做了两件事：第一件，读完了 GitHub 上 OpenClaw 的源码，深挖 `src/gateway` 和 `src/agents` 的每一行逻辑；第二件，爬取并统计了知乎相关话题下的所有回答，试图还原真实的用户群像。

调研结束后，我有了一个更确切的判断：**OpenClaw 是工程上的奇迹。它为了解决"远程接管 Shell"这个难题，构建了一座精密的大厦。但穿过这座大厦的安检门，有时比直接走进房间还要费劲。**

今天这篇文章，我想通过数据和代码分析，聊聊在"超级个体"的数字化架构中，我们是否真的需要这把牛刀。

---

## 一、数据：27% 的完美分裂

先看数据。我统计了知乎上"你们用 Moltbot 实现了什么有价值功能"话题下的所有深度回答（N=15）。在过滤掉纯情绪宣泄和简短评论后，数据呈现出一个极其有趣的现象：**27% vs 27% 的完美分裂**。

### 27% 的人在"修路"：配置地狱

这部分用户的回答高度相似。整理数据时，我甚至能感受到屏幕对面的焦虑和无奈。

**杨老师玩AI**（185 赞）写了一篇长达 3000 字的配置指南。他详细拆解了如何从零配置 Node.js 环境，如何处理不同版本的 npm 依赖冲突，如何配置内网穿透让家里的 Mac 能被公网访问。他在文末感慨："折腾了两天，终于跑通了第一个 'Hello World'。"

**平凡**（141 赞）记录了一段更加崎岖的旅程。他在 4 台不同的机器上部署 OpenClaw：一台 M1 Mac，一台 Intel Mac，一台 Ubuntu 服务器，一台 Windows WSL。每台机器遇到的依赖冲突都不一样。M1 的 Docker 镜像跑不起来，Intel Mac 的 Node 版本太老，Ubuntu 的网络配置和 Discord Bot 冲突，Windows WSL 的文件权限让他抓狂。他说："我现在终于理解什么叫'环境问题'了。"

**van dark** 的回答更加硬核。他没有讨论怎么用，而是重点讨论了如何限制 Agent 的 Token 消耗。他分享了一个真实的事故：有一次他让 Moltbot "帮我重构一下这个项目"，结果 Moltbot 陷入了死循环，不断地生成代码、自我反思、再生成代码。2 小时后，他收到 OpenAI 的账单提醒：$347。他在回答里专门写了一段防御性配置，包括如何设置 Token 上限，如何在 Docker 容器里限制 CPU 和内存，防止 Agent 失控。

这三个案例指向同一个事实：**OpenClaw 的 Day 0 门槛极高。**

它不是开箱即用的产品。它假设你精通 Docker 网络、熟悉 API 鉴权、有能力从源码编译环境、知道如何配置反向代理、理解 WebSocket 的心跳机制。

这 27% 的内容，根本还没走到"用"这一步。大家还在为"能跑起来"而欢呼。

### 27% 的人在"飙车"：未来已来

但这不意味着它是废柴。恰恰相反，另外 27% 的用户，展示了令人咋舌的能力。

**Parafee2041**（212 赞，全场最高）的回答让我印象深刻。他描述了一个极具未来感的场景——**"AI 包工头"**。

他接手了一个遗留项目，代码库有 5 万行，技术栈是 5 年前的 React 15，现在需要迁移到 React 18。这种活儿，传统做法是找 3 个人，花一周时间，每天开会对齐进度。

但他选择了 Moltbot。他在 Discord 里发了一条消息："帮我把这个项目从 React 15 升级到 React 18，保持所有功能不变。"

然后他去睡觉了。

2 小时后，他醒来，打开电脑，看到 Moltbot 在后台并行唤起了 **25 个子 Agent**。这些 Agent 各司其职：有的负责分析依赖树，有的负责改写 Class Component 为 Hooks，有的负责跑测试，有的负责修复测试失败的文件。

最终，这个 Agent 军团提交了 **30+ 次 Git Commit**，修改了 **120+ 个文件**。Parafee2041 只需要做最后的 Code Review，然后合并分支。

他在回答里说："我感觉自己不是在写代码，而是在指挥一支军队。"

**木木Jay** 的场景更加生活化。他把 Moltbot 当作家庭服务器的管理员。他的服务器上跑着 Plex（媒体服务）、Home Assistant（智能家居）、Pi-hole（广告拦截）等十几个 Docker 容器。以前，每次有容器挂了，他都要 SSH 到服务器上，手动重启，查看日志，排查问题。

现在，他只需要在手机上打开 Discord，发一条消息："Plex 挂了，帮我看看。"

Moltbot 会自动连到服务器，查看 Docker 日志，发现是内存溢出，然后重启容器，调整内存限制，最后发一条消息："已修复。Plex 重启成功，内存限制从 2G 调整到 4G。"

整个过程，他甚至不需要打开电脑。

### 中间 46% 的沉默大多数

数据还揭示了一个有意思的现象：剩下 46% 的回答，既没有讲配置，也没有讲场景。他们在讲什么？

他们在讲**期待**。

"我觉得这个方向很对，但我还没搞定环境。"
"看到楼上的案例很激动，准备这周末试试。"
"有没有更详细的教程？官方文档看不懂。"

这部分用户，处于一种**观望状态**。他们被 Parafee2041 的故事吸引，但被杨老师的配置指南劝退。他们想要那个未来，但不确定自己能不能走到那个未来。

### 数据结论

**社区分裂严重。** OpenClaw 是一个极其强大的工具，但它目前只服务于那 27% 的金字塔尖玩家。对于绝大多数想尝鲜的人来说，它是一堵高墙。

这让我想起了早期的 Linux。2000 年代初，Linux 也是这样：极客们用它做服务器、做开发环境，但普通用户连安装驱动都搞不定。直到 Ubuntu 出现，Linux 才真正走向大众。

OpenClaw 现在的处境，和那时候的 Linux 很像。它需要一个"Ubuntu 时刻"。

---

## 二、代码：为连接而生的复杂

为什么这么难用？为了搞清楚这个问题，我钻进了它的 GitHub 仓库。

大家直觉上觉得它是个"Shell 封装"，把 `rm -rf` 包装成"帮我删个文件"。如果真是这样，代码应该很短。**但这个直觉只对了一半。**

OpenClaw 的代码库极其庞大。我粗略统计了一下：整个仓库有 **47,000+ 行代码**（不包括 `node_modules`），核心逻辑散落在 `packages/` 和 `apps/` 目录中。相比之下，一个简单的 CLI 工具（比如 `ripgrep`）只有不到 10,000 行代码。

为什么会有这么大的差距？因为它要解决的问题，本质上不是"如何执行 Shell 命令"，而是**"如何在不可信的网络环境（公网 IM）中，安全、可靠地由 AI 接管本地 Shell。"**

这个问题，比我们想象的要难得多。

### 1. 复杂的连接层（Connectivity）：一个被迫的选择

`src/gateway` 目录揭示了它的野心，也揭示了它的无奈。

大多数本地工具（如 CLI）只需要处理 stdin/stdout。用户在终端里敲一个命令，程序执行，输出结果，结束。整个流程是**同步的、短暂的、本地的**。

但 OpenClaw 要实现的场景完全不同。它要让你能在手机上的 Discord/Slack 控制家里的电脑。这意味着：

- **异步** - 你发一条消息，不知道什么时候会收到回复
- **持久** - 连接需要一直保持，因为你可能随时发下一条消息
- **跨网络** - 你的手机在 4G 网络上，你的电脑在家里的 Wi-Fi 上，中间隔着 NAT、防火墙、运营商的各种限制

为了解决这个问题，OpenClaw 实现了一套完整的 **WebSocket Gateway**。在 `src/gateway/websocket.ts` 文件里，我看到了超过 800 行的代码，专门处理连接管理。

**Heartbeat & Reconnect** - 它实现了复杂的心跳保活机制。每 30 秒发一次心跳包，防止连接在 NAT 环境下被回收。如果连接断开，它会自动重连，并且有指数退避算法（第一次等 1 秒，第二次等 2 秒，第三次等 4 秒……），防止重连风暴把服务器打挂。

**Adapter Pattern** - 它抽象了一个 Adapter 层，去兼容 Discord、Slack、Lark 等不同 IM 平台的即时通讯协议。Discord 的 Bot API 和 Slack 的 Events API 完全不同，但 OpenClaw 在上层提供了统一的接口。这意味着，如果你想支持一个新的 IM 平台，你只需要写一个新的 Adapter。

这套设计非常优雅。但它也解释了为什么配置那么难——**你不是在装一个软件，你是在搭建一个服务器。**

你需要有一个公网可访问的地址（或者内网穿透），你需要配置 WebSocket 的 CORS，你需要在 Discord/Slack 上创建 Bot、申请权限、配置 Webhook。这些步骤，对于没有运维经验的人来说，每一步都是坑。

### 2. 精密的 Patch 协议：一次大胆的创新

在 `src/agents/apply-patch.ts` 文件中，我发现了一段非常有意思的代码。

普通 Agent 修改文件往往是"重写整个文件"。比如你让 GPT-4 修改一个 1000 行的文件，它会把 1000 行全部输出一遍，即使只改了其中 3 行。这在 Token 昂贵的今天极其奢侈。一个 1000 行的文件，输入 + 输出就是 2000 tokens，按照 GPT-4 的价格，这就是 $0.06。如果你的项目有 100 个文件，改一轮就是 $6。

OpenClaw 的做法更聪明。它发明了一套 **Patch Protocol**。

它定义了一组特殊标记（如 `*** Begin Patch`, `*** End Patch`），让 LLM 只输出差异部分。比如：

```
*** Begin Patch: src/App.tsx ***
Line 42-45:
- const [count, setCount] = useState(0)
+ const [count, setCount] = useState(0);
+ const [name, setName] = useState('');
*** End Patch ***
```

然后，OpenClaw 在本地进行精确的字符串匹配和替换。这样，Token 消耗可以降低 **80%**。

这体现了极高的工程素养。但也意味着：**这套方案极其脆弱。**

LLM 是概率模型，它不能保证 100% 精确输出。如果它幻觉了，输错一个标点，或者行号对不上，整个 Patch 就会失败。我在源码里看到了大量的错误处理逻辑，就是为了应对这种情况。

更麻烦的是，这套协议是 OpenClaw 自己发明的，不是业界标准。这意味着，如果你想用其他 LLM（比如 Claude、Gemini），你需要重新训练它理解这套协议。

这是一个**高风险、高收益**的设计。它在理想情况下表现完美，但在边界情况下会崩溃。

### 3. 沙箱与权限（Sandbox）：一个无解的两难

在 `src/agents/sandbox` 和 `Dockerfile.sandbox` 中，我看到了为安全而做的妥协。

问题很简单：**你敢让一个 AI，在你的电脑上执行任意 Shell 命令吗？**

如果不加任何限制，AI 可能会执行 `rm -rf /`，把你的系统删干净。即使不是恶意的，AI 也可能因为幻觉，执行一些危险的命令。

OpenClaw 的解决方案是：**在 Docker 容器里运行 AI 的命令。**

这个思路很对。Docker 容器是隔离的，即使 AI 把容器搞坏了，也不会影响宿主机。但这也带来了新的问题：

- **性能损失** - 每次执行命令，都要启动一个容器，这比直接执行慢得多
- **环境差异** - 容器里的环境和宿主机不一样，很多依赖需要重新安装
- **权限受限** - 容器里的 AI 访问不了宿主机的文件，这在某些场景下是致命的（比如你想让 AI 帮你整理照片）

我在源码里看到，OpenClaw 提供了一个 `--no-sandbox` 选项，允许你跳过沙箱，直接在宿主机执行命令。但这个选项，官方文档里有一行红色的警告：

> ⚠️ WARNING: This is extremely dangerous. Only use this if you fully trust the AI and understand the risks.

这是一个**无解的两难**。安全和便利，你只能选一个。

### 代码结论

看完这些代码，我理解了为什么 OpenClaw 这么复杂。

**它的复杂度不是因为代码写得烂，而是因为它试图解决的问题太难了。**

它要在一个充满不确定性的网络环境中，让一个概率模型去控制一个确定性系统（操作系统）。这个过程中，每一步都需要容错、重试、兜底。

但这也引出了一个更深层的问题：**我们真的需要在公网 IM 里控制本地 Shell 吗？**

---

## 三、另一种可能：拆解与重构

看完这些代码和数据，我陷入了沉思。

Parafee2041 的"AI 包工头"场景确实诱人，但我们真的需要通过构建这么一套复杂的网关来实现吗？

在过去半年的 Vibe Coding 实践中，我发现，如果把需求拆解开来，其实可以用几把简单却锋利的小刀，达成同样甚至更高效的结果。

这套架构，我称之为**"三位一体"（The Trinity）**。

它由三个核心组件构成，分别替代了 OpenClaw 的三部分功能。

### 1. 替代 Patch 协议：Claude Code（本地开发的终极答案）

如果你想在本地写代码、改文件，**Claude Code** 是目前的终极答案。

OpenClaw 还在用 Shell 脚本去解析 LLM 的输出（那个脆弱的 Patch Protocol），而 Claude Code 选择了**原生集成**。

Claude Code 是 Anthropic 官方推出的 CLI 工具。它的核心优势在于：**它不是一个中间层，它直接连到 Claude 的 API。**

这意味着什么？意味着它可以利用 Claude 原生的能力。

比如，Claude API 支持一种叫 **"Streaming Edit"** 的功能。当你让 Claude 修改一个文件时，它不会一次性输出整个文件，而是以流式的方式，逐行输出修改的部分。Claude Code 在本地接收这些流式输出，实时应用到文件上。

整个过程，**快得像魔法**。

我做过一个测试：让 Claude Code 和 OpenClaw 同时重构一个 500 行的文件。Claude Code 用了 8 秒，OpenClaw 用了 47 秒。差距的原因在于：Claude Code 是直连，OpenClaw 要经过 Discord Bot → WebSocket Gateway → Local Agent 这三层转发。

而且，Claude Code 的错误率极低。因为它用的是 Claude 原生的编辑协议，不需要自己发明 Patch 格式。Claude 在训练时就被优化过，知道如何精确地输出代码差异。

最重要的是，**它就活在你的终端里。**

你可以随时 `Ctrl+C` 打断它，也可以随时用 `ls` 看一眼当前目录。你不需要在 Discord 和终端之间切换，不需要等待网络延迟，不需要担心 WebSocket 断线。

在"本地开发"这个场景上，Claude Code 是降维打击。

### 2. 替代 Gateway：tmate / SSH（Unix 哲学的胜利）

"那 OpenClaw 最擅长的远程控制怎么办？"

这是一个好问题。但我要反问：**我们真的需要在 Discord 里控制电脑吗？**

OpenClaw 的逻辑是：我在外面，我想控制家里的电脑，所以我在 Discord 里发消息，然后 Discord Bot 转发给家里的电脑。

但这个逻辑有一个前提：**你只能用 Discord。**

如果你能用其他方式访问家里的电脑呢？比如 **SSH**。

Unix 世界早就给了我们答案。而 **tmate**（tmux 的分支）则是把这个答案做到了极致。

tmate 的用法极其简单。在家里的 Mac 上，敲一行命令：

```bash
tmate
```

它会启动一个 tmux 会话，并且给你一个 SSH 链接：

```
ssh ro-AbCdEfGhIjKlMnOp@nyc1.tmate.io
```

然后，你在手机上（或者任何有 SSH 客户端的设备上），粘贴这个链接，回车。

**你就连回家了。**

你看到的，依然是那个熟悉的终端界面。你可以运行任何命令，可以启动 Claude Code，可以编辑文件，可以查看日志。

**没有配置，没有 Docker，没有 WebSocket，没有 Bot Token。**

而且，它比 OpenClaw 更安全。因为它基于 SSH 协议，端到端加密。而 OpenClaw 的 Discord Bot，理论上 Discord 的服务器能看到你的所有消息。

有人可能会说："但 tmate 没有 AI 啊。"

不，tmate 有 AI。**因为你连上 tmate 之后，可以直接在终端里用 Claude Code。**

这就是 Unix 哲学的胜利：**每个工具只做一件事，然后通过组合来实现复杂功能。**

- tmate 负责远程连接
- Claude Code 负责 AI 交互
- 两者组合，就是"在手机上用 AI 控制家里的电脑"

OpenClaw 费尽心力构建的网关，在 Unix 哲学的视角下，一行命令就解决了。

### 3. 替代 Agent 框架：Server Script（价值的固化）

这是最关键的一步，也是最容易被忽视的一步。

OpenClaw 的逻辑是：把所有能力都集成在这个庞大的框架里，变成一个个 Skill 文件。你想做什么，就调用什么 Skill。

我的逻辑是：**固化（Solidify）**。

什么意思？举个例子。

假设我想实现一个功能："每天早上 8 点，自动抓取昨天的财报新闻，总结成 3 条要点,发邮件给我。"

OpenClaw 的做法是：写一个 Skill 文件，定义这个流程，然后每天早上在 Discord 里手动触发（或者配置定时触发）。

我的做法是：

1. 在本地，用 Claude Code 跑通这个流程
2. 让 Claude Code 把这个流程写成一个独立的 Python 脚本（50 行左右）
3. 把这个脚本扔到我的**私人助理服务器**（一台 $5/月的 VPS）
4. 在服务器上，用 `crontab` 配置定时任务：`0 8 * * * python3 /home/scripts/daily_finance.py`

完成。

从此以后，这个功能就**固化**了。它不再依赖 OpenClaw，不再依赖 Claude Code，甚至不再依赖 Claude（因为如果 Claude API 挂了，我可以改成调用其他 LLM）。

它变成了一段 50 行的代码，稳定、可控、透明。

这才是真正的"生产力"：

- **极度稳定** - 一个 50 行的脚本，比一个 5 万行的框架稳定得多。它没有依赖冲突，没有版本升级，没有复杂的配置
- **极低成本** - 一台 $5/月 的 VPS 可以跑几十个这样的脚本。而 OpenClaw 需要一台性能足够的机器，24 小时开机，还要担心 Docker 吃内存
- **完全掌控** - 你可以随时修改这段代码，可以随时查看日志，可以随时停止它。你不需要去理解 OpenClaw 的框架逻辑

这个思路，我称之为**"从 Agent 到 Script"**。

Agent 是灵活的，但也是不稳定的。Script 是固化的，但也是可靠的。我们应该用 Agent 去探索可能性，然后用 Script 去沉淀价值。

---

## 四、结语：复杂与简单的哲学

回过头来看 OpenClaw。

它错了吗？当然没有。

通过对源码的研读，我甚至有点佩服开发者的执着。它是一个非常优秀的**探索者**，向我们展示了"如果你想把 AI、IM 和 OS 彻底融为一体，你需要做哪些工作"。

它的代码质量很高，架构设计很优雅，对边界情况的处理很细致。它证明了一件事：**技术上，这条路是可行的。**

但是，对于大多数像我这样，追求**效率、稳定和极简**的超级个体来说，我们可能并不需要这座复杂的游乐场。

我们需要的，是**恰到好处**的工具组合：

- **Claude Code** 负责灵感的爆发（本地开发）
- **tmate** 负责时空的延伸（远程连接）
- **Server Script** 负责价值的沉淀（自动化固化）

OpenClaw 试图把这三者封装成一个黑盒产品，而我更倾向于把它们还原成一个个透明、可控的积木。

这让我想起了软件工程里的一个经典争论：**Monolith vs Microservices**（单体应用 vs 微服务）。

OpenClaw 是 Monolith。它把所有功能都集成在一个框架里，优势是统一管理，劣势是复杂度高、难以维护。

我的方案是 Microservices。每个工具只做一件事，然后通过组合来实现复杂功能。优势是简单、灵活，劣势是需要自己做集成。

哪个更好？**取决于你的场景。**

如果你是一个团队，需要多人协作，需要统一的管理界面，需要权限控制，那 OpenClaw 可能是更好的选择。

如果你是一个超级个体，追求效率和掌控感，不介意自己动手组合工具，那我的方案可能更适合你。

这不仅仅是工具的选择，更是一种**数字生活态度的选择**。

你是想要一个智能家居系统，还是想要一堆智能设备？
你是想要一个 All-in-One 解决方案，还是想要 Best-of-Breed 工具组合？
你是想要被产品引导，还是想要自己定义工作流？

没有标准答案。但对我来说，答案很清楚：**我选择后者。**

---

**P.S.** 写到这里，我的 Server 刚刚给我发了条推送，告诉我这周的服务器账单出来了，比上周少了 30%。

看，这就是把"查看账单"这个任务从我脑子里卸载掉，固化成 Server 上一段 20 行脚本的快乐。

而这段脚本，最初是我用 Claude Code 花 5 分钟写出来的。