夜雨聆风
Codex 操作浏览器主要有两种模式：一种是 Chrome 插件模式，一种是内置浏览器模式。刚开始用的时候，它们看起来都只是“让 Codex 帮我点网页”，但用了一段时间之后会发现，两者的能力边界、资源消耗和适合场景差异很大。
尤其是在拿 Codex 做网页数据抓取、前端调试、后台批量操作时，选对浏览器模式，体验会完全不一样。
一个被低估的用法：拿 Codex 当爬虫
传统爬虫通常用 requests 或 Playwright 无头模式去请求页面。但现在很多网站的风控越来越严格，指纹检测、行为分析、验证码、登录校验轮番上阵。一旦识别到程序化请求，很容易直接拦截。
Codex 的浏览器操作不太一样。它操作的是真实浏览器或接近真实交互的浏览器环境，有完整的渲染引擎、正常的 JavaScript 执行环境，也能像普通用户一样点击、输入、翻页、等待页面加载。
配合 /goal 模式，你可以直接给 Codex 一个目标，比如：
“把这个网站上所有产品的名称、价格、评分抓下来，整理成 CSV。
Codex 会自己拆解步骤：打开页面、识别列表、翻页、处理加载异常、提取字段、最后整理结果。很多时候，这比自己写一套爬虫脚本省事得多。
当然，抓取数据仍然要遵守网站规则、授权范围和合理频率。Codex 的价值不是“绕过规则”，而是把原本需要大量手工浏览或脚本胶水的工作，变成更自然的浏览器自动化。
Chrome 插件模式：能力强，但吃资源
用 @Chrome 调用的是 Chrome 插件模式。它最大的优势可以概括成一个词：登录态共享。
它直接运行在你自己的 Chrome 浏览器里，继承你已有的 Cookie、登录会话和扩展。那些必须登录才能访问的内容，比如付费订阅文章、企业内部管理后台、CRM 系统、需要登录的社交平台，Chrome 插件模式通常都能直接访问。
对网站来说，这就是你本人正在操作浏览器。
Chrome 插件模式还有几个很实用的特点：
能使用你当前 Chrome 里的登录状态和已安装扩展。 Codex 会把任务放在独立标签页分组里，不会随便打断你正在看的页面。 支持 DevTools 协议，可以看网络请求、Console 错误和性能数据。 更适合处理那些对浏览器指纹比较敏感的网站。
但代价也很明显：它非常吃资源。
Chrome 本身就是内存大户，每个标签页都是独立进程。Codex 插件在上面还要做截图、DOM 解析、状态同步和指令交互，CPU 和内存占用都会上来。如果机器配置一般，比如 8GB 内存的笔记本，跑起来可能明显卡顿。
如果拿它做长时间、批量的数据抓取，还可能遇到截图延迟、页面状态不同步、浏览器响应变慢等问题。
另外，Chrome 插件模式目前只支持 macOS 和 Windows，不支持 Linux；它也不支持无头模式，Chrome 窗口必须保持打开。
适合它的场景很明确：需要登录态的短期任务。
比如：
登录某个平台抓取一批数据。 在企业内部工具里批量更新记录。 从 CRM 或后台系统里整理客户信息。 访问订阅内容或需要账号权限的页面。
内置浏览器模式：轻快，但有边界
用 @Browser 调用的是 Codex 自带的内置浏览器。它更像一个轻量的沙盒浏览器环境。
它最大的优势是轻快。不需要启动完整 Chrome，资源消耗小，响应速度也更利落。对于频繁打开页面、检查页面状态、调试本地开发服务器这类任务，内置浏览器用起来很顺手。
但它有一个根本限制：没有你的登录态。
它不会继承你 Chrome 里的 Cookie、扩展和已保存会话。打开一个需要登录的页面，你得在内置浏览器里重新登录。而且有些反爬或风控严格的网站，对这种非标准浏览器环境更敏感。
我试过在内置浏览器里登录 X，反复失败，大概率就是浏览器指纹或环境特征触发了风控。
不过，内置浏览器真正出彩的地方不是登录站点抓取，而是前端开发调试。
它有一个很好用的标记模式，也就是 Annotation Mode。你可以直接在渲染好的页面上选中某个元素，或者框选一个区域，然后写批注：
这个按钮往上移一点。 这个标题加粗。 这里的间距太大了。 这个卡片在移动端溢出了。
Codex 会把这些视觉批注当作可执行指令来理解。相比用文字描述“第三行第二个按钮的 margin-top 减少 8px”，这种方式直观太多。
配合 Developer Mode，内置浏览器还可以查看 Console 输出、抓网络请求、做性能分析。对于本地前端开发来说，它几乎就是“指哪改哪”的调试入口。
适合它的场景包括：
公开页面的数据抓取。 不需要登录态的网页操作。 本地开发服务器调试。 页面样式、交互和响应式问题修复。 用批注方式告诉 Codex 具体要改哪个 UI 元素。
怎么选？
简单说：
“需要登录态，用 Chrome 插件；不需要登录态，用内置浏览器。
如果你的机器配置有限，又需要抓取大量公开页面，内置浏览器通常是更舒服的选择。它轻、快、对本地开发友好，也不会把系统资源吃得太凶。
如果目标网站必须登录才能看到内容，或者网站对浏览器环境检测很严格，那就更适合 Chrome 插件模式。它继承真实 Chrome 的登录状态和扩展环境，成功率更高，但你要接受更高的资源消耗。
可以粗略按下面这个表来判断：
Codex 自己会怎么判断？
很多时候，Codex 也会根据任务自动选择工具。它大致遵循这样的优先级：
如果有专用集成，比如 Jira、GitHub，就优先用专用插件。 如果任务需要你的浏览器登录态，就用 Chrome 插件。 其余不需要登录态的网页任务，优先用内置浏览器。
这个判断逻辑很合理。专用插件通常比浏览器自动化更稳定；登录态任务需要 Chrome；公开页面和本地调试则交给内置浏览器，成本更低。
总结
Codex 的浏览器能力不只是“帮我点网页”。它更像一层自然语言驱动的浏览器自动化。
Chrome 插件模式适合登录态强、权限复杂、需要真实浏览器环境的任务；内置浏览器模式适合公开页面抓取、本地调试和高频轻量操作。
我个人最喜欢的组合是：用 Chrome 插件处理内部系统和登录页面，用内置浏览器调试前端页面、抓公开数据。前者像一个能接管真实浏览器的自动化助手，后者像一个随叫随到的开发调试面板。
这两个模式各有边界，但也各有很大的挖掘空间。用好了之后，很多原本需要写脚本、录宏、手工点页面的工作，都可以直接交给 Codex 来完成。
