生产级Web智能体需要Chromium之外的五层基础设施：温浏览器池、VM级隔离、一致的身份和住宅路由、统一的重放和追踪，以及多模型网关。当基础设施对产品具有战略性、强制性或本身就是产品时，内部构建这些层才最有意义。

构建智能体基础设施实际需要什么

TL;DR： 一个Web智能体需要的不仅仅是一个浏览器。在规模化时，它需要温池、隔离、网站认可的身份、可观测性，以及每个决策背后的模型网关。每一层都可以自行构建，但它们组合在一起是一个需要高级工程师团队持续维护的常设系统。本文将分解这五层，并告诉你何时自己构建是值得的。

自建 vs. 购买：如何自行构建智能体基础设施

每个在Web上执行实际工作的智能体都需要“手“来完成工作，而这些“手“就是浏览器。不是一个获取标记的HTTP客户端，而是一个真正的浏览器：运行页面的JavaScript、在导航间保持会话、渲染模型推理的DOM、并突破登录墙。模型决定做什么，但浏览器才是实际渲染页面的一方。

“手“只是开始。我们常常忽略，当我们打开笔记本电脑时，实际上带到了办公桌上的远不止这些。要像人类一样在开放网络上工作，智能体还需要人类的其余能力。它需要网站认可并放行的护照、能在运行出错时观察发生了什么的眼睛，以及每次点击背后的判断或推理。然而，智能体没有我们的生物构造，所以所有这些之下是其自身的计算机对应物——即能让数千个智能体同时运行而不相互泄漏的基础管道。

在真实的博客网站上与此组件交互：browserbase.run/build-buy

在真实的博客网站上与此组件交互：browserbase.run/build-buy

启动第一个浏览器很容易。Chromium和Playwright是开源的，而且你已经在运行容器，所以一个智能体可以在一天之内通过一个流程进行点击。

我敢说这是一个周末项目，直到你梦想着投入生产环境。

你之前监视的一个浏览器变成了成千上万个你无暇顾及的浏览器，每个都必须携带网站接受的护照，到达那些旨在拒绝它的页面，在会话中途失败时恢复，并记录足够的信息以便你调试一万次运行中失败的那一次。不要误会我的意思，你可以用你已经熟悉的工具构建所有这些，但这比启动Chromium要多得多。

关键是，这一切甚至都不是你的智能体本身。护照、池、隔离、代理、可观测性和模型路由都是你的智能体与Web之间的一个基座。因此，每个季度花在构建和维护这一切上的时间，也就是没有花在你产品中独一无二部分上的时间。

让我详细说明在构建智能体像人类一样使用Web的基础设施时需要考虑的所有事情。

温池：预启动浏览器以消除冷启动延迟

智能体将浏览器置于请求路径中，因此：模型选择一个动作 → 浏览器执行它 → 页面被渲染回来。这个页面是模型在下一次循环运行之前唯一的视图。浏览器的延迟就是智能体的延迟，而任务中途的冷启动意味着正在运行的智能体停滞不前，而下游的某些东西正在等待它。

在本地你永远感觉不到这一点，因为你可以启动Chromium一次，它就会一直运行，如果单个会话崩溃，你可以手动重启。但在规模化时，这种手动操作消失了，小数字也不再是小问题。一个由数千个浏览器组成的舰队，没有人监视任何一个会话，因此0.1%的崩溃率（以前只是一个四舍五入的误差）不幸地变成了数千个会话中稳定出现的事故流。本来可以在笔记本电脑上重新启动的内存泄漏，变成了整个舰队的缓慢OOM。

冷启动成本在此基础上叠加。拉取镜像、启动Chromium、等待它接受命令需要数秒，而这些秒是智能体被阻塞等待浏览器存在的死时间。解决这个问题的方法是预先准备好浏览器，这就是温池的用途。浏览器已经启动并处于空闲状态，等待下一个请求。

良好运行温池归结为三点。

第一是规模。温浏览器太少，请求将在冷启动后排队，这正是你一开始想要消除的延迟。温浏览器太多，意味着为闲置的浏览器付费。正确的数量需要跟踪你的流量，因此池必须根据一天中的时间增长和收缩，而不是固定不变。

第二是经济性所在的空间比。每个活动浏览器需要携带多少备用浏览器取决于你的流量突发程度，因此一个负载突发且不可预测的产品必须为其峰值过度配置，可能每使用一个浏览器就保持一个温浏览器。如果足够的独立流量分布在同一个池中，那么突发就会平滑，因此一个备用浏览器可以覆盖几个活动会话，每个会话的成本就会下降。

随着流量攀升，这个比例会改善。

在真实的博客网站上与此组件交互：browserbase.run/build-buy

在真实的博客网站上与此组件交互：browserbase.run/build-buy

第三部分是耗尽。会话是有状态且长时间运行的，因此你不能像处理无状态工作者那样在负载下降的瞬间缩减容量。中途杀死一个会话会杀死活跃的工作。缩减规模意味着等待会话完成才能回收其容量，并且运行一个循环部署，分阶段耗尽和补充池。

所有这三者都随流量变化，因此不能只是设置好就忘记。这是一个迭代过程，意味着你今天调整好的池在用法发生变化的那一刻就失调了。

这是第一层。它实际上只是由于状态而变得更加困难的普通自动缩放，而为了保持响应性而携带的空闲容量是一个永远不会归零的成本。

隔离：在共享集群中对不受信任的页面进行沙箱化

浏览器是你沙箱中唯一设计用于运行不受信任代码的东西。其他一切都在执行你编写或审查过的代码，但浏览器会加载智能体导航到的任何页面，并运行它提供的任何JavaScript，都在你自己的进程中和计算机上。

再次强调，这在你笔记本电脑上不会造成伤害，但一旦你启动数千个浏览器，它们都在未经审查的页面上并共享基础设施，问题就严重了。一个被攻破的浏览器就是通往其共享主机的立足点。恶意页面利用Chromium漏洞突破浏览器进程，在共享基础设施上，这种逃逸会影响到并发的会话。

这种情况发生的频率比你想象的要高。Chromium不断发布安全修复，其中很多被评为高或严重，有些是在已经在野外被利用后才被修补的。运行地球上攻击最多的软件，同时成千上万份，针对你不控制的输入，这是一个不小的障碍。

你需要分两部分来处理。

第一部分是隔离本身。每个会话都需要一个真正的边界，这样突破浏览器的页面会撞上一堵墙，而不是主机。没有感染！这意味着每个浏览器一个沙箱，最好是每个轻量级VM，而不是共享内核，这样即使渲染器漏洞逃逸出Chromium，也无法到达机器或其旁边的会话。天真的版本——许多浏览器共享一个容器——是一个坏页面就能搞垮整个团队的版本。

我们的计算层运行在Firecracker上，因此我们的浏览器在VM级别保持隔离，而不必为每个会话支付完整VM的费用。

第二部分是修补。CVE永无止境，修补也永无止境。每个发布版本都必须经过测试并快速部署到整个集群，因为修复公开和漏洞武器化之间的窗口很短。公开的CVE是一个清晰的配方，任何想在窗口期内进入的人都可以利用。

在真实的博客网站上与此组件交互：browserbase.run/build-buy

在真实的博客网站上与此组件交互：browserbase.run/build-buy

很快你会发现，修补和隐蔽相互对抗。如果你为了隐蔽而分叉了Chromium，那么每个上游安全补丁在发布前都必须重新应用到你的分叉上，因此你越依赖自定义规避，保持最新状态就越痛苦。安全性和隐蔽性最终会在同一个发布管道中争夺同一个二进制文件。

身份：一致性和住宅路由

你的智能体访问的每个网站都会评估它并提出两个问题：这是谁？他们从哪里来？人类毫不费力地通过两者，而智能体必须用护照赢得两者。开放网络要么让智能体通过，要么将其拒之门外。

在本地，这两个问题都不会被问，也没有人筛选你。在规模化时，每个请求都会问这两个问题，默认设置会通过验证码、速率限制和完全封锁而失败。

网站看到的是谁

浏览器在每次访问时都携带一个身份，这只是网站可以读取的关于谁在连接的信号集合，它们跨越整个栈。在网络层面，TLS握手产生指纹（JA3或更新的JA4），HTTP/2帧顺序形成签名，这两者都在真正的Chrome和大多数自动化栈之间有所不同。更高层次上，页面可以读取navigator.webdriver、枚举已安装的字体和插件、并哈希画布或WebGL绘图以查看图形栈的渲染方式。它甚至可以观察行为，如鼠标路径和点击之间的时间。

清理明显的破绽是容易的部分。无头Chromium将navigator.webdriver设置为true、携带HeadlessChrome用户代理、不暴露插件、并以无熵的方式渲染画布。你可以通过分叉Chromium并进行更改来直接清除每个破绽。

困难的部分是一致性。检测系统一起读取所有信号，因此一个声称是Windows上的Chrome但携带Linux渲染字符串、字体指标不匹配、时区与IP地理位置不符的浏览器，比一个未修改的无头浏览器更容易被识别，因为没有真实设备会产生这种组合。

你必须保持身份，使每个信号与其他信号一致，从GPU字符串到操作系统到字体再到区域设置，当你轮换它们以分散流量时，每个信号都必须保持同样一致。

然后是验证码。超过一定量级，无论身份多么干净，一些会话还是会受到挑战。因此，你需要接入一个解决路径，检测你面临的挑战类型，并将答案返回到页面中。

在真实的博客网站上与此组件交互：browserbase.run/build-buy

在真实的博客网站上与此组件交互：browserbase.run/build-buy

你从哪里连接

一个完美的身份如果来自错误的地方，仍然会暴露你。第二个问题指向IP，默认答案会立即失败，因为直接来自你云端的流量携带数据中心地址。每个主要提供商的IP范围都是公开的，因此许多网站在页面加载之前就将来自这些地址的流量视为自动化流量。

通过意味着通过住宅IP路由，这是普通人浏览时使用的类型，因此网络将其视为正常流量。前进两步，后退一步，因为这现在打开了一个来源和声誉问题。这些地址必须来自某个地方，而这个地方必须是你能够站得住脚的。声誉也不是固定的，因为地址会被标记，整个池会被烧毁，共享你池的吵闹邻居可能会降低所有其他人的声誉。

IP声誉表现为一种你需要维护的资产，而不是一次买断的东西。这是另一个移动的部件。你需要轮换地址，淘汰被标记的地址，在池磨损时替换容量，并不断检查地址的来源。

在真实的博客网站上与此组件交互：browserbase.run/build-buy

在真实的博客网站上与此组件交互：browserbase.run/build-buy

这两个问题都有自己的变化节奏。检测系统随时更新，池会衰变，这个月有效的身份+网络设置下个月就会开始遭遇封锁，除非有人在监视封锁率并保持两者都是最新的。

可观测性：记录会话和追踪模型决策

前三层让智能体进入页面并采取行动。下一步是观察它是否真的做到了。你不能信任一个你无法监视的智能体，这就是为什么智能体基础设施需要眼睛和日志。我们从黑盒 → 一个可调试的工作流。

在本地已经是这样了。浏览器就在那里，所以你可以看着它点击流程，并在情况不对劲时打开开发者工具。这是一个会话、一个屏幕时的免费可见性。

在规模化时，它变黑了。智能体在你没有眼睛的机器上运行，在一个67步任务中的第40步失败，而你只得到一个极其详细的日志行：“点击未命中”。你看不到吞掉按钮的模态框或首先触发的重定向。为了调试它，你需要看到浏览器所看到的，这意味着记录会话。这变得相当昂贵。

视频与DOM对比

有两种记录会话的方法，它们以相反的方式失败。

视频在会话运行时编码实际的像素。它精确捕获渲染的每一帧，但编码数千个并发流会消耗运行浏览器的同一台主机的CPU。因此，可观测性与集群竞争计算资源。

另一方面，DOM重建记录DOM及其变化，然后在稍后在一个新页面中重放它们，就像rrweb那样。它轻量得多，因为你存储的是变化流而不是视频，但它在真实Web变得复杂的地方恰恰会失效。嵌套iframe、影子DOM、跨域框架和画布不能干净地重建，因此那些在恶意页面上的奇怪会话（最需要调试）最有可能重放错误。

你需要根据你的用例选择你的失败模式。视频消耗计算和存储但显示真相，而重建便宜但有时不可靠。健壮的设置两者都运行，因此在保真度重要的地方使用视频，在其他地方使用重建，这意味着两个记录管道而不是一个。

在真实的博客网站上与此组件交互：browserbase.run/build-buy

在真实的博客网站上与此组件交互：browserbase.run/build-buy

看见原因，而不仅仅是结果

重放浏览器告诉你页面上发生了什么。对智能体来说，这不是最重要的部分。智能体采取行动是因为模型做出了决定，因此当运行出错时，应该质疑决定本身。模型是否误读了页面？得到了错误的工具结果？还是幻觉了一个不存在的按钮？

回答这个问题意味着追踪每个模型调用和工具调用，并与会话同步，以便你可以看到模型在选择动作时推理的页面状态。重放和追踪必须放在同一个时间线上，因为分开它们各自只讲述了一半的故事。一种方法是将会话重放、网络和事件日志，以及模型和工具追踪放在一个视图中。

所有这些还必须存储并索引足够长的时间以发挥作用。整个集群中完整的录制 + 每一步追踪是TB级别的数据。你可能需要的日志是上周那次失败的运行中的旧日志，因此保留是关键。

模型网关：跨模型提供商的路由、回退和缓存

浏览器是手，但模型是判断力，而判断力通过API调用运行在各个实验室。