文章

OpenClaw：技术泡沫下的明星项目

发表于
Preview Image
作者 唐玥璨
24 分钟阅读
OpenClaw：技术泡沫下的明星项目

前言

最近，一个名为 OpenClaw 的开源项目在 GitHub 上迅速蹿红，Star 数甚至一度超越了 Linux 内核。作为一个长期关注 AI 领域的技术从业者，我花了些时间研究了这个项目的架构和实现，得出的结论却让我感到一丝不安：这个项目本质上并没有任何划时代的技术创新，它的火爆更像是这个时代技术浮躁的一个缩影，让人不禁想起 2000 年的 .com 泡沫。

OpenClaw 是什么？

简单来说，OpenClaw 是一个 AI 助手框架，它允许用户通过各种即时通讯软件（如 Telegram、Discord、Slack 等）与大型语言模型进行交互。项目宣传的核心卖点包括：

  • 多平台 IM 集成
  • 可扩展的 Skill 系统
  • 持久化记忆能力
  • 角色扮演功能

听起来很美好，但当我们剥开这些华丽的外衣，会发现其技术内核异常单薄。

技术解构：没有创新的创新

核心本质：模型调用工具

OpenClaw 的核心功能可以概括为一句话：它是一个大型语言模型的调用封装工具。仅此而已。

项目内部所有的”智能”表现——无论是回答问题、执行复杂任务还是进行多轮对话——全部来自于底层接入的大语言模型（如 Claude、GPT 等）。OpenClaw 本身并不具备任何推理能力、知识储备或决策智能，它只是将用户的输入格式化后发送给模型，再将模型的输出转发给用户。

这就像是一个精美的电话转接系统——无论通话内容多么精彩，功劳都应该归于通话双方，而非中间的交换机。

Skill 系统：提示词工程的包装

OpenClaw 引以为傲的 Skill 系统，本质上是什么？

是提示词模板（Prompt Template）。

每一个 Skill 都是一段预先编写好的提示词，用于指导模型在特定场景下如何回应。例如，一个”天气查询”Skill 可能包含这样的提示词：

1
2
3
4

你是一个天气助手。当用户询问天气时，你应该：
1. 提取用户提到的地点
2. 调用天气 API 获取数据
3. 用友好的方式回复用户

这有什么技术创新吗？完全没有。提示词工程（Prompt Engineering）是每一个使用大模型的人都会做的基础工作，OpenClaw 只是将其模块化、文件化了而已。

解剖 OpenClaw：提示词缝合怪的真实面目

为了更直观地证明 OpenClaw 的技术含量之低，让我们解剖它的核心文件结构。OpenClaw 使用一系列 Markdown 文件作为”配置”，但这些文件本质上就是提示词模板的堆砌：

AGENTS.md - 行为准则提示词

这个文件定义了 AI 助手的基本行为规则，内容类似于：

1
2
3
4

## 每次会话必读
1. 读取 SOUL.md —— 了解你是谁
2. 读取 USER.md —— 了解你在帮助谁
3. 读取 memory/YYYY-MM-DD.md —— 获取近期上下文

这有什么技术含量？这只是把系统指令写成了文件而已。任何一个程序员用 10 分钟就能写出同样的逻辑：读取文件 → 拼接字符串 → 塞给模型。

SOUL.md - 人格设定提示词

所谓的”灵魂”文件，内容通常是：

1
2
3
4
5
6
7

# SOUL.md - Who You Are

## Core Truths
**Be genuinely helpful, not performatively helpful.** 
Skip the "Great question!" and just help.

**Have opinions.** You're allowed to disagree, prefer things.

翻译一下：这就是一段系统提示词（System Prompt），告诉模型”你要有个性、要真诚帮助用户”。没有任何状态机、没有情感模型、没有记忆网络——就是纯文本。

IDENTITY.md - 身份定义提示词

1
2
3
4
5

# IDENTITY.md - Who Am I?

- **Name:** 用户的专属助理
- **Identity:** 忠诚可靠的助手
- **Emoji:** 🤖

这甚至不能称之为”配置”，这就是角色扮演的提示词：”你的名字是 X，你的身份是 Y”。幼儿园水平的提示词工程。

MEMORY.md & USER.md - 上下文注入提示词

这两个文件分别存储”长期记忆”和”用户信息”。实现方式？

1
2
3
4

# MEMORY.md
## 核心身份认知
- 用户明确要求：牢记"助手"身份
- 关键事件：2026年2月27日整理了某报告

这就是把对话历史写进文件，每次请求时读取并拼接到提示词里。没有任何向量数据库、没有 RAG 检索、没有智能摘要——就是简单的文件读写 + 字符串拼接。

HEARTBEAT.md & TOOLS.md - 定时任务与工具提示词

HEARTBEAT.md 定义定时检查的任务列表，TOOLS.md 记录工具使用偏好。本质上都是：把本该写在代码里的逻辑，搬到了 Markdown 文件里。

总结：手搓一个 OpenClaw 需要多久？

让我们算一笔账：

  • 文件读写功能：Python 的 open() 函数，5 行代码
  • 提示词拼接：字符串的 join() 方法，3 行代码
  • 调用模型 API：requests.post()，10 行代码
  • IM 集成：各平台的 Webhook/Bot API，每个平台 50 行代码

总计：一个合格的程序员，用 200 行代码、2 小时时间，就能手搓一个功能等价的 OpenClaw。

这不是夸张。OpenClaw 的核心价值——提示词管理——没有任何技术壁垒。它的护城河是什么？是 Star 数、是社区热度、是包装精美的文档，而非技术本身。

Function Call：MCP 协议下的工具调用

OpenClaw 的另一个宣传点是”Function Call”功能，即模型可以调用外部工具（如搜索、计算、API 调用等）。

但这同样不是 OpenClaw 的创新。Function Call 是 Anthropic、OpenAI 等模型厂商在 2023-2024 年间就推出的原生能力。OpenClaw 所做的，只是将这些能力通过配置文件暴露出来，让普通用户更容易使用。

更具体地说，OpenClaw 使用的是 MCP（Model Context Protocol）协议——这是 Anthropic 推出的一种标准化接口，用于让模型与外部工具进行交互。MCP 定义了工具的描述格式、调用方式和返回规范。

OpenClaw 的”Skill”本质上就是 MCP 协议下的功能脚本：

1
2
3
4
5
6
7
8
9
10
11
12

# 一个典型的 MCP 工具定义
weather_tool = {
    "name": "get_weather",
    "description": "获取指定城市的天气信息",
    "parameters": {
        "city": {"type": "string", "description": "城市名称"}
    }
}

# 对应的执行函数
def get_weather(city: str) -> str:
    return requests.get(f"https://api.weather.com/{city}").text

这就是全部。OpenClaw 没有实现任何协议解析、没有开发任何调用机制——它只是使用了 Anthropic 现成的 MCP SDK，把函数定义写成了 JSON/YAML 格式的配置文件。

换句话说，OpenClaw 在这里扮演的角色是能力的搬运工，而非能力的创造者。

记忆系统：最基础的上下文管理

OpenClaw 声称拥有”持久化记忆”能力，能够让 AI 助手记住用户的偏好、历史对话等信息。

实现方式是什么？

将对话历史保存到文件或数据库中，每次请求时作为上下文一起发送给模型。

这是大模型应用开发中最基础、最通用的做法。没有任何算法创新，没有向量检索优化，没有智能的记忆筛选机制——只是简单的”把之前的对话附带上”。

角色扮演：提示词的魔术

OpenClaw 的”角色扮演”功能允许用户定义 AI 的人格、语气、行为方式等。

实现方式？

在系统提示词中加入角色描述。

例如：

1

你是一个专业的程序员助手，说话简洁直接，不喜欢废话。

这就是全部。没有任何情感计算模型，没有个性演化算法，没有多智能体交互框架——只是一段静态的文本描述。

仿品泛滥：零门槛的必然结果

OpenClaw 的技术门槛之低，直接导致了 GitHub 上出现了大量的仿造项目。这些项目大多只是改了名字、做了微不足道的优化，却同样获得了大量关注：

NanoClaw

号称”更轻量级的 OpenClaw”，核心改动：

  • 移除了部分”冗余”的 Markdown 配置文件
  • 将 Python 代码从 500 行压缩到 300 行
  • 声称”性能提升 50%”

实际：只是删掉了几个注释和空行。

IronClaw

主打”企业级”定位，新增功能：

  • 支持 Docker 部署（其实就是写了个 Dockerfile）
  • 增加了”审计日志”（把对话记录多存了一份）
  • 提供了 Web 管理界面（用 Gradio 搭的）

实际：包装大于实质，企业级特性就是多几个配置文件。

ZeroClaw

宣称”从零开始，不依赖任何框架”，特点：

  • 完全自研（其实就是把 OpenClaw 的代码重写了一遍）
  • 更快的启动速度（去掉了几个 time.sleep）
  • 更小的体积（没装 dev 依赖）

实际：重复造轮子，还造得更差。

PicoClaw

面向”树莓派和嵌入式设备”优化：

  • 支持 ARM 架构（Python 本来就能跑）
  • 内存占用更低（限制了上下文长度）
  • 离线模式（其实就是没联网时返回固定提示）

实际：噱头大于实用。

仿品现象说明了什么？

这些项目的出现，恰恰证明了 OpenClaw 的技术壁垒几乎为零：

  1. 复制成本极低：阅读源码 → 复制粘贴 → 改个名字 → 新项目诞生
  2. 差异化微不足道：所谓的”优化”大多是配置层面的调整
  3. 关注度与质量无关：仿品们同样能获得大量 Star，说明社区更关注概念而非实现

这就像是在 .com 泡沫时期，随便一个”互联网+”的概念就能获得投资——今天，随便一个”AI+”的项目就能获得 Star。

真正的亮点：IM 集成

说了这么多”不是什么”，那么 OpenClaw 真正有价值的地方在哪里？

答案是：即时通讯软件的集成。

OpenClaw 确实做了一件有意义的事情——它降低了普通用户使用 AI 的门槛。通过将 AI 助手接入 Telegram、Discord、Slack 等日常使用的通讯工具，用户无需安装额外的应用、学习新的界面，就能与 AI 进行交互。

对于非技术用户来说，这是一个不错的用户体验改进。但这属于产品层面的优化，而非技术层面的创新。

超越 Linux：泡沫的信号

让我们回到文章开头提到的现象：OpenClaw 的 GitHub Star 数超越了 Linux 内核。

这是一个值得深思的信号。

Linux 内核是什么？它是现代计算基础设施的基石，支撑着全球数十亿台设备，从智能手机到超级计算机，从嵌入式系统到云计算平台。它凝聚了三十多年的工程智慧，解决了无数复杂的技术难题，是软件工程史上的里程碑。

OpenClaw 是什么？它是一个调用 API 的胶水代码集合，核心创新接近于零。

当后者的关注度超过前者，这说明了什么？

技术浮躁的时代

我们正生活在一个技术浮躁的时代：

  1. 概念炒作大于实质：只要项目与”AI”、”大模型”、”智能体”等热门词汇沾边，就能获得大量关注，无论其技术深度如何。

  2. 短期热度高于长期价值：人们更关注项目的”星标数”、” trending 排名”，而非其对技术生态的真正贡献。

  3. 包装重于内核：精美的文档、炫酷的 Demo、活跃的社区，往往比扎实的技术实现更能吸引眼球。

.com 泡沫的回响

2000 年的 .com 泡沫中，大量没有盈利模式、没有技术壁垒的网站获得了惊人的估值，仅仅因为它们”在互联网上”。当泡沫破裂时，绝大多数项目灰飞烟灭，只有真正有技术实力和商业模式的公司存活下来。

今天的 AI 领域正在经历类似的过程：

  • 任何接入 GPT API 的项目都敢自称”AI 公司”
  • 简单的提示词包装被包装成”智能体框架”
  • 基础的功能集成被吹嘘为”下一代交互范式”

OpenClaw 的火爆，正是这种泡沫的缩影。

反思：我们需要什么样的创新

我并非要否定 OpenClaw 的价值。作为一个开源项目，它确实为某些用户提供了便利，也为开发者提供了参考实现。但我们需要清醒地认识到：

OpenClaw 不是技术创新的典范，而是技术整合的样本。

真正推动行业进步的，是像 Anthropic、OpenAI 这样投入巨资研发基础模型的机构；是像 Transformer、Diffusion 这样开创性的算法突破；是像 Linux、Kubernetes 这样解决实际工程难题的基础设施。

如果我们把掌声和关注都给到 OpenClaw 这样的项目，而忽视了真正的技术创新，那么整个行业的资源分配就会发生扭曲。资本会流向包装和炒作，而非研发和突破。最终，当泡沫破裂时，受损的是整个技术生态。

本文的元叙事：一个自我解构的实验

具有讽刺意味的是，这篇文章本身就是由 OpenClaw 编写的。

作者只是提供了核心观点和一些论点，OpenClaw 接收这些信息后，完成了以下工作：

  1. 文章撰写 - 将零散的观点组织成结构化的长文
  2. 格式校验 - 确保符合 Jekyll 的 Markdown 规范
  3. 代码合并 - 将多次修改的内容整合到同一文件
  4. 本地测试 - 启动 Jekyll 服务，打开浏览器预览&测试效果
  5. 提交 PR - 调用 Git 命令提交到仓库
  6. CI/CD 触发 - 通过 GitHub Actions 自动部署
  7. 在线测试 - 打开浏览器预览并且验证生产环境是否正常

听起来很强大，对吧？但请不要被这种”自动化工作流”迷惑。

任何一个 Agent 框架都可以实现这些步骤：

  • Qwen Agent（阿里开源）- 同样支持多步骤任务编排
  • AutoGen（微软开源）- 多 Agent 协作的鼻祖
  • AutoGPT（早期项目）- 两年前的项目就已经能做到这些

OpenClaw 在这里展示的能力，不过是大模型 + 文件操作 + API 调用的组合——这正是我们整篇文章批判的”提示词缝合”模式。

这篇文章的存在，本身就是一个完美的例证：

  • 它证明了 OpenClaw 确实能完成一些实用任务
  • 它也证明了这些任务没有任何技术门槛
  • 最重要的是，它证明了批判 OpenClaw 的文章可以由 OpenClaw 自己写出

这不是悖论，这是现实：工具的中立性。一把刀可以用来切菜，也可以用来伤人；一个提示词框架可以用来写批判自己的文章，也可以用来生成垃圾内容。

关键在于使用工具的人，以及我们对工具的期待。

如果我们期待 OpenClaw 带来技术革命，我们会失望——正如这篇文章所论证的。

如果我们只是把 OpenClaw 当作一个稍微聪明一点的自动化脚本，那它是合格的——正如这篇文章的产出过程所展示的。

结语

OpenClaw 的流行是一个值得警惕的信号。它提醒我们，在技术狂热的浪潮中保持清醒是多么重要。

作为技术从业者，我们应该：

  • 区分整合与创新：能够调用 API 不是创新，创造新的 API 才是。
  • 关注内核而非包装：精美的文档不能替代扎实的技术实现。
  • 警惕概念炒作：热门词汇不等于实际价值。
  • 尊重真正的工程：Linux 内核这样的项目值得我们更多的关注和敬意。

技术的进步需要泡沫带来的热情和资本，但更需要脚踏实地的工程和真正有价值的创新。希望当这波 AI 热潮退去时，我们留下的不仅仅是几个 Star 数很高的仓库，而是真正推动人类文明进步的技术成果。

技术, 推荐
OpenClaw AI 技术泡沫 大模型 开源
本文由 唐玥璨 版权所有