browseros-ai/BrowserOS 是什么？

BrowserOS 项目包含两个产品：面向 AI 代理的 neo 和面向人类的 Chromium 分支。本文聚焦 neo，它导入你的 Chrome 登录态，让 Claude Code、Codex 等代理在独立标签页里并行操作真实网站，所有数据留在本机。

browseros-ai/BrowserOS 可以商用吗？

可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。

browseros-ai/BrowserOS 还在维护吗？

在维护。仓库最近一次提交在 1 天前。

browseros-ai/BrowserOS 是用什么编程语言写的？

主要是 TypeScript（依据 GitHub 的语言统计）。

BrowserOS neo 评测：开源代理浏览器，本地运行，导入 Chrome 登录态

Q: browseros-ai/BrowserOS 还在维护吗？

在维护。仓库最近一次提交在 1 天前。

秒懂

它是什么？: BrowserOS 项目包含两个产品：面向 AI 代理的 neo 和面向人类的 Chromium 分支。本文聚焦 neo，它导入你的 Chrome 登录态，让 Claude Code、Codex 等代理在独立标签页里并行操作真实网站，所有数据留在本机。
适合谁用？: BrowserOS neo 适合已经使用 Claude Code、Codex 或 Cursor 等代理工具、并且需要让代理操作真实登录账号的开发者。它不适合想要一个全能 AI 浏览器的人，也不适合需要无状态、可重复的 CI 环境的团队，因为它的核心卖点正是持久化的个人登录态。
能商用吗？: 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
还在维护吗？: 在维护。仓库最近一次提交在 1 天前。
用什么语言写的？: 主要是 TypeScript（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年9月10日 · browseros-ai/BrowserOS

两个浏览器，一条分界线

BrowserOS 仓库里其实有两个独立产品，README 用一句话划清界限：一个给你的代理，一个给你自己。neo 是代理专用浏览器，定位是 Chrome 旁边的第二浏览器，不是替代品。另一个 BrowserOS 则是带内置 AI 助手的 Chromium 分支，面向日常人类使用。两者共用仓库，但下载入口和文档路径不同。如果你冲着“开源 AI 浏览器”来，先想清楚要哪个，否则很容易装错。

neo 解决的真问题：登录态

Playwright 这类无头驱动会启动一个没有登录信息的全新 Chrome 子进程，适合 CI，但做不了“读我的收件箱”这种需要真实账号的任务。云浏览器跑在数据中心，Twitter 和 LinkedIn 会拦截数据中心 IP，登录体验也很痛苦。neo 的做法是在本地启动一个浏览器，一键从 Chrome 导入登录态、书签和扩展，并跨会话持久保存。它跑在 127.0.0.1 上，不是云端。这个设计直接绕开了两个痛点：无登录态的自动化等于废掉一半真实任务，数据中心 IP 则触发反爬。

它如何与代理协作

neo 不是自己内置 AI，而是连接你已有的代理。README 列出 Claude Code、Codex、Cursor、VS Code、OpenClaw、Hermes，一键连接。它通过 MCP 协议暴露浏览器能力，文档中专门有 MCP 安装面板的说明。代理拿到任务后，在 neo 的标签页里操作真实网站，你可以在新标签页的仪表盘上实时观看它正在访问哪个站点、做到哪一步。每个会话都会被保存为可拖拽的视频，附带逐步操作时间线，事后可以像回放录像一样检查代理到底干了什么。

并行与 token 消耗的取舍

neo 支持并行代理，每个代理在自己的标签页里独立工作，你可以同时发起多个任务。它声称相比 Claude 的 Chrome 扩展和 Codex 浏览器，完成同样任务消耗的 token 显著更少。这个说法没有给出具体数字，但逻辑上说得通：因为登录态和页面状态都在本地持久化，代理不需要反复重新登录或重新加载上下文。不过，并行任务意味着多个代理共享你的真实账号，如果某个代理误操作，比如发错帖子或删错邮件，后果直接落在你的正式账号上。

安装与数据存放位置

neo 提供 macOS 和 Windows 的安装包，下载链接直接指向官方 CDN。安装后第一步是从 Chrome 一键导入登录态、书签和扩展。然后它会自动发现你机器上已安装的代理工具，比如 Claude Code 或 Codex，一键连接。所有会话数据、截图和历史都存放在 ~/.browserclaw/ 目录下，README 强调这些数据“永远不会离开你的机器”。对隐私敏感的用户，这个路径设计很直接，但要注意：这意味着你的登录 cookie 以明文形式存储在本机，任何能读取该目录的进程都能拿到。

与同类产品的差异

README 明确对比了三类替代品。第一类是无头驱动，如 Playwright 和 agent-browser，它们没有登录态，适合 CI 不适合真实工作。第二类是云浏览器，如 browser-use 和 browserbase，运行在数据中心，登录困难且容易被封。第三类是锁定型 AI 浏览器，如 ChatGPT Atlas、Perplexity Comet 和 Dia，它们只支持自家的 AI。neo 的定位是避开所有这三类：本地运行、保留登录态、不绑定特定 AI。这个差异化很清晰，但也意味着它依赖你已有的代理工具链，如果你没有用任何 MCP 代理，neo 对你毫无用处。

许可证与维护成本

项目采用 AGPL-3.0 许可证。这意味着如果你修改代码并提供网络服务，必须开源修改后的源码。对于个人使用或内部工具，影响不大，但如果你想基于它构建商业产品，需要认真评估合规义务。仓库最近推送频繁，agent-server 组件在 2026 年 9 月 9 日同一天发布了 v0.0.161 和 v0.0.162 两个版本，说明迭代速度很快。快速迭代的代价是升级频率高，你需要跟上 server 和 extension 的版本匹配，否则可能出现兼容问题。文档站点 docs.browseros.com 是主要的信息来源，但 README 中部分链接指向的页面内容未在本次材料中提供。

编辑结论

BrowserOS neo 适合已经使用 Claude Code、Codex 或 Cursor 等代理工具、并且需要让代理操作真实登录账号的开发者。它不适合想要一个全能 AI 浏览器的人，也不适合需要无状态、可重复的 CI 环境的团队，因为它的核心卖点正是持久化的个人登录态。在采用前，先确认你的代理工具是否在官方支持列表内，并检查 AGPL-3.0 对你分发方式的影响。若你只想要一个带 AI 助手的日常浏览器，应关注同仓库下的 BrowserOS Chromium 分支，而不是 neo。

官方来源

社区笔记