我们如何把 Agent Device 的移动自动化 token 砍掉一半以上
- 原文：How We Optimized Agent Device for Mobile App Automation
- 作者：Michał Pierzchala（Callstack Principal Engineer）
- 原文发布：2026 年 4 月 3 日
上周，我们在一款生产环境应用上跑了一次复杂、多步骤、由 AI 驱动的调试会话：全程约 9 分钟，在 Opus 4.6 上大约消耗 150,000 个 token。考虑到要导航应用、调试网络请求、做性能分析，这个成本似乎还算合理，对吧？
并不尽然。
如今，同一套会话只需要 6 分多钟、69,200 token——token 成本不到原来的一半，耗时也减少了 约 33%。
下面从 LLM 驱动的移动端自动化里 token 效率的问题讲起，再说明我们如何把 token 用量砍半。
为什么要谈 token 效率
AI agent 看到的每一张截图、每一次 UI dump、每一行日志，都会进入上下文窗口变成 token。交互越多、上下文越大，只要这些观察确实在推动任务解决，就无可厚非；麻烦在于 agent 会做不必要的动作，白白吃掉宝贵的上下文窗口。
这会带来两个很直接的影响：
更多 token 意味着更高成本。 截图这类富输入很贵；而基于文本的无障碍快照往往便宜得多，同时仍能给 agent 足够信息。
更多 token 也意味着可用上下文更少。 上下文窗口有上限。若 agent 用臃肿的观察把窗口塞满，重要细节就会被挤出或被摘要掉；上下文越拥挤，模型也越容易漏看关键点。
可以把它想成：token 就是 agent 的工作记忆预算。把预算浪费在沉重、重复的输入上，agent 就会更慢、更贵、更不可靠；用尽量少的上下文，有助于模型保持准确、快速和划算。
Agent Device 是什么
agent-device 是一个命令行工具，用来让 AI agent 直接、可靠地控制 iOS 与 Android 应用——相当于给 LLM 配上一双「眼睛」和一双手，让它更好地理解正在操作的应用。
借助简单、易于推理的 CLI，agent 可以导航应用、跑自动化测试流程、调试原生日志，并从模拟器与真机上抓取可视化证据——整体体验接近人类设备操作员。
我们如何让 AI agent 把 token 用量砍半
先从我们交给模型的任务说起，完整路径如下：
打开 Expensify → 进入 Inbox → 打开聊天 → 用相机提交报销 → 调试慢 API → 分析主要渲染热点 → 发送消息。
在我们看到改进的最新一次测试里，一共 55 次 tool 调用：25k token 花在 tool 调用与 skills 上，44k 花在推理上；仅一次回退到截图交互——说明至少在多数时候，我们给了 agent 足够好的工具与指令。
把移动界面翻译成 LLM 原生就能理解的形式，挑战非常大。从一开始，agent-device 就依赖快照思路（下文 snapshot -i 示例）；理论上它通常应比截图更省 token。但现实比简单例子和理论复杂，我们不得不重新思考若干设计。
用好无障碍（accessibility）树
Agent Device 用无障碍树快照在应用里定位自身——与 VoiceOver 等读屏软件让视障用户能够使用应用的机制相同。为了让无障碍树对 agent 更友好，我们把它转成文本表示，并分配诸如 @e5 这样的 ref，指向树里可被 agent 交互或读取的具体节点。
Snapshot: 180 nodes
@e1 [window]
@e2 [scroll-view] "Inbox" [scrollable]
@e3 [button] "Message 1"
@e5 [button] "Message 2"
@e6 [button] "Message 3"
@e7 [button] "Message 4"
...
相对截图，这条路有两个明显好处：总体上更省 token，并且给 agent 提供了可操作的引用。截图仍是很好的兜底，但平均而言会比交互式快照多烧 3–4 倍 token，还要求模型自己猜元素并在图上找坐标——即便是高端模型，有时也会搞错。
用 UI 快照做了 12 次屏上读取，总共只花了 5k token——在本台设备上，大约只相当于 3 张原始截图的 token 成本。仅此一项，就在「读屏」上带来了 3.5 倍的效率提升。
裁剪快照
移动端 UI 层级往往巨大，常有成百上千个屏外元素、隐藏视图和深层嵌套包装。我们对 UI 快照做了激进裁剪：直接砍掉屏外元素，只把当前可交互的 UI 状态喂给模型，从而显著降低提示里的噪声/信号比。
Snapshot: 10 visible nodes (50 total)
@e1 [window]
@e2 [scroll-view] "Inbox" [scrollable]
[content above scroll-view hidden]
@e3 [button] "Message 1"
@e5 [button] "Message 2"
@e6 [button] "Message 3"
@e7 [button] "Message 4"
[content below scroll-view hidden]
...
在长列表等场景下，这种做法最多可把 token 使用压低约 80%。更重要的是，它还能降低错误率：避免 agent 去点 press / fill 根本够不到的屏外元素，从而少做失败后的重快照或滚动，既省 token 又省时间。
改进 Agent Skills
相对上一版 agent-device，我们把内置 skills 写得更直白：教 agent 如何更高效地探索应用。最大的转向是更 token 友好的工作流——优先用可见优先快照、在变更后优先用 diff 快照、在操作前先弄清应用/包名、用有针对性的日志查询，而不是把大块输出整块塞进上下文。
我们也收紧了对常见失败模式的指引：skills 现在会点明 stale ref、React Native 警告/错误浮层（我们测试里的一大 token 杀手）、屏外元素，以及何时从常规探索切换到调试。结果是更少瞎猜、更少浪费步数、行为更稳定。
修复 Android 特有问题
Android 侧做了一批可靠性修复，针对最容易让 agent 困惑的来源：快照更偏可见优先；屏外条目改为摘要，而不是暴露成误导性的「可点 ref」；当导航或提交后无障碍树滞后于真实界面时，工具也更能恢复——这类情况常常是 agent 退回截图的常见原因。
我们还加强了 Android 诊断：自上一版起增加了 Android CPU / 内存采样、改进了从 logcat 恢复网络 dump，并修复了 open / 重开流程里的应用与包名处理。综合起来，Android 会话不那么脆、也更容易排查。
接下来做什么
token 降幅超过 50% 已经是很大一步，但仍有空间。我们已确认结构化快照明显优于截图，但还能继续推：
- Skill 优化：估计还能再通过收紧 tool schema 省下约 3k–4k token。
- Diff 快照：计划实现
diff snapshot逻辑（步骤之间只发 UI 变化，而不是整棵树）。不会是银弹，但会带来边际收益。 - 日志分析效率：优化如何把网络与性能日志交给模型，有望再降 2k–4k token。
通过持续打磨 LLM 与设备之间的接口，我们让自主移动端测试与调试更快、更便宜、也更可靠。
动手试试
在 GitHub 上看 Agent Device 的实际效果，欢迎顺手点个 star。你也可以用我们的模板把流程接到 CI/CD；若在搭建上需要帮助，欢迎联系 Callstack。
