这四家在 API 边界上卖的是同一样东西——一个你用 CDP 或 Playwright 驱动的真实 Chrome——所以人人开场就做的那份 SDK 对比，几乎什么也决定不了。你真正在选的，是谁持有那个已登录的会话：cookie、存下来的 profile、会话过期后用来重建它的凭据，以及那个让你的账号继承其信誉的出口 IP。这才是你无法低成本反悔的决定，而功能对照表恰恰把它漏掉了。
一览
四家供应商，对"为智能体跑浏览器，难在哪里"给出了四个不同的答案。
| 供应商 | 许可与托管 | 最用力的方向 | 什么时候买它 |
|---|---|---|---|
| Browserbase | 闭源云服务；其框架 Stagehand 为 MIT。 | 开发者体验——会话回放、稳定的 CDP 表面、Stagehand 原生集成。 | 你想要从原型走到"可调试"的最短路径。 |
| Steel | steel-dev/steel-browser，Apache 2.0；可自托管，也可用其云。 |
开放性——同一个服务端既能跑在你的基础设施上，也能跑在他们那儿。 | 退出成本或数据驻留是硬约束，或者你就想自己跑。 |
| Hyperbrowser | 闭源云服务。 | 把门闯开——默认隐身、验证码求解、代理轮换。 | 目标站点会反击，而且量很大。 |
| Anchor Browser | 闭源云服务，企业档提供 BYOC 与本地部署。 | 已认证场景——密钥注入、会自动重新认证的登录态、按会话隔离。 | 智能体是以一个真实用户身份登录的，而采购部门有问题要问。 |
为什么 API 不是那个决定
这四家都讲 Chrome DevTools Protocol，这意味着"点击与输入"的那部分代码，一个下午就能在它们之间搬家。团队往往是选完之后才发现这一点，于是得出结论：换供应商很容易。并不容易，原因在于：可移植的那部分，本来就不是贵的那部分。
搬不走的是状态。上线一个月后，一个能干活的浏览器智能体已经积累了十几个服务的已登录 profile、一批被目标站点逐渐容忍下来的代理出口 IP，以及——只要它真在干正事——散落在供应商边界之内的某些凭据。迁移意味着把每个 profile 重新认证一遍、把一批新 IP 的信誉重新养起来，还要搬密钥。API 是一个周末的事；身份是一个季度的事。
所以要按状态来评估，而不是按客户端库。三个问题就能带你走完大半：存下来的登录态放在哪里、能不能导出；模型有没有任何机会看见凭据；以及出问题时，目标站点封的到底是谁的 IP。
凭据是那个没人打分的维度
默认做法比团队以为的更糟
最朴素的实现是把密码放进提示词。智能体被要求去登录，凭据就在它的上下文里，于是它也在你的轨迹里、在供应商的日志里，并且任何落在智能体刚读过的那个页面上的注入都能够到它。这是数据外泄问题在浏览器智能体上的版本；它之所以常见，恰恰因为它是第一个能跑通的做法。
市面上的三种答案
Anchor 的卖点正对着这里：密钥由平台注入会话，而不经由模型传递；存下来的登录态在过期时会自行重新认证，不需要自定义逻辑；终端用户可以接入自己的账号，而应用本身完全不碰凭据。Browserbase 与 Steel 都提供托管 profile，这解决了"反复登录"的问题——会话被保留，所以只登一次——但没有解决"第一次登录"的问题，因为总得有个东西把密码交出去。Hyperbrowser 的重心不在这儿；如果你的负载是"已认证"而不是"对抗性"的，它不是为你优化的那一个。
不管选谁都该提的要求
凭据绝不进入模型上下文。Profile 按租户隔离，而不是跨客户共享。会话状态可导出——一个导不出来的 profile 存储，就是你的退出成本。以及，会话按你设定的时限终止：一个持有活跃已认证会话的浏览器是一项常驻能力，而受限凭据主张短生命周期的理由，在这里只会更强，不会更弱。
你感受到的延迟来自控制面，不是浏览器
这个领域唯一的公开基准是 steel-dev/browserbench，而它由 Steel 发布——四家中的一家。这份排名当然要打个折看，但随后请注意两件事：它是开源的，你可以拿自己的负载去跑；而它测出的效应大到"排序不太可能是发布者做出来的假象"。
按那组数字，Steel 的控制面创建一个会话约需 229 毫秒，比 Browserbase 快约 1.6 倍、比 Hyperbrowser 快 12.8 倍、比 Anchor 快 28.6 倍。对 Hyperbrowser 与 Anchor 而言，控制面约占会话总延迟的 80%；对 Browserbase 约为 22%。"创建到释放"的完整生命周期上，Steel 约为平均 0.89 秒、p95 1.09 秒，Browserbase 约为 1.68 秒与 1.87 秒。
这重不重要是个负载问题，而答案会干净地翻转。一个开一个会话、在里面干四分钟活的智能体，永远不会察觉两秒的启动。而一个每个任务都新建一个隔离会话的负载——当任务涉及不同租户时你就必须这么做——每个任务都要付这笔钱；到那时，一个好几秒的控制面就是整次运行里的主要成本。在让任何基准替你做决定之前，先量一量你自己的"会话数与工作时长之比"。
隐身是一次责任转移，不是一项能力
指纹伪装、住宅代理轮换与验证码求解被当作功能卖，从功能上说它们确实是。但它们同时也是这套栈里"厂商在替你做一件你的法务与安全团队会想知道的事"的那部分，而产品页面不是进行那场对话的地方。
- 这场军备竞赛不会收敛。某家检测厂商推了个更新，你的成功率掉下来，然后你只能等你的供应商。买隐身，就是买下一个"其可靠性由一个正在积极与之作对的第三方决定"的依赖——所以要把"对你自己那些目标站点的成功率"当成一项长期指标，而不是上线时的一次检查。
- 共享 IP 池意味着共享信誉。在住宅代理池上，你继承的是所有其他使用者的行为。某个目标封掉这个网段，你就因为不是你干的事被封了，而且你完全看不到原因。
- 求解验证码是一项关于"同意"的表态。部署了验证码的站点表达了一种意愿。绕过它是否可接受，取决于你的使用条款、你的法域，以及你在做什么——这个问题值得在量还没上去的时候回答，而不是之后。
- 已认证的负载多半不需要它。如果智能体登录的是你的用户自己拥有的账号，站点并没有在试图拦你。为这类负载买对抗手段，等于加了一层指纹伪装，而它本身就可能在一次合法登录上触发风控。
什么情况选哪个
| 情形 | 选 | 因为 |
|---|---|---|
| 做原型，或者你首先想要回放与顺手的手感 | Browserbase | 一流的调试表面与 Stagehand 原生集成；其余维度居中——而当你还在摸清问题形状时，居中完全够用。 |
| 数据驻留、离网部署，或你拒绝被锁定 | Steel | Apache 2.0 的服务端你可以自己跑，而他们云上跑的是同一个服务端——于是"退出"是一次部署变更而不是一次重写。在唯一那份公开基准里控制面最快。 |
| 针对会反击的站点做大规模抓取 | Hyperbrowser | 隐身、代理轮换与验证码处理是产品本体而非附加项，而且经济模型是为持续大流量搭的。 |
| 智能体以真实用户身份登录，且采购要介入 | Anchor Browser | 密钥注入让凭据远离模型，存下来的登录态在过期时自行重新认证，按会话的虚拟机隔离，以及带 BYOC 与本地部署选项的合规档位，正好回答采购会问的那些问题。 |
| 短任务，每小时数千个全新会话 | Steel 或 Browserbase | 在这个比例下，创建会话就是主要成本，而两个较慢的控制面会把它变成你挂钟时间的大头。 |
对许多团队来说，一个不太舒服的答案是：他们需要两家。一家用于针对"用户自己拥有的系统"的已认证工作，另一家用于开放网络检索。这确实是两个不同的问题、两套不同的风险画像；硬把它们塞给同一家供应商，正是你最终为一条登录流程买下对抗功能的原因。
常见问题
我以后还能换供应商吗？
自动化代码可以——四家都讲 CDP，驱动层一天就能搬。状态不行：存下来的登录态、养熟的 IP 信誉，以及供应商持有的任何凭据，都得重建一遍。在签约之前问清 profile 能否导出，别等签完再问。
哪一个是开源的？
Steel 以 Apache 2.0 发布其浏览器服务端 steel-dev/steel-browser，完全可自托管。Browserbase 的框架 Stagehand 是 MIT，但云服务本身是闭源的——这是两个不同的说法，却经常被混为一谈。
那份延迟基准可信吗？
它由排在第一的 Steel 发布，所以排名要带着怀疑读。但它同时是开源、可复跑的，而且它报告的差距很大——最快与第三之间的控制面差了 12 倍以上——所以即便边际数字有粉饰，排序多半是真的。如果这个数字对你重要，就拿自己的负载跑一遍。
我需要住宅代理吗？
只有当你的目标在积极封锁数据中心流量时才需要。对于针对"用户自己拥有的账号"的已认证工作，住宅出口通常没必要，偶尔还有害——因为一个意料之外的 IP，本身就是一次合法登录上的风控信号。
怎么让凭据不进入模型上下文？
要么用一家"把密钥注入会话本身"的供应商，要么在智能体循环之外完成登录、交给它一个已经认证好的会话。密码只要在提示词里出现过一次，它就在你的轨迹里，并且能被提示词注入够到——见提示词注入。
这和挑一个浏览器自动化框架是同一个选择吗？
不是，而把两者混为一谈是常见错误。Browser-use、Stagehand、Skyvern 与 Playwright MCP 决定智能体如何感知页面并在其上行动；这四家决定浏览器在哪里跑、由谁持有它的身份。两类你各需要一个。
延伸阅读
本站相关：
- 浏览器智能体——在这四者之上做构建的实战手册。
- 浏览器智能体的失效模式——跑起来之后会出什么问题。
- 计算机操作与图形界面智能体——更大的那个类别，从零讲起。
- 智能体的出站控制——为什么托管浏览器是一条不由你运营的出站路径。
- 智能体的受限凭据——该拿去要求供应商的那套标准。
- Browser-use vs Stagehand vs Skyvern vs Playwright MCP——这一层之上的框架层。