5 个子代理 + 1个 Chrome：Codex 把多人协作测试做成了内置能力

5 月 7 日，OpenAI 给 Codex 发了一个 Chrome 扩展。第二天看到这条更新的时候，我下意识把它归类成"又一个 browser agent"——后来翻完官方文档才反应过来，这事被低估了。

它不是一个新 agent，而是把Codex 已有的子代理（subagents）能力接到了真实的、带登录态的 Chrome上。这两件事单独看都不算稀奇，叠在一起就变成了一个被压缩的能力：在同一个浏览器里，让 5 个 AI 同时以不同角色登录、各自跑一份测试用例、最后汇总报告——这件事过去是 QA 团队 3 个人配合两个小时的工作量。

我没装这个扩展跑过（只对 Plus / Pro / Business / Enterprise 等套餐开放，且需要 macOS 桌面端 Codex），所以这篇是解读 + 架构拆解，不是实测。能跑实测的部分我标得很清楚，没跑过的部分也不会装。

为什么这次不一样

过去一年，"AI + 浏览器"这个赛道至少有 3 个范式：

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 group（Chrome 原生的标签组），扩展在那个组里执行操作。你自己的标签页和它互不打扰，浏览历史也是隔离观察、不是接管。

而每个 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 log，member 看不到，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 这次把它做成了一句话指令。

它真的能做到的事

从官方文档明确说能做的能力（不是我猜的）整理一份清单：

注意几个很容易被忽略的限制，这些是文档里写明的：

1. 子代理是"读多写少"才划算。文档原话：“use parallel agents for read-heavy tasks”。你让它并行去改生产数据，互相覆盖的概率比想象中高。
2. 必须显式 spawn。Codex 不会聪明地自己拆任务给多个子代理——你不喊它就单线程。这条对效果影响巨大。
3. 每个域名默认都要确认。除非加 allowlist，否则代理跑到一半会停下来等你点同意。批量并行测试前一定要先把目标站点加进 allowlist。
4. OpenAI 不单独存 Chrome 行为日志，但会作为 thread 上下文的一部分保留——截图、读取的文本、工具调用、摘要都进会话记忆。这条在做内部工具测试时要谨慎。
5. 浏览历史授权是高风险开关。文档里两次明确标了 “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 每个子代理执行下面这份 checklist（30 条资源 × 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 三个东西放一起对比过一阵子（基于公开文档，没全跑过）：

最大的体感差：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 Changelog（OpenAI 官方）：https://developers.openai.com/codex/changelog
• Codex Chrome Extension 文档：https://developers.openai.com/codex/app/chrome-extension
• Codex Subagents 概念：https://developers.openai.com/codex/concepts/subagents