浏览器里的 AI 同事：OpenAI Codex 如何接管你的 Chrome

模块二 · 浏览器自动化 | 2026年5月10日 | 小学子

OpenAI 刚刚发布了一个 Chrome 插件，让 Codex 能够直接操控用户的浏览器，在用户已登录的网站和应用中完成任务。这是 AI Agent 能力的一次重要升级，也让我们离"AI 替你工作"更近了一步。

什么是 Codex Chrome 插件？

简单说，这是一个让 Codex 能够"看到"并"操作"你浏览器页面的工具。之前 Codex 只能处理本地文件、读代码、写代码；装了这个插件之后，它能：

"Codex can now use Chrome on your computer to complete work inside the websites and apps where you're already signed in."

这意味着 AI 不再只是一个"后端工具"——它现在有了前端界面，能像人一样操作浏览器。

技术原理：Agent 的感知与执行闭环

一个能操作浏览器的 AI Agent，核心需要解决三个问题：

1. 感知（Perception）

Agent 需要"看到"页面。当前主流方案有两种：

视觉方案：用多模态模型直接看页面截图，理解页面结构。这是 Claude Code Browser 工具和 Canvas 的做法。优点是不需要网站配合，缺点是上下文窗口消耗大、速度慢。

语义方案：通过 DOM 遍历或 Accessibility API 提取页面结构化信息。Codex 很可能采用这种方案——因为 Chrome 插件可以直接访问浏览器 DOM，不需要额外接口。

Codex 的插件能读取"用户已登录"的网站，说明它有某种页面内容读取机制，可能是通过 Chrome 的 content script 注入实现的。

2. 规划（Planning）

给定一个高层目标（比如"帮我填写这份表格"），Agent 需要：

  1. 理解目标 → 拆解成一系列页面操作步骤
  2. 每一步操作 → 对应一个具体的 DOM action（click、type、scroll 等）
  3. 处理异常 → 页面结构不符合预期时怎么办

这就是我们之前文章里讨论的 Skill System 的用武之地——当 Agent 需要完成特定领域的浏览器任务时，它会调用相应的 Skill（浏览器操作 Skill）来执行。

3. 执行（Execution）

执行层面需要解决两个技术挑战：

Codex 使用"特定任务标签页分组"（task-specific tab groups），让用户可以在 AI 工作的同时继续手动操作其他标签页，这是一个不错的用户体验设计。

对比 Claude Code 的浏览器工具

Claude Code 也有自己的浏览器自动化能力（Browser 工具），两者设计思路有显著差异：

维度Claude Code Browser 工具Codex Chrome 插件
上下文截图 + MMLU 页面理解结构化 DOM 读取
触发方式需要 Claude 主动发起可以后台持续运行
用户交互会话式，需明确指令更自主，能主动操作
权限模型每个操作需确认可批量操作后统一确认
适用场景开发调试、网页测试重复性 Web 任务自动化

Claude Code 的方案更适合开发场景（你明确知道要让它做什么）。Codex 的方案更适合办公场景（AI 自己规划并完成一个多步骤的工作流）。

实际应用场景

这个插件打开了几类真实场景：

安全隐忧

让 AI 操控你的浏览器，这本身就是一个需要极度谨慎的事情。

OpenAI 对此的回应是"每个任务需要单独的确认"，但显然这是一个需要用户高度警惕的能力。

我们在见证什么

Codex Chrome 插件的出现，是 AI 从"工具"到"同事"转变的一个里程碑。它不再只是回答问题，而是开始主动替你执行任务。

这和 Claude Code 的 Browser 工具走的是同一条路——让 AI 拥有执行现实世界任务的能力。但这次更进一步：它深入到了用户日常使用的浏览器环境中，而且是后台自主运行。

对于 Claude Code 源码剖析系列的读者来说，这个插件也验证了我们之前的一个核心观点：一个强大的 Agent 系统，感知和执行能力是同等重要的。Skill System 负责规划，Browser 工具负责执行——两者配合才能完成复杂任务。

接下来的问题是：当 AI 能自主操作你的浏览器时，你的浏览器标签页还是你的吗？

AI Agent Claude Code Codex 浏览器自动化 OpenAI