5 月 7 日OpenAI 给 Codex 发了一个 Chrome 扩展。第二天看到这条更新的时候我下意识把它归类成又一个 browser agent——后来翻完官方文档才反应过来这事被低估了。它不是一个新 agent而是把Codex 已有的子代理subagents能力接到了真实的、带登录态的 Chrome上。这两件事单独看都不算稀奇叠在一起就变成了一个被压缩的能力在同一个浏览器里让 5 个 AI 同时以不同角色登录、各自跑一份测试用例、最后汇总报告——这件事过去是 QA 团队 3 个人配合两个小时的工作量。我没装这个扩展跑过只对 Plus / Pro / Business / Enterprise 等套餐开放且需要 macOS 桌面端 Codex所以这篇是解读 架构拆解不是实测。能跑实测的部分我标得很清楚没跑过的部分也不会装。为什么这次不一样过去一年AI 浏览器这个赛道至少有 3 个范式范式代表特征AI 浏览器ChatGPT Atlas、Comet、Dia整个浏览器替换成 AI 原生壳远程 Browser AgentOperator、Browserbase、Browser Use在云端开一个 headless 浏览器AI 在里面操作本地浏览器扩展各种 Chrome 扩展少有上规模的寄生在用户自己的 Chrome 里Codex 的 Chrome 扩展走的是第三条但它和过去那批扩展最大的不同有一句话能说清它不接管你的浏览器它在你浏览器旁边再开一组标签页自己用。官方文档里这句很关键“It works in parallel across tabs in the background without taking over your browser, and you stay in control of which websites Codex can use.”翻译成工程语言每个 Codex 线程会单独开一个tab groupChrome 原生的标签组扩展在那个组里执行操作。你自己的标签页和它互不打扰浏览历史也是隔离观察、不是接管。而每个 tab group 背后挂的是一个独立的 agent thread。这就引出了真正有意思的部分。子代理这把刀过去缺的就是浏览器Codex 的 subagents 文档里有一段对理解这次更新的意义很关键“Use parallel agents for read-heavy tasks such as exploration, tests, triage, and summarization.”“Spawn one subagent for security risks, one for test gaps, and one for maintainability. Wait for all three, then summarize the findings by category.”也就是说子代理这个能力本来就在 Codex 里你说一句开三个子代理一个查安全、一个查测试、一个查可维护性它真的会开三个独立的 thread 并行跑主代理只收汇总。文档明确说子代理不会自动 spawn必须你显式喊。这个能力以前的瓶颈在哪子代理只能读代码、跑命令、读文档。它碰不到生产 SaaS 的真实状态。举个具体场景你在做一个多租户 SaaS要验证admin 能看到 audit logmember 看不到viewer 连菜单都不该出现这种权限边界。过去 Codex 子代理能做的极限是读你的 RBAC 配置文件grep 路由表跑你写好的单元测试它读不到登录后的真实页面因为它没有 session cookie。Chrome 扩展上线后链路接起来了[主代理] ├─ subagent #1 (admin 登录态 tab group) │ → 跑 admin role 的 8 条权限验证 ├─ subagent #2 (member 登录态 tab group) │ → 跑 member role 的 6 条权限验证 ├─ subagent #3 (viewer 登录态 tab group) │ → 跑 viewer role 的 4 条权限验证 └─ [主代理收汇总按 role × 资源 出对比表]每个子代理拿到的是一个隔离的 tab group自己的 session 在自己组里互不串扰。这就是用户说的多人协作测试——不是 AI 之间真的在交互是 AI 同时扮演多个用户在同一系统里跑各自的剧本最后由主代理拼图。QA 圈子里这件事过去叫 “multi-persona end-to-end testing”。手动做的话得开 3 个无痕窗口、手抄 3 份 checklist、来回切换、人脑做 diff。CI 里做的话得维护 3 套 Playwright fixture、3 个 storage state 文件、写一堆 dedup 逻辑防止断言互踩。Codex 这次把它做成了一句话指令。它真的能做到的事从官方文档明确说能做的能力不是我猜的整理一份清单能力来源备注多 tab 并行操作官方 changelog“works in parallel across tabs in the background”真实登录态访问LinkedIn / Salesforce / Gmail / 内部工具官方 chrome-extension 文档这是它和 in-app browser 最大的差异每个 thread 独立 tab group官方 chrome-extension 文档“Tab group organization per Codex thread”域名级 allowlist / blocklist官方 chrome-extension 文档默认每个域名都要确认可加白名单文件上传官方 chrome-extension 文档需要单独打开 “Allow access to file URLs” 权限Chrome显式调用官方 chrome-extension 文档prompt 里 mention 才用扩展否则走默认通道截图 / 文本读取 / 工具调用进 thread context官方 chrome-extension 文档浏览器活动会进会话上下文子代理并行任意场景官方 subagents 概念页gpt-5.4-mini适合做轻量子代理注意几个很容易被忽略的限制这些是文档里写明的子代理是读多写少才划算。文档原话“use parallel agents for read-heavy tasks”。你让它并行去改生产数据互相覆盖的概率比想象中高。必须显式 spawn。Codex 不会聪明地自己拆任务给多个子代理——你不喊它就单线程。这条对效果影响巨大。每个域名默认都要确认。除非加 allowlist否则代理跑到一半会停下来等你点同意。批量并行测试前一定要先把目标站点加进 allowlist。OpenAI 不单独存 Chrome 行为日志但会作为 thread 上下文的一部分保留——截图、读取的文本、工具调用、摘要都进会话记忆。这条在做内部工具测试时要谨慎。浏览历史授权是高风险开关。文档里两次明确标了 “elevated risk”因为浏览历史里可能有内网 URL、设备活动、敏感页面 referer。一个能马上动手的用法自己 SaaS 的角色矩阵测试不用等团队改流程单人也能用的最实在场景是测自己产品的 RBAC。假设你在做一个 SaaS有 5 个角色owner / admin / member / viewer / billing。手动测一遍权限矩阵在 30 个资源上的表现1 个人 2 小时打底。用 Codex Chrome 扩展理论上的 prompt 大概长这样Chrome 帮我测 https://app.your-saas.com 的角色权限矩阵。 开 5 个子代理每个用一个角色登录账号见 ~/qa-accounts.txt - subagent A: owner - subagent B: admin - subagent C: member - subagent D: viewer - subagent E: billing 每个子代理执行下面这份 checklist30 条资源 × 4 个动作 1. /dashboard 能否访问 2. /admin/users 能否访问 3. /admin/billing 能否访问 ... (省略) 每条记录返回HTTP 状态码、页面是否渲染主内容、菜单项可见性。 全部跑完主代理出一个 5 × 30 的矩阵表标红实际行为 ≠ 配置预期的格子。这个 prompt 我没真的执行没装扩展但每一步官方文档都明确支持多子代理、tab group 隔离、登录态保留、截图回传、汇总。值得说的是这种用法的本质改变测试不再是写一份 spec 让脚本去跑而是描述一个场景让一群 AI 去蹚。前者要求测试用例预先穷尽后者允许 AI 在跑的过程中发现你没写在 checklist 里的异常比如某个页面加载到一半弹了未预期的 modal。代价是不确定性同样的 prompt 跑两遍结果可能略有差异。这件事和传统 E2E 测试的deterministic哲学是冲突的。所以它不会替代 Playwright它会和 Playwright 互补Playwright 跑回归确定性、CI 必须通过子代理矩阵跑探索性找你没写的用例。几个跟其他 browser agent 的真实差异我把 ChatGPT Atlas、Operator、Codex Chrome Extension 三个东西放一起对比过一阵子基于公开文档没全跑过维度ChatGPT AtlasOperatorCodex Chrome Extension形态独立浏览器远程云端 browser你本地 Chrome 的扩展登录态Atlas 自己的远程 browser需要单独登录复用你 Chrome 已有的 session多实例并行单 session 为主串行任务为主原生多 tab group 并行适用场景替代日常浏览个人事务自动化开发者工程化场景触发方式浏览器内对话ChatGPT 网页/Operator 入口Codex 主代理 prompt 里Chrome隔离粒度一个 Atlas 实例一个云端 session每 thread 一个 tab group最大的体感差Atlas 和 Operator 是给最终用户用的Codex Chrome 扩展是给写代码的人用的。它假设你已经在 IDE 里跟 Codex 在配合做一个具体工程任务浏览器只是这个任务的一部分。这个定位差异决定了它不需要做得像 Atlas 那么通用——它只服务一类场景当 AI 需要看到登录后的真实状态才能完成任务时。这个定位选得很狠。说白了OpenAI 看清了通用 browser agent 短期内做不完美但绑死开发者工作流的垂直 browser agent 能立刻产生价值。几条非显而易见的判断写到这段的时候我把上面的事实材料合起来反复想了几遍有几条结论我没在主流报道里看到第一这次更新真正改变的是context 入口不是操作能力。Codex 之前缺的不是点鼠标的能力是进不去登录后的真实数据。一旦能进去主代理的 reasoning 质量会跳一个台阶——因为它看到的是 production 真实状态不是基于猜测和 grep 的脑补。第二子代理 Chrome 的组合可能会改写测试金字塔。传统 testing pyramid 底下是大量 unit tests、中间是 integration、顶上是少量 E2E。但探索性多角色测试这一层过去几乎为零贵到没人做。子代理矩阵把这一层成本拉低到了 token 级别金字塔可能变成沙漏形——unit tests 不变、E2E 大幅扩张、integration 反而被挤压。第三“per-website confirmation prompts” 这个默认设定看似麻烦其实是它能在企业里跑起来的关键。如果 Codex 默认 always-allow企业 IT 第一时间就会全公司禁掉。每域名确认是为了让 SOC 团队睡得着觉。但这条同时也意味着真要做大规模并行测试allowlist 治理会变成一个新的运维问题——谁能加白怎么审计这块官方目前没说企业版应该会补。第四对国内用户最尴尬的是网络层。Codex 桌面端 这个扩展是要稳定连 OpenAI API 的子代理并行更是把 token 消耗推到几倍量级。这件事的解法不在 OpenAI 这边——得靠中转网关把请求接进来再发出去顺便做 fallback。我自己日常 Codex 调用接的就是 TheRouter 一个统一 Key并行子代理拉起来不会因为某一路抖一下就全挂。第五谁应该今天就开始准备。如果你做的是 SaaS 后台、内部管理系统、SSO 集成产品、CRM 类产品——这个扩展上线就是为你写的。如果你做的是 To C 工具、纯 API 后端、嵌入式 SDK——观望就行这次更新和你关系不大。没说的几件事最后说几句这次更新没有解决的问题免得读者高估它它不是 stagehand / browser-use 的替代。后者是开放生态的浏览器自动化框架你能在任何 LLM 上跑Codex Chrome 扩展只在 Codex 里跑。封闭生态的代价就是迁移成本。它不会让没写过 E2E 的团队突然就有完整测试覆盖。子代理矩阵是探索性补充不是从零起步的方案。底层的 Playwright / Cypress 该写还得写。写场景比想象中难。开 5 个子代理跑权限矩阵这句话听起来简单真要写到 Codex 能稳定执行prompt 里要交代账号、checklist、断言标准、汇总格式。这一层是新的工程能力不是按个按钮就有。跨公司 / 跨账户的复杂工作流仍然是难题。文档里举的例子还是 LinkedIn / Salesforce / Gmail 这类经典 SaaS。涉及多个账户切换 真实 OAuth 三方授权 反爬验证的复杂流程目前还没看到公开 demo。如果你做开发这件事值得花一个下午把扩展装起来把第一个测试场景跑通。我自己的下一步就是把它接到我现在维护的几个 SaaS 项目里看看子代理矩阵在真实 RBAC 测试上的胜率到底有多高。等跑出真实数据我会再写一篇 follow-up把推算和实测的差距讲清楚。参考资料写本文时核对过的官方来源Codex ChangelogOpenAI 官方https://developers.openai.com/codex/changelogCodex Chrome Extension 文档https://developers.openai.com/codex/app/chrome-extensionCodex Subagents 概念https://developers.openai.com/codex/concepts/subagents