测评人:廖麟鹭,张祖熙,任泽铖
一、前言
随着大模型技术的深度渗透,手机智能体正经历从“语音助手”到“自主执行体”的关键演进。这一转变不仅意味着交互方式从被动响应向主动预判的升级,更代表着产品能力边界的全面拓展。当前,行业内主要存在两条并行的技术路线:一条是由手机厂商主导的系统原生路线,通过深度整合底层硬件与操作系统,实现更高效的本地算力调度和更无缝的场景联动;另一条则是由独立AI公司推动的第三方路线,依托云端大模型的强大能力,提供更丰富的功能生态和跨平台的服务能力。
为了客观评估这两类产品的真实表现,本次测评设计了一系列覆盖日常办公、生活服务、复杂决策等场景的标准化任务,旨在通过测试结果,厘清它们在任务完成度、隐私安全及多轮交互等维度的能力差异
二、测评产品
本次测评的手机智能体产品主要分为以下两类:
- 1.系统原生智能体:小布助手、YOYO、超级小爱
- 2.第三方通用智能体:千问、豆包
三、测评方案
本测评项目聚焦于手机AI Agent的指令执行效果与核心能力,将任务分为三个复杂度递增的基本层级:基础指令执行、任务理解、跨应用操作,并分别设计了对应的demo进行测试。我们对测试环境、操作流程和结果进行了记录,供读者参考和进一步探究。
四、系统原生智能体测试结果
1.小布助手
测试机型:OPPO Find X8s
系统版本:ColorOS 16.0.3
小布助手版本:12.5.2(版本号:12.5.2_f64d459_260126)
测试时间:2026年2月12日
(1)基础执行



小布助手可以完成系统控制、应用唤起的基础执行,并且在省电模式和下述即将出现的时钟等界面右方的按钮处,可以快捷关闭或再次打开。
(2)复杂理解
1)多轮对话
对话 1:


对话 2:

小布助手对于简单的多轮对话具有理解能力,并对上一轮对话具有简单的记忆能力。但对于设定闹钟这类简单操作的不同指令理解存在偏差,当输入最简单指令时能正确理解,但当单轮指令变得稍复杂后会出现错误,如下图所示:


类似出现错误情况的还有创立便签,如下图所示:

2)复合指令
指令1:

指令2:

对于指令1,小布助手能完全理解,并经过测试在半小时后也响铃提醒了。
对于指令2,小布助手对于“辣”这类偏主观的描述理解不足,回答中有很多强行自圆其说的辞藻;对于“评分4.5以上”的理解也不足,在回答中出现了“评分为4.2-4.5之间符合要求”的明显矛盾。
指令 3:

这类指令小布助手完全不能理解,并且可以看出小布助手对这种两步式的指令重心落在了用户需求所处的最后一步;当最后一步指令模糊时,甚至会直接跳过第一步的指令。
(3)任务执行
1)手机自带应用


对于拨打通话、发送短信类的操作实现成功,但对于读取短信的功能有所欠缺, 会显示读取失败或直接打开短信界面供用户自行读取:

2)第三方应用


微信相关操作都无法实现,但会弹出微信界面供读者自行操作。


打车、订火车票或机票的任务完成良好。

无法完成大众点评订餐的功能,会输出文字引导用户按文字步骤操作。
(4)拟人交互
1)共情闲聊

能给出具体的建议,并且能根据前面几轮的对话联系猜想用户的经历,可见小布助手具有一定的记忆能力和共情能力。
2)方言识别


可以识别方言的种类并能听懂简单的方言。对于四川方言的词语,大致理解准确,但少量词语的释义出现了偏差,对于方言和谐音叠加的网络流行语言无法识别,且对该对话的幽默内核理解错误,只能看出表面的“情绪冲突”。对于粤语的词语理解能力相比之下会好很多,且由于对话中的感情更直接故理解较为精准。
2.YOYO
测试机型:HONOR MagicV5
系统版本:MagicOS 10.0 YOYO
版本:90.10.27.040
测试时间:2026年2月12日
(1)基础执行
- 0)打开YOYO或长按开关机键3秒唤起YOYO
- 1)在输入框输入或语音输入简单指令“微信”或者“帮我打开微信”
测试效果:

然后会自动跳转到微信界面;
(2)复杂理解
- 1)在输入框输入或语音输入指令“我休息一会儿,半个小时后叫我”
测试效果:

然后YOYO会自动创建半小时后的闹铃;
(3)任务执行
- 1)在输入框输入或语音输入指令“YOYO帮我在笔记里记录一条笔记,内容为:账号123456密码123456”
- 2)在输入框输入或语音输入指令“YOYO帮我设定仅此一天的闹钟,定时为晚上的11点15分”
测试效果:


- 1)在输入框输入或语音输入指令“YOYO帮我订一张机票”
- 2)继续完善指令“帮我订一张2月27日上午从太原武宿飞往上海虹桥的经济舱机票”
测试效果:


均可以打开订票界面;
- 1)在输入框输入或语音输入指令“帮我查看我联系人中最常联系的人”
- 2)操作失败,原因解释如下:
测试结果:


显示无法由YOYO直接打开并进行查看,涉及了用户的隐私信息;
(4)拟人交互
- 1)在输入框内输入“请以李白的口吻与我交谈”
- 2)向YOYO进行提问或简单交流
测试结果:


3.超级小爱
测试机型:Redmi K90
系统版本:Xiaomi HyperOS 3.0.20.0
超级小爱版本:7.11.20.1317
测试时间:2026年2月12日
(1)基础任务
演示1:打开天气
- 0)打开小爱或按开关机键0.5秒唤起小爱
- 1)语音输入/键入“天气”

测试结果:
简述了天气状况,并生成了一张天气卡片,点击可进入系统自带的“天气”应用。注:需开启定位权限。
点评:实用,高效。
(2)任务理解
演示2:创建日程
1)语音输入/键入“明晚八点我有一个线上头脑风暴会”

测试结果:
在日历中添加了事件“有一个线上头脑风暴会”,时间为次日20:00,可选开启闹钟提醒。
点评:用户并未明确提出指令,小爱识别到了日程安排需求,并提取信息完成了任务。但事件提取比较粗糙,事件标题为用户原话复制,不够简洁明了。
(3)跨应用操作
一、系统原生应用
演示3:查找/呼叫联系人
1)语音输入/键入“查询xx电话”/“呼叫xx”
测试结果:


可成功模糊搜索及呼叫。
演示4:图片编辑
1)在图库中打开一张图片时,按电源键0.5秒唤起小爱,语音输入/键入“为我增强这张图片的HDR效果,获得更好的高光和暗部细节”
测试结果:
修改前:

修改后:

小爱使用系统相册编辑器的“智能美化”(一键AI修图)和影调调节(对比度、饱和度、高光、阴影等)功能,编辑了图片,并添加了“超级小爱AI生成”的水印。
点评:相比于第三方智能体直接生成成品的AI修图,超级小爱使用影调调节为用户后续调整提供了方便。但用户无法使其在编辑时避免使用“智能美化”(一键AI修图),导致一定的细节丢失。
二、非原生应用
演示5:回复信息
演示5.1 小红书
1)语音输入/键入“打开小红书,为有未读消息的好友回复‘已阅’”
测试结果:


打开小红书并回复了消息,但执行可靠性不足:有时会选择置顶好友而非有未读消息的好友。
演示5.2 微信
2)语音输入/键入“打开微信,为有未读消息的好友回复‘已阅’”
测试结果:如下图

由于权限原因,只能打开微信,不支持应用操作。
演示6:点外卖
1)语音输入/键入“在美团预订一杯饮品外卖,茉莉奶白的香草慕斯金骏眉,少冰三分糖,时间明天上午十一点”
测试结果:

打开美团,点击“外卖”,搜索了“茉莉奶白的香草慕斯金骏眉”,找到目标商品,进行定制并预约了时间。
经过多轮测试,三次执行中有两次定制错误,分别选择了热和默认七分糖;同时,YOYO不会使用优惠券。确认订单和支付步骤交由用户完成。
一些细节还可以优化,如:
1.外卖搜索没有提取关键词,而是直接复制用户原话
2.点外卖流程中未自动使用优惠券
演示7:概括知乎文章
1)浏览知乎文章
(https://www.zhihu.com/question/26833362/answer/1898076690757944301)时,按电源键0.5秒唤起小爱,语音输入/键入“概括这篇文章”
测试结果:

把屏幕内容都念了一遍。看似打开了文章链接,实则只读了屏幕,全文其他部分信息完全没有读到。
点评:基于“读屏”进行操作。在有权限的应用中,代理程度高,几乎完全解放双手。但可靠性不足,时常失误。
同时,部分应用(如:微信)未开放权限,无法操作。
产品小结:该产品交互便捷,能够准确识别用户需求,基于屏幕读取技术实现代理操作。在已授权应用中,自动化程度较高,基本可解放用户双手,但执行过程中仍存在偶发性失误,可靠性有待提升。细节方面仍有优化空间,例如:外卖搜索时未提取关键词,而是直接复制用户原话;点餐流程中未能自动使用优惠券等。此外,部分应用(如微信)未开放权限,暂无法进行操作。
五、第三方通用智能体测试结果
1.千问
安卓沙盒机制:系统为每个应用分配的独立、隔离的运行环境,应用之间默认无法相互访问,也无法直接操作系统底层。
由于安卓沙盒机制,千问等第三方通用智能体无法访问其他应用,因此大部分跨应用操作都无法执行,也无法弹出对应页面,只能给出文字版操作流程供用户手动操作,如下图所示:

但随着千问与其他企业达成合作,部分场景已突破沙盒限制、打通跨应用快捷通道。最近爆火全网、登顶热搜的“千问点奶茶”,正是这类合作落地的典型案例——用户只需发送含有关键词的简单指令,千问便能直接提供奶茶的多项选择供用户在千问界面直接下单,将跨应用操作从“教程”变成了“执行”,如下图所示:

千问作为阿里巴巴旗下的AI应用,自然与淘宝率先实现深度技术整合与功能联动。在千问界面询问“帮我在淘宝搜索一件连衣裙”,千问会弹出一串带有链接的文字,点进相应链接无需跳转淘宝就可以看到对应连衣裙的界面。同时,千问在回答末尾会弹出“淘宝申请授权”的提示框,完成授权后就可以直接在当前界面下单,具体操作页面可见下列两图。


千问提供的便利不止在于购物。千问app在今年一月已宣布全面介入阿里核心业务,其中包括高德地图。今年二月,千问随即联合飞猪宣布与全球40余家旅行品牌达成AI合作,为用户的出行提供了许多便利。下图是利用千问订机票的实际操作界面。

在图片中,可以看到千问给出了多项选择,而点击卡片右侧的“订票”就可以直接购票,操作十分便捷。
2.豆包
由于该产品限量发售,在官方平台已售罄,本次测评未能对其进行一手实测。但我们通过搜集资料,评述了其 AI Agent 技术实现的突破,及其遭遇的生态壁垒。
(1)概述
豆包智能手机是字节跳动联合努比亚于 2025 年 12 月1 日发布的系统级 AI 智能体手机,首款产品为努比亚M153 技术预览版,售价 3499 元,限量 3 万台,117秒售罄,二手平台溢价超 3 倍。其核心差异在于内置系统级豆包 AI 助手,能通过自然语言指令跨应用自动完成复杂任务,如比价下单、订票、行程规划等,被定位为"会主动工作的 AI 终端"。
(2)AI Agent实现路径
豆包 AI Agent 采用 GUI Agent 技术路径,通过系统级深度整合实现"看懂屏幕+模拟人类操作"的跨应用自主执行能力,核心架构分为五层:
1)交互入口层:AI 语音助手通过 Agent 进程处理自然语言指令,精准识别用户意图。
2)任务规划层:基于火山方舟框架,将复杂指令拆解为子任务(如“找同款并发给好友”拆分成“相册识别→电商比价→社交发送”)。
3)系统权限层:
INJECT_EVENTS(事件注入权限):属于系统签名级权限,能够直接向系统注入输入事件,其底层权限高于无障碍服务。
READ_FRAME_BUFFER(帧缓冲区读取权限):用于直接读取 GPU 图形缓冲区,从而获取屏幕显示内容。
CAPTURE_SECURE_VIDEO_OUTPUT(安全视频输出捕获权限):可突破银行类应用的安全防护机制,获取受保护的屏幕输出内容。
4)虚拟化执行层:
创建与物理屏幕隔离的虚拟屏幕(即无头模式,屏幕亮度为 0),实现人机操作的完全分离。
AutoAction 进程通过事件注入机制执行操作,AI Kernel 进程(占用 160MB Native 堆内存)负责本地推理。
5)云端协同层:
云端部署豆包 Pro 模型(700 亿参数),负责处理复杂推理与任务路径规划。
本地部署豆包 Lite 模型(70 亿参数),专注于高效执行,每 3-5 秒传输约250KB 的屏幕数据,并接收约 1KB 的指令信息。
形成“观察—决策—执行—验证”的闭环反馈机制,确保任务执行的准确性与稳定性。
核心技术优势:首次实现移动设备上高完成度、强泛化能力的GUI Agent,无需App开放API即可跨应用操作,颠覆传统“打开App→手动操作”模式。
(3)发布后遭遇的生态壁垒问题
豆包手机发布仅3天便遭遇全行业集体封杀,核心功能几近瘫痪,形成典型的生态利益博弈。
1)具体表现
| 应用类型 | 封杀手段 | 影响 |
|---|---|---|
| 社交类 | 微信弹出“环境异常”,限制登录/冻结账号 | 自动回复、聊天整理功能失效 |
| 电商类 | 淘宝、闲鱼、大麦等直接拉黑,禁止AI操作 | 跨平台比价、自动下单核心功能瘫痪 |
| 金融类 | 农行、建行等要求关闭豆包助手才能操作 | 支付、转账等敏感操作受限 |
| 游戏类 | 《王者荣耀》等禁赛甚至封号 | 游戏相关AI功能无法使用 |
2)原因
- ①安全风控冲突:豆包的模拟操作与黑灰产常用的群控外挂、自动化诈骗工具高度相似,触发平台最高级警报。微信、银行等无法区分“善意AI”与恶意工具,只能一刀切封杀。
- ②入口控制权争夺:豆包试图成为“超级枢纽”,绕过App前端界面,将超级App降级为功能模块,稀释其流量入口价值与广告、交易抽成收益。
- ③数据隐私顾虑:虽官方承诺敏感环节手动完成、不存储屏幕内容,但缺乏第三方验证,难以打消平台对用户数据泄露的担忧。
3)应对措施及后续
- ①技术妥协:暂停金融类App操作权限,支付环节强制用户手动确认。
- ②生态合作:与厂商沟通制定AI操作准则,探索更安全的跨应用交互方式。
- ③产品迭代:第二代豆包手机预计2026年Q2发布,将优化权限策略,采用分级授权机制。
(4)总结
豆包智能手机的 AI Agent 技术代表了移动 AI 的重大突破,其 GUI Agent 路径展现了从“被动问答”到“主动执行”的跨越。然而,它触动了腾讯、阿里等巨头的流量入口,引发集体封杀,这也暴露了 AI 技术创新与现有生态规则的深层矛盾——这场博弈不仅是技术之争,更是移动互联网向 AI 时代转型过程中,新旧入口权力交替的必然结果。
六、两类智能体测试结果对比
通过对系统原生智能体(小布助手、YOYO、超级小爱)与第三方通用智能体(千问、豆包)的实测对比,我们可以从以下几个维度总结其差异:
(1)技术路径:
系统原生智能体依托厂商对操作系统底层的深度整合,具备调用硬件能力、读取系统状态、执行跨应用操作的天然优势。以超级小爱为例,其通过读屏技术和系统权限,能够在授权应用中实现高度自动化的任务执行。而第三方通用智能体受限于安卓沙盒机制,默认无法访问其他应用数据,必须通过商业合作或GUI Agent技术突破壁垒——千问通过与阿里生态深度整合实现了“点奶茶”“订机票”等功能,豆包则尝试以系统级整合的方式实现突破。
(2)任务完成度:
在基础指令执行层面,两类产品呈现能力断层:系统原生智能体依托系统权限,可顺利完成打开应用、设置闹钟、发送短信等基础操作;而第三方通用智能体受限于安卓沙盒机制,连最简单的“打开微信”指令都无法执行,只能以文字教程引导用户手动操作,基础执行能力几乎为零。
但在复杂任务理解层面,情况发生了反转。系统原生智能体虽然能执行操作,但对指令的理解能力参差不齐:小布助手对“辣”“评分4.5以上”等主观描述理解不足,YOYO对涉及隐私的查询保持过度谨慎,超级小爱的读屏执行可靠性有待提升——呈现出“做得到但听不懂”的特点。而第三方通用智能体虽然受限于权限无法执行,却能精准理解用户意图:千问能准确解析“少冰三分糖”“评分4.5以上”等复杂条件,并提供详细的操作步骤或直接跳转合作应用内完成——呈现出“听得懂但做不到”的特点。
这一反差揭示了两类产品的核心差异:系统原生强在执行链路,弱在意图理解;第三方通用强在语义理解,弱在操作权限。只有当双方优势结合时,才能实现真正的智能体体验——例如千问通过与阿里生态深度整合,在淘宝、飞猪等合作应用中实现了“听得懂且做得到”的流畅操作,甚至优于部分原生助手。
以下是一个结合了多轮测试得到的两类智能体在各维度能力的示意图:(评分基于多轮实测得出,旨在呈现相对差异,非绝对精度指标)

七、结语
通过本次测评可以发现,当前手机智能体正处于“能力分化”的发展阶段。系统原生智能体依托系统权限,在基础指令执行、跨应用操作、隐私安全控制等方面占据天然优势,呈现出“做得到”的鲜明特点;但其在复杂意图理解、主观描述解析等维度仍存在明显短板,呈现出“听得懂但听不懂人话”的尴尬。第三方通用智能体则恰恰相反,凭借云端大模型的强大语义理解能力,能精准解析复杂指令,却受限于安卓沙盒机制,连最基础的“打开微信”都无法执行,陷入“听得懂但做不到”的困境。
手机智能体的终极形态,应当是“听得懂、做得到、有温度”三位一体的存在。这需要两条技术路线的深度融合与优势互补。短期来看,两类智能体将沿着各自擅长的方向持续深耕:系统原生路线继续强化理解能力,第三方路线通过生态合作突破执行壁垒。长期来看,真正的突破点在于系统级大模型的深度融合、标准化跨应用交互协议的建立,以及端云协同的混合架构。最终形态的智能体,应能在用户授权下无缝穿梭于各类应用之间,既能理解“少冰三分糖”的细腻需求,又能完成跨平台比价订票的复杂任务,还能在深夜emo时给予恰当的情感回应——成为真正懂用户的“数字伴侣”。
这一目标的实现,需要产业链各方的共同努力。
对手机厂商而言,既要补强“大脑”,提升对主观描述、复合指令的理解能力;也要开放“手脚”,在保障安全的前提下让智能体能力可拓展;还应做深“情感”,持续打磨拟人交互体验。对第三方AI公司来说,需通过生态合作、GUI Agent等技术路径突破跨应用操作壁垒,同时守住大模型的理解能力优势,并建立透明可控的隐私保护机制,避免重蹈豆包被全行业封杀的覆辙。从行业整体来看,推动建立AI智能体交互标准与授权机制,探索分级授权体系,让平台方有据可依、开发者有章可循、用户用得安心,是当务之急。
对用户而言,两类智能体并非替代关系,而是场景互补的选择。追求日常便捷与隐私安全的用户,可首选系统原生智能体处理基础操作;有复杂任务需求、重度使用特定生态的用户,则不妨尝试第三方通用智能体。而真正理想的使用方式,是将两者结合——根据需求灵活选择,各取所需。
这是两个看似相反的方向,却共同指向手机智能体的未来,它们在各自的道路上探索,终将汇聚成更完整的答案。大门已经打开,前路已经指明,接下来,就需要我们携手共进,一步步走向那个更智能也更温暖的明天。