洗个澡功夫，Codex 替我跟售后把退款要了回来

本文来自微信公众号： APPSO ，作者：AI 有用功，原文标题：《洗个澡功夫，Codex 替我跟售后把退款要了回来 ｜附指南》

网购的快递被人偷了，联系客服，客服系统显示，预计等待时间25分钟。

换作以前，这意味着我们要么盯着聊天窗口发呆，要么开着网页干别的事，同时隔几分钟切回来看看排到没有，不然一不小心退出去又要重新排队。

新加入OpenAI的开发者体验工程师Jason Liu选择了第三种方案。他把这件事交给了Codex。

指令很简单：每5分钟检查一次聊天窗口；如果客服上线，改成每分钟检查一次；尽量帮我完成退款。

然后，他去洗澡了；等他回来时，Codex已经把退款办完了。

整个过程里没写一行代码，一个agent趁我们没时间/不在意，跟另一套客服系统耗着、磨着，直接把钱要了回来。

除了代替人类和客服聊天，Codex还能通过iPhone Mirroring直接操作我们的手机，开发者能用它直接复现一个App里的bug。

每天早上扫一遍私信和新闻，把值得留的东西归档进笔记库；甚至打开一个在线音乐编辑器，重写整首曲子的和声和结构，调好节奏，存档，然后让它继续放着。

这些都是OpenAI在Codex上最近重点推进的一项能力：让AI真正获得操作电脑的能力。

OpenAI的工程师Jason Liu专门写了一篇长文，解释Codex现在拥有的三种「电脑操作能力」：Computer Use、Chrome插件、应用内浏览器。

这三种让Codex操作电脑的能力，名字看起来有点绕，功能大概也有些重叠。

很多人第一次看到，都会冒出同一个问题：为什么一个Agent，要做三套电脑操作的系统？

从功能本身来说，它们都是让Codex拥有接管电脑的能力，但Browser、Chrome和Computer Use背后对应的，其实是OpenAI给Agent设计的一套行动权限体系。

不同的操作模式，有不同的适应场景。像是能用插件就不要点网页，能直接调用API就别让AI用识屏操作界面。

就像是如果微信给Agent提供了接口，AI发送消息只需要执行一次函数。

而如果没有接口，Codex就得先打开微信，找到消息，选择联系人，点击输入框，复制内容，再按发送。

从结果上看，两种方式完成的是同一件事，但从效率和可靠性来看，却完全不在一个量级。所以在OpenAI的设计里，Computer Use更像一个兜底方案。

要搞清楚什么时候用Computer Use，什么时候用Chrome来进行电脑操作，我们结合Jason Liu的帖子把这三种授权模式讲清楚，方便大家更好地让Codex来操作电脑。

最宽的那道门

先说能力最「大」的：Computer Use。

我们之前分享过多篇Codex的使用指南，从目标管理到电脑使用和浏览器操作，里面就曾演示过，使用Computer Use能直接修改我们的备忘录。

Codex能直接自动编辑我们的备忘录

它能看屏幕，能操作几乎任何图形界面，能用键盘、菜单、剪贴板，跟我们授权过的App打交道。没有API的软件它照样能用，它完全依靠「看着屏幕，自己判断该点哪」。

代价是慢。结构化的插件可以直接调一个接口；Computer Use得先看清界面、判断点哪、等App反应、再看下一屏，这个视觉循环相当浪费时间。

那慢有什么用？

最好是用在那些只有图形界面、压根没接口的地方。而且，在Mac上，慢不一定碍事，它能在后台安静地操作我们授权的App，它工作的时候，我们该干嘛干嘛，回头一看它已经默默跑完了某个流程。

开头那个退款，就是这么办成的，让Codex慢慢去找到和客服聊天的方法，然后我一边去洗澡。

但一走开，也可能不放心，毕竟这也是三者里最宽的一道信任边界，我们等于把整台桌面交了出去。

用Codex使用Claude，问Codex好还是Claude Code好，Codex表示不认可Claude的回答

OpenAI官方也反复提醒，一次只给它一个明确的App或流程，不相关的敏感软件该关就关，碰到钱、账户、密码、隐私、系统安全的操作，我们还是得守在旁边。

它最妙的用法，可能是用来作为一种补位。目前大多数的Agent都能连接第三方的软件，像是连接Gmail、Slack等工具。

Codex也能直接从Slack读反馈、改代码、重新渲染视频，但当Slack集成工具没法上传文件时，这个时候Computer Use出手，点了一下「添加文件」，把这一步补上的。

OpenAI工程师在最后给出的建议是，当任务取决于以下情况时，请使用Computer Use：

类似Spotify的原生桌面应用程序或金融应用程序

iOS模拟器、iPhone镜像或其他纯GUI流程

系统或应用程序设置

没有插件或API的数据源

在多个应用程序之间切换的工作流程

在其他方面都很有用的结构化集成中，缺少一个步骤

带着你身份的门

第二道窄一点：Chrome插件。它接管的，是我们已经登录好的浏览器。

早些年的Agent操作浏览器，要它去X搜索某个东西，经常报错说什么没有凭证信息，Chrome解决的就是这件事。

Cookie、配置、登录态、开着的标签页，这些它都能用，所以Gmail、LinkedIn、Salesforce、公司内部后台，这类需要登录才能访问到网页信息的任务，就可以交给Chrome来完成。

让Codex操作浏览器汇总X首页的资讯

关键的差别在这里，由于Chrome浏览器使用，带着我们的身份，网站会直接把它的点击、提交、发消息，当成是我们本人在操作。能力更强，风险也更大。

Jason Liu把一个已经打开的在线作曲页面丢给Codex，告诉它「把音乐弄得更有意思些」。

Chrome就会自动把这个标签页连同页面自带的工具一起交给Codex，它读完整首曲子，重写和声、改掉四分钟的曲式、调了速度、存档，最后让它接着播放。

从修改编曲到最后的完美播放，Codex全程没满屏乱找按钮，因为它能把标签页的上下文，和页面提供的能力拼起来用。

Jason还提到他使用Chrome浏览器使用的另一个案例，是拿它盯一个常年更新的Twitter长帖。指令大概是，「每天用Chrome看看私信、读相关新闻、找找值得了解的反馈和提及，把能沉淀的都存进笔记库，但别发帖、别发消息。」

Codex就能打开Twitter，更有意思的是，这个任务能日复一日回到同一个登录态里，把找到的东西跟我们本地文件接起来，最后交付一份能复核的结果。

所以如果整件事都发生在浏览器里，优先用Chrome。他也提到使用Chrome插件进行任务的理想界面是，

Gmail或LinkedIn

Salesforce或支持控制台

内部仪表盘

跨多个网站的权威研究

取决于您的账户或浏览器扩展程序的表单

干净隔离的门

第三道最窄：应用内浏览器。它就在Codex的对话里，我们和它看的是同一个渲染出来的页面。

最要紧的一点是隔离，应用内浏览器不会使用我们平时的浏览器配置、不带Cookie、没有插件、没有登录态。

所以针对本地开发、调试Web应用、复现视觉bug、看响应式布局，用应用内浏览器大概是最方便的。它能直接改代码、操作页面、看渲染结果、截图，改完自己再跑一遍，直到交付预期的成果。

最有意思的是批注，无论是Vibe Coding，还是完成真实项目，我们在审核一个本地页面时，可以直接点某个元素，或者圈出一块区域，留一句话，「这个层级反了」「这块别做成卡片」「这些控件得再松一点」。

Codex会收到带着截图和元素上下文的评论，改完文件，再把同一个页面打开给你看下一版。

浏览器使用和Chrome使用不同的地方其实就在于登录状态，这也导致浏览器使用更适合在开发阶段，我们可以和自己的同事一样，直接指着某个地方告诉Codex，而不是来回甩截图和文字，页面本身，就成了需求文档。

它的代价也来自隔离，让这个Codex内置的浏览器去处理Google登录、passkey、或者依赖我们浏览器插件的网站，几乎是做不到。

根据Jason在博客中的总结，应用内浏览器会特别适合构建和调试Web应用程序。

本地开发服务器

文件支持的预览

无需登录的公共页面

重现视觉错误

检查响应式布局

留下元素级设计反馈

在这三项之外，OpenAI工程师还提到和计算机使用相关的第四项功能是Appshots。我们之前也介绍过这项功能，在macOS平台上，任何场景同时按下空格键左右两边两个Command键，就会自动把窗口截图、窗口上下文信息，一起发给Codex。

他专门提到这项功能的是想表达，Appshots负责指，Browser、Chrome、Computer Use负责动手。

一开始，我们一想到「AI用电脑」，脑子里浮现的画面，大概都是它像人一样移动鼠标、敲键盘、一下一下点过去。好像AI越像人在操作电脑，就越厉害。

但OpenAI自己的最佳实践，指向的是相反的方向：像人一样点击，是最慢、最脆弱、信任成本最高的那条路。真正想要的，是给agent足够结构化的接口，让它尽量用不着去点。

那个看起来最像「AI终于会用电脑了」的视觉控制，恰恰是整套体系里兜底的一环，结构化工具走不通时，才轮到它上场。

总结下来就是，跨应用走Computer Use，要带身份/登录态走Chrome扩展，干净独立的网页任务走内置浏览器。