谷歌放大招了！开源AI项目Artemis，让手机自动化成功率飙升到99%
事情是这样的。
最近刷GitHub Trending，被一个项目给震到了。
谷歌开源了一个叫Artemis的AI项目，专门做Android自动化测试。我一看介绍，卧槽，这玩意也太猛了吧。
先说最炸裂的数据：在Google Research的AndroidWorld基准测试上，Artemis的任务完成率达到了99%以上。
99%是什么概念？
这个基准测试包含了20多个应用、100多个多步骤任务。之前那些AI自动化工具，在这个测试上基本都是惨不忍睹，能跑通60%就算牛逼了。
结果谷歌直接把天花板捅破了。
这玩意到底能干啥？
坦率的讲，我第一次看到Artemis的介绍时，还以为又是一个普通的自动化测试框架。
但仔细一看，不对劲。
这东西的核心能力，是把自然语言指令直接转换成可靠的Android自动化操作。
什么意思呢？
你用大白话告诉它：「打开系统设置，找到电池选项，看看当前电量是多少，顺便检查一下有没有崩溃弹窗。」
它就真的能帮你把这些操作一步步执行下来。
不是录制回放，不是写脚本，就是纯纯的自然语言驱动。
更骚的是，它还能自动捕获日志、截图、生成测试报告。你让它跑完一轮测试，它给你一份完整的诊断报告，比人写的都详细。
两种模式，各显神通
Artemis有两个执行模式，这个设计我觉得挺有意思的。
Flash模式
快，就是快。
每一步操作只需要3-5秒，采用的是反应式观察-行动循环。没有复杂的图编排，就是一个模型看屏幕、思考、行动，一气呵成。
适合那种常规的、确定性强的UI任务。比如自动化填写表单、批量操作、快速验证某个功能是否正常。
Pro模式
稳，就是稳。
每一步需要15-40秒，但它是多智能体协作的架构。有一个Planner负责制定任务计划，一个Operator负责执行，还有一个Checker负责验证。
这个模式能处理100多步的长流程任务，还能做持续监控。适合那种复杂的端到端测试，或者需要深度推理的场景。
我觉得这个双模式设计很聪明。就像开车一样，有时候你需要快速超车（Flash），有时候你需要稳稳地跑长途（Pro）。不同场景用不同模式，效率和可靠性都能兼顾。
MCP集成，这才是杀手锏
说到Artemis最让我兴奋的地方，不是它的自动化能力有多强，而是它的MCP（Model Context Protocol）集成。
啥是MCP？
简单说，就是让AI编程助手能直接控制你的手机。
Artemis内置了一个原生的MCP服务器，可以直接连接到Claude Code、Codex、Windsurf这些主流的AI IDE。
这意味着什么？
你可以在写代码的时候，直接用自然语言让AI帮你测试手机应用。
举个例子，你在Claude Code里写完一个Android应用的新功能，然后直接说：「把最新的改动打包成APK，安装到连接的设备上，打开登录界面用测试账号登录，验证登录后有没有意外弹窗，把最终页面的截图返回给我。」
然后AI就会调用Artemis，自动完成这一整套操作。
这个工作流，说实话，我第一次看到的时候有点懵。
因为以前做移动端测试，要么手动点点点，要么写一堆自动化脚本。现在倒好，直接用自然语言描述测试场景，AI帮你执行，还能自动收集日志和截图。
这不就是测试工程师梦寐以求的「动嘴不动手」吗？
架构设计，有点东西
我仔细看了一下Artemis的架构设计，发现谷歌在这块确实下了功夫。
多模态定位
它不是单纯靠OCR或者UI树来定位元素，而是把多种方式结合起来了。
优先用无障碍服务的元素索引，如果找不到，就回退到坐标定位和视觉定位。对于那些用Canvas、Compose、Flutter实现的自定义界面，也能搞定。
这个设计很务实，因为现实中的Android应用千奇百怪，没有一种定位方式能包打天下。
预执行检查
Pro模式下，每一个操作在执行之前，都会先检查一下目标元素是不是真的在屏幕上。
这个听起来好像很基础，但实际做自动化测试的人都知道，这玩意太重要了。很多自动化脚本失败，就是因为元素还没加载出来就去点了。
历史压缩
Flash和Pro模式都会把旧的截图替换成视觉摘要，把完成的步骤压缩成可搜索的历史块。
这样既能保持上下文的连贯性，又不会让token消耗爆炸。对于长时间运行的任务来说，这个优化很关键。
争议：谷歌又被指控「抄袭」了
说到Artemis，不得不提一下最近的争议。
有开源团队指控谷歌在Artemis中使用了他们的代码，但没有正确归属。
具体来说，是一个叫mobile-use的开源项目，由Minitap公司开发。这个项目也是做移动端自动化的，Artemis里确实包含了mobile-use的源代码。
谷歌在README最后加了一行：「This project includes source code developed by Minitap, Inc.」
但指控方认为，这远远不够，谷歌应该更明确地标注哪些代码来自mobile-use，以及遵守相应的开源许可协议。
这事儿吧，我不好说谁对谁错。但谷歌在开源领域的「借鉴」历史，确实不是第一次了。
之前Gemini的训练数据争议、TensorFlow与Theano的恩怨，都闹得沸沸扬扬。
不过话说回来，Artemis本身的技术实力是实打实的。99%+的成功率不是靠抄代码能抄出来的，背后肯定有大量的工程优化和算法创新。
这东西能用来干啥？
除了正式的自动化测试，我觉得Artemis还有很多有意思的玩法。
RPA（机器人流程自动化）
现在很多RPA工具都是针对PC端的，移动端的RPA一直是个痛点。
有了Artemis，你可以用自然语言描述一堆手机操作，让它自动执行。比如批量注册账号、自动化营销操作、数据采集等等。
当然，这些操作可能涉及灰色地带，大家悠着点用。
无障碍辅助
Artemis的无障碍服务能力，其实可以用来帮助视障人士操作手机。
想象一下，一个视障用户说：「帮我打开微信，找到张三的聊天记录，把最近那条语音消息播放出来。」
如果Artemis能接入语音交互，这不就是一个天然的手机语音助手吗？
AI Agent的「手」
现在AI Agent的概念很火，但大部分Agent都只能处理文本和代码。
有了Artemis，AI Agent就有了操作真实手机的能力。它可以帮你测试应用、收集数据、甚至执行一些需要手机操作的任务。
这可能是Artemis最有想象力的应用场景。
快速上手
如果你也想试试Artemis，其实挺简单的。
macOS/Linux：
git clone https://github.com/google/artemis.git && cd artemis
./start.shWindows PowerShell：
git clone https://github.com/google/artemis.git
cd artemis
.start.bat启动脚本会自动帮你安装ADB、scrcpy、FFmpeg这些依赖，还会提示你配置MCP和AI IDE的规则。
启动后会打开一个Web控制台，有设备连接向导、实时屏幕投影、Prompt沙盒、执行回放这些功能。
你也可以直接用命令行：uv run artemis run "打开设置，找到电池，告诉我当前电量" --profile flash
一些思考
写到这里，我突然想到一个问题。
Artemis的出现，是不是意味着测试工程师要失业了？
说实话，我不这么认为。
自动化测试工具发展了这么多年，从Selenium到Appium，再到现在的AI驱动测试，每一次技术革新都有人喊「测试要完了」。
但现实是，测试工程师的岗位需求一直在增长。
为什么？
因为工具越强大，能覆盖的测试场景越多，需要人来设计测试策略、分析测试结果、处理复杂业务逻辑的需求也越多。
Artemis能帮你执行测试，但它不知道你的业务逻辑是什么，不知道哪些场景是高风险的，不知道测试结果背后的含义。
这些，还是需要人来做。
不过，测试工程师的工作方式确实会改变。
以前是写脚本、维护脚本、调试脚本。
以后可能是描述测试场景、分析AI生成的测试报告、优化测试策略。
从「写代码的人」变成「指挥AI的人」。
这个转变，其实挺好的。
最后
Artemis的出现，让我看到了移动端自动化的未来。
自然语言驱动、多模态定位、MCP集成、99%+的成功率，这些技术组合在一起，确实有点「魔法」的味道。
当然，它也不是完美的。目前只支持Android，iOS还在路线图上。对于一些复杂的自定义UI，定位准确率可能还有提升空间。
但瑕不掩瑜。
如果你是做移动端开发或者测试的，强烈建议去GitHub上看看这个项目。
如果你是AI爱好者，也可以研究一下它的架构设计，有很多值得学习的地方。
如果你只是普通用户，也许很快，你就能用自然语言让AI帮你操作手机了。
大时代啊，朋友们。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
谢谢你看我的文章，我们，下次再见。
/ 作者：mojianpo
/ 投稿或爆料，请联系邮箱：406223802@qq.com
