Open Operator、无服务器浏览器与计算机使用型 Agent 的未来

摘要

• Browserbase 的押注是：浏览器会成为核心 AI 基础设施原语，因为 LLM 能将自动化适配到持续变化的网站。 过去需要为100个网站分别维护100套脚本，如今可以用一套脚本实时生成正确动作；与此同时，Airbnb 等现代网站依赖 JavaScript hydration，实际浏览器因此不可或缺。Paul Klein 称 Browserbase 是“你的 AI 的网页浏览器”（“the web browser for your AI”）。

• 真正的护城河，是让有状态、资源密集型的浏览器呈现出无服务器体验，同时不假装底层系统本身是无服务器的。 Chrome 超过 Lambda 的 250 MB 限制，在其受限算力上运行表现也很差；生产负载则需要容器、区域容量、可观测性、字体、扩展和会话持久化。因此，Browserbase 从 Fargate 下沉到 Kubernetes 和 Firecracker，并加入预测性扩容；“毫秒级启动数千个浏览器”是最佳情况，在 10,000 个请求下并非保证。

• Stagehand 是开源分发层，Browserbase 则从其下方昂贵的基础设施中变现。 它的自然语言 API——act、extract 和 observe——让开发者无需自行生成 Playwright 代码，就能把浏览器工具接入自己的 Agent 循环。“Stagehand 不是 web agent，而是构建 web agent 的框架”；用户也可以在本地运行，并使用自己的模型密钥。

• OpenAI 的 Operator 更多是在验证这一品类，而不是威胁 Browserbase，但当前的计算机使用体验仍不够可靠，无法成为日常工具。 swyx 和 Paul 都试过 Operator，之后没有继续使用；Paul 认为，基于坐标的点击不如 Stagehand 基于 DOM 锚定的动作可靠。Open Operator 刻意定位为参考实现，而 swyx 预计，等可靠性提升后，API 驱动的 Operator 大约还需 5年才会真正产生影响。

• 身份认证，而不是 CAPTCHA，可能成为 Agent 商业和委托工作的长期控制平面。 Paul 预计未来会出现类似 OAuth 的流程：用户批准某个 Agent、限制其权限范围，并保留独立身份——例如让它在无需与任何人沟通的情况下预订 Airbnb。今天 CAPTCHA 求解和代理路由仍是必要基础设施，但 Browserbase 更长期的目标，是成为“优质 Bot 的仲裁者”。

• 浏览器自动化才是核心工作负载；批量抓取应先走更便宜的瀑布式流程，再决定是否启用完整浏览器。 Paul 建议先试 curl，再调用专门的抓取 API，只有在需要 JavaScript hydration 或几乎必须保证执行成功时，才“拿出重型武器”。相较于完整虚拟桌面，他的经济学判断是：专用浏览器可以用“10%”的成本提供所需功能的“90%”；但仅支持 Windows 的遗留软件仍是重要例外。

• 更大的命题是“软件使用软件的未来”，这将创造新的基础设施、接口和潜在的巨大市场。 应用将能在 Gmail、会计系统和网页表单之间发起异步工作，并提供实时视图；当 Agent 遇到 2FA 或其他交接环节时，人类可以介入。Paul 认为 Browserbase 终有一天会成为一家十亿美元公司，并建议 5年后再回来看；公司当时成立还不到1年，团队20人，已完成 Series A，并拥有数百家 AI 公司客户。

精读

1. LLM 将浏览器变成 AI 基础设施原语

• Paul 对 Browserbase 的定义刻意强调基础设施属性：它是“你的 AI 的网页浏览器”，通过 API 和 SDK 提供无头浏览器，让应用可以点击按钮、填写表单、抓取动态网页内容，而无需自建容器集群。

• 这是一种几乎字面意义上的创始人与市场匹配。Paul 此前在 Stream Club 担任 CTO，搭建过内部无头浏览器基础设施；Mux 对这项技术重视到直接收购了公司，而 Paul 告诉联合创始人，除非下一家公司做浏览器基础设施，否则自己不会再创业。

• 两个变化让时机成熟。现代网页往往需要 JavaScript hydration，Paul 举的例子是 Airbnb；而 LLM 可以理解渲染后的内容，并动态生成针对不同网站的自动化操作。过去在100个网站上做预订演示，意味着维护100套脚本；现在，一套更高层的脚本就能为每个网站生成所需动作。

• Paul 也修正了自己早期对多模态的判断：他原本预计结构化 HTML 会占主导，因为语言模型理解结构化文本，“没想到视觉会成为这么大的驱动力”。计算机使用型模型的进展远超预期，使浏览器渲染和截图也成为新的需求驱动因素。

2. 无服务器浏览器其实是一个困难的有状态系统

• Paul 梳理了基础设施逐级升级的过程：本地 Puppeteer、Playwright 或 Selenium 脚本可以运行，直到生产环境要求把 Chrome 放进云端。Chrome 超过 Lambda 的 250 MB 限制，更轻量的构建和 layers 只能部分缓解问题，而 Lambda 受限的算力会让资源密集型浏览器运行缓慢。

• 迁移到 EC2 只能解决单个会话，无法解决数千个会话。多用户需求带来容器、Kubernetes 和有状态分布式系统；每个用户工作期间，连接都必须保持存活。随后，字体、emoji 渲染、扩展、广告拦截、视频录制和可观测性，又把一个简单脚本变成了“巨型怪兽”项目。

• swyx 直接质疑无服务器承诺：要实现即时容量，肯定需要昂贵的预热资源池。Paul 表示同意——“如何让一个明显不是无服务器的系统，提供类似无服务器的体验？”——答案包括高密度浏览器打包、预测性扩容、多区域部署和降低延迟的路由。10,000 个请求的突发流量，仍可能遭遇更慢的冷启动。

• Browserbase 起步于 ECS 和 Fargate；Paul 说，公司一度成为所在区域最大的 Fargate 客户。后来它进一步下沉，采用 Kubernetes 和 Firecracker，以获得更多控制力、更快速度和多租户能力：基础设施供应商不能把宕机归咎于上游，因此 Browserbase 正逐步接管所有关键路径上的组件。

3. 可靠性从浏览器容器延伸到代理供应链

• 地理位置的正确性同时取决于浏览器区域设置和网络来源。客户可以选择区域；当网站按 IP 路由或过滤时，代理可以让一个欧洲会话看起来来自美国。Browserbase 还会尽量把会话调度到靠近目标地点的位置，以降低往返延迟。

• Alessio 怀疑代理服务可能比浏览器编排更难；Paul 的回答是：“一层又一层的难题。”Browserbase 不拥有代理，而是聚合多家供应商，审计代理来源，确保容量不会暗中“跑在某个人的电视上”，同时监控故障，并在合作方状态不佳时重新路由流量。

• CAPTCHA 求解器也采用同样的抽象。Browserbase 集成多家供应商，内部保留部分能力，并把敏感功能限制在它能够理解客户的套餐中。产品价值部分来自制度化能力：在 Browserbase 的 SOC 2 义务下，把可疑、缺乏文档的采购转化为经过监控的基础设施，并完成供应商尽调。

4. Agent 身份认证可能让 CAPTCHA 求解走向过渡期

• Paul 的长期目标，是识别出 Browserbase 的流量确属合法，并成为“优质 Bot 的仲裁者”，未来甚至可能与 Cloudflare 等公司合作。今天的 CAPTCHA 把所有 Bot 都视为敌人，但 Agent 让“获授权的自动化”和滥用之间出现了区分的必要。

• 他更强的判断是，未来阻挡 Agent 的更可能是身份认证，而不是 CAPTCHA。一套 Agent 身份认证流程可能先通知用户：某个 Browserbase Agent 想访问 Airbnb；只有用户批准后，流程才会继续——无需分享密码，也无需假装 Agent 就是人类。

• swyx 进一步明确了身份模型：每个用户令牌都可以配一个成对但不同的 Agent 令牌，类似主社交账号与其备用账号。Paul 将其对应到 OAuth 和基于角色的访问控制：Agent 可以获得预订公寓的权限，但不能给人发消息。

5. 人类接管是功能，而不是失败的证明

• 由于用户一开始并不信任 Agent，Browserbase 的实时视图会把云端浏览器以 iframe 的形式串流进应用。双向控制允许用户暂停自动化、直接点击或输入，再把控制权交还给 Agent——“浏览器里的浏览器，yo。”

• 底层使用的是 Chrome DevTools Protocol 的 Page.startScreencast 能力，将 PNG 通过网络发送出去，并中继交互事件。Paul 将其与 Operator 的 VNC 式视图作对比，但两者支持的是同一种模式：“暂停。人类，你能在这个窗口里做点什么吗？好，太棒了。继续。”

• 具体需求来自尚未解决的 CAPTCHA、2FA 验证码及其他交接环节；为每种情况定制 UI 往往得不偿失。“Web agent 仍然需要 human-in-the-loop 类型的工作流”；直接暴露整个浏览器，通常是最简单、最值得信任的界面。

• swyx 提议把一个浏览器状态分叉成100条并行分支。Paul 喜欢其中的 Agent 搜索逻辑，但承认实现方式尚未解决：“序列化状态，再恢复状态。我不知道。”复制页面对象很容易；但要复制一个填写到一半的表单，可能需要冻结并复制整个容器的内存。

6. Stagehand 将自然语言变成浏览器 API

• Paul 在反复把 DOM 内容发送给 LLM、让其生成 Playwright 代码后，打造了 Stagehand。他的结论是：自然语言应该直接进入自动化框架，而不是作为围绕 Puppeteer、Playwright 或 Selenium 的定制胶水代码存在。

• 它的3个原语清晰拆分了浏览器工作。Act 执行点击、填写表单等指令；extract 返回结构化数据，也可以基于 Zod schema；observe 列出相关的可能操作，让外部 Agent 循环根据更高层目标选择下一步。

• 这种架构边界是有意设计的：“Stagehand 不是 web agent，而是构建 web agent 的框架。”Paul 认为，Agent 循环应靠近应用层，因为目标和步骤编排取决于具体应用；Stagehand 提供浏览器工具，但不替开发者决定其中的特殊逻辑。

• Stagehand 采用 MIT 许可证，使用开发者自己的模型和 API key，也可以连接本地浏览器。只有用户选择 Browserbase 托管浏览器时，Browserbase 才能获得收入。目前的优化目标是可靠性，而非原始速度或成本，因此它更适合 Agent 和自动化，而不是工业规模抓取。

7. Stagehand 的适应性不应掩盖有意设计的测试失败

• swyx 最初认为，“点击 Quick Start”这类指令可以成为无需具体实现的集成测试，并能适应 DOM 变化。Paul 反驳说：当页面结构意外改变时，传统测试就应该失败，而不是让 AI 默默重新解释原本想验证的行为。

• 更适合 Stagehand 的测试场景是可用性测试，问题在于：一个类似人的 Agent 是否仍能完成任务。对于严格的前端回归测试，传统测试和明确失败能够保留信息，而自适应自动化可能把这些信息隐藏起来。

• 这次修正揭示了更广泛的产品差异。Stagehand 在自动化外部网站时可以吸收无害变化，但当开发者拥有该界面、需要明确暴露结构变化时，这种适应性并不天然值得追求。

8. Operator 验证需求，同时留下基础设施缺口

• swyx 直言不讳的评价——他试过一次 Operator，觉得“还行”，之后再没用过——与 Paul 的体验一致。不过 Paul 仍认为计算机使用型模型很重要，因为截图加推理可以实现自动化，即便鼠标坐标仍不如基于 DOM 元素锚定的动作可靠。

• 因此，在 Paul 看来，Operator 并不是 Browserbase 杀手；它证明了可能性，也扩大了开发者兴趣。他还怀疑大型实验室是否能放心接管代理和 CAPTCHA 求解：“OpenAI CAPTCHA solving”会成为有害标题，而“Browserbase solves CAPTCHAs”几乎不会引发审视。这些正是“网页自动化中那些令人不适的部分”。

• Open Operator 是参考项目，不是进军终端用户软件。它把目标拆解成步骤，将截图和指令发送给 LLM，通过 Stagehand 执行动作，并嵌入 Browserbase 的实时视图。它并不使用计算机使用型模型。

• swyx 仍看好未来的 Operator API：等可靠性达到要求后——他的时间窗口是 5年——后台浏览器就能预订餐厅、完成工作，无需人类持续观察。Browserbase 目前还没有走产品化路线；Open Operator 的定位是可复用的参考项目。

9. 自动化，而不是商品化抓取，驱动 Browserbase 的使用

• Paul 修正了 swyx 关于抓取占主导的假设：大多数需求来自浏览器自动化，而 Browserbase 对批量采集而言相对昂贵。大致有3类工作负载：自动化、网页数据获取，以及需要浏览器工具的 Agent 应用。

• 他以成本为导向的抓取方案是瀑布式流程：先试 curl，再试 ScrapingBee 这类专业抓取 API，最后才“拿出重型武器”。当页面必须经过 JavaScript hydration，或请求需要每次都可靠成功时，Browserbase 才有合理性。

• Beni 给出了一个完全不使用 AI 的长尾案例。食品券领取者拍下收据，Beni 维护的脚本会提交返利申请并把款项存入账户。对 Paul 而言，机会在于“数百万、数百万份繁琐表单”——从福利申请到 O-1 签证，它们的复杂性正在消耗人类时间。

10. 专用浏览器可以在成本上击败完整虚拟计算机

• swyx 梳理了一套正在成形的技术栈：搜索 API、提取器、浏览器、代码沙箱和完整虚拟机，然后询问这些专业工具会共存还是趋于合并。Paul 认为这不是零和游戏：可触达的工作量包括“数万亿小时”的在线知识工作，因此专用原语和打包式 Agent 平台都有空间。

• 他的专业化论点是经济性的。早期大多数计算机使用型演示都在控制浏览器，因此运行完整 GUI 操作系统往往没有必要；高效编排的浏览器可以用“10%”的成本提供相关功能的“90%”。

• 但这个判断存在重要前提：一些遗留 EHR 和企业应用需要 Windows 或 Internet Explorer，完整操作系统在这些场景下仍是正当工具。Paul 预计 PIG.dev 等专业厂商会服务这类工作负载，而 Browserbase 将专注于浏览器这一足够复杂、可以独立存在的原语。

11. 公司围绕“软件使用软件”组织起来

• Paul 的核心命题是：“软件的未来，就是软件使用软件。”会计产品不再只是计算或转换文本；用户点击一次，应用就可能打开 Gmail、找到收据、上传收据，再通过 API 和浏览器动作的组合为交易添加评论。

• 这一变化需要异步界面，因为 AI 运行更慢；需要用于表达意图的聊天界面；也需要在异常情况下让人类介入。Paul 认为创办公司“是最后不得已的手段”，但相信这些新的软件模式需要当时尚不存在的基础设施。

• Browserbase 成立还不到1年时，已有20名员工、Series A 和数百家 AI 公司客户；在 AI Grant 批次中，公司在 AI 上的开支为“$0”，因为核心业务是基础设施。Paul 表示 Browserbase 终有一天会成为一家十亿美元公司，并建议 5年后再回来看看——“如果那时我在 Coinbase 做 PM，那就说明哪里出了问题。”

• 作为单人创始人，Paul 称这家公司是“仁慈的独裁”：更少的协同层级带来更快速度，而优秀的员工负责日常决策。团队周一至周五线下办公，大约10:00 AM 到 5:00 或 6:00 PM，而不是 9/9/6；“周末是用来做有趣工作的”，员工会探索路线图之外的想法。