当浏览器需要同时服务于人、自动化程序和 AI 智能体，我们开始重新思考：浏览器是否仍然应该只是一个由人逐个打开、逐个操作的窗口？

1. 当浏览器窗口从几个变成几十个

如果你管理过多个社交媒体账号、电商店铺、内容平台账号，或者运行过大规模浏览器自动化任务，可能见过这样的工作场景：

电脑桌面上同时打开 Chrome、Edge、夸克等多款浏览器，每款软件又各自开启了数个甚至十几个窗口。每个窗口都登录着不同的账号，使用着独立的 Cookie、代理和浏览器配置，执行着各自的任务。当窗口数量不多时，这种操作方式直观且易于管理。

但当浏览器环境逐渐增加，问题很快就不再是“怎样打开一个网页”，而变成了：

• 哪个窗口对应哪个账号？
• 哪些环境正在运行，哪些任务已经结束？
• 哪个页面出现了验证码、登录失效或其他异常？
• 自动化任务运行时，用户如何观察页面并随时接管？
• 浏览器关闭后，登录状态和用户数据能否继续保留？
• 为什么运行一段时间后，内存和 CPU 占用越来越高？
• 多个账号之间的 Cookie、缓存和网络环境能否真正隔离？

传统浏览器解决的是“一个人如何浏览网页”。

而矩阵运营、浏览器自动化和 AI 智能体面对的，是“如何持续管理大量独立浏览器环境”。

Seek Browser，就是从这些实际问题开始的。

2. 浏览器的使用者不再只有人

传统浏览器的设计前提非常清晰：用户打开浏览器，通过鼠标和键盘访问网页。

但现在，浏览器的使用方式正在发生变化。在矩阵运营和自动化场景中，浏览器通常同时服务于三类使用者。

第一类是人。

人负责制定目标、判断结果、处理验证码、确认高风险操作，以及在自动化出现异常时接管页面。

第二类是自动化程序。

自动化程序负责执行稳定、重复且规模较大的工作，例如页面检查、信息录入、数据读取、状态监控和流程操作。

第三类是 AI 智能体。

相比固定流程的自动化程序，AI 智能体可以理解页面内容，根据任务目标决定下一步操作，并处理更多无法完全预先编排的页面流程。

过去是人打开浏览器完成任务。未来则可能是自动化程序和 AI 智能体在浏览器中持续工作，人负责观察、判断和处理关键节点。

这意味着，浏览器不能只考虑“如何让人操作网页”，还要考虑：

• 如何为不同任务提供独立、稳定的浏览器环境；
• 如何允许自动化程序可靠地连接和操作页面；
• 如何让多个环境长期运行并被统一管理；
• 如何让人随时看到任务正在做什么；
• 如何在人和自动化之间平稳地交接页面控制。
  

Seek Browser 希望为人工操作、浏览器自动化和 AI 智能体提供统一的运行与管理基础。

3. Seek Browser 是什么

Seek Browser 是一套面向多账号运营、浏览器自动化和 AI 智能体的浏览器工作平台。

它所管理的不只是一个个浏览器窗口，而是一个个相互隔离、可以持续运行的浏览器环境。

每个环境可以包含：

• 独立的账号和登录状态；
• Cookie、缓存及其他站点数据；
• 独立的代理和网络配置；
• 浏览器参数及设备配置；
• 当前打开的页面；
• 自动化连接入口；
• 环境运行状态和任务信息。

这些环境可以按照业务、项目和账号进行分组，也可以通过现有接口被自动化程序打开、连接和控制。

我们希望把过去分散在浏览器窗口、账号表格、代理工具和自动化程序中的信息，放进同一套管理体系中。

对于普通用户而言，它是一套多账号浏览器管理工具。

对于开发者而言，它提供可以连接和操作的浏览器运行环境。

对于未来的 AI 应用而言，它可以成为智能体访问网页、执行任务和保留用户状态的基础设施。

Seek Browser 环境管理列表

4. 我们关心的不只是隔离，还有自动化兼容

多账号浏览器首先需要解决环境隔离。

不同账号之间的 Cookie、缓存、登录状态和代理网络不应该相互影响。关闭浏览器以后，这些用户信息仍然需要被正确保存，以便下一次继续使用。

但仅有环境隔离并不够。

当浏览器需要被自动化程序或 AI 智能体操作时，它还必须提供稳定、可连接的自动化接口。

Seek Browser 保留了现有浏览器自动化的主要接入方式。已有的 Playwright、Puppeteer 自动化程序，可以通过 CDP 连接指定的浏览器环境，获取页面、读取 Cookie，并执行导航、点击、输入等操作。

对于自动化调用方来说，我们希望尽可能隐藏不同浏览器内核之间的实现差异。自动化程序仍然按照熟悉的流程工作：

1. 自动化程序调用 Seek Browser API；
2. 通过 API 选择需要使用的浏览器环境；
3. Seek Browser 打开或复用该环境，并返回自动化连接地址；
4. Playwright、Puppeteer 或 AI 智能体通过该地址连接；
5. 获取页面并执行任务。

为了更清晰地展示这一流程，下图概括了自动化程序通过 Seek Browser 连接并执行任务的关键步骤：

当然，浏览器兼容性不是一句“支持 CDP”就能完全保证的。

点击、弹窗、iframe、多页面、下载、Cookie、页面生命周期等行为，都需要通过真实业务任务不断验证。因此，我们会保留不同内核的选择，让用户根据任务特点，在兼容性和资源效率之间做出判断。

5. 为什么我们设计了 SeekLite

在传统模式下，每个浏览器环境都会启动一个独立 Chrome，并使用独立的 user-data-dir。

这种方式具有直接、成熟和兼容性较高的优点，因此 SeekChrome 仍然会是 Seek Browser 的重要内核。

但当几十个环境需要同时运行，并且每个任务都会持续较长时间时，每套独立 Chrome 进程树都会产生固定的内存、CPU 和系统资源成本。

为此，我们设计了 SeekLite。

SeekLite 是 Seek Browser 中面向轻量化运行场景的浏览器内核。它基于 Electron，并复用 Seek Browser 的基础运行能力，同时继续为不同环境提供独立的用户数据、Cookie、代理和页面空间。

它的目标不是简单地“把 Chrome 换成 Electron”，也不是立即替代所有 Chrome 场景。

SeekLite 更重要的价值，是验证一种新的运行方式：

当大量浏览器环境需要同时被自动化程序和 AI 智能体使用时，是否可以共享更多基础设施，同时保留必要的账号隔离与自动化能力？

对于依赖完整 Chrome 扩展、特殊浏览器能力，或者尚未经过验证的复杂自动化任务，SeekChrome 仍然是更稳妥的选择。

对于已经通过实际任务验证、需要大量环境持续运行的场景，则可以使用 SeekLite，尝试降低大量独立浏览器实例带来的固定资源开销。

我们不会在缺少正式测试数据的情况下宣传一个固定的资源下降比例。页面数量、目标网站、媒体内容和自动化行为都会影响最终结果。

真正有意义的对比，应当建立在相同账号数量、相同页面和相同任务持续时间之上。

对比项	SeekChrome	SeekLite
运行方式	独立 Chrome 实例	共享宿主能力
兼容方向	更接近完整 Chrome	持续通过真实任务验证
核心目标	优先完整能力	优先矩阵运行效率
推荐场景	扩展及复杂 Chrome 任务	多环境、长期自动化任务
环境管理	窗口管理	窗口管理与 Spaces 集中观察

SeekChrome 与 SeekLite 并不是简单的替代关系，而是面向不同任务的内核选择。

6. Spaces 工作台：同时观察多个浏览器环境

当大量自动化任务同时运行时，另一个问题随之出现：用户如何知道每个环境里正在发生什么？

如果把所有页面都显示为独立窗口，桌面会很快被占满。频繁切换窗口也会打断正在进行的工作，并增加人工检查成本。

因此，我们设计了 Spaces 工作台。

一个 Space 表示一个独立的浏览器运行环境；Spaces 工作台则用于集中查看和管理多个环境。

在 Spaces 中，用户可以查看：

• 当前正在运行的浏览器环境；
• 每个环境的页面缩略图；
• 环境名称和运行状态；
• 自动化程序是否已经连接；
• 一个环境中当前包含多少页面；
• 最近打开或操作的页面；
• 打开、查看、接管和关闭等操作。

自动化任务可以继续在后台操作页面。用户不需要让所有浏览器窗口长期铺满桌面，只需要在 Spaces 工作台中观察任务。

当某个环境出现验证码、登录失效、页面异常或其他需要人工判断的问题时，用户可以打开对应的真实页面进行处理。

处理完成后，自动化程序仍然连接同一个浏览器环境，并继续使用原来的页面和登录状态。

第一阶段，Spaces 工作台主要承载 SeekLite 环境。后续随着运行时管理能力逐步抽象，Spaces 也可以接入其他浏览器内核，成为 Seek Browser 中统一的多环境工作台。

Spaces 将多个浏览器环境集中在一个页面中，用户可以观察任务，并在需要时打开真实页面接管操作

7. 一个自动化任务如何在 Seek Browser 中运行

假设一个运营团队需要管理 30 个内容平台账号。

每个账号在 Seek Browser 中对应一个独立浏览器环境，分别保存自己的登录状态、Cookie、代理配置和浏览器参数。

每天任务开始后，自动化程序通过 API 打开指定环境，再使用 Playwright 或 Puppeteer 连接浏览器，完成页面检查、数据读取、内容操作或状态监控。

运营人员不需要持续切换 30 个浏览器窗口。他们可以进入 Spaces 工作台，集中查看各个环境的当前页面和运行状态。

如果某个账号出现验证码、登录失效或其他异常，运营人员可以打开对应页面并人工处理。处理完成后，自动化任务继续使用同一个页面和账号状态执行，不需要重新创建浏览器，也不需要迁移 Cookie。

在这个过程中：

• Seek Browser 负责管理浏览器环境；
• 自动化程序和 AI 智能体负责执行任务；
• Spaces 工作台负责集中观察和操作；
• 人负责判断、确认和异常处理。

这正是我们理解的人机协作：不是把人完全排除在流程之外，而是让人从大量重复操作中退出，把注意力集中在真正需要判断的节点上。

8. 我们想做的，不只是更多浏览器窗口

Seek Browser 仍在持续开发和验证中。

我们不会把 SeekLite 描述成适用于所有任务的万能内核。

也不会在没有经过真实业务测试之前承诺完全兼容所有 Chrome 自动化程序。

我们更希望建立一套长期可演进的浏览器工作平台：

• 浏览器环境可以被独立管理和持续复用；
• 自动化程序可以稳定连接并执行任务；
• AI 智能体可以在网页中理解和行动；
• 人可以集中观察并随时接管；
• 不同浏览器内核可以根据任务特点自由选择；
• 大量环境运行时，资源与管理成本能够得到持续优化。

我们希望 Seek Browser 最终管理的，不是一堆彼此独立的浏览器窗口，而是一批可以持续运行、被自动化控制、被人观察和接管的数字工作环境。

在这里，人负责目标、判断和关键决策；自动化程序和 AI 智能体负责大量重复执行；浏览器则成为三者共同使用的工作空间。

这就是我们为什么要做 Seek Browser。

后续内容

接下来，我们还会继续分享：

• SeekLite 为什么采用共享宿主架构；
• Spaces 工作台的产品设计与技术实现；
• Playwright、Puppeteer 如何连接 Seek Browser；
• 多个浏览器环境之间如何隔离 Cookie 和用户数据；
• SeekChrome 与 SeekLite 应该如何选择；
• AI 智能体如何同时操作多个浏览器环境；
• 真实矩阵任务中的资源占用与兼容性测试。

如果你正在开发浏览器自动化、矩阵运营或 AI 智能体相关项目，也欢迎在评论区交流你遇到的实际问题。