Grok Bot+agent-desktop 零额度高效操控本地应用

经过多轮尝试，针对当前OpenAI未开放Codex同款电脑操作接口的情况，目前实现系统级操作能力的最优组合方案是Grok Bot搭配Vercel开源的agent-desktop。

想要达成类似Codex的电脑操作效果，目前主要有两条成熟的技术路线可供选择。

第一条路线是amontlabs推出的LCU（Local Computer Use），其技术路径与Codex完全一致，通过macOS的Accessibility API读取界面信息，进而完成点击、输入、拖放等各类操作。该方案的优势在于能够“理解”界面结构，准确识别按钮、输入框等交互元素；但缺陷也较为突出，若应用的UI未向Accessibility树暴露相关信息，系统就无法正常工作。此外，该方案需要依托模型完成视觉识别、动作规划等核心任务，因此会消耗较多的tokens，且在Grok Bot调用时，LCU作为MCP工具同样会占用Codex的token资源。

第二条路线是agent-desktop采用的CGEvent注入方案，它不依赖Accessibility API，而是直接在操作系统层面模拟鼠标和键盘的真实输入事件，整个过程和人手在触控板上的操作完全一致。该工具本身只是一个CLI程序，不承担任何推理工作，因此单独运行时不会消耗任何额度。不过，agent-desktop自身无法自主决策，需要额外的Agent来指导其执行具体的操作，比如点击位置、拖放路径、等待时长等。如果将操作步骤整理成脚本后回放，整个过程的额度消耗为零。

在处理重复操作时，只有遇到可变项（比如AI剪辑中的素材差异、导出分辨率不同）时才需要模型介入，其余步骤都可以直接执行，这使得整体操作速度大幅提升。以视频剪辑为例，首次操作耗时13分钟，第二次仅用37秒，而LCU的平均耗时则在4到5分钟之间。

为了进一步验证两者的差异，相关人员对比了AI剪辑的每一步操作时间，发现LCU在素材拖拽环节浪费了大量时间——因为剪映是Electron套壳的自绘UI，时间线区域的拖拽目标对Accessibility API几乎不可见，导致LCU发出的拖拽指令无法被剪映接收。而agent-desktop则没有这个问题，通过设置800毫秒的慢速拖动，模拟人手的真实操作，剪映能够正常识别拖拽动作，顺利完成任务。

不过，agent-desktop也存在一定的局限性，由于它模拟的是真实输入事件，需要占用应用窗口，无法像LCU那样在后台运行，因此最佳的运行设备是mac mini。

这类能够通过单个Agent控制多种应用的方案，在当前的AI Agent应用场景中带来了极大的便利，大幅提升了操作效率，为AI在日常任务中的应用提供了更广阔的空间。