图片资源未同步：未命名图片

OpenClaw 创始人反着写代码：砍掉中间层，反而更快

AI 编程圈这两年有个迷信： 工具越全、架构越像样、流程越“规范”，产出就越稳。

但 OpenClaw 创始人的开发方式，几乎是朝着“最佳实践清单”的反方向狂奔——而且还跑出来了一个爆火的开源 AI Agent。

先把话挑明：这不是反智，也不是摆烂。 这是一种更狠的工程判断：能直连就别加层，能用 CLI 就别造平台，能讲清楚就别先搭架子。

---

1）他到底“反”了哪些共识？

不用 Plan Mode：别给新模型打旧补丁

他的观点很直接：

• “Plan Mode 是给老模型打的补丁，新模型不需要你帮它规划。”

当大家还在卷“怎么写更好的计划提示词”，他直接把这一步跳过。

潜台词是：把计划做成强约束，很多时候是在 替模型做低质量的提前承诺。后续一旦发现理解偏了，修正成本更高。

不用 MCP：大多数工具就该是 CLI

更狠的一句：

• “大多数 MCP 应该是个 CLI。”

社区在搞生态、搞协议、搞统一入口，他的判断是：很多场景没必要先协议化。

如果一个工具调用，最终就是“传参→执行→读 stdout/stderr→返回结果”，那先把它变成稳定 CLI，往往比先把它包装成复杂中间层更划算。

不用 RAG：把事说清楚，比搭检索强

一句话：

• “Just talk to it.”

这不是否定检索增强，而是强调优先级： 把需求、约束、上下文讲清楚，通常比“先搭一套检索增强架构”更能立刻提升成功率。

不用子 Agent：多智能体？开几个终端就行

别人做多 Agent 编排器，他开几个终端窗口：

• 一个窗口跑一个 Agent
• 各干各的
• 简单粗暴

这听起来像偷懒，但它有个现实优势： 可观察性强、可控性强、失败隔离强。

---

2）这些选择背后，其实是同一个敌人：中间层

把这堆“反最佳实践”放一起，会发现他砍掉的都是同一类东西：

• Plan Mode：你和模型之间的中间层
• MCP：工具调用的中间层
• RAG：知识获取的中间层
• 编排器：多 Agent 之间的中间层

每多一层抽象，就多三类成本：

1. 出错点：多一层就多一层失败模式
2. 调试面：多一层就多一层日志、状态、边界条件
3. 心智负担：你得先理解这层，再去理解业务

所以他的逻辑其实很朴素：

模型能力已经够强了。 很多脚手架与其说是在帮它，不如说是在挡它。

---

3）为什么这路子能跑通？因为它不是“想出来的”，是“试出来的”

这个判断不是拍脑袋来的。 据说 OpenClaw 爆火之前，他做过 43 个项目：

• 终端优先
• 快速验证
• 不搞花活

这类人往往形成一套条件反射：

• 先跑通最短链路
• 再把问题打碎
• 最后才考虑抽象与平台化

换句话说：先要“能用”，再要“优雅”。

---

4）续写：从工程角度看，这套方法更像“降维打击”

所谓“最佳实践”，经常默认一个前提： 团队大、协作复杂、需求稳定、质量门槛极高。

但个人/小团队做 AI 产品，最稀缺的资源不是规范，是：

• 反馈速度
• 试错次数
• 问题定位效率

中间层越多，反馈闭环越长。 闭环一长，就会出现一种最恶心的现象：

• 明明是需求没讲清
• 结果去调 Plan
• 再去调 RAG
• 再去调工具协议
• 最后把自己调成“平台工程师”

产品没做出来，仪式感倒是拉满。

这也是为什么他更偏向“直连”：

• 能直接对话，就别先写一堆 plan prompt
• 能直接跑命令，就别先做一套工具调用中台
• 能把上下文塞清楚，就别先上检索系统

一句话：优先消灭链路长度。

---

5）经验与感想：AI 时代的工程能力，正在从“搭架子”转向“控变量”

传统工程里，能力经常体现为：

• 设计更漂亮的抽象
• 搭更完整的架构
• 把边界画得更清楚

AI 时代，另一个能力更值钱：

• 识别当前问题的“主因变量”
• 用最短路径验证
• 让失败尽快暴露

中间层往往会把变量混在一起：

• 模型理解错了？
• 工具返回慢了？
• 检索召回偏了？
• 编排器状态乱了？

最后就变成： “看起来每个模块都没问题，但整体就是不对。”

所以这套“砍中间层”的哲学，本质是在追求：

• 更清晰的因果链
• 更短的调试路径
• 更低的系统熵

少即是多，不是鸡汤，是维护成本的数学题。

---

6）怎么落地：一套“反过度工程化”检查清单

下面这套清单，适用于任何 AI 编程/Agent 项目（尤其是 0→1）：

先问 3 个问题

1. 这层中间层解决的是什么具体失败？（要能说出失败案例）
2. 如果不加它，最短路径能不能先跑通？
3. 加了它之后，调试成本会上升多少？有没有观测闭环？

再按顺序上工具（别跳级）

• 第 1 级：直接对话 + 明确约束（先把事讲清楚）
• 第 2 级：稳定 CLI 工具（可复用、可观测）
• 第 3 级：必要的结构化（配置/模板/最小权限）
• 第 4 级：再谈协议/生态/平台化

一个很实用的“停手条件”

• 只要问题还能通过“讲清楚 + 少量脚本 + CLI”解决，就别急着上编排器和 RAG。

---

推荐标签：#OpenClaw #AI编程 #Agent #工程实践 #过度工程化 #CLI