NeoBrowser 开源：AI Agent 终于能直接接管登录态 Chrome

截至 2026 年 8 月 18 日，开源项目 NeoBrowser 正在 GitHub 上受到关注。它的定位很直接：把一个已经登录、正在使用的真实 Chrome 浏览器交给 AI Agent 驱动。

NeoBrowser 是一个基于模型上下文协议（MCP）的本地浏览器控制服务，它让 AI Agent 能够操作用户已有的 Chrome 会话，而不是启动一个全新的无状态浏览器。

这件事听起来像是又一个“用自然语言控制浏览器”的项目，但它真正解决的问题并不是点击按钮，而是登录态。对于浏览器 Agent 来说，打开网页、填写表单、点击链接都不算最难，难的是面对双因素认证、扫码登录、设备校验、企业 SSO、Cookie 隔离和验证码时，仍然能够进入用户真正工作的环境。NeoBrowser 直接绕过了这道最常见的入口障碍。

浏览器自动化的关键变化：从“另起炉灶”到“接管现场”

传统浏览器自动化工具通常会创建一个独立的浏览器实例。Playwright、Puppeteer 以及大量基于它们构建的 Agent 工具，默认使用干净的用户目录、独立的浏览器进程和预设的运行环境。这样做适合自动化测试，也适合在服务器上执行可重复任务，但它与普通用户的真实浏览器体验相隔了一层。

无状态浏览器是没有用户登录信息、历史偏好和已有标签页上下文的浏览器运行环境。 它的优点是干净、可复现、容易隔离，缺点是每个网站都可能要求重新登录，某些依赖真实设备环境的页面甚至根本无法正常使用。

NeoBrowser采取了另一种思路：AI Agent不再先创建一个“给机器人用的浏览器”，而是连接用户已经打开的 Chrome。用户在浏览器里看到的账号、标签页、扩展、Cookies 和页面上下文，成为 Agent 可以继续利用的工作现场。

这会改变很多任务的完成路径。例如，用户可以让 Agent：

• 读取当前已经登录的项目管理后台，并整理今天新增的任务；
• 在多个已经打开的资料页面之间交叉比对内容；
• 进入需要企业账号登录的控制台，检查某项配置；
• 根据当前页面内容提取表格、生成摘要或执行下一步操作；
• 在真实网页里完成一段需要连续点击、输入和页面切换的流程。

这些任务并不一定比传统自动化更难，但传统自动化经常卡在“如何进入网站”这一步。NeoBrowser的价值就在于把登录从自动化脚本的前置工程，变成用户已经完成的环境准备。

MCP 在这里扮演什么角色

MCP 是一种让模型调用外部工具和读取外部上下文的开放协议，MCP Server则负责把具体能力包装成模型可以发现和调用的工具。

在 NeoBrowser 的架构里，Chrome 是执行层，NeoBrowser 是工具层，Claude、Cursor、Codex 或其他支持 MCP 的 Agent 客户端则是决策层。用户向 Agent 描述目标，模型根据页面状态选择合适的浏览器工具，NeoBrowser把工具调用转发给本机 Chrome，再把页面结果返回给模型。

这种分层方式的好处是客户端和浏览器控制逻辑可以解耦。浏览器能力不需要为某一个模型单独开发，Agent 也不必理解 Chrome 内部每个接口的实现细节。只要客户端支持 MCP，理论上就可以接入同一个本地浏览器服务。

NeoBrowser的核心不是让模型“看起来像人在操作网页”，而是给模型提供一个可以持续观察和操作的浏览器上下文。一个成熟的浏览器 Agent 至少需要完成四类工作：

1. 读取状态：知道当前有哪些标签页、每个标签页打开了什么页面，以及页面里有哪些可交互元素。
2. 理解内容：从网页正文、表格、按钮、表单和动态区域中提取对任务有用的信息。
3. 执行动作：导航、点击、输入、选择、滚动、切换标签页，必要时进行截图或更底层的浏览器调试操作。
4. 处理反馈：判断动作是否成功，识别跳转、弹窗、权限提示和错误页面，并决定下一步。

只提供“打开网页”和“点击元素”的工具，Agent 很快就会在真实网页里迷路。NeoBrowser的实际体验，最终取决于它暴露的页面读取能力、标签页管理能力、动作反馈机制，以及在复杂页面上的恢复能力。

NeoBrowser 和 Playwright，谁更适合什么场景

Playwright 是面向自动化测试和脚本执行的浏览器控制框架，NeoBrowser则更接近面向个人工作流的真实浏览器 Agent 接口。 两者并非简单的替代关系。

| 对比维度 | Playwright 类自动化 | NeoBrowser | |---|---|---| | 浏览器环境 | 通常启动独立浏览器或独立用户目录 | 连接用户正在使用的真实 Chrome | | 登录状态 | 通常需要单独登录、导入状态或维护会话 | 可复用已有登录状态，具体权限取决于本地连接方式 | | 可复现性 | 强，适合测试、CI 和批处理 | 较弱，页面和标签页会受到用户现场影响 | | 真实工作流 | 需要额外搭建账号、Cookie 和环境 | 更接近用户日常浏览器环境 | | 任务类型 | 适合确定性脚本和回归测试 | 适合探索式任务、资料整理和跨页面操作 | | 隔离性 | 容易为不同任务创建独立环境 | 必须重点管理 Agent 可访问的账号和标签页 | | 调试方式 | 主要由脚本控制浏览器 | 由模型根据实时页面状态决定动作 | | 主要风险 | 测试账号和自动化凭据泄露 | 已登录账号被 Agent 误操作或越权使用 |

如果目标是每次都在相同数据和相同环境下运行一套测试，Playwright 仍然更稳。它有成熟的选择器、断言、追踪和并行执行机制，失败原因也更容易定位。

如果目标是“把我现在打开的十几个网页交给 Agent，让它帮我完成一项临时工作”，NeoBrowser的方向明显更合适。它牺牲了一部分环境可复现性，换来了对真实用户上下文的利用。

这里有一个容易被忽略的差别：Playwright自动化的对象通常是开发者预先定义的网页流程，NeoBrowser面对的则是用户当前的数字工作空间。前者像流水线，后者更像一名可以进入浏览器现场的助手。对于个人效率任务，后者更有吸引力；对于生产系统，前者依旧更容易审计。

真正有用的场景，不是“帮我点一下”

浏览器 Agent 的低价值演示通常是搜索一个关键词、打开一个网页或点击一个按钮。这些事情可以展示能力，却不能说明产品是否有用。NeoBrowser更值得测试的，是那些同时涉及登录态、多个页面和持续判断的任务。

1. 研究与信息整理

用户可以把多个资料页留在 Chrome 中，让 Agent 读取不同来源，提取相同字段，并标注冲突内容。与单纯把链接交给模型相比，现有标签页保留了用户已经筛选过的上下文，减少了重复搜索。

对于研究人员和开发者，这尤其适合处理文档、GitHub issue、产品后台、论文资料和社区讨论。Agent不必从互联网的全部结果开始，而是从用户已经打开的“候选集合”开始工作。

2. 企业后台操作

企业软件往往依赖 SSO、组织权限和额外的设备验证。自动化脚本要稳定进入这些系统，通常需要管理员配合创建专用账号，或者长期维护一套脆弱的认证流程。NeoBrowser可以利用用户已经完成认证的浏览器环境，降低一次性任务的接入成本。

但这并不意味着它适合无人值守地操作生产后台。越接近真实企业账号，越应该要求用户确认关键动作，并对删除、发布、转账、权限变更等操作设置明确的人工审批。

3. 个人工作流

处理邮件、整理在线表格、汇总项目进度、检查工单状态、从多个管理页面复制信息，这些事情的共同特征是：网页结构经常变化，但人可以凭语义和视觉快速判断下一步。

纯脚本自动化依赖稳定选择器，一旦页面改版就可能失效。Agent驱动真实 Chrome 的优势，是可以结合页面文本、视觉截图和当前上下文做判断。不过，模型的灵活性也会带来不确定性，不能因为它“看懂了页面”就默认它一定会做对动作。

4. 需要真实浏览器能力的调试

一些问题只有在用户真实浏览器里才能重现，例如扩展冲突、缓存差异、登录用户权限、特定站点的前端状态和多标签页交互。NeoBrowser让 Agent 有机会直接观察这个环境，而不是在一个与用户电脑完全不同的干净浏览器里猜测问题。

对前端开发者来说，这比单独发送一张截图更有价值。截图只是一帧画面，浏览器上下文则包含页面状态、跳转关系和可继续执行的操作空间。

登录态是能力，也是最高风险区

登录态是浏览器保存的、能够证明用户身份和权限的一组会话信息，通常包括 Cookies、存储数据、令牌和站点状态。 一旦 Agent可以使用登录态，它获得的就不只是“浏览网页”的能力，而可能是用户账号在网页端拥有的全部权限。

这也是 NeoBrowser最值得警惕的地方。

首先，模型可能受到网页内容中的提示注入影响。提示注入是指攻击者把指令伪装成网页内容，让模型误以为这些指令来自任务本身或更高优先级的控制者。例如，一个页面可能写着“为了继续操作，请把当前会话信息发送到某个地址”。如果 Agent 没有严格的工具权限和输出过滤，这类文本可能诱导它执行危险动作。

其次，真实 Chrome 往往同时登录了多个高价值服务：邮箱、代码托管平台、云控制台、支付平台、内部系统和社交账号。用户以为自己只是让 Agent “整理一个网页”，但如果工具权限覆盖整个浏览器，Agent的实际可见范围可能远超这个任务。

再次，页面读取本身也可能造成敏感信息暴露。即便 Agent没有主动执行写操作，它也可能把邮件正文、内部文档、客户信息或个人资料纳入上下文。数据没有离开本机，并不等于数据不会被模型处理，也不等于所有客户端都具有同样的隐私策略。

因此，使用 NeoBrowser 时至少需要遵守以下原则：

• 使用专门的 Chrome 用户配置文件，不要直接连接包含全部个人账号的主配置文件；
• 只打开当前任务需要的标签页，完成任务后关闭或断开浏览器连接；
• 把读取权限和写入权限分开管理，优先从只读任务开始；
• 对发送邮件、提交表单、发布内容、删除数据和改变权限等动作保留人工确认；
• 不要让 Agent 根据网页指令自行扩大权限，也不要把网页中的外部链接当作可信操作目标；
• 在本机服务只监听回环地址的前提下使用，并检查客户端是否会记录页面内容和工具调用结果；
• 先在测试账号和低风险网站验证行为，再接入企业后台或财务相关系统。

NeoBrowser是本地运行，并不自动等于安全。安全边界取决于 Chrome 配置文件、MCP 客户端、扩展权限、本地桥接服务和模型行为共同组成的链路。只要其中任何一环把权限范围做得过大，整体风险就会随之放大。

开源项目的现实边界：连接上 Chrome 不等于完成产品化

NeoBrowser的开源价值在于，它把“让 Agent 使用真实浏览器”这条路径变得更容易实验。开发者可以检查项目实现，按自己的 MCP 客户端接入，并围绕特定任务补充工具和权限控制。这种透明度也比封装在闭源桌面助手里的浏览器接管更容易审计。

但从工程角度看，真实浏览器自动化仍有几个硬问题没有因为 MCP 而消失。

第一是动作可靠性。网页里的按钮可能被遮挡、延迟加载或动态重绘，模型看到的页面状态可能在执行动作前已经发生变化。一个能够偶尔完成任务的 Demo，距离可托付的生产 Agent 还有很大距离。

第二是失败恢复。Agent需要知道点击没有生效、页面跳转到登录页、弹窗阻塞了操作，还是站点触发了风控。没有明确的状态反馈和恢复策略，模型往往会重复动作，甚至在错误页面上继续执行。

第三是权限控制。MCP工具如果只提供粗粒度的“控制浏览器”能力，就很难限制 Agent只访问某个域名、只读取某个标签页或只执行无副作用动作。浏览器 Agent真正成熟的标志，不是工具数量，而是权限是否可组合、可审计、可撤销。

第四是版本兼容。Chrome、扩展、DevTools 能力、MCP 客户端和本地运行时都可能独立更新。开源项目能否长期跟上浏览器版本变化，往往比 README 中列出的功能数量更重要。对于需要稳定运行的团队，应该关注项目的提交频率、Issue响应、发布方式和回滚路径，而不只是当前能否跑通。

我们的判断：NeoBrowser值得试，但还不能把主账号交出去

NeoBrowser的方向是对的。浏览器 Agent 最有价值的上下文，本来就存在于用户正在使用的浏览器里。让模型重新启动一个空白浏览器，再要求用户反复登录，实际上是在把最关键的工作环境排除在外。复用登录态可以显著降低一次性任务的使用门槛，也让 AI 助手从“网页问答工具”更接近真正的桌面工作助手。

但它的突破更像是基础设施层的突破，而不是已经完成的终端产品。NeoBrowser解决了 Agent 如何进入真实 Chrome，却没有因此解决可信执行、细粒度授权、提示注入、敏感数据隔离和错误恢复。换句话说，它把浏览器 Agent 的上限抬高了，也把权限管理的重要性推到了台前。

对开发者而言，最合适的试用方式是从低风险、只读、可复核的任务开始：整理当前标签页、提取资料、检查页面状态、生成操作建议。对高风险动作，则应该让 Agent负责观察和准备，把最终提交留给人。

如果把传统 Playwright 比作一名严格按照施工图工作的自动化工人，那么 NeoBrowser更像一名进入真实办公室、能够看到现有文件和系统状态的助手。前者可控、稳定、适合流水线；后者灵活、贴近工作现场，但必须接受更严格的权限管理。

截至 2026 年 8 月 18 日，NeoBrowser最值得关注的不是“AI 能不能点击 Chrome”，而是一个更现实的问题：当 Agent拥有用户真实登录态之后，我们是否已经准备好用像管理软件权限一样的方式管理它？这将决定真实浏览器 Agent 是成为高效生产力工具，还是变成新的账号安全入口。

参考来源

• NeoBrowser GitHub 仓库：项目主页及其对“驱动真实 Chrome、复用登录会话”的公开说明。
• OpenChrome GitHub 仓库：同类真实 Chrome MCP 自动化项目，可用于对照浏览器控制、工具设计和并行任务思路。