OpenGUI 移动操作员
让 AI 在真实 Android 设备上看屏、规划并执行应用内操作。
按维度查看评分与理由
证据显示：README 提到需要用户授权 USB 调试、AccessibilityService 等权限，但未明确最小权限原则；有用户确认步骤（如授权操作），但未系统化；数据流描述（如截图、任务分发）存在但不够透明；敏感数据处理（如 API 密钥）有提及但未详细说明；依赖安全未提及；外部影响（如远程控制）有描述但未评估风险；回滚机制未提及；来源归属（如 Core-Mate）有提及但未验证。扣分原因：缺乏具体实现细节和证据。
证据显示：README 和代码结构一致，但存在不一致之处（如 README 提到 'Qwen 3.6 Plus' 但可能不存在）；依赖可用性未明确；失败消息有提及（如错误报告）但未详细。扣分原因：依赖和失败处理证据不足。
证据显示：README 明确了目标用户（开发者、AI 代理）和使用场景（Android 自动化）；能力边界有描述（如需要 Android 设备、权限）；触发方式（CLI、IM）有说明但不够精确；环境适配（如 Docker、本地）有提及。扣分原因：触发精度和边界细节不足。
证据显示：信息架构清晰（README、docs、skills）；安装说明存在（start.sh、get-started.md）；命名稳定性未明确；示例和 FAQ 较少；已知限制有列出；许可证明确（BUSL-1.1）；版本变更日志未提供；维护责任未明确。扣分原因：命名稳定性、示例、变更日志、维护责任证据不足。
证据显示：输出可用性（结构化结果）有描述；边际价值（如成本节省）有提及；成本效益（如模型成本对比）有说明。扣分原因：缺乏实际运行数据支持。
证据显示：README 中的声明（如功能、性能）有部分代码引用，但未完全对应；跨来源验证不足；事实与推断未明确区分。扣分原因：声明与代码对应性不足，缺乏独立验证。
- 该仓库使用 BUSL-1.1 许可证，非 OSI 批准的开源许可证，生产使用需商业许可。
- README 中提到的模型（如 Qwen 3.6 Plus）可能不存在，需验证。
- 远程控制功能（如 Discord、REST API）可能带来安全风险，需谨慎配置。
这个 Agent 能做什么，适合哪些场景？
OpenGUI 是面向 Android 真机或模拟器的移动 GUI 智能体框架，用于理解屏幕并操作应用界面。后端以 Plan Supervisor 管理任务状态，Executor Graph 在实时设备状态上执行截图、视觉、动作和用户交互循环，Summarizer 返回结构化执行结果。Android 客户端通过 StandbySocketManager.kt 保持待命连接，并由 GestureService.kt 通过 AccessibilityService 执行动作。任务可由本地 CLI、REST API，以及飞书、Telegram、Discord 等远程入口分发到待命设备。项目支持将规划与 VLM 执行分配给不同模型路径，并提供 Claude Code 与 Codex 的引导和远程控制流程。
用户提交任务后，Plan Supervisor 将目标拆为可执行步骤，Executor Graph 读取 Android 应用当前界面并在设备实时状态上运行截图、视觉、动作和 call-user 循环；执行结果经 review/retry 回到监督流程，最后由 Summarizer 产出结构化结果。设备待命分发由 server/apps/backend/src/common/ws/standby.gateway.ts 处理，客户端的 StandbySocketManager.kt 维持连接，GestureService.kt 在 Android 侧执行手势。可通过 pnpm opengui -- devices --json 查询设备，通过 pnpm opengui -- do "..." --json 派发任务，并用 pnpm opengui -- status <executionId> --json 查询执行状态。
- 需要在已连接 Android 手机上查看当前应用界面并获得屏幕内容摘要的开发者。
- 需要让真实手机中的 X、Reddit 或 Hacker News 收集某个主题近期内容的研究人员。
- 需要通过飞书、Telegram、Discord 或 REST API 向待命 Android 设备下发任务的运维团队。
- 需要执行重复性 Android 应用流程，并在任务结束后获取结构化结果的自动化团队。
- 需要由 Codex 或 Claude Code 完成本地启动、APK 构建、安装与调试，同时只在手机端请求人工操作的用户。
这个 Agent 有哪些优点和局限？
- 不是单次短循环：主图与 Executor Graph 分工执行，Plan Supervisor 持续管理任务状态、续跑与复核。
- Android 端具有明确的待命和执行链路：StandbySocketManager.kt 维护设备连接，GestureService.kt 经 AccessibilityService 执行动作。
- 本地 CLI、REST API、飞书、Telegram 和 Discord 均可作为任务分发入口，适合将手机作为远程工作节点。
- 规划与 VLM 执行可走不同模型路径，支持 Claude、GPT、Gemini、Kimi、MiniMax 及兼容模型的路由。
- 必须使用 Android 真机或模拟器，并需要 USB 调试和 AccessibilityService 权限。
- 执行质量受模型、应用 UI、网络状态和任务时长影响，长任务可靠性仍需要更多真实环境验证。
- 当前不是常驻的操作系统级助手；任务需手动触发或经已配置的分发渠道触发。
- 项目采用 BUSL-1.1：生产、商业使用、托管服务及商业产品集成需要向 Core-Mate 取得单独商业许可。
如何安装或部署这个 Agent？
准备 Android 手机或模拟器，启用 USB 调试和 AccessibilityService，并为实际任务执行提供模型 API 密钥。启动后端：cd server 后运行 ./start.sh；启动 Android 客户端：cd client 后运行 ./start.sh。后端启动流程涉及 Docker 化的 PostgreSQL 和 Redis 设置；如需 Discord 分发，还需配置 DISCORD_BOT_TOKEN，未配置时后端会跳过 Discord。
如何使用这个 Agent？
后端和客户端启动后，在 server 目录运行：pnpm opengui -- devices --json 查看设备；pnpm opengui -- do "Observe the current Android screen and summarize what you see" --json 下发首个任务；pnpm opengui -- status <executionId> --json 跟踪任务。也可让 Codex 或 Claude Code 读取 skills/open-gui-bootstrap/SKILL.md 完成引导，或使用 skills/open-gui-remote-control/SKILL.md 通过本地 CLI 调度 Android 任务。
这个 Agent 与同类方案有什么区别？
与典型的短时、交互式手机智能体演示相比，OpenGUI 明确采用主图加执行子图的执行模型，在后端维护任务状态，并内置 Android 待命连接及飞书、Telegram、Discord、REST 分发路径。