文 | AI 价值官，作者丨星   野，编 辑丨美 圻

三个月前，努比亚 M153 首销售罄的消息刷屏科技圈，豆包手机助手让人第一次直观感受到 AI 真正 " 接管 " 手机是什么体验。但热度还未散去，微信、支付宝、各大银行 App 的封锁接踵而至。差不多同一时间，OpenClaw 在开发者圈以另一种方式验证了同一件事的价值，只不过是在电脑端而非移动端。

随着谷歌联手三星推出 Gemini 手机智能体，小米开始下场 " 养虾 "，由豆包手机助手率先开启的手机 AI Agent 赛道，竞争格局已迎来关键转变，成为软件厂商、手机厂商、操作系统三路人马的同场竞技。

三条路线的技术底座不同，生态身份不同，面临的阻力也各自迥异。豆包的读屏方案、谷歌的 AppFunctions 框架、小米的系统原生 API ——表面上都在解同一道题，内核的逻辑却大相径庭。谁的方案能真正跑通，取决于它在整个移动生态中处于什么位置，而不只是技术本身的优劣。

豆包手机走到今天，面对的已经不只是应用生态的阻力，还有手机厂商用系统级权限构筑起来的新壁垒。但字节的处境，也并非外界看起来那样被动。它在 B 端的 MCP 布局、飞书积累的协议化经验、以及独家内容技术生态，都是手机厂商无法复制的资产。问题在于，如何把这些资产转化成应用厂商愿意合作、硬件厂商无法忽视的实际筹码。

手机版 " 龙虾 " 来了，但第三方应用还没跟上

最近一段时间，一只叫做 OpenClaw 的 " 龙虾 " 火出了 AI 圈，" 赛博养虾 " 快速出现人传人现象。不过，对大多数普通用户来说，OpenClaw 的门槛依然不低——它运行在电脑端，需要一定的技术背景才能部署和使用，距离真正的大众普及还有相当距离。

3 月 6 日，小米正式启动移动端系统级智能体 Xiaomi miclaw 的小范围封闭测试。雷军在转发公告时只写了三个字：" 手机龙虾 "。这是小米对 OpenClaw 热潮的正面回应，也是手机厂商 " 养虾 " 浪潮中率先亮相的那一只。意味着这场 AI Agent 革命的战场，正式从极客的电脑延伸到了普通用户的手机。

从官方介绍来看，miclaw 的核心卖点是把手机系统能力变成 AI 可直接调用的工具集。Xiaomi miclaw 可将手机系统能力封装为超过 50 项工具，并持续扩展，即便执行 20 步复杂操作也能保持需求连贯性。 

生态联动是 miclaw 目前最核心的差异化能力。小米深耕 IoT 多年，米家生态接入设备已超过 10 亿台，而 miclaw 第一次让这个庞大的设备矩阵真正被 AI 统一调度——读取设备状态、发送控制指令，在用户授权的情况下，所有接入米家的智能设备都能成为 AI 可驱动的终端。

对于第三方应用的接入，小米给出了两条路径：一是通过 MCP 协议，PC 端已有的数千个 MCP 工具理论上可以直接接入手机 AI；二是发布了第三方应用接入 SDK，第三方 App 主动声明自己能提供的工具能力，Xiaomi miclaw 动态发现和调用。

这两条路径都有一个醒目的前提：第三方需要 " 主动 " 接入。从目前公开的演示和官方描述来看，微信、支付宝等高频第三方应用，并未出现在任何实际操作场景之中。小米也明确将 miclaw 定位为 " 早期技术探索阶段 "。

即便第三方生态的接入仍是未解题，miclaw 已经构建出一个其他厂商难以复制的独特优势。一个小米重度用户，已经可以用一句话调度家里所有的智能设备、读取全部系统通知、管理日历和健康数据，并在小米自有应用矩阵里完成相当一部分的日常任务。

值得关注的是，小米并不会是唯一一家 " 养虾 " 的厂商。华为、OPPO、vivo 均已在系统级 Agent 方向持续投入。对用户而言，未来可能无需额外安装任何应用，通过系统 OTA 更新就能获得 Agent 能力，普及门槛将降至历史最低。

但对应用生态而言，当各家手机厂商同时推出各自的标准化调用体系，意味着美团、携程、支付宝等平台需要面对多套 SDK 的接入请求——在商业谈判尚未理顺的阶段，这可能反而形成适配压力，让应用厂商在开放力度上更加审慎。

更深远的影响在于：当系统级 Agent 成为每部手机的标配，AI 调度应用的方式将逐步取代用户主动打开 App 的习惯，应用分发逻辑将被重写。谁掌握了 AI 调度的入口，谁就掌握了下一代流量的分配权——而这，恰恰是每一家手机厂商都清楚的终局。

GUI 向左，OpenClaw 向右

AI 手机的正确姿势是什么？

如果说 2025 年底豆包手机助手的亮相，是一场模型公司与硬件厂商联合的突袭。到了 2026 年开年，这场战役的格局已经今非昔比。手机厂商、操作系统、AI 模型公司正在同一条赛道上加速，目标高度一致：让 AI 接管手机操作，成为用户的全能代理。

要理解它们的本质差异，需要先厘清一个更底层的技术问题：AI 到底应该怎样 " 操作 " 手机？

OpenClaw 的核心设计理念是本地运行，基于 MCP 协议的三层结构——核心层调用大模型，适配层连接平台，技能层执行任务——它不依赖视觉识别，而是通过系统 API 直接执行指令。

豆包手机助手的路径则截然相反：用户下指令，手机截屏发给云端大模型，模型看懂屏幕后返回操作指令，手机执行，再截屏，如此循环。这是一种彻底的 " 视觉仿人 " 路线，AI 像人一样盯着屏幕干活。

这套读屏路线的早期成效有目共睹。2025 年 12 月 1 日，豆包手机助手技术预览版发布，搭载该助手的努比亚 M153 工程样机首批 3 万台一夜售罄，在科技圈引发现象级关注。跨平台比价点外卖、自动整理旅行攻略、批量处理消息，几乎覆盖手机日常使用的全场景，只在付款等关键环节需要人工介入。

但这一技术路线，与现有移动应用生态存在天然冲突。实际落地中，微信曾触发 " 登录环境异常 " 安全提示，部分银行 App 也弹窗要求关闭 AI 助手相关功能，豆包因此宣布暂停金融场景的 AI 自动操作。这背后既有用户隐私与安全的合规考量，更核心的是商业利益博弈：AI 时代流量入口、用户数据与操作链路的价值愈发关键，读屏路线试图绕开现有 App 壁垒，势必面临极大的生态阻力。

谷歌和三星在 2026 年 2 月给出了一条更接近 OpenClaw 精神的路径。三星 Galaxy Unpacked2026 发布会上，谷歌安卓生态系统总裁萨马特展示了 Gemini 智能体，能够在后台自动完成订餐、叫车、购物等跨应用复杂任务。

谷歌披露了一套名为 "AppFunctions" 的底层框架，类似 MCP 协议的本地版本，通过 AppFunctions，应用开发者可以定义功能接口，让 Gemini 更精准地调用；同时谷歌也在开发 "UI 自动化框架 "，让 AI 能在没有官方适配的应用上通过视觉识别完成任务。这是一套 " 双保险 " 路线：优先推动应用主动开放 API，同时保留视觉读屏作为备用。

该方案目前仅面向美国、韩国的 Galaxy S26 与 Pixel 10 系列推出 Beta 版，仅覆盖外卖、网约车等少量合作场景，能力落地高度依赖应用方的适配与授权。

对此，中兴通讯终端事业部总裁、努比亚总裁倪飞直白评价：" 看到三星 S26+Gemini 的组合，同样采用了 GUI 方式，但只实现了努比亚 M153 的局部能力，还是有些遗憾。" 这个对比并非毫无道理，但恰好说明了两条路线的本质取舍——豆包走 " 先落地、再协调 " 的快速覆盖路线，谷歌 + 三星走 " 先定生态规则、再逐步开放 " 的稳妥路线。

小米 miclaw 的整体思路与谷歌高度相近，但二者的优势各有侧重：谷歌掌控安卓全球系统级底层入口，而小米作为国内头部手机厂商，依托自身终端与用户体量，在国内应用生态的实际落地对接中更具话语权。

国内六家主流手机厂商的智能体用户规模，一年内合计增长 6500 万，整体达到 5.35 亿。这一体量让手机厂商在与第三方应用的合作中更具主动权，接入开放 SDK，可借助系统级 AI 入口获得新的用户触达渠道，双方更易形成互利的合作关系。

无论是谷歌 AppFunctions 还是小米的开放 SDK，核心难题都在于应用厂商愿意开放的能力边界。AI 智能体替代用户完成操作后，用户无需打开 App，平台的广告曝光、用户交互、流量入口价值都会被大幅削弱，甚至可能冲击现有 App 的产品形态与核心利益，这也是应用方存在顾虑的重要原因。

这也决定了这类 API 开放路线能落地的场景，仅局限于应用方主动让渡的范围，难以完全满足用户的全场景需求。

三条路线的问题由此清晰呈现。豆包手机路线覆盖场景最广、用户感知最直接，但应用封锁的压力始终存在。谷歌 + 三星路线规范性最强，有安卓生态和庞大应用关系网络托底，但先谈妥再落地的节奏，决定了它能覆盖的场景深度有限。小米 miclaw 路线话语权最高，系统原生的身份让生态谈判更顺畅，但第三方核心应用的接入同样没有现成答案。

这场博弈的核心矛盾不是技术问题，而是利益问题。谁能让超级 App 相信开放 API 带来的增量收益大于被 AI 抽走流量的损失，谁才能真正打通手机智能体的全场景能力。在这个问题没有答案之前，所有路线都只是在各自已经谈妥的一亩三分地里，跑得尽可能顺畅。

豆包手机助手的下一步

应该怎么走？

豆包手机是这场竞赛的开创者，但开创者未必是终局的赢家。面对手机厂商集体入场，字节需要找到一条与硬件厂商摩擦最小、自身优势发挥最大的路线。

字节初期以纯大模型供应商身份推进合作遇阻，转而通过与手机厂商开展系统级深度合作落地豆包手机助手。华为、小米、OPPO、vivo 均将自有智能体视为系统核心与流量分配入口，不愿向第三方开放系统级主导权。在此背景下，字节一边持续与多家手机厂商洽谈合作，一边优先选择与中兴等厂商联手，以降低合作门槛、快速验证能力落地。

这条路线的逻辑是清晰的：将 AI 能力深度植入硬件，打造 " 智能中枢 " 而非自有品牌手机。据供应链消息，字节已于 2025 年底开启豆包手机助手正式版项目，豆包二代手机预计将于 2026 年第二季度中后期发布，依旧延续与中兴努比亚的合作模式。

豆包二代最关键的技术决策，是如何处理 GUI 读屏与标准化 API 调用之间的关系。两者的根本差异在于：读屏是 AI 去适应人类的操作界面，API 调用是应用主动为 AI 提供能力接口，前者灵活但脆弱，后者稳定但依赖应用方的主动配合。

两套方案并行，是豆包二代目前最现实的路径。阿里在内的部分 App 与字节达成停火协议，允许努比亚设备正常登录，豆包主动限制操作场景；另有手机厂商智能体负责人透露，主动寻求合作的 App 大厂明显增多了。

目前豆包团队已与打车、外卖、订票等领域的部分平台达成常用权限合作，这是从读屏向 API 调用迁移的早期信号。已谈妥的高频场景推进标准化调用，尚未覆盖的长尾场景保留读屏作为补充——这是向协议化路线逐步靠拢的过渡方案，而非一次性的路线切换。

在这个过程中，定位的调整比技术路线的切换更为关键。OpenClaw 之所以让大厂放心，是因为它不试图成为用户与数字世界之间的唯一中介，只是提供工具，让用户自己决定用谁的模型、部署在谁的云上。豆包如果能将定位从 " 流量中介 " 调整为 " 能力增强层 "，主动开放接口、让应用厂商也能从 AI 调度中获益，封锁的动机自然会弱化。

字节在 B 端积累的 MCP 工程化经验，是支撑这一转变的重要基础。飞书的 Lark MCP Server 已将消息、日历、云文档、多维表格等协作能力以 MCP 标准对外开放，这套标准化能力的沉淀，意味着豆包在推进 C 端 API 接入时有完整的技术框架可以直接复用。

对字节而言，豆包的机会不在于成为下一个流量控制点，而在于能否在开放生态中成为最不可替代的能力提供者。开创一个赛道，和赢得一个赛道，从来都是两件事——但对字节来说，至少这场仗还远没有打完。