AI 浏览器自动化，给 agent 一个不会清空的浏览器运行环境
Demo 里 agent 跑得很漂亮，一上批量就开始出问题：每次启动都是空白浏览器，登录态全丢，长流程被反复登录打断；几个任务共用一个实例，Cookie 互相覆盖，同样的 prompt 跑出两种结果；云端 agent 共用出口，想给每个任务固定代理与时区都做不到。NexBrowser 把浏览器运行环境这一层补上：按任务分配独立环境与你自有的代理，登录态跨重启保留，Local API 免费不限调用，browser-use、Playwright MCP 与自研 agent 都能直接接进来。
免费额度：1 个成员 + 10 个窗口，不过期；Local API 不单独计价。
同一套环境承载脚本与 agent · 有头 / 无头可切
AI 自动化能跑通 Demo，却难以稳定跑批
agent 解决的是「怎么操作页面」；真正吃掉工程时间的，是会话管理与运行环境的复现。
每次启动都是空白浏览器
agent 拿到的是全新实例，登录态、Cookie 与本地存储一概没有。一个需要登录才能完成的长流程，会被反复的登录、验证码与二次验证打断，模型的 token 大半花在重新登录上。
多任务共用实例，状态互相覆盖
几个 agent 跑在同一个浏览器里，Cookie 与 localStorage 互相顶掉，A/B 分组与语言设置也会串。同样的输入跑出不同结果，失败了也没法复现，调试变成碰运气。
一次性实例不保留缓存与配置
每轮运行都从零开始加载资源、重新配置指纹与代理，慢不说，出问题时也无法回到上一次的确定状态去对比，只能整批重跑。
云端 agent 共用出口
托管方案通常共用一批出口 IP，你既指定不了每个任务的代理，也固定不了时区与语言。需要按地区访问、或者需要账号长期绑定某条出口时，这一层就卡住了。
agent 跑批时，运行环境要解决的五件事
模型负责决策，运行环境负责让决策能稳定落地。这五件事都不是模型能提供的。
- 01
会话与登录态持久化
Cookie、localStorage 与缓存要在任务之间、重启之间保留下来，agent 才不用在每个流程开头处理登录。配置还要能云端同步与导入导出，换一台机器继续跑不需要重新准备。
- 02
任务级隔离
每个任务或账号一个环境，存储、指纹与代理各自独立，互不读取。并行跑十个 agent 时，第七个失败不会污染其余九个的状态，结果也才有可比性。
- 03
代理、时区与语言可指定
按任务绑定你自己的代理出口，时区与语言随之对齐，访问地区敏感的站点时拿到的是目标地区的版本；同一个账号长期使用同一条出口，也比每次随机换出口稳定。
- 04
并发与资源可控
同一台机器能跑几个 agent，取决于内存、CPU 与窗口额度。环境要能有头 / 无头切换：调试时看得见页面，跑批时不占图形资源，并发数按机器实际能力设定。
- 05
可观测与可复现
运行日志、失败步骤、产出结果要能落盘导出，出问题时能定位到是模型判断错了还是页面变了。环境配置固定下来，同一个任务今天和下周跑出的差异才有分析价值。
NexBrowser 不替代你的 agent，只把上面这五件事做成稳定的一层。脚本化自动化的接口说明可以看Local API 浏览器自动化，不想写代码的流程编排可以看无代码 RPA。
NexBrowser 在 AI 自动化里提供的四项能力
持久化会话、任务级隔离、标准接入、调度与导出——agent 需要的底座，一次配好长期复用。
持久化的会话与登录态
agent 所需的登录态保存在环境里，跨任务、跨重启长期保留；Cookie、缓存与本地存储不会在关闭后清空，配置支持云端加密同步与导入导出，换机器继续跑不用重新登录。
按任务分配独立环境
每个任务或账号一个环境，20 余项指纹参数、Cookie、缓存与本地存储彼此独立；多个 agent 并行运行时各自隔离，单个任务失败不影响其余任务的状态与进度。
Local API 接入，不单独计价
内置 Local API 免费且不限调用次数，兼容 Selenium / Puppeteer / Playwright / WebDriver；启动环境后拿到 CDP 端点，browser-use、Playwright MCP 或自研 agent 用标准客户端连上即可，脚本几乎不用改。
调度、重试与结果导出
把同一套流程复制到多个环境按计划执行，有头与无头两种模式可切；单步失败自动重试，运行日志与产出结果可导出为 CSV / JSON，接进已有的数据管线。
四步把 agent 接进受管理的运行环境
先用一个真实任务跑通，再按同一套模式复制到其余任务。
- 1
创建独立环境
为每个任务或账号创建环境，命名用「任务 + 地区」，指定代理、时区与语言，第一次手动登录一遍把登录态存下来，之后 agent 启动即是已登录状态。
- 2
启动并取得端点
通过 Local API 启动指定环境，拿到该环境的 CDP / WebDriver 端点。这一步等价于你平时的 launch()，区别是浏览器由客户端托管，配置与登录态都已经在里面。
- 3
接入 AI 框架
Playwright 侧用 const browser = await chromium.connectOverCDP(wsEndpoint) 接管；Puppeteer 用 puppeteer.connect({ browserWSEndpoint })；browser-use、Playwright MCP 与 computer-use 类 agent 按各自的连接配置指向同一个端点即可。
- 4
调度与运行
把流程复制到多个环境并设定时任务批量执行，失败步骤自动重试；实时查看运行日志，结果导出 CSV / JSON，异常任务单独告警。
开发团队选它的三个理由
接入成本低，环境可复现，账单可预期。
标准协议，接入不改架构
Local API 兼容 Selenium / Puppeteer / Playwright / WebDriver，任何支持 CDP 或 WebDriver 的客户端都能连接到已启动的环境；已有脚本改的是连接方式，不是业务逻辑。
环境真实且可复现
真实 Chromium 内核加 20 余项自洽的指纹参数，同一个环境每次启动都是同一台「设备」，配合持久化的登录态，agent 的运行结果才有复现和对比的基础。
账单按窗口，不按调用
Local API 免费且不限调用次数，不按请求数或 token 加价；1 个成员 + 10 个窗口永久免费，扩容低至 0.30 USDT/窗口/30 天，按实际并发数扩容即可。
先用一个真实任务验证接入成本
下载 Windows 客户端，用免费的 10 个窗口把一个 agent 流程接进来跑一轮。
AI 浏览器自动化常见问题
browser-use 需要什么样的浏览器环境？
browser-use 负责让大模型理解页面并决定下一步操作，它需要的是一个可以长期使用的浏览器：登录态不会在重启后丢失、每个任务有自己的存储与代理、可以有头调试也可以无头跑批。把它指向 NexBrowser 启动的环境端点，页面运行在真实 Chromium 内核上，登录态由环境保留，流程里就不用再写登录步骤。
Playwright MCP 怎么连到已有的浏览器？
先用 Local API 启动目标环境并取得它的 CDP 端点，再让 Playwright 侧用 chromium.connectOverCDP(wsEndpoint) 连接，而不是自己 launch 一个新实例。这样 agent 操作的是你配置好的环境：指纹参数固定、代理已绑定、登录态已存在。Puppeteer 用 puppeteer.connect({ browserWSEndpoint }) 同理，WebDriver 客户端也可以按标准协议接入。
AI agent 每次运行都要重新登录怎么办？
根因是运行环境是一次性的。把该账号固定放进一个环境，第一次手动登录并保存登录态，之后每次启动这个环境都是已登录状态，Cookie、localStorage 与缓存都还在。配置还能云端加密同步，换一台机器登录同一个团队账号即可继续跑，不需要在流程里维护登录与验证码的分支逻辑。
Local API 要额外付费吗？
不需要。Local API 内置在客户端里，免费且不限调用次数，也不按请求数或 token 计价，免费档同样可用。你付费的对象是并发窗口数与团队席位：1 个成员 + 10 个窗口永久免费不阉割功能，扩容低至 0.30 USDT/窗口/30 天，按实际需要的并发数扩即可。
一台机器能同时跑几个 agent？
取决于内存、CPU 与窗口额度。每个环境相当于一个独立的浏览器实例，8GB 内存同时跑十来个窗口比较从容，16GB 可以再多一些；无头模式比有头省资源，适合跑批。建议先按机器实际能力设定并发上限，再用调度把任务排队，而不是一次性把所有任务全开。
云端 agent 服务和本地浏览器环境有什么区别？
托管方案省去部署，但通常共用出口 IP，代理、时区与语言难以按任务指定，会话保留策略也由服务方决定。本地环境的差别在于控制权：代理是你自己的，环境配置与登录态留在本地并可云端同步，有头模式随时能看到页面在做什么，调试和合规审计都更直接。
还有其他问题？我们随时为您解答联系客服支持 →