资讯 · 改写稿
让 Agent 在后台操作 macOS：贵在哪，以及怎么把成本砍到 15%
一句话结论：让 Agent 后台操作 macOS 应用，钱不是花在「点」上，而是花在「每一步都把整个窗口重读一遍」上。作者把「选元素」这一步交给一个只做选择题的小模型后，实测中位耗时从 49.7 秒降到 28.1 秒、单次成本从 $0.388 降到 $0.060。
场景很实用：作者让 Claude Code 在后台操作 macOS 应用——填一个表单、从弹窗里选一项、跑个计算——整个过程应用不会被切到前台，所以他能在同一台 Mac 上继续干自己的活。他做的是一个架在 cua-driver 之上的 MCP server（beans-picker）。
钱花在哪：每步重读整个窗口
cua-driver 本身没问题：它能在不抢焦点的情况下点击、输入、按键。成本来自 Agent 的用法——要动一下，模型先调 get_window_state，它返回窗口的整棵无障碍树加一张截图。模型把整份读完，找到目标元素，按下标点击；点完，再把整棵树读一遍看结果。
一个五步任务，就是五次以上的全量读取，而每次读取都会留在对话里。来源给出的实测：只用 cua-driver 的一轮中位消耗 64.6 万个 Claude token（含缓存），任务不过是「把名字填进 Name 字段」「用计算器算 80 的 15%」这种量级。
把活拆成三份
作者的做法是把工作切成三段：
- 调用方思考：Claude Code 或 Codex 负责拆任务、决定下一步、出错了怎么办。
- Jev 选元素：由无障碍树生成一份候选动作列表，再问一个只做选择题的小模型（TypeSafe 的 Jev）哪一项对得上这一步。它只从列表里挑，且从不写文本，所以不会凭空造出一个目标。
- cua-driver 执行：点击、输入、按键照旧在后台完成。这个 server 本身从不调用生成式模型。
把「模型通读整棵树」换成「从短候选列表里选一项」，就是省下大头的地方。
实测与它证明不了的
作者给的对比是中位数：耗时 28.1s vs 49.7s（约 1.8 倍），成本 $0.060 vs $0.388（便宜约 85%）。他也明确说明这篇 benchmark 有它证明不了的东西——换句话说，这是他在自己场景下的一组测量，不是通用保证。这一点值得记住：换任务、换应用，比例会变。
本站计算：按调用量折算
**本站计算**——把单次成本差乘上调用量：$0.388 − $0.060 = $0.328/次。若每月跑 500 次后台任务，约从 $194 降到 $30，省约 $164/月；跑 2000 次则约省 $656/月。对高频后台自动化来说，这个差值是决定「能不能长期跑」的关键，而不是那 20 秒。
让模型通读整棵树再点：这是账单的大头，五步任务等于五次以上全量读取。
把 benchmark 当成通用保证：作者自己说明它证明不了什么，换场景比例会变。
让选元素的小模型也写文本：一旦它能造目标，就会指到不存在或不该点的控件。
忽略缓存：来源的 token 数是含缓存的，实际计费要看命中情况。
自检清单
常见问题
为什么后台操作会这么贵？
因为每动一步，模型都要重读整个窗口的无障碍树加截图，且每次读取都留在对话里，五步任务就是五次以上全量读取。
优化后省了多少？
来源实测中位：耗时 28.1s 对比 49.7s，成本 $0.060 对比 $0.388，约便宜 85%。
关键思路是什么？
把「选元素」从「通读整棵树」换成「从候选动作列表里做选择题」，并让执行层不调用生成式模型。
这个结论能直接套用吗？
作者明确说明该 benchmark 有它证明不了的范围，换任务或应用比例会变；建议先跑自己的基线。
来源参考
以上为外部来源；本文为 RefHub 用自己的结构重写，事实以来源页为准，价格与政策会变，请回源核对当日。
下一步：让判断只做选择题的模型，读 Jev 与类型化判断；给 Agent 划权限边界，见 执行容器。