OpenClaw 是 vibe Coding 出来的吗?

OpenClaw 火了之后，很多人把它当成 vibe coding 的代表案例。

一个人，一个 AI，一个 Agent 产品。

听起来像是：

“以前需要一个团队几个月做的软件，现在一个人靠自然语言就能完成。”

但如果仔细看 OpenClaw 的诞生过程，会发现事情没有这么简单。

OpenClaw 的作者 Peter 不是“不会写代码的人，让 AI 自动生成了一个复杂产品”。

它更像是：

一个有多年工程经验的人，把 AI 当成自己的超级开发团队，通过快速试错、真实使用和持续演化，把一个 Agent 系统一步步构建出来。

这两者差别非常大。

OpenClaw 的开发方式，更像产品经理 + 架构师 + 测试人员

传统软件开发：需求分析--产品设计--技术设计--开发--测试--上线。

但 Agent 产品的开发方式正在变化。

尤其是个人开发者做 AI 产品时，流程更像：想法--快速实现--自己使用--发现问题--继续修改--再次使用--不断演化。

OpenClaw 很大程度符合这种模式。

Peter Steinberger 并不是先写一份完整 PRD，然后按照设计文档开发一个 Agent 平台。

更像是：“我希望有一个真正属于自己的 AI 助手。”

于是先让 AI 帮自己实现。

使用过程中发现：

为什么它不知道以前发生过什么？

为什么能力不能扩展？

为什么工具调用不可控？

为什么执行任务中断后无法恢复？

这些问题逐渐推动系统增加：Memory-Skill-Workspace-Tool-Permission-Runtime。

最终形成今天看到的 OpenClaw。

所以很多功能不是规划出来的，而是在真实使用过程中被“逼出来”的。

那 Peter 是不是完全 vibe Coding？

某种程度上，是。

但不是很多人理解的那种 vibe coding。

普通理解的 vibe coding：

提出需求-AI 生成代码-复制运行-能跑就结束。

这种方式做 Demo 很快。

但是做生产系统，很容易失控。

因为 AI 很擅长解决：“这个功能怎么实现。”

但不擅长决定：“这个能力应该放在哪里。”“这个架构未来如何演进。”“这个设计会不会三个月后变成技术债。”

Peter 的优势在于，他不是把 AI 当程序员，而是把 AI 当一个执行能力极强的工程伙伴。

他的工作从：写每一行代码。

转变成：定义系统方向--控制架构边界--验证最终行为。

AI Coding 最大的问题：代码会不会越来越乱？

这是很多人质疑 vibe coding 的核心。

如果每个功能都让 AI 增加一点代码：今天加微信，明天加邮件，后天加权限。

最后可能变成：一个几千行的大文件，无数 if，无数临时方案。

任何系统都会发生这种问题。

传统开发如此，AI 开发也如此。

AI 甚至可能让这个问题更严重。

因为 AI 太擅长打补丁。

所以关键不是：AI 能不能写代码。

而是：有没有能力控制系统演化。

OpenClaw 如何避免架构失控？

第一，稳定核心，外围扩展。

Agent 系统变化非常快。

如果每增加一个能力，都修改核心 Runtime，系统一定会腐化。

好的设计是：核心保持稳定，变化能力插件化。

例如：Agent Runtime。

下面连接：Skill。Tool。Channel。Memory。

不同能力通过接口扩展，而不是不断修改核心逻辑。

这和传统软件的插件架构类似。

第二，把变化从代码迁移到配置和上下文。

传统软件：行为主要由代码决定。

Agent 软件：行为由更多东西共同决定：代码。Prompt。Skill。Memory。Workspace。配置文件。

例如：

一个 Agent 的工作方式，不一定需要重新开发。

可能只需要修改：AGENTS.md。Skill 描述。权限策略。上下文文件。

这降低了频繁修改核心代码的需求。

第三，验证对象从代码变成行为。

传统开发：Review 代码。

AI 时代：Review 系统行为。例如新增一个工具。

重点不是：代码写得漂亮吗？

而是：Agent 是否正确调用？有没有破坏已有能力？是否存在安全风险？任务是否完成？

所以测试方式也会变化。

未来更多是：任务级测试。场景级测试。Agent 行为测试。

为什么 OpenClaw 选择 TypeScript 和 Node.js？

很多人看到 OpenClaw 使用 TypeScript，会疑惑：为什么不是 Python？为什么不是 Java？

其实原因和 Agent 特性有关。

TypeScript 是一种编程语言。Node.js 是运行环境。

关系类似：TypeScript 写代码。Node.js 执行代码。

Agent 本质是一个高度异步系统。

比如：用户提出任务。Agent 调模型。模型返回工具调用。调用文件系统。调用外部 API。等待结果。继续推理。

整个过程大量依赖：消息。事件。异步调用。

Node.js 非常适合这种场景。

另外，TypeScript 对 Agent 开发还有一个优势：Agent 世界大量基于：JSON。API。Schema。Message。Tool。

这些结构和 TypeScript 类型系统非常匹配。

端侧 Agent 为什么喜欢 Electron？

很多本地 Agent 会采用：Electron + TypeScript + Node.js。

原因很简单。

Electron 本质是：浏览器界面。加上 Node.js 本地能力。

一个端侧 Agent 可以变成：Electron负责 UI。Node.js负责 Agent Runtime。Native 模块负责系统能力。Sandbox负责安全隔离。

例如：一个桌面 Agent：

用户聊天界面。

↓

Agent Runtime。

↓

MCP Tool。

↓

Sandbox。

↓

操作系统。

这和 OpenClaw 的思路非常接近。

未来 Agent 技术栈会怎么发展？

Agent 不会只有一种技术栈。

不同层会使用不同技术。

应用层：TypeScript。Node.js。Electron。

负责：Agent 产品。用户交互。工具编排。

云端 Agent：Python。FastAPI。LangGraph。

负责：模型调用。复杂流程。

企业系统：Java。Go。

负责：权限。治理。高并发。

底层 Runtime：Rust。C#。C++。

负责：Sandbox。系统能力。安全控制。

未来 Agent 不是一个框架解决全部问题。

更像一个新的软件分层：上层是 Agent。中间是 Runtime。底层是执行环境。

OpenClaw 真正代表什么？

OpenClaw 证明的不是：“不会写代码的人也能做复杂软件。”

它证明的是：“优秀工程师借助 AI，可以把过去一个团队完成的软件开发过程压缩到个人尺度。”

未来开发者的核心能力会发生变化。

以前：写代码。

以后：设计系统。定义边界。管理 Agent。验证结果。控制演化。

代码会越来越像一种执行能力。

真正稀缺的是：知道应该创造什么。知道系统应该如何成长。