给 Maestro 做了个开源 MCP 增强层：多设备并行、断言、失败自动归因用 Maestro 做移动端 UI 自动化

用 Maestro 做移动端 UI 自动化测试的应该不少。它的官方 MCP server 能让 AI Agent 读屏、点击、跑 flow，但用下来有个明显感受：它刻意只做到"能操作"这一步 —— 单设备、原子操作，对结果对不对没有态度。

跑一整套回归时，三个问题特别疼：

只有一台设备。跨设备并行是 Maestro Cloud 的收费点（$250/设备/月），开源 CLI 里永远不会给
没有断言。Agent 验证一个结果要自己跑 → 截图 → 读层级 → 描述 → 判断，四五个来回，结论只存在当轮对话里，不可复现
失败没人管。只告诉你 fail，不告诉你是 App 的锅还是脚本的锅 —— 而这才是 QA 接到红的第一问

所以我写了个开源项目 maestro-plus，定位很克制：官方 MCP 的增强层，一个官方工具都不重复实现（仓库里有条测试强制这一点，谁忘了构建直接红）。

补了什么

工具	干什么
`run_parallel`	N 条 flow 跨 M 台设备并行，设备池租约管理，返回实测加速比
`run_and_assert`	跑 flow + 求值一组断言，一次调用拿结论
`debug_failure`	失败自动归因：收集失败步骤、前后截图、Maestro 自己的失败抓屏、日志、层级，然后判定是应用缺陷还是测试缺陷（带置信度）
`assert_visual`	屏幕区域级像素比对，可配容差，基线可显式刷新
`explore_and_record`	把 Agent 已执行的步骤转成可回放 flow，并自动生成断言（录制里最容易写坏的部分），生成后实跑验证
`list_device_pool` / `health_check`	设备池状态、工具链自检与降级映射

debug_failure 的归因规则举一个例子：logcat 有 FATAL EXCEPTION → 应用缺陷，高置信；焦点被系统权限弹窗抢走 → 测试缺陷（flow 没处理弹窗），高置信；失败步骤引用的元素在层级里存在但 disabled → 应用缺陷，中置信；元素完全不存在 → 诚实地给 unknown + 低置信，因为一次失败确实分不清"界面没渲染出来"和"选择器过期"。

我认为诊断工具宁可说"不知道"，也不能把 bug 送错团队。

设计上守两条线

官方有的能力一律包一层，不重写 —— 上游哪天自己做了并行，这个项目还能活，因为 debug_failure 这种脏活官方不会做
官方 MCP 挂了就走 adb + Maestro CLI 降级，永远降级、绝不失败

用法

{
  "mcpServers": {
    "maestro-plus": {
      "command": "npx",
      "args": ["-y", "maestro-plus"]
    }
  }
}

前置要求就是 Maestro CLI + adb，Python 3.10+。CI（3.10/3.12 双版本 lint + test）是绿的。

GitHub：github.com/Fwmouomu/ma…

设计决策的完整论证（逐条对着官方文档核对过的能力缺口）在 docs/why.md，已知坑也在 docs/limitations.md 里摊开了 —— 包括"没有无障碍树就没有诊断"和"真实失败里 unknown 会比你希望的多"。

Android 先行，iOS（simctl）在 roadmap。欢迎来提 issue，特别是真实失败样本 —— 归因规则需要真实 case 校准，我拿自己那套 JusCall 测试套件在喂它。