三层各管什么
要让 AI 稳定地控制真实手机，得有三层能力配合，每一层解决的问题不一样。
| 层级 | 代号 | 职责 | 不负责 |
|---|---|---|---|
| L1 原子能力 | 真机 Agent | 在真机上完成一次可验证的基础操作（点击/滑动/输入等） | 理解用户自然语言 |
| L2 工作流 | 剧本/模板 | 把刚需场景编成稳定步骤图（如“发布一条抖音短视频”） | 替代 IAM/控制台 |
| L3 对话编排 | Cloud/Eino | 选工作流、补全槽位、创建/查询任务、解释失败 | 在对话里直接点 UI |
| 任务状态机 | df_task | 下发、取消、日志、终态 | 执行 UI 自动化 |
原子能力不稳，上面两层也跑不稳。目前支持这些调用：
launch_app：启动指定 App，成功回执要求前台已是目标 App。tap：点击坐标或选择器，可选 UI 变化确认。swipe：滑动手势，手势完成后回执。input：输入文本，目标框文本符合预期或可读取即算成功。wait_ui：等待文案或控件出现，超时则明确报错。album_import/pick_media：媒体资源就绪，确保可被发布页选中。screenshot（可选）：用于调试或局部重规划，默认不落盘（产品约定不存截图）。
每个调用都有成功或失败回执。依据是执行、断言、回传，三步各自留证据。某一步失败，能定位到是哪一步，流程不会糊成一团。
工作流把这些调用拼成固定步骤。一条 L2 工作流包括四部分。
workflow_id：唯一标识，比如publish_short_video。- 槽位 schema：用户要填哪些参数，比如文案、视频路径、目标 App。
- steps 或 FSM（有限状态机）：执行步骤图，每一步调用原子能力，并带断言。
- 发布状态和 scope。scope 分两种。
system是系统预置，tenant是租户自定义。status标成published，才对外可见。
当前内置的示例是「短视频发布」。参数有四个：账号语境、文案、媒体引用方式、目标 App。目标 App 先定一个就够，抖音、小红书、视频号任选。建好之后可以立即执行，也可以绑定一台指定的在线设备。定时发布、多设备批量这些 P1 能力还在排期里。
L3 接的是自然语言。你说一句话，系统拆开再调度。链路是这样：
- 用户说出意图，例如「明天 9 点用这台手机发一条抖音，文案是 xxx」。
- Eino Agent 做规划：解析意图，认出要调用哪个工作流，再抽出槽位参数。
- 产出步骤图，建成任务。工作流展开成
df_task，状态变成running。 - 经 WebSocket 下发到 Agent 执行端。Agent 执行 steps，把进度和结果回传。
- 在控制台看结果。状态从
pending到running，再到succeeded或failed。失败一定有可读的错误信息。
L3 默认不直接编排每一次 tap。它做高层的意图理解和调度，具体步骤在 L2 工作流里已经定好。改流程时改工作流 JSON 就行，不用重新训练模型。
MCP、会话、工作流怎么配合
产品分成三块，共用同一套工作流和基础设施。
| 模块 | 是什么 | 做什么 |
|---|---|---|
| MCP Server | 给 WorkBuddy/Claude 等外部 AI 的入口 | 列设备、跑工作流、查任务；不点手机 |
| Agent 会话 | 控制台内置对话工作台 | 运营用户多轮聊天→选工作流、填参→建任务 |
| 工作流 | 可版本化的自动化模板库 | 槽位 schema + steps/FSM + 发布状态；内外统一 |
这三块走同一条通路：ws(task_dispatch) → agent 执行端 → 真机。从 MCP 进来，或从控制台的 Agent 会话进来，执行链路相同。
截图不落盘
全链路不落盘、不落库截图。设备信息和任务记录留在你自己的电脑上。数据敏感的工作室和企业用得上这条：别人拿到机器，也还原不出屏幕内容。
再加上多租户和 RBAC 权限体系。不同事业部只看到自己的设备。运营只有设备、任务、AI 三项权限。只读角色建不了任务。
具体怎么上手，见 安装部署。