企业官网建设流程全解析

最近我在工位上坐了一整晚，盯着一个AI Agent 在我自己的手机上连续操作：切应用、读屏幕、调键盘、点确认。这个动作放在一年前，叫自动化脚本回放；现在不一样了，背后没有写死的坐标和控件路径，而是模型自己在“看”、在“想”、在“点”。说实话，第一次看到它在我真实手机上自主完成跨应用任务时，我的感受不是“哇，太强了”，而是“坏了，移动端自动化这套老体系要重新出题了”。

旧考题我很熟：控件定位、脚本回放、CI批量跑测，核心诉求是“稳定地重复”。但AI Agent 操作真实手机，核心诉求变成了“理解意图、适应环境、为行为负责”。我梳理下来，真正称得上“新考点”的核心是三个：意图驱动的动态规划、真实环境下的感知与校验、安全护栏与可观测性。这篇不是理论科普，是我在模拟项目里把Agent放到真机上跑之后，对这三个考点的复盘和踩坑记录。

1. 先聊清楚：AI Agent 操作真实手机，和过去的自动化到底哪里不一样

1.1 传统自动化：一条确定性的“因果链”

传统移动端自动化的本质，是“用例即代码”。我们预先写好一串操作：打开某个App，等待某个控件出现，输入一段文本，点击某个按钮，断言某个结果。这背后依赖的是稳定的控件树、明确的页面层级、可枚举的状态。

这套体系在测试领域打磨了很多年，优势是快、准、可回归。但它有一个天花板：只要是预先写死的，就只能在“预期内”工作。页面改版了，控件id变了，脚本立刻失效；出现了一个没有预料到的弹窗，脚本就会卡在原地；App从启动到加载完成的时间稍微抖动了一点，等待条件就要重新调。

我之前做自动化时最崩溃的事情，就是每天醒来先看昨天的回归报告，然后花一上午修脚本。不是功能坏了，是脚本依赖的某个控件属性变了。那种“自动化维护成本高于手工成本”的时刻，恐怕很多同行都经历过。

1.2 Agent自动化：一套概率性的“感知-决策-执行循环”

AI Agent 操作手机的逻辑完全不同。它不再把手机当成一条固定流水线，而是当成一个“需要随时观察、随时调整”的真实环境。

一层模型接收屏幕截图、界面层级、系统状态等信息，然后根据目标意图，动态生成下一步动作：向右滑动、点击某个按钮、输入文本、等待页面加载。做完一步，再截取屏幕，对比前后变化，决定继续还是修正。整个过程是一个“感知-决策-执行-再感知”的闭环。

这才是“考点”的真正来源。传统自动化把难度压在“如何精确表达每一步”，Agent自动化把难度压在“如何让Agent在不确定的环境中不断做对下一步决策并验证决策结果”。前者是工程问题，后者是智能体问题。

1.3 一张对比，快速定位范式变化

我把两个时代的关键差异整理成了一张表，后面聊考点时会反复用到它：

这张表其实已经暗示了三个考点。下面展开聊。

2. 三个新考点放在一起看，本质是一次“自动化”范式的切换

2.1 考点一：意图驱动的动态规划

旧自动化是“我告诉你每一步怎么做”；新自动化是“我告诉你要什么，你规划路径并执行”。

这带来的第一个考点，是意图理解和动态规划能力。Agent拿到一句“帮我订一杯咖啡”之后，要自己做决定：先找哪个App，进入了什么页面，选哪种咖啡，加到购物车还是直接下单，遇到确认弹窗怎么处理，最终判断“订单成功”的标准是什么。

其中最难的部分是“动态”。计划永远赶不上变化，屏幕上出现什么不可预知：广告弹窗、键盘遮挡、系统更新提示、网络异常。Agent需要在执行过程中不断重新规划。这不是把一个大任务拆成固定子任务就行了，而是每次决策都要结合当前屏幕状态重新评估。

2.2 考点二：环境感知与状态校验

如果Agent只是会“生成操作”，那它和普通脚本没有本质区别。真正的分水岭是它会不会“看”和“确认”。

真实手机是高度不稳定、高度动态的环境。同样是打开一个App，系统有时先弹广告，有时直接进首页；同样是点击一个按钮，有时页面秒开，有时转圈5秒；键盘弹出时机、页面滚动距离、网络请求成败，这些因素都会影响下一步操作。

所以Agent必须有一套完整的环境感知和状态校验系统：感知现在看到的是什么，判断是否和预期一致，执行操作后验证结果是否生效。感知不准，决策就是瞎猜；只感知不校验，Agent就是盲飞。

2.3 考点三：安全护栏与可观测性

前两个考点决定Agent“能不能做成”，第三个考点决定“敢不敢让它做”。

一个真正操作真实手机的Agent，拥有的是实打实的系统控制权。它能打开App、点击转账按钮、发送消息、修改设置。能力越大，出事的半径越大。让一个概率模型在真实手机上自由发挥，如果没有边界和监控，等于把车钥匙交给一个刚拿驾照的新手还不给刹车。

安全护栏解决的是“什么事绝不允许Agent做”和“什么事必须停下来问人”。可观测性解决的是“Agent到底做了什么、有没有异常”。这两个能力不单独存在，它们共同构成Agent的“责任底座”。

3. 考点一：意图驱动才是关键，控件定位只是表现

3.1 从“控件路径”到“语义目标”：改版不会击倒Agent

传统脚本最怕App改版，因为控件路径变了。Agent处理改版的方式完全不同：它不再关心某个按钮的ID是否还存在，而是关心“当前屏幕上哪个区域看起来像是‘开始’按钮，点击后是否出现了预期页面”。

这意味着，Agent天然具备一定的抗改版能力。我在模拟项目里特意做了一次实验：某款购物App前后端更新了界面布局，旧的脚本路径全部失效，但基于屏幕截图语义理解的Agent，通过页面上“立即购买”这几个字的语义识别，依然能正确点击并完成下单。

但注意，这只是表象。真正支撑这个能力的是底层的意图解析。Agent不能靠随机试错，它得能理解用户的需求：需求里有几个目标，先后顺序是什么，哪些步骤可跳过，哪些必须完成。

3.2 任务分解：把模糊意图转化为可验证的子任务

意图驱动落地时，第一件事是把用户输入转化为结构化的任务计划。我在项目里习惯让Agent先生成一个“任务分解对象”，类似这样：

{ "目标": "在手机上下单一杯中杯冰美式", "子任务": [ {"步骤": "打开咖啡类App", "验证": "进入首页"}, {"步骤": "搜索'冰美式'", "验证": "出现结果列表"}, {"步骤": "选择中杯、冰、默认糖浆", "验证": "商品详情页显示中杯/冰"}, {"步骤": "加入购物车并结算", "验证": "跳转至订单确认页"}, {"步骤": "选择自提门店", "验证": "门店信息已显示"}, {"步骤": "提交订单并支付", "验证": "出现订单成功页"} ], "失败预案": { "找不到商品": "更换关键词重新搜索", "支付遇到弹窗": "截图记录后暂停，请求人工确认" } }

每个子任务都带上“验证点”，这一步非常重要。没有验证点的任务分解，Agent很容易做了一半不知道自己做没做对。

3.3 执行层的三个细节：坐标、滚动、等待

动态规划落到真实手机上，执行层有三个细节大多数人一开始会忽略：

• 操作的粒度：Agent不能只点击一个坐标点，最好把一次操作定义为“目标区域+动作类型”。模型先根据截图选出一个屏幕区域，再决定点击、长按还是输入。区域命中比坐标精确匹配更抗屏幕分辨率变化。
• 滚动不是一次性的动作：真实手机屏幕上的内容往往需要多次滚动才能加载完。我踩过的坑是Agent只滚动了一次，以为到顶了，实际列表只加载了一部分。现在我的做法是每次滚动后截屏，对比前后两帧的像素变化率，如果变化很小就认为“滚到底了”。
• 等待不能靠固定sleep：真机的性能波动很大，同一页面有的手机半秒加载完，有的手机需要三秒。固定等待不是稳，而是又慢又容易出错。正确姿势是“轮询检查目标状态”，状态出现再继续，超时才报错。

3.4 意图误判的典型案例

意图驱动听起来很顺，但实际执行中会出现很多语义歧义。我在项目里遇到最典型的一个例子：用户说“把这个表格发给我”。Agent打开备忘录，找到表格，然后调用即时通信App准备发送，但“发给我”到底是从备忘录发到即时App的“文件传输助手”，还是发一封带附件邮件？两个路径都合理。

这种歧义，靠模型自己猜并不安全。我现在坚持一个原则：当意图的自然语言中存在多个可行目标且目标之间代价差异大时，Agent必须停下来向用户确认，而不是自己拍板。动态规划不是“全自动”，而是在关键决策点“人机共商”。

4. 考点二：真实手机的“不稳定性”，逼出了感知与校验体系

4.1 模拟器里岁月静好，真机上一地鸡毛

我最初是在模拟器里跑Agent的，一切都很顺利：界面稳定、控件树干净、网络固定。当时我甚至觉得移动端Agent也没那么难。但第一次迁移到真实手机后，问题扑面而来：

• 设备解锁后桌面布局发生变化，图标位置和模拟器完全不同；
• 某个App启动时弹了“开启通知”的系统对话框，把首页整个盖住；
• 手机在后台自动更新了一批应用，界面字体和控件层级都变了；
• 输入法弹出时，把底部按钮顶出了截图范围之外；
• 电量低时，系统自动进入了省电模式，导致动画和加载逻辑不同。

模拟器环境太“标准”了，真实手机才是一个正常Agent要面对的日常。所以我后来定了一条项目规则：所有Agent功能，从第一天起就在真实手机上验证，模拟器只用来调基础API。

4.2 感知层设计：截图、层级、OCR三件套

要让Agent在真实手机上“看得懂”环境，我目前用的组合是三类感知数据：

• 屏幕截图：提供视觉信息，模型从中理解布局和元素语义。
• 界面层级：通过系统无障碍服务或调试桥获取当前页面的层级结构，作为视觉信息的补充。
• OCR：在截图基础上识别文字内容，用于判断按钮文案、页面标题、弹窗内容。

这三者不是互相替代的关系。截图适合理解“整体长什么样”，层级适合知道“哪些区域可点击”，OCR适合读取“按钮上写的是什么”。我用下来的经验是：层级数据虽然在部分系统场景下会缺失，但一旦能拿到它，决策准确率会显著提升，因为它能提供比像素更稳定的结构信息。

我的做法是，把层级关键节点也映射到截图的坐标区域，然后把“该区域出现了什么文本、属于可点击控件”一并送给模型。这个融合输入比只给一张截图要稳得多。

4.3 校验层设计：点击之后怎么知道“真的点了”？

“执行就好”是Agent时代最大的错觉。真实手机屏幕上，一次点击可能触发多种结果：页面正常跳转、按钮无响应、弹出一个错误提示、点击命中区域被遮挡导致点错东西。

我总结了一套点击后的校验策略，每一步都对应一个问题：

这一套“执行后校验”最大的作用是防止Agent自我欺骗。很多Agent在生成操作时，会倾向于认为自己“点了一下就完成了”，实际上页面还没加载出来。加上校验之后，Agent被迫面对“动作是否真的产生结果”这件事，整个系统的可靠性能上一个台阶。

4.4 状态机：让Agent知道自己“卡住了”

真机执行久了，我最怕遇到的不是某个单步失败，而是Agent陷入“重复循环”而不自知：它反复点击同一个位置，屏幕反复闪动，就是没有进展；或者它在某个确认弹窗上永远点“确定”，弹窗关了又弹出来。

后来我在Agent流程里加了一步“状态检查”：Agent每次生成新动作前，先把当前屏幕截图和历史截图做相似度对比。如果连续三次操作前后截图几乎一致，说明Agent进入了死循环，必须触发异常处理。

这个机制非常简单，但救了很多次场。它相当于给Agent装了一个“我觉得自己卡住了”的传感器。没有它，Agent会在错误路径上越走越远，而不是及时停下来。

5. 考点三：安全护栏与可观测性，比想象中更早成为瓶颈

5.1 权限和任务边界，先于功能上线

我见过不少团队做Agent时，先冲能力，后补安全，结果上线第一天就出了幺蛾子：Agent在无人看管时连续点击了多个“确认支付”，或者在一个误判的页面上反复发起操作请求。

我的建议是，做任何真实设备的Agent，先把“任务边界清单”写出来，再开始写意图规划逻辑。这个清单至少要包含：

• 不允许Agent自动执行的操作类型；包括但不限于转账、删除数据、注销账号、发送不可撤回的消息、修改隐私设置等。
• 允许执行但必须二次确认的操作：下单、发送消息、提交表单、删除单项内容等。
• 允许自动执行的低风险操作：打开应用、查询信息、滚动浏览、复制文本等。

边界清单不是静态的，按照实际使用场景不断调整。但大原则是：风险越高的操作，越要留一道人工确认闸门。

5.2 人工确认点：什么样的事情必须停下来问一句

我实践下来，至少在下面三种情况下，Agent必须暂停并请求用户确认：

• 前半段操作已经涉及到了资金、隐私、删除等敏感动作，哪怕用户指令包含相关关键词；
• 执行过程中出现“多选一”的高分歧路径，例如用户说“发给A”但手机上存在多个同名联系人；
• Agent连续两次重试仍然失败，此时继续尝试的边际收益很低，应转为人工介入。

确认机制最好做成“应用内弹窗”或“消息卡片”，不能只是呼叫一个系统语音提示，用户可能根本没注意到。

5.3 可观测性：每一次点击都可审计

可观测性不只是技术指标，更是一种行为习惯。我在项目里对Agent的每一步操作都做了记录：

• 操作时间、目标区域截图；
• 执行前屏幕和预期状态；
• 执行后校验结果；
• Agent的当前置信度和判断理由；
• 如果触发了失败预案，记录触发原因和处理路径。

这样一方面可以在Agent执行异常时快速定位是“意图理解错了”还是“页面识别错了”，另一方面也为后续优化积累了高质量的训练数据。

真实手机上的Agent记录还有一个额外收益：它天然形成了一条完整的“用户操作轨迹”。拿它和正常人工操作轨迹做对比，能很快找出Agent在操作习惯上的笨拙之处，比如无意义的滑动次数过多、在某个页面停留过久等。这些细节都是优化的切入点。

5.4 熔断与恢复：Agent也会翻车，预案要做在前面

没有任何Agent能在真实手机环境下做到100%正确。所以系统必须具备“熔断”能力：当连续失败次数超过阈值、检测到敏感操作未获确认、或设备状态异常（比如锁屏、失去网络连接）时，Agent立即暂停，保持现状，通知用户接管。

我常用的熔断策略是“三二一”：连续三次操作校验失败，暂停并降级为只读模式；两次尝试相同敏感操作未获响应，终止该任务；一旦检测到设备进入锁屏或应用被卸载等异常状态，立刻终止全部自动操作。

恢复也要设计好。不是用户重新点击“继续”就完事，而是要让Agent回到一个“安全状态”：退回到首页、清理临时数据、确认没有未提交的内容，然后再决定是否重试。

6. 实操复盘：让Agent自己在手机里跑通一个完整任务

6.1 实验环境与任务定义

为了验证前面这些思考，我在一个模拟项目里搭了一套真实测试环境。设备用的是主力安卓测试机，通信方案是“系统调试桥+无障碍服务”，Agent运行在一个本地调度服务中，模型用多模态大模型，同时接入截图识别、层级解析、OCR三个感知模块。

任务定义为：让用户对着手机说“把备忘录里的三条待办整理成文本，打开邮件App，新建一封收件人为自己的草稿邮件，并把待办文本粘贴进去”。

有意思的地方在于，这个任务涉及跨应用操作，而且包含“识别待办内容”“转换格式”“新建草稿”等多个环节，非常适合检验动态规划、感知校验、安全护栏三个考点。

6.2 意图解析与规划阶段

Agent启动后，首先接收自然语言指令，输出任务分解。我实际跑出来的规划，核心节点是：

1. 打开备忘录，找到三条包含“待办”关键词的条目；
2. 逐条提取文本内容，拼接为一段带换行的纯文本；
3. 打开邮件App，点击“新建邮件”；
4. 在收件人栏输入用户自己的邮箱（提前存在配置里，永远不会自动变更）；
5. 在正文区域粘贴待办文本；
6. 校验正文是否包含三条内容；
7. 保存为草稿，不发送。

注意第七步。这个任务里我把“发送”设为敏感操作，所以Agent规划的终点是“保存草稿”而不是“发送”。这一步看起来是任务定义的自然选择，实际上就是安全护栏在规划层的体现：能自动做，但不把权限给满分。

6.3 执行与校验阶段

执行过程中有两次比较关键的“感知-决策”转折。

第一次发生在备忘录列表页。测试机的备忘录首页有一个“最近删除”悬浮入口，恰好和“新建待办”按钮位置接近。Agent最初的方案是点击右上角新建，但屏幕截图显示该区域附近出现了另一个弹窗气泡。感知层通过OCR识别到弹窗上的文字不是预期内容，随即终止了点击，重新规划为“先关闭弹窗再新建待办”。

第二次发生在邮件正文页。键盘弹出后，截图中编辑器的可视区域被压缩，Agent选择的粘贴位置从第一个字符变成了后半段。校验层通过检测编辑器光标位置发现粘贴位置异常，Agent主动撤回，先滚动到正文顶部，再进行粘贴。这个操作虽然只多花了两秒，却避免了一封乱七八糟的草稿。

6.4 真实运行结果与调参记录

我在这一台机器上连续跑了20次相同任务，最终的指标是：完整成功率17/20，3次失败中有1次是备忘录加载极慢导致超时，1次是邮件App启动后弹出了系统级广告页被识别为无关页面，Agent错误点击了广告，另1次是粘贴完成后保存草稿按钮被输入法遮挡，Agent没有正确滚动到底部。

与其说这是模型能力的失败，不如说是感知输入还不够丰富。后来我调整了策略：在点击保存草稿前，强制做一次“键盘收起”动作，并增加一次额外的截屏校验。调整再跑10次，成功率提升到9/10。

这个实验给我的最大感受是，移动端Agent的成败并不全押在“模型聪明不聪明”上，而是很大程度取决于感知是否完整、校验是否严格、护栏是否提前介入。

7. 聊聊新的心智模型：自动化工程师的新活儿

7.1 你不再是写脚本的那个人

在移动端Agent的新体系里，我的角色已经从“把步骤写成代码”变成了“定义边界、设计校验、搭建可观测链路”。每天盯着的对象不再是脚本报错，而是“Agent的决策日志”和“失败时的上下文截图”。

这个转变对老自动化人来说有点残酷，也很有趣。你过去的控件定位经验、页面结构理解仍然有用，但它们不再是主角。真正的主角是：意图如何拆解、状态如何验证、风险如何控制。

7.2 沉淀“任务原子库”和“失败知识库”

两次实操下来，我最大的一个心得是：不要每次都让Agent从零开始理解一个任务。把常用动作沉淀成“任务原子库”，比如“打开某个App并等待首页加载”“在页面中搜索文本”“填写输入框并校验内容”“保存草稿但不发送”，这样Agent只需要做更上层的组合规划，执行稳定性会明显提高。

同时还要建“失败知识库”：每遇到一种失败模式，就记录下当时的屏幕特征、失败原因和有效恢复策略。下次Agent遇到类似状态时，可以更快地从知识库中检索到处理路径。

7.3 最后一个建议：从低风险任务起步

想认真做移动端Agent的同行，我唯一坚持的建议是：从低风险任务起步。先让它帮你整理文本、打开应用、查询信息，把感知、校验、护栏打磨稳了，再逐步尝试下单、填写表单这类中风险操作。

在我自己的实践里，一套在“把待办整理成草稿邮件”这种任务上打磨过的Agent框架，迁移到“自动回复消息”这类任务时，底层的感知和护栏逻辑几乎不用动，只需要换意图模板和任务原子。骨架对了，换业务就是换皮。

我第一次看到AI Agent在真实手机上跨应用完成任务的时候，心里的确激动了一下，但随后冒出来的全是“它刚才那个点击对不对”“如果这是转账怎么办”这类问题。也许这就是做工程久了形成的条件反射：比起惊喜，我们更在意可控。所以这篇文章不讲Agent的魔法,只讲让它规矩干活的框架。真做到这一步，它才会从一个实验室里的“表演型选手”，变成一个敢被托付日常任务的靠谱同事。