2026-10-31 晚上我认真调研了一遍 Mika（GitHub: wangzan101/Mika）。起因是我一直在琢磨给几台手机做自动化——每日签到、领金币这类轻任务，以及之后可能的多手机矩阵。Mika 的自我介绍是「你手机上的私人 AI 助理，替你操作 App、上网、把事办成」，看起来正中下怀。这篇文章把那晚的调研结论沉淀下来：Mika 是什么、为什么操作那么快、问题在哪里，以及和向日葵、PC 端框架、iPhone 侧方案怎么选。

一句话结论：Mika 是开源里消费级体验最完整的安卓手机 AI Agent，值得装一个试水；但它快的原因（无障碍节点树）和它藏不住的原因（无障碍注入）是同一个开关的两面——如果你在乎封号风险，换任何同类软件都解决不了，那需要的是另一条路线。

一、Mika 是什么

  • Android 端 on-device AI agent，开源（Apache-2.0），公开 Beta。装 APK 就能用，不需要 Root。
  • 控制方式：无障碍服务（MikaAccessibilityService）读界面、注入点击/输入/滑动手势；通过无线调试配对让它给自己开启无障碍，绕开侧载 App 的「受限设置」拦截。
  • 执行在一个隐藏的后台虚拟屏上，不占主屏，可以边干别的边跑；自带浏览器和本地 Linux 沙箱（沙箱仅 arm64）。
  • 模型自己配：必须支持 tool calling 的模型，可接 ChatGPT 等 API，也可接 Ollama / LM Studio 本地模型。没有官方服务器——屏幕内容会发给你配置的服务商。
  • 要求：App 操作需 Android 12+（推荐 14+），聊天/网页 11+ 即可。Beta 状态，官方主要在一台 Android 14 设备上测试过。

二、为什么它操作快：不是 OCR，是节点树

第一次看 Mika 操作的人多半会问：它是不是在截图识别？不是。它的主力感知是无障碍节点树，OCR 和视觉模型只是节点树读不到时的兜底。

无障碍 API 能把界面控件树直接递给它：每个按钮的文字、resource-id、坐标范围、是否可点击——相当于网页的 DOM。对它来说，App 界面是一份现成的带标签清单，不需要「看图猜哪里是按钮」。

于是快的原因就清楚了：

  1. 感知零图像处理。读节点树是毫秒级内存操作；对比视觉方案（截图 → 压缩上传 → 模型推理 → 返回坐标），光网络往返就是一秒。
  2. 点击不用算坐标。视觉方案要模型在图上回归像素坐标，慢且容易偏；Mika 的 LLM 只输出「点某个元素」这种 tool call，执行时直接取节点 bounds 注入，token 也省。
  3. 执行在本地。无障碍直接在本机注入手势，没有 adb 管道往返。
  4. 每步只剩模型思考时间。感知和执行近乎免费之后，耗时基本等于 LLM 生成 tool call 的速度——所以你接的模型快慢直接决定它操作快慢。

什么时候它会变慢：游戏、Canvas/SurfaceView 自绘界面、没开语义化的 Flutter 页面，节点树是空的，这时才落到内置 OCR 或视觉模型看截图的路径，速度和准确率都掉一个档次。它刷文字型 App（设置、签到页、资讯）飞快，进游戏就明显变笨。

三、使用 Mika 存在的问题

1. 检测面是最大问题，后台小屏不改变任何信号

一个常见错觉是「它通过小屏幕操作，不碰真实输入，应该检测不到」。判断恰好相反——无障碍是国内风控盯得最紧、检测手段最成熟的一类，虚拟屏只解决「不占主屏、能并行」的体验问题：

  • 服务枚举是一行代码。任何 App 调 AccessibilityManager.getEnabledAccessibilityServiceList() 就能列出全部开启的无障碍服务，Mika 的包名和服务名固定公开。风控只需一条规则：有没有第三方无障碍服务带 canPerformGestures / canRetrieveWindowContent 能力。
  • 注入事件自带指纹。无障碍派发的手势在输入层带隐藏标志位（FLAG_IS_GENERATED_GESTURE 一类），native 层读原始 MotionEvent 就能拿到；再叠加轨迹噪声、按压面积、传感器微动这些行为特征，机器点击和人手在事件层差异明显。腾讯 ACE、网易易盾这类反作弊把「无障碍模拟点击」列为成熟检测项。
  • 虚拟屏自己也是信号。App 检查 getDisplayId() != DEFAULT_DISPLAY、尺寸密度异常就能发现自己在小屏里跑；银行类 App 在非默认屏直接拒绝是常见做法。
  • 组合画像更重。无障碍 + 无线调试配对 + 后台虚拟屏 + 固定包名，这套组合比一个普通自动点击器显眼得多。
  • 判例佐证。2025 年 AutoCMD+ 案——被告就是一个无障碍自动点击工具，操作对象是抖音和微信，法院认定构成不正当竞争。这类工具是平台有专门对抗动作的品类，不是没人管。

所以「快和无痕在软件路线里是同一个开关的两面」：它快，因为走的是无障碍通道；它藏不住，也因为走的是无障碍通道。

2. 稳定性与成熟度

公开 Beta，官方主要在一台 Android 14 设备上测试过；LLM 有随机性，同一个任务今天成功、明天可能点错卡住。无人值守定时任务跑起来后，你需要自己加监控和失败兜底，这点 Beta 工具不会替你做。

3. 场景边界

文字型 App（设置、签到页、资讯）是它的主场；游戏和自绘界面节点树为空，落到 OCR/视觉兜底，速度和准确率双降。按「能读节点树」这个标准选场景，比按宣传语选靠谱。

4. 成本

每一步都要过一遍 LLM，无人值守定时任务等于持续烧 token；接本地模型免费，但手机端模型能力有限，复杂任务成功率会掉。

5. 隐私与信任

没有官方服务器，屏幕内容发给你配置的服务商；接本地模型可以让内容不出设备。开源可审计、无闭源远控守护进程的漏洞历史包袱，这两点是它相对向日葵的真实加分项。

四、和向日葵比：无人值守场景 Mika 更合适，风险不会更小

针对「定时领金币」这类无人值守任务：

向日葵Mika
定时执行无，要自己叠亮屏/解锁/脚本原生定时任务：一次性/间隔/每日/每周、条件检查、无人值守运行
任务配置手动远程操作自然语言一句话配置
执行方式前台远程操作，占屏幕后台小屏执行，不占主屏
每日成本免费版连接时长/设备数/画质限制每步过 LLM，持续烧 token；本地模型免费但能力有限
可靠性人盯着就稳LLM 随机性 + Beta
点击通道无障碍注入（Android 7+）无障碍注入
信任面闭源远控，Windows 端 2022 年出过批量利用的 RCE开源可审计，可接本地模型

一个容易搞混的点：向日葵的画面通道（MediaProjection 投屏）在目标 App 内确实检测不到——Android 没有公开 API 让 App B 枚举 App A 的投屏会话。但你这件任务里 90% 的动作是点击，安全的恰恰是那 10%。向日葵做无人值守还要叠屏幕常亮、免锁屏、设备管理员权限，「无障碍 + 常亮 + 设备管理员」本身就是典型自动化画像，免费版限制也很快撞上。

结论：功能上 Mika 赢（它是手机端 App 这类方案里唯一原生支持无人值守的），安全上不分高下——它和向日葵在风控眼里是同一池子里的鱼，Mika 的画像甚至更重。

五、和 PC 端开源框架比：更强效果和更好 API 的代价

方案形态控制方式特点
Mobile-Agent-v3 / GUI-OwlPC 端框架 + 模型adb + 截图视觉AndroidWorld 73.3%，技术最强，偏开发者，PC 要常驻
DroidRunPC 端框架adb + 无障碍树官方自报成绩随所接模型从 63% 到 91.4% 不等，API 友好，适合脚本批量控多台
Open-AutoGLM（智谱）PC 端 Phone Agentadb + 视觉语言模型商业版 AutoGLM 2.0 改云手机执行，动不了你本机 App 的登录态
AppAgent / AutoDroid研究项目PC + adb偏学术，2023—2024 项目，活跃度一般

共同点比差异重要：它们全部依赖 adb 或无障碍注入，检测面和 Mika 是同一类。软件路线上不存在「更好的 Mika」，只存在体验更好或能力更强的同类。真要说差异：想效果最好、愿意折腾，PC 跑 Mobile-Agent-v3；想写脚本批量控多台，DroidRun 的 API 更友好；Open-AutoGLM 这类云手机方案对你本机的 App 登录态无能为力。

六、iPhone 侧的现实：画面好办，输入无解

  • 画面：有线采集卡就是天花板。iPhone 15 以后 USB-C 直连（DisplayPort Alt Mode），老 Lightning 机型走苹果数字 AV 适配器转 HDMI。这是系统显示输出不是录屏，UIScreen.isCaptured 对有线 HDMI 不保证置 true，实际会检查外接屏的 App 很少。iPhone 上别用软件投屏——ReplayKit 屏幕直播走「捕获中」状态，isCaptured 置 true、状态栏挂红条，风控读这个状态是标准操作。
  • 输入：iOS 从系统层面没有注入 API——没有无障碍注入、没有 adb，不越狱没有任何第三方 App 做得到 Mika 干的事。所以消费级 iOS agent 只能走截图 → 视觉模型 → 坐标推理，慢是路线本身决定的。唯一例外是开发者通道：XCUITest / WebDriverAgent 读的同样是系统 UI 树（accessibility tree），操作也是合成事件，范式跟 Mika 一样快——但要 Mac + Xcode + 签名 + 开发者模式，是测试基建不是消费产品。向日葵自己的答案也很有参考价值：它的 iOS 控制硬件 UUPro 本质是蓝牙 HID 鼠标，配合辅助触控指针模式，不算无痕（辅助触控开关、屏幕指针光标都在）。
  • 落到实际：固定流程（每日签到、领金币）根本不需要「快」，截图慢无所谓，固定坐标脚本甚至不需要 AI。上外设之前，iOS 自带两条官方半自动通道可以先试：快捷指令自动化（定时触发 + App Intents，只覆盖支持该框架的 App），以及开关控制配方（录一段固定手势，用蓝牙外接开关触发；开关控制是否在运行有公开 API 可读，并不隐身）。iPhone 试点机用「采集卡看画面 + 机械点击 + 固定脚本」完全可行，真正的成本是页面改版后的重标坐标。

七、所以什么场景选什么

  1. 自己的一台手机、接受封号风险的轻任务：Mika 是开源里体验最完整的，装一个试水，值得。
  2. 想要最强效果、愿意折腾：PC 常驻跑 Mobile-Agent-v3。
  3. 要写脚本批量控多台：DroidRun 的 API 更合适——但这是把自动化画像乘以台数，风险自己掂量。
  4. 账号值钱，或量大到算矩阵：软件注入（Mika、向日葵、DroidRun、Mobile-Agent）全部不合格，回到只读画面（采集卡/摄像头）+ 机械点击的物理路线。这条线上软件方案的检测面全部消失，剩下的对手只有行为层风控——节奏、路径、时段的统计分析，任何方案都躲不掉，拼的是「别太机器」。
  5. 每天几毛钱的金币：不值得上几百块的机械臂。先看目标 App 有没有官方签到小组件、定时提醒；其次定时提醒人手点一下。账号不值钱又想自动化，上软件注入并接受「可能清金币/封号」，这是知情选择；金币能提现的场景是风控重灾区，清零、提现拦截、降权、封号都常见，账号绑着实名和手机号，封一个少一个。

边界声明：这篇只做设备与工具的选型分析，不提供绕过平台风控的方法。无障碍批量自动化已有不正当竞争判例，量到多台矩阵就是另一个性质的决定，值得单独想清楚再动。

资料来源（2026-10-31 至 11-01 核对）