7.6
深览指数
科技虎嗅·AppSo··AI 生成
洗个澡功夫，Codex 替我跟售后把退款要了回来
文章通过具体案例演示了OpenAI Codex的三种电脑操作能力（Computer Use、Chrome插件、应用内浏览器），并对比了它们的适用场景、权限边界和效率差异。核心洞察是：OpenAI的设计哲学并非让AI模仿人类操作，而是按结构化程度高低构建一套分级权限体系，最像人点击的Computer Use反而是兜底方案。适合已了解Agent概念、想具体设计Codex工作流的读者。原文 ↗
核心观点
- ▍OpenAI给Codex设计了三级电脑操作体系(Computer Use、Chrome插件、应用内浏览器)，其本质是按结构化程度分级的权限体系，最像人类操作的图形界面控制(Computer Use)反而是最慢、最脆弱、信任成本最高的兜底方案。
- ▍结构化工具能走通时，不要用视觉控制。优先顺序是：直接API调用 > Chrome插件(带登录态) > 应用内浏览器(无登录态) > Computer Use(全屏视觉操作)。
- 01案例1：用Computer Use自动循环检查客服排队窗口(5分钟/次→客服上线后1分钟/次)，人洗澡回来已完成退款，整个流程无需编码。
- 02案例2：Chrome插件自动打开在线作曲页面，重写整首曲子和声与曲式、调整BPM、存档并保持播放，利用了已登录的浏览器上下文。
- 03案例3：Chrome插件定时扫描Twitter私信和新闻，归档到本地笔记库，且日复一日复用同一登录态，不主动发帖。
- 04案例4：应用内浏览器用于本地Web开发调试，可直接对页面元素加批注('层级反了')，Codex接收截图+元素上下文后修改文件再展示下一版。
- 05Computer Use的典型兜底场景：Slack集成无法上传文件时，Computer Use出手点一下'添加文件'补上缺失步骤。
- 06应用内浏览器的关键隔离特性：不携带用户浏览器Cookie、插件、登录态，因此只能处理无需登录的公共页面或本地开发环境。
反方 / 局限
- — Computer Use虽然能力范围最广，但依赖视觉循环(看屏→判断→操作→等待反应→看下一屏)，速度慢且信任成本极高——等于将整个桌面交出去，官方建议避开资金、密码、隐私、系统安全类操作。
- — 应用内浏览器因完全隔离登录态，无法处理Google登录、passkey或依赖浏览器插件的网站，适用范围有明确天花板。
OpenAICodexComputer UseChrome插件应用内浏览器AppshotsJason LiuiPhone Mirroring
13 分钟 · 4 卡片 · 12 资料
读原文 →