WEBVTT
Kind: captions
Language: zh

00:00:00.166 --> 00:00:02.866
一句话就能让AI打开真实手机

00:00:03.100 --> 00:00:06.466
跨应用查路线算时间播放音乐

00:00:06.500 --> 00:00:08.566
最后自动提交测试报告

00:00:08.766 --> 00:00:10.733
谷歌刚刚把这套系统开源

00:00:11.133 --> 00:00:15.533
项目方还给出了99.1%的任务成功率

00:00:15.933 --> 00:00:17.800
但先别急着把它理解成

00:00:17.800 --> 00:00:20.133
安卓已经被AI彻底接管

00:00:20.500 --> 00:00:22.866
因为那个数字背后还有一场关于

00:00:22.866 --> 00:00:26.500
跑分代码来源和开源署名的争议

00:00:26.600 --> 00:00:28.266
这套系统叫Artemis

00:00:28.466 --> 00:00:29.933
它面对的是一台真实

00:00:29.933 --> 00:00:31.733
Android手机或模拟器

00:00:32.133 --> 00:00:33.966
网页和专门为AI准备

00:00:33.966 --> 00:00:35.600
的演示界面都不够

00:00:35.766 --> 00:00:38.000
开发者用自然语言描述任务

00:00:38.300 --> 00:00:39.800
Athena观察屏幕

00:00:39.900 --> 00:00:40.866
寻找控件

00:00:41.000 --> 00:00:42.600
执行点击和输入

00:00:42.733 --> 00:00:45.133
再根据界面变化决定下一步

00:00:45.333 --> 00:00:47.000
一个典型任务可以这样写

00:00:47.000 --> 00:00:48.600
打开Google Maps查询

00:00:48.600 --> 00:00:50.366
三个地点的行车时间

00:00:50.400 --> 00:00:51.866
把结果记录下来

00:00:51.866 --> 00:00:55.500
再打开YouTube搜索Coldplay并播放歌曲

00:00:55.733 --> 00:00:57.700
传统自动化需要工程师

00:00:57.700 --> 00:00:59.800
逐个编写控件选择器

00:01:00.300 --> 00:01:02.200
等待条件和异常处理

00:01:02.366 --> 00:01:04.066
Artemis接到目标后

00:01:04.066 --> 00:01:05.466
会自己拆解步骤

00:01:05.533 --> 00:01:07.200
并在应用之间切换

00:01:07.333 --> 00:01:08.800
这件事听上去只比

00:01:08.800 --> 00:01:10.800
语音助手多了几次点击

00:01:11.066 --> 00:01:12.900
底层难度却完全不同

00:01:13.066 --> 00:01:15.966
语音助手通常调用预先接好的接口

00:01:16.066 --> 00:01:17.800
能做什么早已写死

00:01:18.366 --> 00:01:21.866
Automis面对的是不断变化的图形界面

00:01:22.066 --> 00:01:23.300
按钮会移动

00:01:23.566 --> 00:01:25.100
弹窗会突然出现

00:01:25.200 --> 00:01:26.666
网络速度不稳定

00:01:26.800 --> 00:01:30.100
应用更新以后控件名称也可能改变

00:01:30.266 --> 00:01:32.466
传统移动测试因此很脆弱

00:01:33.000 --> 00:01:35.100
一条脚本昨天还能运行

00:01:35.300 --> 00:01:38.200
今天可能因为按钮换了位置就失败

00:01:38.566 --> 00:01:40.533
测试工程师往往在维护

00:01:40.533 --> 00:01:42.700
大量选择器和等待时间

00:01:42.933 --> 00:01:44.900
业务逻辑反倒没有变化

00:01:45.166 --> 00:01:46.766
产品功能没有变化

00:01:47.166 --> 00:01:49.066
自动化脚本仍然要重写

00:01:49.166 --> 00:01:51.200
Optimus尝试把这部分维护

00:01:51.200 --> 00:01:53.133
工作交给多模态模型

00:01:53.466 --> 00:01:55.900
它先读取Android的无障碍层级

00:01:56.200 --> 00:01:57.900
获得界面中的文字

00:01:57.933 --> 00:02:00.133
控件类型和可操作区域

00:02:00.466 --> 00:02:02.100
能找到稳定元素时

00:02:02.100 --> 00:02:03.966
它通过元素索引点击

00:02:04.400 --> 00:02:05.966
界面结构不足时

00:02:06.066 --> 00:02:09.500
再使用坐标OCR和视觉定位

00:02:09.533 --> 00:02:11.700
这套组合很重要标准

00:02:11.800 --> 00:02:15.133
Android应用通常会暴露清楚的控制树

00:02:15.200 --> 00:02:17.566
AI可以知道哪个元素是按钮

00:02:17.766 --> 00:02:19.400
哪个元素是输入框

00:02:20.066 --> 00:02:22.733
flutter compose和CANVAS绘制的

00:02:22.733 --> 00:02:24.766
界面可能只给出很少结构

00:02:24.900 --> 00:02:27.466
游戏界面甚至完全没有可用控件

00:02:27.700 --> 00:02:29.866
optimus遇到这种情况就

00:02:29.866 --> 00:02:32.133
转向截图和视觉模型

00:02:32.333 --> 00:02:34.366
纯视觉方案也有明显缺点

00:02:34.800 --> 00:02:37.266
截图里的两个按钮可能长得很像

00:02:37.400 --> 00:02:39.766
小图标不一定能准确识别

00:02:39.966 --> 00:02:42.266
动画还会让坐标快速失效

00:02:42.533 --> 00:02:43.766
Artemis没有把全部

00:02:43.766 --> 00:02:45.733
希望放在视觉模型上

00:02:45.800 --> 00:02:47.933
而是优先使用结构信息

00:02:48.366 --> 00:02:49.600
视觉负责补位

00:02:49.766 --> 00:02:51.866
这个选择降低了推理成本

00:02:51.866 --> 00:02:53.466
也让操作更稳定

00:02:53.666 --> 00:02:55.766
项目提供两套执行模式

00:02:56.200 --> 00:02:57.966
Flash模式追求速度

00:02:58.133 --> 00:02:59.566
采用观察一次

00:02:59.666 --> 00:03:00.733
行动一次

00:03:00.866 --> 00:03:02.500
再次观察的循环

00:03:03.100 --> 00:03:06.733
readme给出的典型速度是每一步3-5秒

00:03:06.800 --> 00:03:09.066
它不会先写一份庞大计划

00:03:09.066 --> 00:03:11.933
也不会为每个动作生成长篇说明

00:03:12.066 --> 00:03:13.400
适合目标清楚

00:03:13.666 --> 00:03:15.133
流程较短的任务

00:03:15.300 --> 00:03:17.200
打开设置并关闭蓝牙

00:03:17.700 --> 00:03:19.733
Flash模式看到当前界面后

00:03:19.733 --> 00:03:21.700
会直接寻找设置入口

00:03:22.166 --> 00:03:24.066
如果已经位于快捷面板

00:03:24.066 --> 00:03:26.400
它不必坚持原先设想的路径

00:03:26.733 --> 00:03:28.700
反应式循环的好处是

00:03:28.866 --> 00:03:31.500
灵活界面出现意外弹窗时

00:03:31.500 --> 00:03:32.866
也能临时调整

00:03:33.133 --> 00:03:35.500
速度的代价是缺少全局检查

00:03:35.766 --> 00:03:37.566
任务变成长流程后

00:03:37.700 --> 00:03:40.333
前面一个小错误可能一直带到最后

00:03:40.466 --> 00:03:42.333
代理以为邮件已经发送

00:03:42.366 --> 00:03:44.000
实际停在草稿页

00:03:44.300 --> 00:03:46.066
他以为文件已经移动

00:03:46.100 --> 00:03:48.200
实际只打开了目标文件夹

00:03:48.700 --> 00:03:50.200
每一步看起来都合理

00:03:50.300 --> 00:03:52.600
最终状态却不符合要求

00:03:52.900 --> 00:03:55.166
Pro模式就是为这种任务准备的

00:03:55.733 --> 00:03:57.533
他使用多代理图把职责

00:03:57.533 --> 00:03:59.966
分给planner operator和Checker

00:04:00.400 --> 00:04:02.333
planner维护一份持续

00:04:02.333 --> 00:04:04.700
更新的任务计划operator

00:04:05.366 --> 00:04:07.966
操作设备checker在关键

00:04:07.966 --> 00:04:10.266
节点和结束时检查结果

00:04:10.300 --> 00:04:12.566
一次测试超过100步也可以

00:04:12.566 --> 00:04:14.733
保留阶段状态继续执行

00:04:14.966 --> 00:04:16.533
planner并不只是把

00:04:16.533 --> 00:04:18.666
任务写成编号列表

00:04:19.200 --> 00:04:22.066
计划里会标出需要验证的里程碑

00:04:22.900 --> 00:04:25.100
例如联系人是否真的创建

00:04:25.533 --> 00:04:28.366
文件是否已经出现在目标目录

00:04:28.900 --> 00:04:31.533
设置开关是否保持正确状态

00:04:31.766 --> 00:04:33.166
界面发生变化后

00:04:33.166 --> 00:04:34.500
计划也能调整

00:04:34.766 --> 00:04:36.966
而不是机械重复最初路线

00:04:37.200 --> 00:04:40.166
operator拿到计划后调用完整工具集

00:04:40.466 --> 00:04:42.166
它可以读取屏幕结构

00:04:42.300 --> 00:04:43.366
查看截图

00:04:43.466 --> 00:04:44.533
分析录屏

00:04:44.666 --> 00:04:46.133
调用ADB诊断

00:04:46.900 --> 00:04:48.300
也可以搜索此前

00:04:48.300 --> 00:04:50.066
压缩保存的操作历史

00:04:50.266 --> 00:04:51.400
遇到失败时

00:04:51.400 --> 00:04:53.666
系统会创建一条执行事件

00:04:54.000 --> 00:04:56.933
把失败原因保留在后续上下文中

00:04:57.133 --> 00:04:59.200
直到某次操作真正恢复

00:04:59.500 --> 00:05:00.700
checker保持只读

00:05:00.700 --> 00:05:02.666
不负责替operator点击

00:05:02.800 --> 00:05:04.900
这样设计是为了避免执行者

00:05:04.900 --> 00:05:07.566
一边操作一边宣布自己成功

00:05:08.133 --> 00:05:10.866
checker根据任务目标检查最终状态

00:05:10.900 --> 00:05:13.200
也可以在中间里程碑做验证

00:05:13.400 --> 00:05:15.466
用户还能选择关闭验证

00:05:15.700 --> 00:05:17.100
只做最终验证

00:05:17.400 --> 00:05:18.733
检查所有节点

00:05:19.200 --> 00:05:21.066
或者使用更严格的模式

00:05:21.133 --> 00:05:23.900
每个动作执行前还有一道safety net

00:05:24.166 --> 00:05:27.866
系统优先根据XML界面树确认目标

00:05:28.066 --> 00:05:30.966
结构信息不足时再检查像素按钮

00:05:31.133 --> 00:05:33.400
在模型思考期间已经消失

00:05:33.500 --> 00:05:36.000
操作就会被阻止并交回operator

00:05:36.466 --> 00:05:38.700
移动界面中的状态变化很快

00:05:38.800 --> 00:05:40.466
这道检查可以减少点

00:05:40.466 --> 00:05:41.933
到错误位置的情况

00:05:42.133 --> 00:05:44.766
Artemis还支持连续动作突发

00:05:45.333 --> 00:05:47.400
某些菜单只会短暂显示

00:05:47.600 --> 00:05:50.600
如果每点一次都等待模型重新观察

00:05:50.766 --> 00:05:52.000
菜单早已关闭

00:05:52.466 --> 00:05:55.366
系统可以把几个确定动作连续发出

00:05:55.466 --> 00:05:57.266
缩短模型往返延迟

00:05:57.400 --> 00:05:59.000
这类工程处理很少

00:05:59.000 --> 00:06:00.933
出现在产品宣传中

00:06:01.300 --> 00:06:02.733
却直接决定代理

00:06:02.733 --> 00:06:04.933
能不能在真实应用里工作

00:06:05.200 --> 00:06:07.733
Flash模式每步大约3-5秒

00:06:07.866 --> 00:06:10.400
Pro模式通常需要15-40秒

00:06:10.533 --> 00:06:12.700
速度差距提醒了一个现实

00:06:12.800 --> 00:06:14.566
可靠性不是免费的

00:06:14.566 --> 00:06:16.866
规划检查历史检索

00:06:17.133 --> 00:06:19.966
和故障恢复都会增加模型调用

00:06:20.000 --> 00:06:21.500
短任务追求速度

00:06:21.533 --> 00:06:23.000
长任务追求结果

00:06:23.166 --> 00:06:26.200
两种场景很难用同一套配置解决

00:06:26.333 --> 00:06:29.533
项目最值得关注的用途是软件测试

00:06:30.200 --> 00:06:33.100
普通人远程控制手机还排在后面

00:06:33.200 --> 00:06:35.100
开发者完成一项功能后

00:06:35.100 --> 00:06:37.933
可以让Artemis在真机上复现问题

00:06:38.100 --> 00:06:40.300
收集Logcat日志和截图

00:06:40.366 --> 00:06:42.466
再把结果交回编程代理

00:06:42.500 --> 00:06:45.733
过去分开的写代码跑手机看日志

00:06:45.933 --> 00:06:48.133
开始被串成同一条工作流

00:06:48.166 --> 00:06:50.600
这里的关键接口是MCP

00:06:50.966 --> 00:06:53.100
Optimus自带MCP服务器

00:06:53.100 --> 00:06:55.700
可以连接Antigravity Claude code

00:06:55.966 --> 00:06:58.766
Windsurf等支持MCP的开发工具

00:06:59.100 --> 00:07:01.800
编程代理不再只能阅读代码仓库

00:07:02.300 --> 00:07:03.500
他还可以看到应用

00:07:03.500 --> 00:07:05.200
实际运行后的界面

00:07:05.300 --> 00:07:07.900
并操作设备验证自己的修改

00:07:08.100 --> 00:07:09.666
设想一个常见场景

00:07:09.800 --> 00:07:12.600
用户报告结账按钮点了没有反应

00:07:12.800 --> 00:07:14.933
开发者只拿到一句模糊描述

00:07:15.166 --> 00:07:16.533
接入Artemis后

00:07:16.566 --> 00:07:18.800
编程代理可以安装测试版本

00:07:19.166 --> 00:07:21.266
按照用户路径进入商品页

00:07:21.333 --> 00:07:22.200
触发结账

00:07:22.566 --> 00:07:23.900
截取错误界面

00:07:23.966 --> 00:07:25.866
再读取Logcat中的异常

00:07:26.000 --> 00:07:27.666
它修改代码后还能

00:07:27.666 --> 00:07:29.400
重新执行同一流程

00:07:29.533 --> 00:07:31.766
这会改变修复完成的定义

00:07:32.000 --> 00:07:34.800
很多AI编程工具生成代码后

00:07:34.933 --> 00:07:36.700
只能运行单元测试

00:07:37.733 --> 00:07:39.133
单元测试通过

00:07:39.266 --> 00:07:41.533
不代表手机界面真的可用

00:07:41.733 --> 00:07:43.100
按钮可能被遮挡

00:07:43.300 --> 00:07:45.366
权限弹窗可能阻断流程

00:07:45.666 --> 00:07:47.933
键盘弹出后布局也可能错位

00:07:48.200 --> 00:07:50.966
Artemis把验证推进到设备层

00:07:51.300 --> 00:07:54.200
项目还提供CLI Python SDK

00:07:54.300 --> 00:07:56.066
和本地网页控制台

00:07:56.266 --> 00:07:58.800
CLI适合在终端直接发起任务

00:07:59.000 --> 00:08:01.133
Python SDK可以接入pytest

00:08:01.133 --> 00:08:03.333
和CI流程网页控制台

00:08:03.333 --> 00:08:04.766
则显示手机画面

00:08:04.766 --> 00:08:06.600
推理轨迹和执行过程

00:08:06.766 --> 00:08:08.366
失败任务可以回放

00:08:09.000 --> 00:08:11.733
测试人员不必只看一句执行失败

00:08:11.966 --> 00:08:14.366
快速启动脚本会准备ADB

00:08:14.700 --> 00:08:18.100
script ffpeg和Python依赖用户

00:08:18.466 --> 00:08:20.166
可以连接开启USB

00:08:20.166 --> 00:08:22.300
调试的实体Android设备

00:08:22.400 --> 00:08:23.966
也可以使用模拟器

00:08:24.133 --> 00:08:25.466
第一次运行时

00:08:25.533 --> 00:08:26.966
系统会在设备上

00:08:26.966 --> 00:08:29.600
安装Artemis accessibility helper

00:08:29.866 --> 00:08:31.733
用它读取屏幕布局

00:08:31.933 --> 00:08:33.733
这个辅助服务会出现在

00:08:33.733 --> 00:08:35.666
Android的无障碍设置中

00:08:35.666 --> 00:08:37.566
并显示一条运行通知

00:08:38.200 --> 00:08:39.400
项目说明称

00:08:39.466 --> 00:08:41.400
它只在手机本地监听

00:08:41.400 --> 00:08:44.300
不会自行把数据发送到其他位置

00:08:44.366 --> 00:08:46.000
如果辅助服务失效

00:08:46.066 --> 00:08:48.333
系统还能回退到uiautomator

00:08:48.566 --> 00:08:50.133
这里要分清本地

00:08:50.133 --> 00:08:52.066
辅助服务和模型调用

00:08:52.533 --> 00:08:54.000
前者可以本地通信

00:08:54.166 --> 00:08:56.200
截图及界面信息是否离开

00:08:56.200 --> 00:09:00.000
设备仍取决于模型供应商配置Athena

00:09:00.000 --> 00:09:04.933
支持Gemini Claude GPT4O和千问VL等模型

00:09:05.733 --> 00:09:08.266
它本身更接近一个代理框架

00:09:08.400 --> 00:09:10.266
不是新的基础模型

00:09:10.400 --> 00:09:12.666
实际表现会受到所选模型

00:09:12.800 --> 00:09:15.800
网络设备性能和应用界面影响

00:09:15.933 --> 00:09:17.333
换一个便宜模型

00:09:17.600 --> 00:09:18.933
成本可能下降

00:09:19.366 --> 00:09:21.466
定位和规划能力也可能变化

00:09:21.600 --> 00:09:24.366
这也是99.1%跑分需要

00:09:24.366 --> 00:09:25.700
谨慎理解的原因

00:09:25.933 --> 00:09:28.300
项目宣称自己在Android world

00:09:28.466 --> 00:09:31.366
达到99%以上任务完成率

00:09:31.500 --> 00:09:35.166
图表给出的具体数字是99.1%

00:09:35.300 --> 00:09:37.400
Android world是Google research

00:09:37.400 --> 00:09:38.766
推出的公开环境

00:09:39.266 --> 00:09:41.900
包含116项手工设计任务

00:09:42.366 --> 00:09:43.766
覆盖20个应用

00:09:43.800 --> 00:09:46.666
并通过随机参数生成大量变化

00:09:46.800 --> 00:09:49.300
任务包括创建联系人

00:09:49.533 --> 00:09:50.533
发送短信

00:09:50.600 --> 00:09:51.966
添加日历事件

00:09:52.100 --> 00:09:54.300
调整亮度开关Wifi

00:09:54.366 --> 00:09:56.900
移动文件和处理播放列表

00:09:57.000 --> 00:09:59.766
任务程序会检查设备最终状态

00:09:59.900 --> 00:10:02.666
不接受模型自己宣布完成了

00:10:03.000 --> 00:10:05.866
这比依靠文字答案评分更可靠

00:10:05.966 --> 00:10:07.933
也更接近真实操作

00:10:08.100 --> 00:10:12.766
99.1%依然不等于现实手机上的99.1%

00:10:13.000 --> 00:10:15.400
Android world使用固定系统版本

00:10:15.466 --> 00:10:17.700
预设应用和明确任务类型

00:10:18.333 --> 00:10:20.800
真实手机有厂商定制界面

00:10:20.866 --> 00:10:24.200
广告弹窗登录验证地区差异

00:10:24.200 --> 00:10:26.366
和不断变化的第三方应用

00:10:26.533 --> 00:10:28.566
测试集能衡量代理进步

00:10:28.800 --> 00:10:31.366
无法覆盖开放世界的全部混乱

00:10:31.466 --> 00:10:34.000
这项成绩目前也属于团队自曝

00:10:34.533 --> 00:10:36.866
公开排行榜接受社区提交

00:10:37.000 --> 00:10:38.500
并不会替每个项目

00:10:38.500 --> 00:10:40.300
完整复现所有运行

00:10:40.566 --> 00:10:42.933
Artemis仓库展示了对比图

00:10:43.066 --> 00:10:45.366
却没有提供足够完整的第三方

00:10:45.366 --> 00:10:48.133
审计材料来证明每一次任务如何

00:10:48.133 --> 00:10:52.533
运行 99.1%可以称为公开的项目成绩

00:10:53.100 --> 00:10:55.566
不能包装成已经独立认证的事实

00:10:55.900 --> 00:10:58.066
基准测试还存在适配风险

00:10:58.600 --> 00:11:01.400
团队知道全部116项任务后

00:11:01.400 --> 00:11:03.100
可以针对常见应用和

00:11:03.100 --> 00:11:05.000
失败模式优化提示词

00:11:05.200 --> 00:11:06.733
恢复逻辑和工具

00:11:07.066 --> 00:11:08.666
优化并不等于作弊

00:11:09.100 --> 00:11:11.933
工程系统本来就该改进薄弱点

00:11:12.000 --> 00:11:13.566
但一个系统在熟悉

00:11:13.566 --> 00:11:15.466
测试集上接近满分

00:11:15.533 --> 00:11:17.333
不代表面对从未见过

00:11:17.333 --> 00:11:19.166
的应用也有同样表现

00:11:19.266 --> 00:11:21.900
更敏感的问题来自项目的代码来源

00:11:22.600 --> 00:11:23.966
Artemis公开后

00:11:24.100 --> 00:11:26.500
minitab团队在Git Hub提出异议

00:11:26.700 --> 00:11:28.466
称仓库包含其开源

00:11:28.466 --> 00:11:30.200
项目mobileuse的代码

00:11:30.266 --> 00:11:32.166
却没有在最初版本中清楚

00:11:32.166 --> 00:11:34.133
保留来源和贡献者信息

00:11:34.500 --> 00:11:36.500
minitype列出的证据很具体

00:11:36.666 --> 00:11:39.366
早期PI project Tamo曾出现

00:11:39.366 --> 00:11:42.066
Mobile use的版本号3.6.3

00:11:42.133 --> 00:11:44.066
以及三位原作者姓名

00:11:44.500 --> 00:11:46.666
后续提交替换了作者信息

00:11:46.966 --> 00:11:49.066
其他大量文件保持不变

00:11:49.133 --> 00:11:51.900
双方共享的内容涉及ADB隧道

00:11:51.933 --> 00:11:54.366
规划辅助函数应用锁定

00:11:54.366 --> 00:11:57.533
工具代理提示词和SDK示例

00:11:57.700 --> 00:11:59.500
开源代码可以复用

00:11:59.500 --> 00:12:02.933
但Apache2.0并不等于可以抹掉来源

00:12:03.333 --> 00:12:06.000
许可证允许修改和商业使用

00:12:06.066 --> 00:12:09.266
同时要求保留相应版权及许可说明

00:12:09.400 --> 00:12:10.866
争议焦点不在Google

00:12:10.866 --> 00:12:12.400
能不能使用这些代码

00:12:12.566 --> 00:12:15.466
而在它是否完整履行了署名义务

00:12:15.666 --> 00:12:17.366
以及发布过程为什么

00:12:17.366 --> 00:12:19.366
先移除了原作者信息

00:12:19.600 --> 00:12:21.800
当前仓库已经补充说明

00:12:22.266 --> 00:12:23.866
明确写着项目包含

00:12:23.866 --> 00:12:25.733
minitab开发的源代码

00:12:25.966 --> 00:12:28.966
相关文件也增加了版权和来源标记

00:12:29.500 --> 00:12:32.100
提出问题的Git Hub议题已经关闭

00:12:32.266 --> 00:12:35.700
这解决了当前readme没有署名的问题

00:12:35.866 --> 00:12:39.066
却无法抹去最初发布时发生过什么

00:12:39.066 --> 00:12:41.066
这场争议让Artemis的

00:12:41.066 --> 00:12:42.600
故事变得更有价值

00:12:42.866 --> 00:12:44.866
大型公司开源项目时

00:12:44.933 --> 00:12:46.900
外界往往默认代码已经

00:12:46.900 --> 00:12:49.100
经过完善法务和来源审查

00:12:49.500 --> 00:12:50.766
实际情况说明

00:12:50.800 --> 00:12:53.366
即使仓库挂在Google组织名下

00:12:53.366 --> 00:12:55.300
也需要查看提交记录

00:12:55.533 --> 00:12:57.133
notice和文件头

00:12:57.333 --> 00:12:59.300
品牌不能代替开源合规

00:12:59.466 --> 00:13:01.933
跑分争议又让问题多了一层

00:13:02.666 --> 00:13:04.600
Mini Tab表示自己的mobileuse

00:13:04.600 --> 00:13:06.733
后来曾自测到更高层级

00:13:07.000 --> 00:13:09.366
但公开榜单没有及时更新

00:13:09.533 --> 00:13:12.333
Artemis的图表列出多个竞争项目

00:13:12.500 --> 00:13:15.533
却没有清楚呈现双方最新可比结果

00:13:15.800 --> 00:13:17.400
这里无法仅凭一方说法

00:13:17.400 --> 00:13:19.366
判断榜单维护者的动机

00:13:19.533 --> 00:13:21.300
但可以确认排行榜存在

00:13:21.300 --> 00:13:23.200
更新和独立验证不足

00:13:23.300 --> 00:13:24.966
这些问题不应被用来

00:13:24.966 --> 00:13:27.666
否定Artemis的全部技术价值

00:13:28.500 --> 00:13:29.866
仓库不是一个空壳

00:13:30.166 --> 00:13:32.200
里面有完整的命令行工具

00:13:32.866 --> 00:13:33.933
MCP服务器

00:13:34.200 --> 00:13:35.266
设备驱动

00:13:35.400 --> 00:13:36.600
网页控制台

00:13:36.966 --> 00:13:38.933
测试目录和多代理流程

00:13:39.100 --> 00:13:40.900
短时间获得大量关注

00:13:40.933 --> 00:13:42.366
也说明开发者确实

00:13:42.366 --> 00:13:44.133
需要更可靠的移动端

00:13:44.333 --> 00:13:45.500
AI自动化

00:13:45.500 --> 00:13:47.000
同样不能因为代码能

00:13:47.000 --> 00:13:48.966
运行就忽略来源问题

00:13:49.133 --> 00:13:50.366
技术能力和开源

00:13:50.366 --> 00:13:52.200
合规是两条独立标准

00:13:52.500 --> 00:13:54.266
一个项目可以有实用价值

00:13:54.300 --> 00:13:57.333
同时在发布流程中犯下严重错误

00:13:57.500 --> 00:14:00.666
把任何一边省略都会让判断失真

00:14:00.866 --> 00:14:02.333
Artemis当前的成熟

00:14:02.333 --> 00:14:04.300
边界也写在路线图里

00:14:04.900 --> 00:14:07.533
Android studio原生插件仍未完成

00:14:07.800 --> 00:14:09.933
ios扩展还在计划中

00:14:10.166 --> 00:14:12.400
端侧轻量视觉模型和实时

00:14:12.400 --> 00:14:14.900
双向语音控制也没有正式交付

00:14:15.166 --> 00:14:18.300
现在可用的是Android设备自动化框架

00:14:18.566 --> 00:14:21.466
不是覆盖所有移动平台的万能代理

00:14:22.133 --> 00:14:24.500
ios迟早会成为重要方向

00:14:24.566 --> 00:14:26.666
但难度不会只是把ADB

00:14:26.666 --> 00:14:27.933
换成另一套命令

00:14:28.166 --> 00:14:30.466
苹果系统对自动化后台

00:14:30.466 --> 00:14:32.666
运行和权限控制更严格

00:14:32.866 --> 00:14:35.600
实体设备与模拟器的行为也不同

00:14:36.400 --> 00:14:38.366
项目路线图写了ios

00:14:38.500 --> 00:14:41.366
不代表现有架构已经解决这些限制

00:14:41.666 --> 00:14:44.200
端侧视觉模型同样值得关注

00:14:44.533 --> 00:14:46.766
今天使用云端多模态模型

00:14:47.066 --> 00:14:48.400
截图和界面信息

00:14:48.400 --> 00:14:50.100
可能需要传到服务商

00:14:50.400 --> 00:14:52.300
延迟和隐私都受影响

00:14:52.500 --> 00:14:54.466
轻量模型如果能在手机

00:14:54.466 --> 00:14:56.800
或开发机本地识别界面

00:14:56.866 --> 00:14:58.666
可以减少数据外传

00:14:58.733 --> 00:15:01.066
也能缩短每一步等待时间

00:15:01.500 --> 00:15:03.333
代价是模型能力下降

00:15:03.566 --> 00:15:06.100
复杂页面的识别可能不够稳定

00:15:06.200 --> 00:15:08.400
Artemis要进入企业测试

00:15:08.600 --> 00:15:10.733
还要解决权限和隔离

00:15:11.133 --> 00:15:13.766
测试手机可能登录内部账号

00:15:13.933 --> 00:15:17.266
包含未发布功能和真实业务数据

00:15:17.500 --> 00:15:21.300
代理拥有ADB截图和日志读取能力

00:15:21.900 --> 00:15:23.333
一旦配置错误

00:15:23.733 --> 00:15:26.600
泄露范围会比普通测试脚本更大

00:15:26.733 --> 00:15:29.000
企业需要限制模型端点

00:15:29.000 --> 00:15:31.133
保存周期和可执行命令

00:15:31.466 --> 00:15:32.566
提示词注入也是

00:15:32.566 --> 00:15:34.300
移动代理绕不开的风险

00:15:34.700 --> 00:15:35.933
应用页面可以显示

00:15:35.933 --> 00:15:38.133
一段专门写给AI的文字

00:15:38.333 --> 00:15:40.166
诱导它忽略测试目标

00:15:40.266 --> 00:15:42.533
打开其他应用或泄露信息

00:15:42.933 --> 00:15:44.933
人类测试员看到异常文字

00:15:44.966 --> 00:15:46.766
会判断模型可能把它

00:15:46.766 --> 00:15:48.400
当成高优先级指令

00:15:48.700 --> 00:15:50.933
safety net能检查目标位置

00:15:51.100 --> 00:15:53.866
未必能识别内容本身的恶意意图

00:15:54.000 --> 00:15:56.733
持续集成环境还需要可复现性

00:15:56.933 --> 00:15:59.466
同一个自然语言任务今天通过

00:15:59.466 --> 00:16:00.466
明天失败

00:16:01.066 --> 00:16:03.133
开发团队很难判断是代码

00:16:03.133 --> 00:16:06.166
回归模型波动还是界面变化

00:16:06.366 --> 00:16:09.266
Optimus必须记录模型版本提示

00:16:09.266 --> 00:16:12.766
词截图动作轨迹和设备状态

00:16:12.933 --> 00:16:15.666
才能让失败结果具有工程价值

00:16:16.000 --> 00:16:19.500
成本也不能被99.1%的数字遮住

00:16:19.866 --> 00:16:22.700
Pro模式每一步可能消耗15-40秒

00:16:22.866 --> 00:16:25.933
还会调用规划视觉和检查模型

00:16:26.000 --> 00:16:27.766
一次上百步的测试要

00:16:27.766 --> 00:16:29.933
花多少时间和API费用

00:16:30.100 --> 00:16:32.566
决定它能否替代传统自动化

00:16:32.700 --> 00:16:35.700
高价值探索测试可以接受较高成本

00:16:35.700 --> 00:16:38.866
大量重复回归测试未必划算

00:16:39.366 --> 00:16:42.100
最合理的使用方式可能是混合测试

00:16:42.500 --> 00:16:44.400
稳定高频的核心流程

00:16:44.400 --> 00:16:46.333
继续使用传统脚本

00:16:46.466 --> 00:16:48.900
速度快结果也容易复现

00:16:49.100 --> 00:16:50.866
经常变化或难以维护

00:16:50.866 --> 00:16:53.133
的界面交给Artemis探索

00:16:53.533 --> 00:16:55.366
AI发现稳定路径后

00:16:55.366 --> 00:16:58.500
还可以帮助生成更固定的测试用例

00:16:58.566 --> 00:17:01.000
这样分工比AI取代所有

00:17:01.000 --> 00:17:03.133
测试工程师更接近现实

00:17:03.333 --> 00:17:05.700
测试人员需要定义风险准备

00:17:05.700 --> 00:17:08.333
环境判断结果和处理异常

00:17:08.733 --> 00:17:11.933
Artemis减少的是反复找按钮维护

00:17:11.933 --> 00:17:14.366
选择器和手工复现的时间

00:17:14.666 --> 00:17:17.566
并没有替团队决定什么功能最重要

00:17:17.700 --> 00:17:20.300
也不能替公司承担发布责任

00:17:20.666 --> 00:17:23.300
测试工程师的工作会随之变化

00:17:23.466 --> 00:17:26.200
过去大量时间花在脚本维护

00:17:26.466 --> 00:17:29.200
未来更多时间会用于设计任务

00:17:29.300 --> 00:17:32.566
设置验证条件和分析失败轨迹

00:17:32.800 --> 00:17:34.800
自然语言看似降低了门槛

00:17:34.933 --> 00:17:37.266
准确描述目标反而更重要

00:17:37.566 --> 00:17:39.600
含糊任务会让代理找到

00:17:39.600 --> 00:17:41.500
一条看起来完成的路径

00:17:41.766 --> 00:17:43.800
却漏掉真正的业务要求

00:17:43.966 --> 00:17:46.700
开发流程也可能从提交代码后统一

00:17:46.700 --> 00:17:49.900
测试变成编程代理边写边操作设备

00:17:50.133 --> 00:17:51.666
它修改登录页面

00:17:51.966 --> 00:17:53.566
立刻安装构建版本

00:17:53.566 --> 00:17:55.666
走一遍登录和找回密码

00:17:55.666 --> 00:17:57.466
再根据日志继续修改

00:17:57.666 --> 00:17:59.200
设备不再是开发链

00:17:59.200 --> 00:18:00.966
末端的人工检查站

00:18:01.200 --> 00:18:03.866
而是AI编码循环的一部分

00:18:03.966 --> 00:18:06.366
这会给小团队带来明显价值

00:18:06.800 --> 00:18:09.133
没有专职移动测试工程师的团队

00:18:09.366 --> 00:18:11.800
也能建立基本的真机回归流程

00:18:11.866 --> 00:18:13.466
可规模扩大以后

00:18:13.600 --> 00:18:16.333
设备农场账号管理和并发

00:18:16.333 --> 00:18:18.966
调度仍然需要专业基础设施

00:18:19.266 --> 00:18:21.500
optimus解决了操作智能

00:18:21.733 --> 00:18:24.666
不会自动解决所有测试平台问题

00:18:25.000 --> 00:18:27.700
设备管理是一项容易被忽略的成本

00:18:27.900 --> 00:18:29.666
几十台手机同时测试

00:18:29.900 --> 00:18:31.600
需要保持系统版本

00:18:32.066 --> 00:18:33.500
屏幕分辨率和应用

00:18:33.500 --> 00:18:35.133
数据处于可控状态

00:18:35.300 --> 00:18:37.533
某项测试结束后还要清理

00:18:37.533 --> 00:18:40.866
联系人短信文件和登录状态

00:18:41.133 --> 00:18:42.700
否则下一次任务会

00:18:42.700 --> 00:18:44.600
读取上一次留下的数据

00:18:44.766 --> 00:18:47.000
Android world之所以能评测代理

00:18:47.333 --> 00:18:48.733
正是因为它为任务

00:18:48.733 --> 00:18:51.100
准备初始化和结束检查

00:18:51.300 --> 00:18:53.966
企业自己的应用没有现成评测器

00:18:54.200 --> 00:18:56.333
团队必须定义什么叫成功

00:18:56.566 --> 00:18:57.933
页面出现提交完成

00:18:57.933 --> 00:18:59.500
可能只是前端提示

00:18:59.733 --> 00:19:01.900
后台订单未必真正创建

00:19:02.066 --> 00:19:04.133
Optimus可以点击和观察

00:19:04.666 --> 00:19:06.200
却需要业务系统提供

00:19:06.200 --> 00:19:07.933
更可靠的验证信号

00:19:08.100 --> 00:19:10.400
数据库记录接口状态和

00:19:10.400 --> 00:19:12.333
设备画面要互相对照

00:19:12.533 --> 00:19:14.166
才能减少假成功

00:19:14.400 --> 00:19:16.933
自然语言任务也需要版本管理

00:19:17.266 --> 00:19:19.900
测试人员把创建一个联系人改成

00:19:19.900 --> 00:19:22.866
创建联系人并确认号码能够搜索到

00:19:23.000 --> 00:19:24.600
验证范围已经变化

00:19:25.000 --> 00:19:27.566
如果这段文字只存在聊天记录中

00:19:27.666 --> 00:19:29.966
团队很难追踪回归标准

00:19:30.200 --> 00:19:33.000
成熟用法需要把任务描述断言

00:19:33.000 --> 00:19:35.900
和环境配置像代码一样保存

00:19:35.933 --> 00:19:37.533
并进入评审流程

00:19:37.733 --> 00:19:40.133
模型更新还会制造另一种波动

00:19:40.766 --> 00:19:42.666
供应商更换默认模型后

00:19:42.666 --> 00:19:44.866
同一句指令可能走不同路径

00:19:45.133 --> 00:19:46.600
新模型更聪明

00:19:46.600 --> 00:19:49.266
却也可能更愿意尝试危险动作

00:19:49.466 --> 00:19:51.333
团队要锁定模型版本

00:19:51.400 --> 00:19:52.400
建立基线

00:19:52.500 --> 00:19:55.366
并在升级前重新运行关键任务

00:19:55.533 --> 00:19:57.533
传统脚本的变化来自代码

00:19:57.966 --> 00:20:00.166
代理测试的变化还来自模型

00:20:00.366 --> 00:20:02.266
Optimus的历史压缩机制

00:20:02.266 --> 00:20:04.733
就是为长任务控制上下文

00:20:04.866 --> 00:20:07.133
它不会一直保留每张旧截图

00:20:07.333 --> 00:20:08.733
而是把已经完成的

00:20:08.733 --> 00:20:11.000
步骤压缩成可搜索记录

00:20:11.100 --> 00:20:14.566
否则100步任务会迅速塞满模型窗口

00:20:14.700 --> 00:20:16.733
费用和延迟一起上升

00:20:16.933 --> 00:20:18.400
压缩能延长任务

00:20:18.700 --> 00:20:20.466
代价是某些视觉细节

00:20:20.466 --> 00:20:22.100
可能在摘要中丢失

00:20:22.333 --> 00:20:24.266
历史检索因此不能只

00:20:24.266 --> 00:20:26.533
依靠一句之前已经完成

00:20:27.300 --> 00:20:29.166
系统需要保留关键证据

00:20:29.500 --> 00:20:31.566
例如创建后的联系人页面

00:20:31.900 --> 00:20:34.566
移动后的文件路径和操作返回值

00:20:35.066 --> 00:20:37.366
摘要负责告诉代理发生过什么

00:20:37.466 --> 00:20:40.333
原始证据负责在出现争议时复核

00:20:40.766 --> 00:20:42.066
两者缺一项

00:20:42.333 --> 00:20:44.333
长流程都会变得不可信

00:20:44.566 --> 00:20:47.133
录屏分析提供了另一条诊断线

00:20:47.566 --> 00:20:48.800
界面一闪而过

00:20:48.800 --> 00:20:51.066
单张截图可能抓不到问题

00:20:51.333 --> 00:20:53.066
录屏可以重建动画

00:20:53.133 --> 00:20:55.333
弹窗和键盘出现的顺序

00:20:55.566 --> 00:20:58.066
Optimus把fempy列为依赖

00:20:58.300 --> 00:21:00.533
就是为了处理这类时序信息

00:21:00.733 --> 00:21:03.400
移动端bug经常只存在几百毫秒

00:21:03.800 --> 00:21:06.100
日志里也未必留下明确错误

00:21:06.200 --> 00:21:08.933
不过录屏会扩大隐私范围

00:21:09.466 --> 00:21:12.200
测试账号的通知联系人头像

00:21:12.200 --> 00:21:14.700
和输入内容都可能进入文件

00:21:15.333 --> 00:21:18.000
团队需要在采集前关闭无关通知

00:21:18.266 --> 00:21:19.600
使用合成数据

00:21:19.600 --> 00:21:21.566
并限制报告中的截图

00:21:21.733 --> 00:21:23.666
代理自动收集越方便

00:21:23.866 --> 00:21:25.600
数据治理越不能依靠

00:21:25.600 --> 00:21:27.366
测试人员临时判断

00:21:27.566 --> 00:21:29.533
权限边界还涉及ADB

00:21:29.800 --> 00:21:31.300
ADB能够安装应用

00:21:31.300 --> 00:21:32.166
读取日志

00:21:32.333 --> 00:21:33.133
启动组件

00:21:33.133 --> 00:21:35.000
并执行系统命令权限

00:21:35.466 --> 00:21:37.166
远高于普通用户操作

00:21:37.333 --> 00:21:39.600
Artemis如果连接生产手机

00:21:39.600 --> 00:21:40.800
风险非常高

00:21:40.966 --> 00:21:42.933
合理部署应使用专门

00:21:42.933 --> 00:21:45.133
测试设备和隔离账号

00:21:45.166 --> 00:21:48.533
CI中的密钥也不能直接暴露给模型

00:21:48.900 --> 00:21:51.000
开源在这里提供了现实优势

00:21:51.266 --> 00:21:52.966
企业可以检查每个工具

00:21:52.966 --> 00:21:54.666
到底调用了什么命令

00:21:54.800 --> 00:21:57.400
也能删掉不需要的高风险能力

00:21:57.600 --> 00:22:00.500
闭源手机代理只给出服务界面

00:22:00.600 --> 00:22:02.866
用户很难确认数据流向

00:22:03.166 --> 00:22:06.500
Optimus把设备驱动和代理逻辑公开

00:22:06.800 --> 00:22:08.466
至少让安全团队有

00:22:08.466 --> 00:22:10.300
审计和改造的入口

00:22:10.366 --> 00:22:12.466
开源也带来维护压力

00:22:12.900 --> 00:22:14.866
仓库没有正式版本标签

00:22:15.166 --> 00:22:18.133
当前项目迭代集中在很短时间内

00:22:18.700 --> 00:22:19.733
依赖很多

00:22:19.933 --> 00:22:23.100
既有LANGGRAPH和多家模型SDK

00:22:23.200 --> 00:22:27.100
也有ADB UI Automator和图像处理组件

00:22:27.533 --> 00:22:29.933
任何上游变化都可能影响安装

00:22:30.133 --> 00:22:32.300
9,000多个星标代表关注度

00:22:32.400 --> 00:22:34.366
不等于长期维护承诺

00:22:34.533 --> 00:22:36.466
开发者在实际采用前

00:22:36.566 --> 00:22:38.700
需要先跑自己的小型评测

00:22:39.366 --> 00:22:41.800
选择10-20条最关键流程

00:22:42.300 --> 00:22:45.466
分别记录成功率平均耗时

00:22:45.666 --> 00:22:47.900
模型费用和人工干预次数

00:22:48.000 --> 00:22:49.200
只看Android world

00:22:49.766 --> 00:22:52.100
总分无法回答企业自己的登录

00:22:52.100 --> 00:22:54.800
支付和权限页面能不能稳定运行

00:22:54.966 --> 00:22:57.066
失败类型也应分开统计

00:22:57.866 --> 00:23:00.466
模型找不到控件属于感知问题

00:23:00.766 --> 00:23:02.933
计划走错属于推理问题

00:23:03.566 --> 00:23:05.800
应用崩溃属于产品问题

00:23:06.266 --> 00:23:08.366
网路超时则是环境问题

00:23:08.466 --> 00:23:10.566
把所有失败压成一个百分比

00:23:10.800 --> 00:23:13.800
团队不知道该修提示词换模型

00:23:13.933 --> 00:23:15.600
还是修改应用本身

00:23:15.733 --> 00:23:19.333
Atemis有时最有价值的结果是暴露

00:23:19.333 --> 00:23:22.066
产品不利于自动化和无障碍访问

00:23:22.700 --> 00:23:24.866
通过本身反倒没那么重要

00:23:24.933 --> 00:23:26.700
一个按钮没有语义标签

00:23:26.966 --> 00:23:28.533
模型只能猜坐标

00:23:29.100 --> 00:23:30.166
视障用户的屏幕

00:23:30.166 --> 00:23:31.900
阅读器也可能无法识别

00:23:32.000 --> 00:23:33.766
代理测试会反过来推动

00:23:33.766 --> 00:23:35.900
开发者补齐控件描述

00:23:36.133 --> 00:23:38.466
最终改善真实用户体验

00:23:38.500 --> 00:23:41.200
这让它与传统视觉测试形成区别

00:23:42.000 --> 00:23:43.533
截图对比擅长发现

00:23:43.533 --> 00:23:45.900
颜色位置和布局变化

00:23:46.333 --> 00:23:49.333
而Temis更擅长判断任务能不能完成

00:23:49.666 --> 00:23:52.366
前者告诉团队按钮移动了5个像素

00:23:52.500 --> 00:23:53.933
后者告诉团队用户

00:23:53.933 --> 00:23:55.600
已经无法完成退款

00:23:55.766 --> 00:23:57.266
两类测试结合

00:23:57.366 --> 00:23:58.733
覆盖面才完整

00:23:58.933 --> 00:24:00.766
市场上也不只有Artemis

00:24:00.766 --> 00:24:04.733
final run auto device droid run uitas

00:24:05.000 --> 00:24:06.966
和多种computer use模型都

00:24:06.966 --> 00:24:08.800
在争夺移动代理入口

00:24:08.866 --> 00:24:11.400
他们选择不同模型和规划架构

00:24:11.500 --> 00:24:12.966
公开程度也不同

00:24:13.133 --> 00:24:15.300
99.1%的领先

00:24:15.400 --> 00:24:17.100
如果不能被持续复现

00:24:17.200 --> 00:24:20.300
很快就会被下一轮模型和工具改写

00:24:20.466 --> 00:24:23.100
Google开源这套框架还有生态意义

00:24:23.500 --> 00:24:25.466
Android开发者可以围绕它增加

00:24:25.466 --> 00:24:28.533
设备驱动行业任务和验证插件

00:24:28.800 --> 00:24:30.500
模型公司也能把它作为

00:24:30.500 --> 00:24:32.600
计算机操作能力的试验场

00:24:32.600 --> 00:24:35.500
一个共同框架如果形成移动代理

00:24:35.566 --> 00:24:37.300
就不必每家公司都从

00:24:37.300 --> 00:24:39.366
截图和点击重新造轮子

00:24:39.366 --> 00:24:42.166
可共同框架必须建立可信治理

00:24:42.600 --> 00:24:44.600
贡献代码需要清楚来源

00:24:44.866 --> 00:24:47.166
排行榜需要公开测试条件

00:24:47.333 --> 00:24:49.666
安全漏洞需要有响应流程

00:24:49.800 --> 00:24:51.566
minitab争议已经说明

00:24:51.700 --> 00:24:53.566
技术社区不仅看功能

00:24:53.566 --> 00:24:56.400
也看维护者如何处理他人的劳动

00:24:56.466 --> 00:24:58.866
Google后来补上署名是必要修正

00:24:58.966 --> 00:25:01.000
公开解释仍然同样重要

00:25:01.533 --> 00:25:04.333
Artemis未来若接入Android studio

00:25:04.666 --> 00:25:07.266
开发者可以在IDE里选中一个界面

00:25:07.366 --> 00:25:09.566
直接生成并运行设备任务

00:25:10.100 --> 00:25:11.766
这个设想很有吸引力

00:25:11.766 --> 00:25:13.800
但插件目前还在路线图

00:25:13.866 --> 00:25:16.666
现阶段仍要通过命令行网页

00:25:16.666 --> 00:25:19.266
控制台或MCP连接部署体验

00:25:19.466 --> 00:25:20.900
更适合愿意处理

00:25:20.900 --> 00:25:22.666
环境配置的技术团队

00:25:22.900 --> 00:25:25.000
实时语音也尚未完成

00:25:25.400 --> 00:25:26.566
即使以后上线

00:25:26.800 --> 00:25:28.100
它的意义也不只是

00:25:28.100 --> 00:25:29.933
说一句话控制手机

00:25:30.566 --> 00:25:32.533
双向语音要求代理在

00:25:32.533 --> 00:25:34.500
操作过程中报告进度

00:25:35.333 --> 00:25:37.100
用户能够随时打断

00:25:37.200 --> 00:25:39.100
并在敏感步骤确认

00:25:39.166 --> 00:25:40.800
没有可靠中断机制

00:25:41.466 --> 00:25:44.066
语音只会让错误操作更难阻止

00:25:44.266 --> 00:25:45.333
长期来看

00:25:45.500 --> 00:25:47.366
手机代理可能从测试

00:25:47.366 --> 00:25:49.333
工具进入运维和客服

00:25:49.766 --> 00:25:51.800
客服人员接到用户问题后

00:25:51.800 --> 00:25:54.500
可以在隔离设备上复现相同路径

00:25:54.800 --> 00:25:57.100
应用商店审核可以自动

00:25:57.100 --> 00:25:59.000
探索权限和订阅流程

00:25:59.366 --> 00:26:01.166
企业内部还能检查不同

00:26:01.166 --> 00:26:03.300
版本是否出现行为变化

00:26:03.600 --> 00:26:04.700
这些场景都需要

00:26:04.700 --> 00:26:06.666
明确授权和受控环境

00:26:06.900 --> 00:26:09.366
不能直接拿真实用户账户试验

00:26:09.533 --> 00:26:11.200
最有争议的想象是让

00:26:11.200 --> 00:26:13.066
代理自行发现漏洞

00:26:13.266 --> 00:26:14.666
它能够遍历界面

00:26:14.666 --> 00:26:15.933
输入异常内容

00:26:15.933 --> 00:26:17.966
观察崩溃并读取日志

00:26:18.166 --> 00:26:20.166
确实具备一定探索能力

00:26:20.366 --> 00:26:23.266
公开项目的目标是测试和诊断

00:26:23.866 --> 00:26:26.600
不等于授权代理攻击第三方应用

00:26:26.766 --> 00:26:28.666
使用边界仍由操作者和

00:26:28.666 --> 00:26:30.333
目标系统的许可决定

00:26:30.500 --> 00:26:32.200
它对普通用户也有潜力

00:26:32.566 --> 00:26:34.066
视障人士可以用自然

00:26:34.066 --> 00:26:36.133
语言完成复杂应用操作

00:26:36.400 --> 00:26:37.666
老人可以减少在

00:26:37.666 --> 00:26:39.533
多层菜单中寻找按钮

00:26:39.933 --> 00:26:42.966
重复性手机任务可以交给代理不过

00:26:43.200 --> 00:26:46.066
项目当前的产品形态面向开发者

00:26:46.166 --> 00:26:48.300
需要配置Python模型

00:26:48.333 --> 00:26:51.100
密钥ADB和无障碍权限

00:26:51.266 --> 00:26:53.533
距离大众助手还有明显距离

00:26:53.733 --> 00:26:56.733
Artemis真正释放出的信号是AI

00:26:56.733 --> 00:26:59.100
代理开始从浏览器走进设备

00:26:59.566 --> 00:27:02.733
网页有DOM和相对统一的交互结构

00:27:02.866 --> 00:27:04.566
手机应用更加封闭

00:27:04.700 --> 00:27:06.000
一个开源框架能够

00:27:06.000 --> 00:27:07.733
跨应用完成长流程

00:27:07.900 --> 00:27:10.500
说明多模态模型工具调用和

00:27:10.500 --> 00:27:12.933
状态管理已经组合到新的阶段

00:27:13.400 --> 00:27:14.966
这个阶段仍然粗糙

00:27:15.333 --> 00:27:16.766
速度按秒计算

00:27:16.866 --> 00:27:19.300
复杂模式一步可能接近1分钟

00:27:19.533 --> 00:27:22.400
权限配置不当会带来安全风险

00:27:22.700 --> 00:27:25.066
基准成绩缺少完整独立验证

00:27:25.200 --> 00:27:27.100
开源署名还发生过争议

00:27:27.600 --> 00:27:29.300
它没有资格被包装成

00:27:29.300 --> 00:27:30.966
成熟的手机操作系统

00:27:30.966 --> 00:27:32.733
代理可它也不是一次

00:27:32.733 --> 00:27:34.566
无关紧要的代码发布

00:27:35.000 --> 00:27:37.066
Google把项目放在公开仓库

00:27:37.266 --> 00:27:39.400
使用Apache 2.0许可证

00:27:39.600 --> 00:27:41.366
开发者可以检查实现

00:27:41.500 --> 00:27:42.300
替换模型

00:27:42.300 --> 00:27:43.866
并接入自己的设备

00:27:44.166 --> 00:27:47.300
开源让外界有机会复测99.1%

00:27:47.333 --> 00:27:50.200
也让代码来源问题无法被藏起来

00:27:50.400 --> 00:27:53.366
它同时接受技术检验和社区审查

00:27:53.566 --> 00:27:55.866
接下来最值得观察的是三件事

00:27:56.066 --> 00:27:58.766
GitHub星标能涨到多少并不关键

00:27:59.200 --> 00:28:03.300
独立团队能否复现接近99.1%的结果

00:28:03.666 --> 00:28:05.400
企业能否在真实应用

00:28:05.400 --> 00:28:07.300
中稳定运行长流程

00:28:07.600 --> 00:28:09.500
以及维护者能否持续

00:28:09.500 --> 00:28:11.666
处理安全与署名问题

00:28:11.866 --> 00:28:13.000
任何一项失败

00:28:13.166 --> 00:28:15.466
Optimus都可能停留在演示阶段

00:28:15.700 --> 00:28:17.333
如果三项都能过关

00:28:17.366 --> 00:28:19.900
移动开发会发生一次实质变化

00:28:20.200 --> 00:28:23.100
编程代理将不再只盯着代码和终端

00:28:23.533 --> 00:28:24.966
他能拿起一台手机

00:28:24.966 --> 00:28:27.566
用用户的方式检查自己的作品

00:28:27.700 --> 00:28:30.666
测试脚本也不必把每个坐标写死

00:28:30.866 --> 00:28:32.533
目标和验证条件会

00:28:32.533 --> 00:28:34.133
成为新的核心资产

00:28:34.133 --> 00:28:35.933
所以Artemis最重要的

00:28:35.933 --> 00:28:37.766
地方不是AI会点手机了

00:28:38.100 --> 00:28:39.366
真正的变化是

00:28:39.400 --> 00:28:42.366
AI第一次有机会把理解需求修改

00:28:42.366 --> 00:28:45.500
代码操作设备和验证结果连成闭环

00:28:45.700 --> 00:28:49.000
99.1%只是吸引注意力的数字

00:28:49.533 --> 00:28:50.800
能不能把这个闭环

00:28:50.866 --> 00:28:53.133
稳定放进真实开发流程

00:28:53.266 --> 00:28:55.500
才决定它会成为基础工具

00:28:55.600 --> 00:28:58.266
还是另一个跑分漂亮的开源项目