OpenClaw 两个月换六个名字：AI Agent 工具难在边界，不在命名

两个月，六个名字。OpenClaw 这段 Git 历史乍看像开源项目改名小剧场，但真正有用的信息藏在 README 第一行。

Simon Willison 为 PyCon US 闪电演讲做准备时，用 first_line_history.py 追溯 OpenClaw README 的第一行变化。Git 历史显示，从 2025-11-24 到 2026-01-30，名称链条是：Warelay → CLAWDIS → CLAWDBOT → Clawdbot → Moltbot → OpenClaw。

我更在意的不是“怎么又改名了”。而是每次改名时，它都在换一种解释自己的方式：通信工具、AI Agent 网关、个人 AI 助理。名字在动，产品边界也在动。

README 第一行改了什么

根据 OpenClaw README 的 Git 历史，first_line_history.py 提取的是第一行标题变化。这个位置很关键。它通常是项目对外说的第一句话，也是维护者最想让别人秒懂的那句话。

这段变化可以压成一张表：

这条线不复杂。

最早是 WhatsApp Relay CLI。边界窄，但清楚：和 WhatsApp 收发、转发、自动回复有关。

随后变成 WhatsApp 与 Telegram Gateway for AI Agents。叙事大了一圈：它不只是通信工具，而是 Agent 接入消息渠道的入口。

再往后，定位变成 Personal AI Assistant。这个词最顺耳，也最危险。用户一听就懂，但期待会被拉高：不只是接消息，还要理解任务、执行动作、长期可用。

“名不正则言不顺。”放在这里不玄。这里的“名”不是商标，而是验收标准。你叫网关，别人看稳定接入；你叫机器人，别人看自动执行；你叫个人助理，别人看任务闭环。

这对谁有影响

先说限制：这段材料只证明 README 的名称和定位在变。它不能证明项目失败、团队混乱、融资压力，也不能证明用户不买账。把改名直接读成事故，是过度推理。

但它至少说明一件事：早期 AI Agent 工具很容易在三个叙事之间摇摆。

对关注 AI Agent 工具的开发者来说，这类变化不是八卦。它会影响你要不要接入、要不要写插件、要不要把它放进自己的工作流。

我的建议很简单：如果你需要的是通信入口，就按“网关”标准看它。看接口、部署、消息可靠性、平台适配。不要因为 README 写了 Personal AI Assistant，就默认它已经能承担完整助理工作。

对做开源项目产品化的人，这段历史也有提醒。早期改名可以理解，试定位也正常。但每次换叙事，都会改变外界的预期。开发者可能愿意忍受工具粗糙，不太愿意忍受边界反复漂移。

企业采用者更现实。遇到这类早期 Agent 工具，最好先观望或小范围试用，不要急着迁移关键流程。原因不是它一定不行，而是定位还在收敛时，接口、路线和维护重点都可能跟着变。

接下来该看什么

OpenClaw 这段 README 历史像一层小化石。它没有给出项目成败，却留下了产品自我解释的轨迹。

接下来最该看三件事。

• 名称是否稳定.OpenClaw 是否继续作为主名出现，还是继续调整叙事。
• 定位是否收窄.它到底主打通信网关、机器人，还是个人 AI 助理。
• README 第一行是否回答具体问题.接入什么、替谁工作、完成哪类任务。

我不反对早期项目改名。铁路、电力、互联网早期都有一堆叫法，很多技术都是先被误解，再慢慢找到市场语言。不完全一样，但有一点相通：新技术刚出来时，命名常常不是包装，而是摸边界。

AI Agent 工具现在也卡在这里。底层能力像网关，中层形态像机器人，外层故事又想做助理。三层都能讲，但三层一起讲，产品就容易发虚。

看早期 AI 项目，别只看 demo 炫不炫。先看它有没有稳定回答三个问题：我接入什么，替谁工作，完成哪类任务。

答不上来，名字越大，欠账越多。