# OpenClaw 调研：一种复杂的极致，与另一种从简的可能 距离上一篇聊 OpenClaw，已经过去几天了。那篇发出后，有朋友问我："OpenClaw 真的有必要搞那么复杂吗？你对它批评不少，为什么不做一个呢？" 这问题让我想了很久。光靠感觉不行，得拿数据和代码说话。 于是我花了个周末做了两件事：一是和AI一起读完了 GitHub 上 OpenClaw 的源码，深挖 `src/gateway` 和 `src/agents` 的每一行逻辑；二是爬取统计了知乎相关话题下的所有回答，看看真实用户到底怎么用这玩意。 调研结束后，我的判断更清晰了：OpenClaw 为了解决"远程接管 Shell"这个难题，构建了一座精密的大厦。但问题在于，这个需求本身可能并不需要如此庞大的系统。穿过安检门，有时比直接走进房间还费劲。 今天这篇，我想通过数据和代码分析，聊聊在"超级个体"的数字化架构中，我们到底需不需要这把牛刀。 --- ## 一、数据：27% 的完美分裂 先看数据。我统计了知乎上"你们用 Moltbot 实现了什么有价值功能"话题下的所有深度回答。过滤掉纯情绪宣泄和简短评论后，数据呈现出一个极其有意思的现象：27% vs 27% 的完美分裂。 ### 27% 的人在"修路"：配置地狱 这部分用户的回答高度相似。整理数据时，我甚至能感受到屏幕对面的焦虑。 杨老师玩AI 写了篇长达 3000 字的配置指南。他详细拆解了如何从零配置 Node.js 环境，如何处理不同版本的 npm 依赖冲突，如何配置内网穿透让家里的 Mac 能被公网访问。文末他感慨："折腾了两天，终于跑通了第一个 'Hello World'。" 平凡 记录了段更崎岖的旅程。他在 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 的回答很典型。他描述了个场景：接手了个遗留项目，代码库有 5 万行，技术栈是 5 年前的 React 15，现在需要迁移到 React 18。 他在 Discord 里发了条消息："帮我把这个项目从 React 15 升级到 React 18，保持所有功能不变。"然后去睡觉了。 2 小时后醒来，Moltbot 在后台并行唤起了 25 个子 Agent，提交了 30+ 次 Git Commit，修改了 120+ 个文件。 听起来很酷。但问题在于：这个场景，真的需要通过 Discord 来完成吗？ 如果他人就坐在电脑前，为什么不直接在本地终端用 Claude Code 或者 Cursor 完成？非要绕一圈，通过 Discord Bot → WebSocket Gateway → Local Agent 这三层转发？ 木木Jay 的场景更能说明问题。他把 Moltbot 当作家庭服务器的管理员。服务器上跑着 Plex、Home Assistant、Pi-hole 等十几个 Docker 容器。当 Plex 挂了，他在手机上打开 Discord，发条消息："Plex 挂了，帮我看看。" Moltbot 会自动连到服务器，查看 Docker 日志，发现是内存溢出，然后重启容器，调整内存限制。 这个场景，确实是"远程控制"。但这也恰恰暴露了 OpenClaw 的定位：它本质上是一个 Shell 封装的远程调用工具。 ### 中间 46% 的沉默大多数 数据还揭示了个有意思的现象：剩下 46% 的回答，既没讲配置，也没讲场景。他们在讲什么？ 他们在讲期待。 "我觉得这个方向很对，但我还没搞定环境。" "看到楼上的案例很激动，准备这周末试试。" "有没有更详细的教程？官方文档看不懂。" 这部分用户，处于一种观望状态。他们被 Parafee2041 的故事吸引，但被杨老师的配置指南劝退。他们想要那个未来，但不确定自己能不能走到那个未来。 ### 数据结论 社区分裂严重。OpenClaw 是个复杂的工具，但它目前只服务于那 27% 的金字塔尖玩家。 更重要的是，即使是这 27% 的"成功案例"，仔细分析会发现：大部分场景其实并不需要这么复杂的系统。它们要么可以在本地完成，要么可以用更简单的工具解决。 OpenClaw 试图解决的核心问题是："如何通过 IM 远程控制本地 Shell"。但这个问题本身，可能就不是一个普遍需求。 --- ## 二、代码：为连接而生的复杂 为什么这么难用？为了搞清楚这问题，我钻进了它的 GitHub 仓库。 大家直觉上觉得它是个"Shell 封装"，把 `rm -rf` 包装成"帮我删个文件"。如果真是这样，代码应该很短。但这个直觉只对了一半。 OpenClaw 的代码库极其庞大。我粗略统计了下：整个仓库有 47,000+ 行代码，核心逻辑散落在 `packages/` 和 `apps/` 目录中。相比之下，一个简单的 CLI 工具只有不到 10,000 行代码。 为什么会有这么大的差距？因为它要解决的问题，本质上不是"如何执行 Shell 命令"，而是"如何在不可信的网络环境中，安全、可靠地由 AI 接管本地 Shell。" 这问题，确实很难。但问题是：我们真的需要在公网 IM 里控制本地 Shell 吗？ ### 1. 复杂的连接层：一个被迫的选择 `src/gateway` 目录揭示了它的野心，也揭示了它的无奈。 大多数本地工具只需要处理 stdin/stdout。用户在终端里敲个命令，程序执行，输出结果，结束。整个流程是同步的、短暂的、本地的。 但 OpenClaw 要实现的场景完全不同。它要让你能在手机上的 Discord/Slack 控制家里的电脑。这意味着： - 异步 - 你发条消息，不知道什么时候会收到回复 - 持久 - 连接需要一直保持，因为你可能随时发下一条消息 - 跨网络 - 你的手机在 4G 网络上，你的电脑在家里的 Wi-Fi 上，中间隔着 NAT、防火墙、运营商的各种限制 为了解决这问题，OpenClaw 实现了一套完整的 WebSocket Gateway。在 `src/gateway/websocket.ts` 文件里，我看到了超过 800 行的代码，专门处理连接管理。 Heartbeat & Reconnect - 它实现了复杂的心跳保活机制。每 30 秒发一次心跳包，防止连接在 NAT 环境下被回收。如果连接断开，它会自动重连，并且有指数退避算法，防止重连风暴把服务器打挂。 Adapter Pattern - 它抽象了个 Adapter 层，去兼容 Discord、Slack、Lark 等不同 IM 平台的即时通讯协议。Discord 的 Bot API 和 Slack 的 Events API 完全不同，但 OpenClaw 在上层提供了统一的接口。 这套设计在工程上确实解决了问题。但它也说明了一件事：你不是在装一个软件，你是在搭建一个服务器。 你需要有个公网可访问的地址，你需要配置 WebSocket 的 CORS，你需要在 Discord/Slack 上创建 Bot、申请权限、配置 Webhook。这些步骤，对于没有运维经验的人来说，每一步都是坑。 ### 2. 精密的 Patch 协议：一次大胆的创新 在 `src/agents/apply-patch.ts` 文件中，我发现了段非常有意思的代码。 普通 Agent 修改文件往往是"重写整个文件"。比如你让 GPT-4 修改个 1000 行的文件，它会把 1000 行全部输出一遍，即使只改了其中 3 行。这在 Token 昂贵的今天极其奢侈。 OpenClaw 的做法是发明了套 Patch Protocol。它定义了一组特殊标记，让 LLM 只输出差异部分。这样，Token 消耗可以降低 80%。 这个设计初衷是好的。但问题在于：这套方案极其脆弱。 LLM 是概率模型，它不能保证 100% 精确输出。如果它幻觉了，输错个标点，或者行号对不上，整个 Patch 就会失败。我在源码里看到了大量的错误处理逻辑，就是为了应对这种情况。 更麻烦的是，这套协议是 OpenClaw 自己发明的，不是业界标准。这意味着，如果你想用其他 LLM，你需要重新训练它理解这套协议。 这是个高风险、高收益的设计。它在理想情况下表现不错，但在边界情况下会崩溃。而更重要的是：这个问题，在本地工具里根本不存在。 ### 3. 沙箱与权限：一个无解的两难 在 `src/agents/sandbox` 和 `Dockerfile.sandbox` 中，我看到了为安全而做的妥协。 问题很简单：你敢让一个 AI，在你的电脑上执行任意 Shell 命令吗？ 如果不加任何限制，AI 可能会执行 `rm -rf /`，把你的系统删干净。即使不是恶意的，AI 也可能因为幻觉，执行一些危险的命令。 OpenClaw 的解决方案是：在 Docker 容器里运行 AI 的命令。 这思路看起来对。Docker 容器是隔离的，即使 AI 把容器搞坏了，也不会影响宿主机。但这也带来了新的问题： - 性能损失 - 每次执行命令，都要启动个容器，这比直接执行慢得多 - 环境差异 - 容器里的环境和宿主机不一样，很多依赖需要重新安装 - 权限受限 - 容器里的 AI 访问不了宿主机的文件，这在某些场景下是致命的 我在源码里看到，OpenClaw 提供了个 `--no-sandbox` 选项，允许你跳过沙箱，直接在宿主机执行命令。但这个选项，官方文档里有行红色的警告： > ⚠️ WARNING: This is extremely dangerous. Only use this if you fully trust the AI and understand the risks. 这是个两难。安全和便利，你只能选一个。但这个两难，恰恰说明了一件事：远程控制这个场景，本身就充满了不确定性和风险。 ### 代码结论 看完这些代码，我理解了 OpenClaw 为什么这么复杂。 它要在一个充满不确定性的网络环境中，让一个概率模型去控制一个确定性系统。这个过程中，每一步都需要容错、重试、兜底。 但这也说明了一个更本质的问题：这个需求本身，可能就不该用这种方式解决。 --- ## 三、另一种可能：拆解与重构 看完这些代码和数据，我的想法更清晰了。 OpenClaw 试图解决的问题，可以拆解成三个层次： 1. 本地开发 - 用 AI 写代码、改文件 2. 远程连接 - 从手机控制家里的电脑 3. 自动化任务 - 让一些流程自动运行 OpenClaw 的逻辑是：把这三者封装成一个单体系统。但问题在于，每个层次其实都有更简单、更优雅的解决方案。 ### 1. 本地开发：Claude Code 如果你想在本地写代码、改文件，Claude Code 就够了。 OpenClaw 还在用 Shell 脚本去解析 LLM 的输出，而 Claude Code 是原生集成。它直接连到 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 格式。 最重要的是，它就活在你的终端里。你可以随时 `Ctrl+C` 打断它，也可以随时用 `ls` 看一眼当前目录。你不需要在 Discord 和终端之间切换，不需要等待网络延迟，不需要担心 WebSocket 断线。 在本地开发这个场景上，OpenClaw 没有任何优势。 ### 2. 远程控制：tmate / SSH "那远程控制怎么办？" 这是个好问题。但我要反问：我们真的需要在 Discord 里控制电脑吗？ OpenClaw 的逻辑是：我在外面，我想控制家里的电脑，所以我在 Discord 里发消息，然后 Discord Bot 转发给家里的电脑。 但这个逻辑有个前提：你只能用 Discord。 如果你能用 SSH 呢？ Unix 世界早就给了我们答案。比如 tmate 的用法极其简单。在家里的 Mac 上，敲行命令： ```bash tmate ``` 它会启动个 tmux 会话，并且给你个 SSH 链接。然后，你在手机上，粘贴这个链接，回车。 你就连回家了。 你看到的，依然是那个熟悉的终端界面。你可以运行任何命令，可以启动 Claude Code，可以编辑文件，可以查看日志。 没有配置，没有 Docker，没有 WebSocket，没有 Bot Token。 tmate 只是个例子。事实上，Tailscale、VPN 这些工具更成熟。它们有完善的权限管理、访问控制、审计日志。你不需要像 OpenClaw 那样，每次操作都消耗大量 Token，还要担心 LLM 幻觉导致的误操作。 而且，这些方案比 OpenClaw 更安全。它们基于 SSH 或 WireGuard 协议，端到端加密。而 OpenClaw 的 Discord Bot，理论上 Discord 的服务器能看到你的所有消息。 有人可能会说："但这些工具没有 AI 啊。" 不，它们有 AI。因为你连上之后，可以直接在终端里用 Claude Code。 这就是 Unix 哲学：每个工具只做一件事，然后通过组合来实现复杂功能。 - Tailscale/tmate 负责远程连接 - Claude Code 负责 AI 交互 - 两者组合，就是"在手机上用 AI 控制家里的电脑" OpenClaw 费尽心力构建的网关，在这个视角下，一行命令就解决了。 ### 3. 自动化任务：Server Script 这是最容易被忽视的一步。 OpenClaw 的逻辑是：把所有能力都集成在这个庞大的框架里，变成一个个 Skill 文件。你想做什么，就调用什么 Skill。 但我的逻辑是：固化。 假设我想实现个功能："每天早上 8 点，自动抓取昨天的财报新闻，总结成 3 条要点，发邮件给我。" OpenClaw 的做法是：写个 Skill 文件，定义这个流程，然后每天早上在 Discord 里手动触发。 我的做法是： 1. 在本地，用 Claude Code 跑通这个流程 2. 让 Claude Code 把这个流程固化成一个独立的 Python 脚本 3. 把这个脚本扔到服务器上 4. 用 `crontab` 配置定时任务：`0 8 * * * python3 /home/scripts/daily_finance.py` 完成。 从此以后，这个功能就固化了。它不再依赖 OpenClaw，不再依赖 Claude Code，甚至不再依赖 Claude。 它变成了段代码，稳定、可控、透明。 这里还有个最佳实践：创意生成阶段用 Claude 的模型，探索出最优方案。但固化下来之后，可以改成调用 Gemini。不仅响应更快，成本还能降低一个数量级。Claude 擅长思考和创新，Gemini 擅长执行和稳定，各取所长。 - 极度稳定 - 一个脚本，比一个 5 万行的框架稳定得多 - 极低成本 - 一台便宜的 VPS 可以跑几十个这样的脚本，而且固化后切换到 Gemini，成本更低 - 完全掌控 - 你可以随时修改这段代码，可以随时查看日志，可以随时停止它 这个思路，我称之为"从 Agent 到 Script"。 Agent 是灵活的，但也是不稳定的。Script 是固化的，但也是可靠的。我们应该用 Agent 去探索可能性，然后用 Script 去沉淀价值。 而这个过程，完全不需要 OpenClaw 这样的庞大系统。OpenClaw 让你一直依赖它的框架，每次执行都要消耗 Token。而固化成脚本后，你可以自由选择模型，甚至可以完全本地化。 --- ## 四、结语 回过头来看 OpenClaw。 它试图解决一个问题：如何通过 IM 远程控制本地 Shell。为了解决这个问题，它构建了一套完整的架构：WebSocket Gateway、Patch Protocol、Docker Sandbox。 从工程角度看，这套架构确实解决了问题。但问题在于：这个问题本身，可能就不该这样解决。 对于大多数人来说： - 如果你在电脑前，直接用 Claude Code 就行，不需要绕一圈通过 Discord - 如果你不在电脑前，用 tmate/SSH 连回去就行，不需要搭建一个服务器 - 如果你想自动化，把流程固化成脚本就行，不需要一个庞大的框架 OpenClaw 试图把这三者封装成一个单体产品。但这个单体，带来的复杂度远远超过了它解决的问题。 这不是工具的选择，而是思路的差异。 OpenClaw 的思路是：用一个大系统解决所有问题。 我的思路是：用几个小工具，通过组合解决问题。 哪个更好？取决于你的场景。 但对于追求效率和掌控感的超级个体来说，我倾向于后者。因为它更简单、更透明、更可控。 更重要的是：它不需要你花两天时间配置环境。