小米们开始下场“养虾”，豆包手机应如何接招？

文 | 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接入时有完整的技术框架可以直接复用。

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