为什么中国大厂几乎集体欢迎 OpenClaw？

Editor's Note

🗓️ 2026.03.10 | Issue#348

腾讯工程师在深圳总部楼下摆摊，免费帮人安装 OpenClaw；几个月前，字节的豆包手机助手却刚上线就被微信、淘宝等平台集体反制。与此同时，Kimi、MiniMax 和云厂商们几乎同时扑了上来，小米也把类似能力直接做进了手机系统。真正值得追问的问题是：为什么这一次，中国大厂几乎集体欢迎它。

3 月 6 日，深圳腾讯大厦楼下排起了长队。

来的人带着 MacBook、NAS、迷你主机，等着腾讯云工程师现场帮他们安装 OpenClaw。预约号很快发完，腾讯云随后披露，云上「养虾人」规模已经突破 10 万。放在任何一个 AI 产品身上，这都已经足够像一个「爆款时刻」。

但这件事真正值得写的，不是深圳排队本身。

因为就在几个月前，另一种「AI 替你操作应用」的产品在中国刚刚遭遇了完全相反的命运。字节跳动和中兴合作推出的豆包手机助手，试图用 GUI agent 直接操作微信、淘宝等 App。它的能力想象力并不比 OpenClaw 小，但上线没多久，就先后碰上了强制退出登录、验证码拦截和功能限制。

同样是让 AI 替用户做事，为什么一个被围堵，一个却被腾讯云、阿里云、百度智能云、MiniMax、Kimi，甚至手机厂商几乎集体欢迎？

如果只看社交媒体，你很容易得出一个表面的解释：中国用户对 Agent 太狂热了，所有人都怕掉队。

这个解释当然不是全错。小红书、闲鱼、B 站和抖音上，围绕 OpenClaw 的「保姆级教程」「上门安装」「远程代装」几乎一夜之间铺开。很多付费用户买下的，并不是一套已经验证过的工作流；他们买的是一个心理位置：先拥有，再研究。多篇报道都提到，很多来安装的人其实并没有明确要让它做什么。

这恰恰说明，深圳排队本身不是答案。

如果一个产品的真正动力只来自用户 FOMO，你很难解释为什么腾讯云愿意在线下摆摊、为什么阿里云和百度智能云几乎同步上线一键部署、为什么 Kimi 和 MiniMax 会这么快把它收编进自己的产品体系。用户可以制造热度，但解释不了供给侧为什么几乎同时加速下注。

真正的答案在更深一层：中国市场真正拥抱的，是一种几乎所有关键参与者都能从中获利的 AI 执行层架构。OpenClaw 只是这个架构眼下最醒目的载体。

OpenClaw 最先打动的是供给侧

先看云厂商为什么这么积极。

过去两年，中国科技公司在 AI 基础设施上投入巨大，但聊天机器人这种产品形态很难真正消耗掉已经建好的推理能力。一个普通用户问几句、写一封邮件、做一页 PPT，token 消耗有限，使用时长也很短。对于已经投入巨额资本开支的云厂商来说，这种需求密度远远不够。

OpenClaw 改变的是这件事。

它更接近一个持续运行的执行层。它会拆解任务、反复调用模型、接工具、做搜索、写代码、出错后重试。对云厂商而言，这意味着收入结构从单次调用，变成了「服务器 + 模型 API + 存储 + 网络 + 运维」的长链条消耗。腾讯云、阿里云和百度智能云争抢的焦点，也不在 OpenClaw 这个项目本身；它们盯上的是围绕 Agent 执行层形成的新「水电煤」位置。

这也解释了为什么它们的动作如此务实：它们没有急着重新发明一个 OpenClaw，而是先把一键部署、预配置镜像、可视化面板和默认模型接入做出来。谁先把用户和开发者迁进自己的云环境，谁就先拿到 Agent 时代的基础设施入口。

模型厂商看到的是另一层机会。

Kimi、MiniMax、智谱这类创业模型公司过去一直有一个相同难题：模型能力并不差，但缺少稳定的分发入口和高频的 C 端消费场景。聊天机器人可以带来流量，却未必能带来足够可持续的收入；真正高频的消费，反而出现在 Agent 这种持续运行、反复调用模型的框架里。

OpenClaw 把模型竞争从「谁回答得最聪明」，部分改写成了「谁更便宜、更耐跑、更适合长时间执行任务」。这恰好是中国模型相对更容易建立优势的维度。结果也很直接：OpenRouter 的排行榜迅速被 Kimi K2.5、MiniMax M2.5、GLM-5、DeepSeek V3.2 这类中国模型占据。Kimi 很快推出 Kimi Claw，MiniMax 紧接着推出 MaxClaw，本质上都是在做同一件事：先借 OpenClaw 获客，再把用户收回自己的托管服务里。

换句话说，OpenClaw 给这批模型公司提供了一条它们自己很难单独建起来的分发通道。

豆包被拦，OpenClaw 被抱，决定性变量是位置

理解了供给侧为什么积极，才能看懂那组最重要的对照：豆包手机为什么被拦，OpenClaw 为什么被抱。

表面上看，两者做的是同一件事，都是让 AI 替用户操作软件、完成任务。但它们在生态里的位置完全不同。

豆包手机助手走的是 GUI agent 路线。它读取界面、模拟点击，用系统级权限穿透不同 App。这条路线的野心也最明显：一旦用户把任务先交给 AI，再由 AI 决定调用哪个平台、走哪条链路，那么微信、淘宝、美团这类超级 App 就会从用户直接面对的入口，降级成后台服务节点。

这正是它最危险的地方。

豆包真正触发反弹的地方，在于它站到了用户与 App 之间，试图成为新的意图分发层。对超级 App 来说，这等于有人要在自己的围墙花园外面再修一个收费站。被围堵几乎是必然反应。

OpenClaw 的位置则完全不同。

它是开源框架，本地部署，用户自己选择模型、自己选择云环境，也没有哪一家单独垄断这个中间层。它当然也在做「执行层」，但它暂时没有把某一个巨头放到「统一收费站」的位置上。相反，它为云厂商带来算力消耗，为模型厂商带来 token 和用户，为内容平台带来教程流量，为代装市场带来服务收入。

所以豆包的麻烦，核心落在它的生态身份不可接受。OpenClaw 的优势也不来自更高的成熟度或更强的安全性；它当前最重要的特征，是它对既有利益分配的扰动最小。

这才是两者命运分化的真正原因。

OpenClaw 真正贵的，不只是 token，还有数据

如果故事只停在「现金流」，那还不够。

OpenClaw 被低估的另一层价值，是轨迹数据。

聊天机器人留下的是问答文本，Agent 留下的则是完整的任务轨迹：用户如何描述目标，模型如何拆解步骤，调用了哪些工具，哪里出错，用户如何纠偏，什么样的执行链路最终成功。对于想做下一代 Agent 模型的公司来说，这类数据比普通网页文本更稀缺，也更接近「AI 如何真正学会做事」。

这意味着，大厂推广 OpenClaw 的意义并不只是把今天的算力卖出去，也是提前争夺下一代 Agent 模型最关键的训练材料。用户以为自己在获得一个免费的数字员工，厂商看到的则是另一个维度：执行数据的众包采集。

一旦从这个角度看，腾讯、阿里、百度、Kimi、MiniMax 这些动作就更容易理解了。它们争夺的，也不只是这一轮热度；更关键的是 Agent 时代谁能先积累最多的真实执行反馈。

但 OpenClaw 很可能不是终局产品

这也是为什么我不认为 OpenClaw 当前的爆红，等于它已经证明自己会成为大众市场的最终形态。

恰恰相反，OpenClaw 更像一个过渡性原型：它负责教育市场，证明用户愿意把任务交给 AI，证明 Agent 可以拉高 token 消耗，证明执行层比聊天框更接近下一阶段的竞争焦点。但真正更强的位置，仍然在默认入口和系统层。

小米最近推出的 Xiaomi miclaw 就说明，终端厂商已经在沿着这条线往前走。它直接把 Agent 做进手机操作系统，能调用系统工具、读取个人上下文、联动 IoT 设备。和需要手动部署、自己维护的 OpenClaw 相比，系统级 Agent 一旦成熟，位置天然更强，摩擦也更低。

这会把竞争推向下一阶段：竞争焦点将从谁能提供一个 Agent 框架，转向谁能把 Agent 变成操作系统默认具备的能力。

从这个角度看，OpenClaw 的历史意义，很可能体现在它提前帮整个中国 AI 产业回答了一个问题：什么样的执行层架构最容易先被现有生态接受并迅速放大。

答案不是最强、最封闭、最想独占入口的那一种。

答案反而是最开放、最容易让各方先赚钱、最不急着挑战现有平台统治的那一种。

深圳腾讯大厦楼下那条队伍，真正排队的并不只是想装一个新工具的用户。

排在那里的，还有云厂商对推理需求的焦虑，模型公司对分发入口的饥渴，终端厂商对系统级 Agent 的提前布局，以及整个中国 AI 产业对「聊天框之后是什么」的集体试探。

所以 OpenClaw 在中国的意义，在于它证明了一种新的执行层可以在不直接挑战旧秩序的前提下，被整个生态一起推起来。它呈现的是产业加速靠拢的一条路径，而不是 Agent 已经成熟的终局。

豆包手机太像一座新的收费站，于是被拦下。

OpenClaw 更像一条所有人都先能跑车的高速公路，于是被欢迎。

这大概就是为什么，中国大厂几乎集体欢迎它。