我们第一次搭手机 Agent 原型的时候，几乎所有人第一反应都是：本地跑一个小模型，把「聪明的大脑」塞进手机里。毕竟端侧推理快、不用联网、隐私第一。
后来我们把设计彻底翻了过来。我们把最需要智能的「意图理解和多步规划」丢到了云端，把最笨重的「画面感知」与「动作执行」死死按在端侧。不是因为算力不够，是因为信任边界和故障域。这件事贯穿了我们整个架构。
下面拆开说，每层放什么，为什么这么放，出错的时候怎么兜底。
架构分层全景：端侧三层，云端两层
端侧分三层。
感知层：通过无障碍服务获取界面控件树（语义化，无需 Root），同时做轻量截图。这里不识别图像含义，只产出结构化的「界面摘要」：当前页面有哪些可点击元素、文本内容是什么。
执行层：接收云端下发的动作指令（点击、滑动、输入），在本地完成动作调度；同时做帧稳定检测——连续 N 帧界面不变才执行下一步，防止动态画面误判。
本地策略与脱敏层：规则引擎处理明确的安全边界。验证码输入框、支付密码页、隐私设置页，在这一层直接拦截，不生成摘要，不往上送。
云端分两层。
意图理解与任务规划层：拿端侧上传的「目标 + 已完成步骤 + 当前界面摘要」，跑大模型做多步规划，拆解下一步动作。
上下文与状态管理层：维护一个任务状态机。目标不变，逐步更新已完成步骤和实时界面摘要，控制上下文长度膨胀。不存原始截图，不存密码。
一句话总结：端侧做「看见什么、能点什么」，云端做「现在该点什么」。
为什么是这一刀：四个维度的取舍
模型能力。多步规划需要大模型的推理链，端侧小模型目前撑不住「点外卖—选地址—用优惠券—确认支付」这种跨应用长链任务。而感知和执行是确定性动作，端侧轻量模型或规则引擎完全够用。
隐私。这是我们最硬的约束。画面不出本机，无障碍控件树经过脱敏后才传给云端，原始截图从未离开手机。支付页、验证码这类信息我们做到「从源头不采集」——感知层直接跳过这些控件，不是采下来再打码。
延迟。端侧的界面解析和动作执行全部在 200ms 级内完成，用户感受不到卡顿。云端大模型推理有秒级延迟，但因为规划是异步的、在后台跑，实际使用体感是「端侧先反馈，云端后给决策」，中间用动效过渡。
成本。如果每步截图全量上传云端做视觉理解，一次点外卖的流量和推理成本会吃掉一个月的预算。我们算过，用结构化摘要代替图片，单次任务云端 token 消耗控制在三位数，成本低了两个数量级。
端云怎么通信：不是传图，是传「状态」
我们设计的通信协议本质是一个任务状态机。端侧上报的数据包非常窄：task_id + goal + completed_steps[] + screen_summary。云端返回 next_action + action_params + new_expected_state。
关键设计有三条。第一，目标全程不变，避免模型「忘事」。第二，已完成步骤只保留关键的语义节点，而不是所有操作日志，防止上下文爆炸。第三，云端不主动请求端侧数据，端侧只在「一步完成且界面稳定后」才上报，避免高频轮询。
这个通信模式天然扛断网——因为云端不需要持续连接，端侧可以在离线时缓存动作指令，联网时再同步。
容错与降级：云端挂了怎么办
云端服务不可用的时候，端侧自动切到「基础模式」：用端侧小模型做有限的单步决策，类似「在当前应用内重复上一动作」。虽然弱，但不会让用户面对一个死掉的 Agent。
更麻烦的其实是「云端给了错的动作」。我们做了三层兜底：
- 执行前校验：动作目标控件在当前界面是否存在、是否可点击。
- 执行后回读：完成动作后立即回读界面状态，看是否符合预期。不符合则上报异常并请求重规划。
- 帧稳定锁：界面在连续 N 帧内没有变化才执行操作（对抗动态加载、弹窗、闪屏）。这是我们踩坑最多的点，没有这个机制，Agent 在跳转动画中间点错按钮的概率高到没法用。
所有失败重试都会留痕，端侧记录操作前后的界面摘要，开发者能一条条回溯「当时 Agent 到底看到了什么」。
敏感数据为什么留在本地：从源头不采集
验证码、支付密码、注销确认——这些场景 Agent 必须「看不见」。不是看见了不传，而是根本不看。
在感知层，我们做安全控件识别：当无障碍服务碰到特定控件类型和文本特征（比如密码输入框、验证码区域），直接跳过，不提取内容，不生成摘要。这样做不是因为合规，是因为用户不需要跟厂商解释「你为什么碰我的密码」，根本碰不到才是边界。
关键操作人工确认：停在最后一步等人点头
支付、注销、隐私授权这种不可逆操作，Agent 必须留一个硬断点。我们的设计是：Agent 把任务执行到「最后一步之前」，比如选好了商品、填好了地址、算好了优惠，然后停在支付确认页，推送一条消息给通知栏：「订单已填好，等你最后看一眼并确认支付」。
确认流程是端侧闭环的：用户指纹/面容验证直接在手机本地完成，不经过云端。用户可以叫停、可以回溯一步（「先不支付，换张卡」），Agent 收到后回溯任务状态机重新规划。整个过程中云端被隔离，只收到一个「用户已确认/取消」的信号，不掌握任何支付凭证。
这是一个从工程角度很明确的选择：我们放弃「全自动」的体验流畅度，换「出事了用户不用承担损失」的安全基线。在架构评审里，这点没有商量余地。
我们做侠客工坊时，这套架构从图纸到跑通点外卖、订高铁、发红包、查社保四个任务，用了一键部署脚本差不多 10 分钟就能起环境。端云协同的边界不是画一次就不变的，后面每接一个新任务，我们都会重新审视一次「这一步真的需要上云吗」，结果往往是把更多东西拉回端侧。
做 Agent 的这两年，最大的感受是：端云拆分不是技术难题，是责任划分。如果你也在搭这类系统，建议先画故障域边界，再画模块边界。哪个场景的错不允许犯，就把那块锁在本地。
你遇到过 Agent 执行中界面跳变导致的误操作吗？评论区说说你们怎么防的，我们当时用帧稳定检测磕了整整两周。
