企业官网建设流程全解析

手机上的自动化工具我玩了不少，早先用坐标脚本、图像识别脚本都折腾过，维护成本高得离谱。最近我把重心切到了 Mobile MCP 这条路线上——用 MCP 协议把移动端设备的“眼睛”和“手”交给大模型，让 AI 自己看屏幕、自己点、自己判断下一步。为了验证这套思路到底靠不靠谱，我用真机跑了两个场景：一个是购物类 Demo 商城的登录流程，另一个是社交平台上的龙蛋养成活动任务。前者是典型的表单+身份验证链路，后者是动态界面下的长链路点击操作，都非常适合检验 AI agent 的实际执行力。

这篇文章会把整体方案、环境搭建、实操过程和我踩过的几个大坑完整写出来。想用 AI 驱动手机做自动化验证的同学、正在研究移动端 MCP 落地的开发者，应该能直接照着抄作业。

1. 移动端 MCP 的底层逻辑：AI 是怎么“动手”的

1.1 MCP 解决的是“接口混乱”问题

先聊概念。MCP 全称是 Model Context Protocol，它解决的核心问题，是大模型和外部工具之间的对接方式。没有标准协议之前，你要么给模型写一堆函数调用，要么让它去解析命令行输出，每种工具都要单独适配一套接口，维护起来非常痛苦。MCP 出现之后，工具方只要按统一标准暴露“工具定义”，模型就能按固定的调用方式去使用它们——截图、点击、滑动、输入文本，全都都能一个个按名称暴露出去。

移动端自动化天然适合走 MCP。因为设备操作本质就是一系列离散动作：看一眼当前界面，找目标控件，点击，确认结果。这些动作本身就是很好的“工具”。我把模型当成决策大脑，把 MCP 服务端当成四肢，把安卓调试桥通道当成神经末梢，整个链路就通了：

大模型/Agent 客户端 ↓ 发起工具调用（JSON-RPC） MCP 服务端（本地） ↓ 调用移动设备操作指令 安卓调试桥（设备通道） ↓ 执行动作 真机或模拟器

这套架构最大的好处是，模型和具体设备解耦。换一台设备、换一个分辨率，工具接口不用变，只是底层执行层的适配不同。我这次用的真机是 Android，整个过程几乎没有为屏幕尺寸写过一行适配代码。

1.2 移动端 MCP 工具清单怎么定

设计工具接口是搭建移动端 MCP 最核心的环节。工具太少，AI 很多事做不了；工具太多，模型反而容易选错。我这套方案最终保留了 8 个基础工具：

有一个非常关键的设计原则：能按语义操作就绝不按坐标操作。假如手机屏幕上弹出了软键盘，原来的“登录按钮在坐标 y=1400”瞬间就会失效，但“点击包含‘登录’文本的控件”永远不会受键盘弹出影响。定位工作交给执行层，模型只用想“我该点什么”，而不需要思考“它在哪个像素位置”，这让 agent 的稳定性提高了一个量级。

1.3 为什么选登录和龙蛋任务这两个场景

登录是一个典型的“低熵”流程：界面结构固定、步骤清晰、预期结果明确。很适合验证 MCP 基础链路是否通畅。但纯登录又不够有代表性，因为动态界面、异步加载、异常分支在登录里体现得不够充分。

龙蛋任务则完全不一样。这类活动页面通常包含倒计时、刷新出的奖励状态、可点击和不可点击状态的切换，界面元素会随用户操作动态变化。AI 必须根据当前截图实时判断“现在该点什么”，而不是机械执行固定脚本。两场景叠加起来，才能把 Mobile MCP 的能力压榨出来。

2. 环境准备：把 MCP 通道架到真机上

2.1 设备接入和授权问题

环境这块的坑比想象中多。先说我用的设备组合：一台 Android 真机，通过 USB 数据线直接连接电脑，开发者选项和 USB 调试都开着。如果你是第一次连，手机会弹出“允许 USB 调试吗”的授权对话框，一定要在手机上点允许，并且勾选“始终允许”，否则后续每次重启都会断一次连接。

连上之后，先验证调试通道是否正常识别：

adb devices

输出里出现“device”状态就是正常，如果显示“unauthorized”，说明授权弹窗没确认。我遇到过一次无论如何都显示 unauthorized 的情况，后来把开发者选项里的 USB 调试关闭再重开，电脑端重启调试服务才恢复。

还有一个容易忽略的点：USB 线。有些线只支持充电不支持数据传输，连上去完全没反应，换一根质量好的数据线可以省下一堆排查时间。我有一根线，前五分钟好好的，第五分钟开始频繁掉线，换线之后彻底解决。

2.2 把设备操作封装成 MCP 服务

服务端我推荐用 TypeScript 写。原因是 MCP 官方 SDK 对 Node/TypeScript 生态支持最完善，写起来也快。按照 MCP 的服务端标准，把调试通道的常用操作包成 JSON-RPC 工具注册进去，每个工具声明好名称、描述、入参格式。

比如“按文本点击”这个工具，服务端内部要做的事其实是：调用底层 UI 自动化框架找到屏幕上包含目标文本的元素，计算元素中心点，再转换成全局坐标执行点击。下面是我接口定义里最重要的一段结构：

{ "name": "tap_text", "description": "按文本语义查找并点击屏幕上的控件", "inputSchema": { "type": "object", "properties": { "text": { "type": "string", "description": "要点击的控件文本，如 登录、喂养、领取" }, "retry": { "type": "number", "description": "查找失败后的重试次数，默认2次" } }, "required": ["text"] } }

写完之后，先用 MCP 客户端手动发一次 screenshot 调用，确认图片能正常返回。这一步千万别跳过，很多问题都在这个环节爆发：图片路径不对、编码格式不支持、模型端没法显示图像等等。链路通到这一步，才算真正进入实战。

2.3 给 Agent 的“玩法说明书”

工具都暴露给模型了，但如果不设定行为准则，模型很容易放飞自我。我在系统提示词里写了两条铁律：操作前必须先截图或查看层级，绝对不能凭空猜元素位置；同一个动作连续失败三次必须停下来，把截图和原因返回给用户，禁止死循环重试。

完整提示词模板可以直接抄这一段：

你是移动端自动化助手，通过 MCP 工具控制一部 Android 手机。 操作规则： 1. 每次操作前先截图或调用 ui_hierarchy，不要凭记忆猜测界面。 2. 点击、输入完成后至少等待 300 毫秒再继续下一步。 3. 优先使用 tap_text 做语义化点击，不要使用 tap_point 固定坐标。 4. 遇到权限弹窗、广告弹窗时，先处理弹窗，再回到主流程。 5. 同一操作连续失败 3 次，立即停止，返回当前截图和失败原因。 6. 完成目标后主动输出总结报告。

这些规则看着简单，但实际执行效果完全不一样。没有这些约束时，AI 一旦看不到想要的目标，会反复瞎点；加了约束后，它会主动截图——重新识别——调整策略——再行动，理性很多。

3. 跑通演示商城登录：从表单到主页的完整过程

3.1 Demo 商城的账号矩阵和登录链路

这个购物 Demo 是业内常见的一种测试环境，内置了好几组测试账号，每个账号暴露不同问题：正常账号能顺利进入商品列表；被锁定的账号会看到明确的锁定文案；模拟慢加载的账号则会在登录请求上拉长几秒时间。这几组账号拿来测 AI 自动化非常合适，因为不同账号本身就构成了不同的分支场景。

我跑这个场景，目的不是“点几下进页面”，而是验证 AI 能不能在完全不知道分支的情况下，根据界面反馈做自适应。特别是慢加载账号登录时会有明显延迟，AI 必须会等待而不是急着重试。

3.2 一步步拆解实际操作顺序

整个登录流程我记录成了一段非常清晰的执行轨迹：

1. open_app 打开 Demo 商城 2. screenshot 确认登录页面 3. tap_text("username") 聚焦用户名输入框 4. input_text("正常账号名称") 5. tap_text("password") 聚焦密码输入框 6. input_text("测试环境专用密码") 7. tap_text("LOGIN") 8. wait_text("Products") 轮询等待商品列表出现 9. screenshot 确认已登录状态

两个关键补充。一是密码栏是掩码状态，AI 永远看不到自己输入了什么。所以我会提前把测试密码放进会话上下文里，让模型直接作为已知信息填入，不需要读屏验证。二是登录按钮的文本在不同版本里是 LOGIN 还是 登录 不固定，英文页面用 LOGIN，本地化版本用 登录。为了让 AI 不僵化，我让 tap_text 工具支持子串匹配，只要控件文本包含目标文本就命中。

3.3 登录场景的高频失误点

第一个坑是键盘遮挡。输入完用户名，软键盘弹出来占据了屏幕下半部分，密码输入框可能被完全挡住。如果 AI 缩键盘没缩，直接点密码框就会点到键盘的字母上。这个问题的解法是在工具层加“收起键盘”能力，每次 input_text 完成后自动收起，等界面恢复到原始布局再继续。

第二个坑是“点击后没反应”。商城登录按钮在点击到响应之间有一段空白期，页面没有变化。AI 如果只看一次截图会误判为点击失败，连着点三次，结果按钮被重复触达。我在 wait_text 工具里做了轮询逻辑，默认 10 秒超时，每 500 毫秒检查一次，而不是靠模型一次性判断。

第三个坑是被锁定的账号。如果用锁定账号登录，页面会直接返回错误提示。AI 一开始不知道这个分支，会在登录页和错误提示之间反复横跳。后来我在系统提示词里补充了一条：“如果页面出现‘locked out’等含锁定语义的词，直接终止流程并输出原因。”分支处理能力立刻提升了一个档次。

4. 社交平台龙蛋任务：动态界面和长链路动作

4.1 场景难点拆解

龙蛋任务我选的场景，是社交平台 App 内部的一个限时养成活动：用户要进入活动页，给自己的龙蛋喂养道具，攒够进度后可以领取奖励。这个任务的问题是：活动入口在首页的位置时常变化；任务面板可能存在多个 tab；按钮会随着任务状态变为灰色不可点，需要在其他界面获取道具后再回来继续。

这种任务用固定脚本写，遇到一次界面变化就废了。但对 AI agent 来说，这反而是发挥空间最大的地方——我只需要告诉它“目标是领到奖励”，剩下的路径它自己探索。

4.2 模型怎么处理“当前状态”

我的做法是给模型一个目标描述，其他全靠实时读屏。AI 每步操作先截图，再根据当前界面特征决定下一步。整个执行轨迹大致如下：

1. open_app 打开社交平台 2. screenshot 找到首页活动入口 3. tap_text("龙蛋活动") 进入活动页 4. wait_text("喂养") 5. screenshot 检查喂养按钮是否可点击 6. tap_text("喂养") 点击一次 7. swipe(向上滑动) 如果按钮不在可视区域 8. 重复截图/点击/确认，直到任务进度达标 9. tap_text("领取奖励") 10. screenshot 验证奖励到账

整个过程里，AI 会频繁遇到“按钮是灰色”的状态。截图里有明显差异，语义层级里的 enabled 属性也会反映出来。我建议在 ui_hierarchy 工具返回的字段里带上 enabled 状态，Agent 看到 disable 就不会硬点，而是切换策略去其他页面拿道具。这就是“语义化 MCP”比裸坐标强的地方。

4.3 节奏控制和防误判处理

养龙蛋这类运营活动，最忌讳的是一模一样的点击频率和点击间隔。同一秒级频率连续操作几十次，很容易触发平台的交互异常提示。我加了一层节奏控制参数，让每次动作之间的等待时间在 800 到 1500 毫秒之间随机变化，同时每次点击位置在控件的有效区域里做轻微偏移。

还有一条重要规则：如果页面出现验证码或滑块验证，模型必须直接停下返回，不能尝试绕过。自动化重复操作本身是帮助用户减负，但验证机制是平台的权利，遇到就交回人工处理，这不仅是对规则的尊重，也是实际项目里最稳妥的做法。本质上，跑这个场景的目标是验证技术可行性，而不是真的去薅平台羊毛。

5. 实盘踩坑纪要：五个大坑从触发到修复

这个项目里我记录了不少问题和对应解法，整理成表最直观。

5.1 设备掉线：最基础也最致命

这个坑在实战第二天就撞上了。当时 AI 正在执行登录步骤，突然所有截图工具都开始返回超时，整个任务卡在被调用状态。排查后确认是 USB 调试连接断开。手机息屏之后系统会自动断开调试通道，这是最容易被忽略的触发条件。我在 MCP 服务端加了一个心跳机制：每 30 秒执行一次轻量 shell 命令检查设备在线状态，发现掉线就自动重连，并在后续保持屏幕常亮。

5.2 坐标漂移：所有坐标方案都是纸老虎

最开始我让模型用 tap_point 点击，因为觉得自己写好了坐标映射，稳得很。结果一次软键盘弹出，所有坐标全部偏移，模型点了三四下都没点对位置。从那以后我痛下决心，所有工具改成按控件语义定位，tap_point 只作为兜底方案保留。经过这个教训，我把执行层收到 tap_text 请求后的逻辑做细：优先用 UI 层级控件查找，找不到再退一步用图像识别模板，还是不中就直接返回“控件未找到”，不让模型盲目点击。

5.3 上下文爆炸：截图不是越大越好

项目前几轮测试，模型会在每轮操作后把完整的设备截图塞进上下文，几百轮下来，上下文越来越长，响应速度每况愈下。做了裁剪之后，效果立竿见影。具体做法是 screenshot 工具增加参数 max_dimension，超过 800 像素的图缩放后再进上下文；ui_hierarchy 也做了字段裁剪，只输出可见且可点击的节点，那些 invisible、disabled 的属性默认过滤掉。上下文体积小了 80%，推理速度提升明显。

5.4 死循环：AI 的倔强比想象中严重

模型一旦陷入“点了没反应→再点→还是没反应”的循环，非常消耗时间。造成死循环的根本原因是任务指令里没有给出“什么情况下算失败”。补齐“连续三次失败就停止”的规则后，这个情况再没发生过。这个经验的普适性很强，任何面向 AI agent 的自动化任务，都必须同时定义成功标准和失败标准，不然模型会把同一动作重复到天荒地老。

6. 如果再让我重做一次，我会怎么改

这轮 Mobile MCP 实战跑下来，我认为最有价值的经验都集中在“给模型减负”上。所谓减负，不是替模型做决策，而是把那些模型不擅长的脏活累活全部收敛到工具层。坐标转换、键盘收起、控件查找、滚动等待，这些全都应该在 MCP 服务端内部解决，模型只负责根据界面状态做策略判断。这个比例如果颠倒，agent 的稳定性会断崖式下降。

具体到改动，我会建议：

• 把截图默认改为压缩率 30% 的 JPEG 而非 PNG，单张图体积缩小明显，对流程提速帮助很大。
• 在 MCP 服务里加 session 复用机制，每次任务结束不要销毁设备连接，下一个任务直接续用，省掉重新握手的时间。
• wait_text加上“出现即返回”和“消失即返回”两种模式，很多确认步骤需要判断“按钮消失”而不是“新元素出现”。
• 日志还是要单独记录，每次工具调用、每次模型决策、每次截图都落盘。复盘的时候能看到 AI 在哪一步开始走偏，这对持续调优非常重要。

我自己最深刻的体会有两句话。第一句：Mobile MCP 不是用 AI 模拟人的动作，而是用 AI 替代人做决策；给它一套稳定的工具，比试图写死所有步骤靠谱得多。第二句：登录和龙蛋任务看似简单，却是最有代表性的两个试金石——一个验证基础链路，一个验证动态决策。这两关过了，再去跑更复杂的移动端场景，心里就有底了。