2026-10-19 让 Agent 走进手机：mobile-mcp / mobilecli 改进与小红书实践
- 数据时间：2026 年 10 月 18—19 日，Asia/Shanghai
- 研究对象：Android 真机研究、小红书、旅行服务工具与 Web 自动化
- mod 版本：mobilecli
1.0.22-er、mobile-mcp1.0.12-er
在我围绕摩旅路线、小红书笔记和住宿条件开展的研究中，手机原生 App 配合服务 MCP 的整体体验，明显优于把整个任务放在 Web 端完成。 小红书负责提供具体的人、地点和现场经历，高德负责把地名变成可以核算的路线，美团、飞猪等服务提供餐宿与交通候选，手机再承接需要实际页面确认的细节。Agent 可以沿着一个问题往下查，而不必在每个来源之间重新开始。
这条路线最初也很笨重：读屏内容长，点击前重复取树，几个已知步骤被拆成多轮调用，旧 Android 设备还会卡在代理启动和前台识别。我们基于上游 mobile-mcp 和 mobilecli 维护了自己的 mod 版本，逐步解决这些摩擦；版本后缀 -er 取自我们的名字 Etherealm Research（ER），用于标识这些修改。实测中，Honor 8 的拼多多搜索至详情流程耗时中位数从 13.48 秒降至 6.37 秒，返回文本从 16,935 降至 6,565 token。这些收益让“持续操作手机做研究”更接近日常可用的工具。
本文把作者体验、实现机制和测量结果放在各自的位置：体验判断针对我的跨 App 研究任务；量化数据来自 Android 原版兼容基线与 -er mod 的对照；Web 部分核验了指定项目的源码，尚无同账号、同任务的手机与浏览器配对实验。小红书实读记录用于解释研究流程，性能表则使用已经完成的设置和拼多多测试。
一、先把两种 MCP 分清楚
旅行场景里，同样叫 MCP，背后的工作可能完全不同。
服务 MCP 直接向业务服务提出问题：查询一个地点、计算路线、搜索酒店或航班。设备 MCP 操作手机的实际页面：读取控件、输入查询、选择筛选条件、打开详情。还有一类工具把浏览器操作包装成 MCP，对外看起来也是一次“读取笔记”，内部仍要完成网页导航、页面等待和内容提取。
这个区分决定了我怎么分配工作。已经有结构化服务的部分，先通过服务查询；需要理解原生 App 当前页面的部分，再交给手机。小红书笔记发现的一个停车点，可以成为高德的新途经点；酒店详情里发现的接驳要求，也可能反过来改变路线。
flowchart TD Q[研究问题：路线、风景、交通与住宿] --> S[服务工具初筛] S --> A[高德：地点与路线核算] S --> B[飞猪、美团：交通和住宿候选] Q --> X[小红书 App：搜索与逐篇实读] A --> P[手机 App：核对具体页面与条件] B --> P X --> E[证据台账：时间、地点、原文与阅读范围] P --> E E --> R[研究结论与方案取舍] E --> C[发现缺口：补查官方道路或天气来源] C --> R
高德的官方 MCP 文档同时提供地点、路径规划及专属地图唤端能力，说明“结构化查询后回到 App”已经有明确的产品接口。我把这种衔接延伸到完整研究流程，并核对当前客户端实际暴露的工具。高德 MCP 文档
二、我对 mobile-mcp 和 mobilecli 做了哪些改进
让旧手机先能可靠工作
Honor 8 运行 Android 8.0.0 / API 26。这里遇到的两个问题分别位于设备侧和主机侧。
设备侧的 hidden-API exemption 调用需要按系统版本处理，我让 API 28 以下跳过这一步。主机侧查询前台应用时，该设备的 dumpsys window displays 缺少所需焦点字段，但 dumpsys window windows 能提供。修复保留首选路径，只在缺失字段的条件下回退；显式空焦点、命令执行失败仍按各自情况处理。
两项修复独立保存，便于上游修复后分别移除。组合版本已在 Honor 8 上完成设备代理启动、前台应用识别、UI 树及真实 MCP 调用验证。这也使一台旧手机能够继续承担研究终端的工作。
让模型读到可操作的语义
UI 树通常混有大量布局容器和重复字段。把它原样交给模型，会让有限的上下文被“页面如何排版”占据。
修改版 mobile-mcp 的 compact 输出折叠符合条件的空布局容器，同时保留子节点、层级、原有 ref、独立点击目标和状态。CLI 的 Go 层补齐 editable、scrollable、longClickable、checkable 等能力字段；没有文字但可以操作的节点也得到保留。空输入框、真实输入值和标签分别表达，使 Agent 能判断“看到了占位提示”还是“已经输入了查询词”。
这里的压缩是有规则的展示变换。需要坐标和完整字段时仍可切换 text 或 json；遇到路线图、正文图片和视频画面，则读取对应视觉证据。模型因此可以先用较短的控件树决定下一步，再把注意力留给真正有信息的内容。
让一次点击对应刚才看到的目标
原有 ref 路径可能在点击前重新取树，再解析编号。页面在这段时间发生变化时，同一个编号可能指向不同目标，同时还多付出一次取树成本。
我在 mobile-mcp 中为每台设备保存最近一次观察到的 ref 与边界，点击直接使用这次快照的位置。任何可能改变 UI 的动作尝试都会使旧 ref 失效，失败也一样；显式读屏始终获取新状态，读屏失败则清除旧引用。
这让 ref 的含义更清楚：它指向“刚才观察到的那个控件”。异步弹窗、内容刷新和人工触碰仍可能让坐标过时，因此跨页面、滚动或状态不确定后，需要重新观察。这个取舍减少重复工作，也要求上层遵守快照的使用范围。
让短流程一次完成，让分支留在观察之后
我沿用已有 batch 能力，改进末尾观察的复用与失败回执。搜索输入框和 ENTER 的行为已经确认时，可以一次完成：
text
当前快照中的输入框 → 点击 → 输入查询词 → ENTER → 读取一次最终页面输入框之后的键入和按键不需要继续引用旧控件；到了结果页，Agent 再根据新内容决定打开哪篇笔记。最后一步已经成功读取同一设备时，修改版 mobile-mcp 复用该观察，避免再附加一次相同读屏。
batch 中途失败时，已执行步骤的回执保留下来。恢复从实际页面和剩余步骤开始。它适合合并确定的短动作，翻页后选哪条结果、正文是否需要展开、评论是否值得继续读，仍然需要观察和判断。
再减少探测与进程启动的开销
mobilecli 1.0.22-er 去掉 Flutter 探测前不必要的应用名称、版本查询，并在同一调用链内复用成功的 debuggable 检查。mobile-mcp 1.0.12-er 继续把普通操作改为直接访问现有主机 daemon：
text
原路径：MCP → 每步启动 CLI → 主机 Go daemon → ADB 隧道 → 设备服务
新路径：MCP → Unix socket → 主机 Go daemon → ADB 隧道 → 设备服务截图、安装、录屏等特殊入口仍保留 CLI。设备端继续使用 app_process、Java DEX 和 UiAutomation；本轮没有增加 APK 或常驻无障碍服务，500 ms 静默窗口与 2 s 等待上限也保持不变。
直连版本把请求发出后的断连、超时归为结果未知，交给上层重新确认页面；它不会自动重放业务动作。设备队列约束同一 MCP 进程内的调用，研究会话仍维持单设备单控制者。这样，减少传输开销的同时，失败后的行为也保持可解释。
三、哪些收益已经测到了
基线为 MCP 1.0.11 与 CLI 1.0.21-android8.2。设置流程的候选为 MCP 1.0.11-er、CLI 1.0.21-er；拼多多候选的 CLI 更新到 1.0.22-er，MCP 仍为 1.0.11-er。
| 真机场景 | 耗时中位数：基线 → mod | 耗时降低 | 返回文本 token：基线 → mod | 文本减少 | MCP 调用次数 |
|---|---|---|---|---|---|
| Honor 8 / Android 8，设置搜索至关于手机 | 6.48 → 4.43 秒 | 31.55% | 7,105 → 2,656 | 62.62% | 6 → 3 |
| JP1 / Android 13，设置搜索至 Android 版本 | 5.80 → 4.92 秒 | 15.25% | 4,764 → 1,746 | 63.35% | 6 → 3 |
| Honor 8，拼多多搜索至商品详情 | 13.48 → 6.37 秒 | 52.75% | 16,935 → 6,565 | 61.23% | 8 → 4 |
每组最终测试都在预热后交替执行五对 A/B，双方各五次达到后置条件；设置核对具体版本值，拼多多核对详情标题及独立内容字段。耗时统计包含实际工具链调用，排除准备、进程连接和模型推理。token 使用 tiktoken/o200k_base 统计返回的 text block，未计入工具 schema、系统提示或账户计费。
同一棵保存下来的树，用两种格式重放时，Honor 8 从 2,217 降至 770 token，JP1 从 1,625 降至 601 token。这说明输出压缩本身就能减少约六成文本。端到端时间还受到取树、页面响应及调用组织影响，因此两台设备的耗时改善幅度不同。
按源码调用链推导，设置流程的 dump 请求从 5 降至 3，拼多多从 7 降至 4。这里统计的是请求次数。Android 实际遍历次数没有单独计量；新 daemon 直连路径也需要 RPC 级计数，旧 CLI trace 已无法覆盖所有请求。
实验还留下了值得保留的失败。拼多多早期候选只有 3/5 成功，原因包括页面过渡空树和首页搜索占位符变化；双方补齐有限的就绪观察后，才得到表中的最终结果。高德第三方流程则停在正式五对测试之前：搜索历史中的同名项被过早接受，重新解析 ref 也可能造成目标漂移，内部证据不足以分配两者的责任。测试脚本虽已补充正式结果条件，真机复测仍待完成。
最新 1.0.12-er 的新增证据是 215 项离线单元／集成测试及 Go daemon 协议互通验证，另有启用和连接记录。 它的第三方 App 性能尚待测量。上述 52.75% 属于此前整套 mod 优化的对照结果；各项优化的独立贡献还需要消融实验。
四、小红书的优化，落在“读完并用对”这条链上
我对小红书的针对性改进由两部分组成：通用驱动减少操作成本，xhs-field-research 与 mobile-research-session 把搜索、阅读、复核和恢复规则接上。当前实现没有新增小红书专有抓取接口。
搜索先服务于问题，再使用“最新”
摩旅研究里的“格聂怎么样”太宽。我会把地点、交通方式和具体疑问组合起来，例如“格聂 摩旅 雨雪”“新龙 G227 施工”，再按缺口补查自驾、自行车或负面经历。
原生 App 搜索后，先核对实际查询词和正式结果页，再选择并确认“最新”排序。搜索输入框、联想词和历史记录都有可能包含同样的地名，真正的目标要在结果页中重新定位。短 batch 缩短输入过程，fresh ref 则把后续动作绑定到新的观察。
最新排序解决发现顺序，旅行时间仍要进入正文确认。2026 年 10 月 18 日，我读到一篇显示“5 天前”的格聂摩旅笔记，作者描述六人摩托队的行程，正文提到 10 月 3—5 日垭口雨雪。这条内容适合解释国庆时的路面和拥堵经历；若要决定十月下旬是否出发，还要补查新的雪冰与道路信息。
控件树承担导航，图像承担视觉证据
小红书的研究过程可以拆成四个连续环节：
| 环节 | 默认操作 | 需要确认的内容 |
|---|---|---|
| 搜索与筛选 | compact 读树、短 batch 输入 | 查询词、正式结果、排序选中状态 |
| 打开笔记 | 新快照定位卡片，进入详情 | 作者、标题、正文主体及页面归属 |
| 阅读与展开 | 正文读树，必要时切换 text/json | 是否截断、展开后的内容、评论归属 |
| 图片与视频核验 | 读取相关图片或视频片段 | 路面、路牌、车型、画面地点和观看范围 |
文字和控件足够时，Agent 无须每一步都看截图；路线图、坑洼路面和图片内文字有信息时，仍要读图。图像与控件树各自承担适合的任务，减少的主要是定位和重复确认的开销。
这个习惯也有助于处理失败。进入详情时只见空容器，可以等待并有限补读；一次 batch 报错，就保留已完成步骤，重新判断页面。反复提交查询、盲目再次点卡片，往往会把状态变得更难解释。
阅读台账让研究进度有实际含义
10 月 18 日的 JP1 研究记录打开了 11 篇唯一笔记、覆盖 11 位作者，其中 10 篇读完相关正文，1 篇为部分视频阅读；历史索引中的 30 篇单独保留。10 篇正文记录中包括风景和招募等低信息内容，“已读”与“能回答当前问题”分别判断。这里的正文读完也只覆盖相关文字，图片和评论按实际阅读范围登记。
这套台账保留几种容易在自动化汇总中丢失的区别：
- 发布与行程。 保存“5 天前”等原显示文本和查看时间，再从正文提取实际出行日期。
- 正文与评论。 作者的实走陈述、评论者的补充和提问分别归属。
- 主线与支线。 G348 的一篇自驾记录提到鹰嘴岩支线窄弯、会车困难和修路，这些信息只作用于相应支线。
- 完整与部分。 一段 13 分 33 秒的视频只观看约 24 秒，就登记这段画面和缺失范围；平台“参考 17 篇笔记”的 AI 汇总另作线索。
小红书的体验优势在这里变得具体：我能沿着 App 的实际信息路径，连续完成查找、展开、阅读和追问，再把结果交给其他来源核验。工具改进缩短机械步骤，研究规则决定这些内容最后能支持什么结论。
五、高德、飞猪、美团怎样与手机接力
服务工具先减少候选数量，手机承接已经选定对象的细节确认。这比让 Agent 在每个 App 首页都重新做一次宽泛搜索更容易保持上下文一致。
| 来源 | 适合先交给服务工具的任务 | 手机承接的确认 | 交接时应保留 |
|---|---|---|---|
| 高德 | 地点搜索、地理编码、分段路线与完整往返核算 | 起终点、途经点、模式、策略及选中路线 | 有序节点、坐标、路线版本、各段公里与时间 |
| 飞猪 / FlyAI | 航班、酒店、景点及套餐候选搜索 | 选中商品的日期、规格、适用条件和详情 | 商品标识或链接、日期、人数、查询时间 |
| 美团酒旅 | 酒店、民宿及交通候选初筛 | 同城同店、房型、日期、价格口径、停车与取消条件 | 准确名称、地址、房型和待确认问题 |
| 小红书 | 围绕路线缺口形成检索问题 | 相关正文、图片、视频及必要评论的实读 | 作者、日期、地点、交通方式、阅读范围 |
高德文档中的驾车规划面向小客车，骑行另有接口。摩旅研究要记录实际使用的交通模式；高速准入、入口执行和道路管制再交给对应公告与经历核验。完整往返还要使用同一起点锚，把停车场和住宿等绕行计入。小红书出现一个好看的点位，就把它加入候选、重新核算，而不是沿用加入之前的总里程。高德能力说明
飞猪官方 AI 平台提供机、酒、景与套餐搜索，介绍了官方商品库和动态库存接入；本地安装的 FlyAI 技能通过 CLI 调用 Fliggy MCP 服务。这个入口适合从自然语言需求得到可继续核对的候选。本文对飞猪的依据是官方能力说明与本地接入文档，尚未取得它与手机同一商品的闭环实测。飞猪 AI 开放平台
美团当前本地旅行入口是 meituan-travel 配合 ht-ai CLI。它属于官方酒旅服务的 Skill／CLI 接入，写运行记录时应保留这一实际路径。初筛之后，手机重点核验列表卡片难以解释的条件：某价格是整间还是人均，优惠是否限特定资格，停车是商户标签还是实际有位置的车位，评价是否来自当前房源。美团开发者平台
这些问题在已有美团研究中确实出现过。台账记录 17 个候选，按严格条件有 15 条完整记录，但跨房型疑似重复尚未消解，保守口径为 14 条，最终复核也仍未完成。这个过程提醒我，把接口结果交给 App 后，仍需核对对象身份和条件；打开了详情页只是核验的起点。
六、与浏览器自动化项目相比，优势具体在哪里
这次主要核验了 autoclaw-cc/xiaohongshu-skills，固定提交为 b043748。该项目复用已登录的 Chrome，通过 XHS Bridge 扩展操作页面，提供搜索、正文、评论、主页，以及发布和互动能力，CLI 返回 JSON。它已经具备完整的业务封装，适合把小红书 Web 功能接入 Agent。项目 README
顺着实际调用看，CLI 连接的是 BridgePage；搜索读取 window.__INITIAL_STATE__.search.feeds，筛选依赖页面控件；详情读取 noteDetailMap，另有评论加载与页面不可访问处理。它的收益是结构化数据直接可用，维护对象则包括网页状态结构、CSS 选择器与扩展通信。CLI 入口、搜索实现、详情实现
另一种路线是 xpzouying/xiaohongshu-mcp。本次核验的 7797fd3 版本使用内置浏览器和保存的登录状态，对外提供 MCP，支持无头和有界面模式。两种项目的实现不同，共同点都是通过浏览器获得小红书 Web 的能力。浏览器实现、接入说明
| 比较维度 | 浏览器项目 | 使用 mod 的真机研究路线 |
|---|---|---|
| 读取接口 | Web 页面状态、DOM、已加载的正文与评论 | 原生 App 可访问性树，按需补图像和视频 |
| 登录环境 | 可复用真实 Chrome，或维护工具浏览器的登录状态 | 使用设备上实际登录的 App 会话 |
| 数据整理 | 专用字段和 JSON 有利于批量导出 | 需要把可见内容整理为台账，阅读范围可逐步记录 |
| 变化后的维护 | 跟进 Web 结构、选择器和加载逻辑 | 跟进 App 控件语义、布局、弹窗和设备状态 |
| 跨来源研究 | 地图、酒店等仍需另接工具或页面流程 | 同一手机驱动可进入多个 App，并承接服务初案 |
| 操作资源 | 无需占用实体手机；仍需有效浏览器会话 | 受手机在线、解锁、网络及单控制者约束 |
在我的任务里，手机路线更顺手，主要有三个原因。
第一，研究动作与日常使用的产品路径一致。小红书的筛选、详情、图文和视频都在同一 App 会话里，Agent 能沿当前观察继续判断。复用登录态这点浏览器项目也能做到；我更看重它与原生内容路径及其他手机 App 的连续性。
第二，一个设备驱动可以覆盖多个来源。小红书的一条现场经历可以接到高德路线，美团的房源条件可以接到同一次行程核验。上层需要保留候选和证据合同，底层则复用读树、输入、点击与恢复机制。由此得到的维护便利，是从实现结构与我的使用过程作出的判断。
第三，省下的调用与上下文可以用来多读、多核对。mod 中的压缩、快照引用和 batch 改进把成本从重复 UI 描述中移走。对于需要反复追问“这是哪段路、哪天走的、作者骑什么车”的任务，减少机械等待比单独导出一批字段更贴近我的需求。
浏览器路线仍有清晰的用处：目标是批量整理 Web 已暴露的正文和字段、现有导出流程成熟、手边也没有持续在线的手机时，专用 Web 适配器可能更省事。原生 App 同样会遇到登录、验证、加载失败和无语义控件；当前材料没有测量两条路线的验证触发率或长期无人值守稳定性。工具选择应围绕研究任务与实际数据可达性展开。
七、下一步最值得验证什么
当前证据已经足以说明，这套 mod 在已测 Android 流程中显著减少了返回文本与调用次数，也降低了工具链耗时。小红书实践则展示了另一种收益：搜索结果能够被持续追踪到正文、具体旅行时间和可用于路线判断的事实。
下一轮验证最有价值的是一套固定的小红书研究任务：同一批关键词、相近时间窗口和一致阅读要求，在手机与浏览器分别完成搜索、排序、展开正文、读取指定评论或图像，再形成去重台账。比较应同时记录完成时间、人工接管、漏读与错误归因、可追溯笔记数，以及每篇有效证据的 token 成本。没有读到目标内容的运行，也要保留在结果里。
工程上还需要补齐 daemon 直连版本的 RPC 计数与真机对照，并复测高德正式结果页的选择。届时我才能进一步判断：哪些收益来自压缩，哪些来自少取树、少启动进程，哪些来自更好的研究流程。
我的使用方向已经明确：服务工具负责高效查询，手机负责具体情境，小红书负责提供需要仔细阅读的现场经历。 对 mobile-mcp 和 mobilecli 的这些改进让协作更轻，逐条留存的证据让研究结果更可信。