Ocbot 是一款基于 Chromium 内核深度定制的开源 AI 原生浏览器，将 AI 智能体直接嵌入浏览器底层。核心亮点包括自愈工作流（视觉理解自动修复路径）、大模型自由切换（支持云端及本地私有化部署）、Token 消耗优化以及完整的 Chrome 体验兼容。相比 OpenClaw 等通用框架，Ocbot 更专注于浏览器自动化场景，提供对话式操作能力。适用于批量数据采集、自动填表、网页监控等场景。项目目前处于早期阶段，编译需较高硬件配置，使用时需注意合规性及网络环境。
一、为什么我们需要一款 AI 原生浏览器？
浏览器是我们日常使用频率最高的软件之一。从查资料、填表单到批量下载文件、监控网页变化，这些操作看似简单，实际上都需要大量的重复劳动。很多人可能没有意识到，自己每天在浏览器上花费的时间中，有相当大的比例是在做机械性的重复操作——打开同一个网站、点击同样的按钮、填写类似的信息、下载格式相同的文件。如果能把这些重复劳动交给 AI 来完成，我们就能把精力集中在真正需要创造力和判断力的工作上。
传统的自动化方案，比如 Selenium、Playwright，虽然功能强大，但有一个致命问题：它们依赖固定的网页元素选择器（比如 XPath、CSS Selector），一旦网站改版，脚本就会立刻失效，维护成本极高。而且编写和调试这些自动化脚本本身就需要一定的编程基础，这把大量的非技术用户挡在了门外。
近两年，随着大语言模型（LLM）技术的爆发，一种全新的思路出现了——让 AI 来理解网页，让 AI 来决定如何操作，让 AI 来执行任务。这就是所谓的"AI Agent + 浏览器"的组合。这种方案的核心优势在于：AI 不依赖固定的选择器规则，而是像人一样"看"网页、"理解"网页、然后"操作"网页。即使网页的布局和代码结构发生了变化，只要页面的视觉呈现和功能逻辑没有根本性的改变，AI 就能自适应地完成任务。这从根本上解决了传统自动化方案"一改就废"的顽疾。
目前市面上已经出现了不少类似的项目，比如 Browser-Use、Nanobrowser、BrowserOS、OpenClaw 等等。而今天我要和大家聊的 Ocbot，则是其中一个比较有特色的开源方案。
Ocbot 的核心定位非常明确：它不是给现有浏览器加一个 AI 插件，而是从 Chromium 内核层面就开始定制，把 AI 智能体运行时直接嵌入到浏览器底层。换句话说，AI 不是浏览器的附属品，而是浏览器的"灵魂"。这种设计理念带来了一个重要的优势——AI 能够直接调用浏览器内核级的 API，在页面操作、截图、表单交互等方面拥有更底层、更高效的控制能力。
要理解 Ocbot 到底能做什么，我们需要从它的几个核心能力入手。我结合官方文档和 GitHub 仓库的信息，帮大家做一个详细的梳理。
Ocbot 最直观的使用方式就是"对话式操作"。你不需要写任何代码，只需要用自然语言告诉它你想做什么，比如：
AI 会自动理解你的意图，生成一条完整的执行路径，然后一步一步地在浏览器中完成操作——打开网页、定位元素、点击按钮、填写表单、截图保存，整个过程就像你手动操作一样，但完全由 AI 来驱动。
这种能力背后的技术原理并不复杂：Ocbot 内置的 AI Agent 会先将当前网页的状态（DOM 结构 + 页面截图）发送给大语言模型，LLM 分析之后返回下一步应该执行的动作，Agent 再通过浏览器的底层接口去执行这个动作。如此循环往复，直到任务完成。这其实和 Browser-Use 等项目的核心逻辑是一致的，但 Ocbot 的优势在于它的 Agent 直接运行在浏览器内核层面，而不是作为外部插件或独立服务存在。
举一个更具体的例子来帮助大家理解这个过程。假设你告诉 Ocbot"帮我把这个页面上的产品表格数据导出来"，Agent 的工作流程大致是这样的：首先，它会对当前页面进行截图和 DOM 结构分析，识别出页面上存在一个数据表格；然后，它会制定执行计划——逐行读取表格中的每一条数据；接着，它通过内核 API 逐个提取表格单元格中的文字内容；最后，它把所有数据整理成结构化的格式（比如 CSV 或 JSON）输出给你。整个过程中，你不需要关心这个表格用的是什么前端框架，有没有动态加载，分页逻辑是什么样的——这些技术细节全部由 AI 来处理。
值得一提的是，Ocbot 的对话式自动化不仅仅支持单步操作，它还能理解和执行多步骤的复合任务。比如你可以说"先登录某某网站，然后到订单管理页面，筛选出本月的所有订单，把每个订单的编号和金额提取出来"。Agent 会自动把这个复合指令拆解成若干个子步骤，按照逻辑顺序依次执行。如果中间某个步骤遇到了意料之外的情况（比如页面弹出了一个确认对话框），Agent 也会根据上下文做出合理的判断和应对。
这是我认为 Ocbot 最有价值的一个特性。
传统的浏览器自动化脚本最怕的就是网站改版。比如你写了一个自动登录脚本，用的是 #login-button 这个选择器，结果某天网站把按钮的 ID 改成了 #btn-signin，脚本就直接报错了。而且更糟糕的是，你可能根本不知道它什么时候改的，等你发现的时候，积压的任务已经一大堆了。
Ocbot 的"自愈工作流"就是为了解决这个问题。它的核心原理是视觉理解——AI 不仅仅依赖 DOM 元素的选择器来定位操作目标，还会对页面进行截图分析。当网站改版导致原有的元素选择器失效时，AI 会通过视觉识别重新找到对应的按钮、输入框或链接，并自动更新执行路径。
具体来说，这个过程包含以下几个关键步骤：
第一步，AI 在首次执行任务时，会同时记录 DOM 选择器和视觉特征（元素的位置、颜色、文字、大小等）。第二步，当后续执行任务时，如果 DOM 选择器定位失败，AI 会切换到视觉模式，通过截图分析重新定位目标元素。第三步，AI 根据视觉识别的结果自动修复执行路径，并将新的选择器信息更新到任务配置中，以备下次使用。
这种"DOM + 视觉"的双模式定位策略，让 Ocbot 的自动化任务具备了很强的鲁棒性。用官方的话说就是"学一次，长期复用"——你只需要教 AI 执行一次任务，后续即使网站发生了 UI 变化，AI 也能自动适应。
从自动化测试领域的视角来看，这种"自愈"能力并不是什么全新的概念。在自动化测试（QA Automation）领域，Self-Healing Test 已经是一个比较成熟的方向了，像 Testim、Mabl 等商业工具都有类似的功能。但 Ocbot 把这个能力带到了通用的浏览器自动化场景中，而且是开源的，这一点值得关注。
为了更直观地理解自愈机制的价值，我举一个真实场景：假如你让 Ocbot 学习了一个"每天自动登录公司后台系统并下载日报数据"的任务。某天，后台系统进行了一次界面升级，登录页面的布局从左右两栏变成了上下单栏，"登录"按钮的 CSS 类名从 .btn-login 改成了 .submit-button，按钮的位置也从页面右侧移到了页面中间。如果是传统的自动化脚本，这时候就直接报错停止了。但 Ocbot 的 Agent 会这样处理：它先尝试用原来的选择器去定位登录按钮，发现找不到了；然后它启动视觉分析模式，对当前页面截一张图，发送给大模型进行视觉理解；大模型通过分析截图，识别出页面中间有一个蓝色的"登录"按钮（虽然位置和样式都变了，但文字和功能没变）；最后 Agent 重新定位到这个按钮，更新执行路径中的选择器信息，继续完成后续步骤。整个修复过程对用户来说是完全透明的，你甚至不会感知到后台发生了什么——任务照常完成，数据照常下载。
这种能力在实际工作中的价值是巨大的。特别是在需要长期运行的自动化任务场景中，网站的小改版几乎是不可避免的。有了自愈机制，你不需要时刻盯着脚本是否正常运行，也不需要每次网站更新后都手动去修改脚本——AI 会自己搞定。
Ocbot 在 AI 推理层面采用了灵活的架构设计。用户可以根据自己的需求和偏好，自由选择不同的大模型作为 AI Agent 的"大脑"：
这种设计在隐私保护方面有着明显的优势。如果你处理的是敏感数据（比如公司内部的文档、财务信息等），完全可以选择本地部署的大模型，确保数据不出设备。这对于企业用户来说是一个非常重要的考量因素。
使用 AI 驱动浏览器自动化，最大的成本就是 LLM 的 Token 消耗。每次执行任务，Agent 都需要把当前页面的状态发送给大模型进行分析和决策，这个过程会消耗大量的 Token。如果是高频重复任务，Token 费用会迅速累积。
Ocbot 在这方面做了一个巧妙的优化：任务在首次执行时，AI 会完整地分析和规划整个执行路径，这个过程确实需要消耗较多的 Token。但一旦路径确定下来，后续执行同样的任务时，Agent 会直接复用已经学到的路径，大幅减少对 LLM 的调用次数。 只有当路径中某个步骤执行失败（比如遇到了网站改版），才会触发自愈机制，重新调用 LLM 进行修复。
这个优化策略让 Ocbot 在长期使用中的 Token 消耗远低于那些"每次都从头分析"的方案。对于需要频繁执行重复任务的用户来说，这是一个很实际的优势。
虽然 Ocbot 是一个深度定制的浏览器，但它在日常使用体验上和 Chrome 几乎没有区别。因为它的底层就是 Chromium，所以你可以：
换句话说，你可以把 Ocbot 当作一个"加了 AI 超能力的 Chrome"来用，日常浏览完全不受影响。
提到 AI Agent 自动化工具，OpenClaw（也叫 Molty）是目前开源社区中热度最高的项目之一。它在 GitHub 上已经积累了超过 6.8 万个 Star，社区非常活跃。那么 Ocbot 和 OpenClaw 之间到底有什么区别呢？我帮大家做一个客观的对比分析。
OpenClaw 的定位是一个通用的 AI Agent 框架。它本质上是一个运行在 Node.js 上的本地服务，通过消息路由的方式连接各种聊天平台（比如 Telegram、WhatsApp），然后调用各种工具（Shell 命令、浏览器控制、文件操作等）来完成任务。浏览器自动化只是它众多能力中的一项。
Ocbot 的定位则更加垂直和聚焦——它就是一个 AI 原生浏览器。所有的设计和优化都围绕"浏览器 + AI"这个核心场景展开。浏览器本身就是 AI Agent 的运行环境，不需要额外的服务或中间件。
OpenClaw 的部署过程涉及 Node.js 环境配置、各种 API Key 设置、消息平台对接等多个环节，对于非技术用户来说有一定的门槛。特别是浏览器自动化功能，还需要额外配置 Chromium 浏览器的 CDP（Chrome DevTools Protocol）连接，在某些系统环境下（比如 Ubuntu 的 Snap 版 Chromium）还会遇到兼容性问题。
Ocbot 在这方面要简单得多——下载安装包，双击运行，就是一个可以用的浏览器。AI 功能开箱即用，不需要额外的环境配置。这对于非技术背景的用户来说是一个巨大的优势——你不需要理解什么是 Node.js，不需要在命令行中敲各种配置命令，甚至不需要知道 API Key 是什么（如果使用官方推理网关的话）。对于技术团队来说，这也意味着更低的推广和培训成本——你可以把 Ocbot 直接推荐给运营、市场、行政等非技术岗位的同事使用，他们也能快速上手。当然，如果你想要从源码编译，那复杂度就上去了（后面会详细说）。
OpenClaw 的能力范围更广，除了浏览器操作，它还能执行 Shell 命令、管理文件、对接智能家居、管理日程等等。它更像是一个"全能型 AI 助手"。
Ocbot 的能力则集中在浏览器场景，但在这个场景中做得更深入。比如它的自愈工作流、Token 优化机制、内核级 API 调用等，都是针对浏览器自动化场景的专项优化。可以这样理解——OpenClaw 是一把多功能的瑞士军刀，什么都能干一点；Ocbot 则是一把专业的手术刀，只在浏览器这个领域发力，但做得更精细、更深入。两者的设计哲学不同，面向的用户群体也有所差异，不存在简单的优劣之分。
简单来说：如果你需要一个全方位的 AI Agent 助手，能管文件、跑脚本、对接各种工具和平台，选 OpenClaw 更合适。如果你的核心需求就是浏览器自动化——自动填表、数据抓取、网页监控、批量操作等，Ocbot 可能是更轻量、更聚焦的选择。
当然，两者也不是完全互斥的。你完全可以把 Ocbot 作为日常浏览器使用，同时在需要更复杂的跨平台自动化时借助 OpenClaw。
了解了 Ocbot 的核心能力，我们来深入看看它的技术架构是怎么设计的。对于开发者来说，理解架构是评估一个项目质量和可扩展性的关键。我结合源码目录结构和官方文档，为大家做一个分层拆解。
Ocbot 采用了分层 + 模块化的架构设计，整体可以分为四层：
┌─────────────────────────────────────────────┐
│ 扩展层 (web/) │
│ AI Agent 运行时 / 浏览器交互 UI / Side Panel │
├─────────────────────────────────────────────┤
│ 内核层 (chromium/) │
│ Chromium 定制内核 / 补丁机制 / 内核级 API │
├─────────────────────────────────────────────┤
│ 工具链层 (scripts/) │
│ 编译工具 / 开发辅助 / 自动化脚本 │
├─────────────────────────────────────────────┤
│ 能力集成层 │
│ 链上身份 / 支付协议 / 标准化接口 │
└─────────────────────────────────────────────┘
项目的源码目录结构清晰地映射了这个分层设计：
ocbot/
├── chromium/ # Chromium 内核定制相关（补丁文件等）
├── web/ # AI 扩展层（Agent 运行时 + 浏览器 UI）
├── scripts/ # 开发工具链（dev.py 等构建脚本）
├── patches/ # 生成的 Chromium 内核补丁
├── plans/ # 功能计划文件（开发路线图）
├── docs/ # 开发文档
├── LICENSE # 开源协议
├── README.md # 英文说明
└── README_CN.md # 中文说明
内核层是整个浏览器的基础底座，基于 Chromium 开源项目进行定制。这一层主要用 C++ 编写，使用 Chromium 官方的编译工具链（Depot Tools）进行构建。
内核层的核心设计原则是"无损定制"——仅通过补丁（Patch）机制新增或修改必要的功能点，尽量不破坏 Chromium 的原生逻辑。这样做有两个好处：第一，能够保证 Chrome 的全量浏览体验（渲染引擎、JavaScript 引擎、安全机制等）完整保留；第二，当 Chromium 上游发布新版本时，可以相对容易地将补丁应用到新版本上，降低版本跟进的维护成本。
内核层对上层 AI 扩展层提供了一组关键的底层 API，主要包括：
这些接口和 Chrome DevTools Protocol（CDP）提供的能力类似，但由于是直接在内核层面暴露的，执行效率和稳定性会更高。
扩展层是 Ocbot 的差异化核心，对应源码中的 web/ 目录。这一层使用 TypeScript 作为主要开发语言，基于 wxt（一个现代化的浏览器扩展开发框架）构建。
扩展层承载了以下几个关键模块：
AI Agent 运行时：这是整个 AI 能力的核心。Agent 运行时负责管理任务的生命周期——从接收用户指令、解析意图、规划执行路径，到逐步执行操作、监控执行结果、处理异常情况，整个流程都由这个模块协调。
LLM 推理模块：负责和各种大语言模型进行通信。这个模块封装了统一的调用接口，无论你使用的是 OpenAI 的 GPT-4、Google 的 Gemini、Anthropic 的 Claude，还是本地通过 Ollama 运行的开源模型，对上层的 Agent 来说调用方式都是一样的。
浏览器交互 UI：Ocbot 在浏览器的侧边栏（Side Panel）中提供了一个交互界面，用户可以在这里输入自然语言指令、查看任务执行进度、管理已保存的工作流等。
视觉分析模块：负责对页面截图进行分析，提取页面的视觉布局信息。这个模块是"自愈工作流"能力的技术基础。当 DOM 选择器失效时，视觉分析模块会接管元素定位的工作。
扩展层和内核层之间通过浏览器扩展的标准接口进行通信，保持了良好的解耦性。这意味着扩展层可以独立迭代升级，而不需要每次都重新编译 Chromium 内核。
对应源码中的 scripts/ 目录，使用 Python 3 作为主要脚本语言。这一层的核心是一个叫做 dev.py 的开发辅助工具，它封装了 Chromium 编译、补丁管理、扩展构建等一系列复杂的操作流程，让开发者可以通过简单的命令来完成这些工作：
# 检查开发环境是否就绪
./scripts/dev.py check
# 下载 Chromium 源码
./scripts/dev.py download
# 应用 Ocbot 的定制补丁
./scripts/dev.py patch
# 编译整个项目
./scripts/dev.py build
# 运行编译好的浏览器
./scripts/dev.py run
如果你有过从源码编译 Chromium 的经验，就会知道这个过程有多么复杂。Ocbot 的工具链层把这些复杂性封装了起来，虽然编译本身仍然需要较长的时间和较高的硬件配置，但操作流程已经简化了很多。
能力集成层是 Ocbot 架构中比较前瞻性的一部分。它主要包含了链上身份标识和标准化协议接口等能力。简单来说，就是让 AI Agent 能够拥有自己的数字身份，并通过标准化的协议接口与外部服务进行交互。
这一层目前还在比较早期的阶段，更多的是架构预留和概念验证，实际的落地应用还需要时间。但从架构设计的角度来看，把这些能力作为独立的集成层来设计，通过标准化接口接入，是一个合理且可扩展的方案。
了解了原理，接下来我们进入实操环节。Ocbot 提供了两种使用方式：直接下载预编译安装包（适合普通用户）和从源码编译（适合开发者）。我分别为大家讲解。
这是最简单的方式，不需要任何开发环境，下载即用。
Ocbot 目前提供了 macOS 和 Windows 两个平台的预编译安装包。根据 GitHub 仓库的信息，最新版本为 26.3.18，下载地址如下：
⚠️ 版本提示：上述版本号为文章撰写时的最新版本，建议大家在下载前先到 GitHub 仓库（ https://github.com/instry/ocbot ）的 Releases 页面确认是否有更新版本。
macOS 安装步骤：
下载 .dmg 文件后，双击打开镜像文件，将 Ocbot 图标拖拽到"应用程序"文件夹即可。首次打开时，macOS 可能会提示"无法验证开发者"，这时需要到"系统设置 → 隐私与安全性"中点击"仍要打开"。
Windows 安装步骤：
下载 .exe 安装程序后，双击运行，按照安装向导的提示一步步操作即可。安装完成后桌面上会生成 Ocbot 的快捷方式图标。
安装完成后，打开 Ocbot，你会看到一个和 Chrome 非常相似的界面。在侧边栏可以找到 AI Agent 的交互面板，输入你的第一条指令就可以开始体验了。
如果你是开发者，想要深入研究 Ocbot 的源码，或者想要基于它进行二次开发，就需要从源码编译。这个过程比较耗时，需要一定的开发环境和硬件配置。
前置依赖：
完整构建流程：
# 第一步：克隆代码仓库
git clone https://github.com/instry/ocbot.git
cd ocbot
# 第二步：检查开发环境
# 这个命令会自动检测你的系统是否满足编译要求
./scripts/dev.py check
# 第三步：下载 Chromium 源码
# 快速模式（仅用于代码审阅，不能编译）：
./scripts/dev.py download
# 完整模式（用于实际编译构建）：
./scripts/dev.py download --method depot --no-history
# 第四步：应用 Ocbot 的定制补丁
# 这一步会将 Ocbot 的修改应用到 Chromium 源码上
./scripts/dev.py patch
# 第五步：编译（最耗时的一步）
./scripts/dev.py build
# 第六步：运行编译好的浏览器
./scripts/dev.py run
关于编译时间的参考：
编译 Chromium 是一个非常吃资源的操作，实际编译时间取决于你的硬件配置：
如果你使用的是普通的台式机或者笔记本，编译时间可能会更长。建议至少准备 16GB 以上的内存和较大的磁盘空间（Chromium 源码加上编译产物可能需要 50GB 以上的磁盘空间）。
关于 download 命令的两种模式：
./scripts/dev.py download 默认使用快速的 tarball 模式下载，下载速度快，但只能用于查看代码，不能用于编译。如果你需要实际编译，必须使用 --method depot 参数，通过 Depot Tools 下载完整的 Chromium 源码树。--no-history 参数可以跳过 Git 历史记录的下载，节省大量的时间和磁盘空间。
无论是通过安装包还是源码编译的方式运行 Ocbot，第一次使用 AI 功能都需要配置大模型的连接方式。Ocbot 提供了三种选择：
选择一：使用 Ocbot 推理网关（最简单）
这是官方提供的零配置方案，无需任何 API Key，开箱即用。适合想要快速体验的用户。不过需要注意的是，使用推理网关意味着你的请求会经过 Ocbot 的服务器进行中转。
选择二：使用自己的 API Key
如果你已经有了 OpenAI、Google 或 Anthropic 的 API Key，可以在设置中直接填入。这样 Agent 的推理请求会直接发送到对应的模型服务商，不经过 Ocbot 的服务器。这种方式的好处是你可以完全控制调用哪个模型、用多少额度，而且数据传输路径更短、更透明。对于有一定技术基础的用户，我推荐优先使用这种方式，一方面可以自主选择最适合你任务的模型（比如简单任务用便宜的小模型，复杂任务用性能更强的大模型），另一方面也能更清楚地掌握自己的使用量和费用情况。
选择三：使用本地大模型
如果你对数据隐私有较高的要求，可以通过 Ollama 等工具在本地运行大模型（比如 Llama、Qwen 等开源模型），然后将 Ocbot 连接到本地的模型服务。这样所有的数据处理都在你自己的设备上完成，完全不需要联网。本地部署的方案特别适合以下几类用户：处理涉及商业秘密或个人隐私数据的场景、网络环境受限或者网络不稳定的场景、以及对 AI 推理延迟要求较高的场景（本地推理不受网络延迟影响）。不过需要注意的是，本地运行大模型对硬件配置有一定要求，建议至少配备 16GB 以上的内存和一块性能不错的显卡。如果你的硬件配置较低，可以选择参数量较小的模型（比如 7B 或 14B 级别的模型），虽然能力会弱一些，但基本的浏览器自动化任务还是能够胜任的。
理论讲得再多，不如看看实际能用来做什么。以下是一些 Ocbot 比较典型的应用场景，我为大家逐一分析。
假设你需要从某个电商平台上采集一批商品信息（名称、价格、评分、销量等），传统做法是写爬虫脚本或者用 RPA 工具。但用 Ocbot，你只需要这样做：
打开目标网页，在 AI 面板中输入类似"提取这个页面上所有商品的名称、价格和评分，整理成表格"的指令。AI Agent 会自动识别页面结构，定位到商品列表区域，逐条提取数据并整理输出。如果数据分布在多个页面，你还可以告诉它"翻到下一页继续提取"，Agent 会自动找到翻页按钮并继续操作。
和传统爬虫相比，这种方式最大的优势在于零代码门槛。你不需要学习 Python，不需要了解 CSS 选择器或 XPath 语法，也不需要处理反爬机制——因为你用的就是一个正常的浏览器，只不过操作它的"手"从你自己变成了 AI。而且，即使目标网站更新了页面结构，自愈机制也能让你的采集任务继续正常运行，不用像传统爬虫那样频繁地去调试和修改选择器。
当然，我也要提醒大家注意合规问题。在进行数据采集时，一定要遵守目标网站的使用条款，尊重 robots.txt 协议，不要频繁大量地请求目标网站导致给对方服务器带来压力。合理、适度地使用自动化工具，才是长久之计。
这是很多行政和运营人员的日常痛点——需要在多个系统中重复填写类似的表单信息。比如每天需要在 OA 系统中提交日报，或者在供应商管理平台上录入采购信息。又比如电商运营人员需要在不同的平台上重复上传商品信息，每次都要填写标题、描述、价格、库存、图片等字段，非常耗时。
用 Ocbot，你可以把"填报日报"这个任务教给 AI 一次：打开 OA 系统，找到日报提交入口，填写各个字段，点击提交。之后每天只需要告诉 AI"帮我提交今天的日报，内容是……"，它就会自动完成整个操作流程。而且得益于自愈机制，即使 OA 系统做了界面升级，已经学习过的工作流也能自动适应。
这里有一个关键的技术细节值得说明：Ocbot 在执行表单填写任务时，不仅仅是简单的"找到输入框然后粘贴文字"。它的 Agent 会理解每个表单字段的语义含义，比如它能区分"项目名称"和"项目编号"这两个输入框分别应该填什么内容，即使这两个字段在页面上的视觉布局发生了变化（比如从横排变成了竖排），Agent 也能正确地把信息填到对应的位置。这种语义级别的理解能力，是传统 RPA 工具（基于固定坐标或选择器的）所不具备的。
需要持续监控某个网页的内容变化？比如监控竞品的价格变动、追踪某个政策文件的更新、关注某个论坛帖子的新回复等。Ocbot 可以定期访问目标页面，提取关键信息并与上次的结果进行对比，发现变化后及时提醒你。
这个场景在实际工作中的应用非常广泛。比如做竞品分析的同学，需要持续追踪竞品官网上的产品定价和功能更新；做市场研究的同学，需要关注行业报告网站上的新发布内容；做采购的同学，需要监控供应商平台上的物料价格波动。这些工作如果纯靠人力去每天手动检查，不仅效率低，而且很容易遗漏。用 Ocbot 设置一个自动化的监控任务，定时去目标页面看一眼，有变化就记录下来通知你，省时省力又不会漏掉关键信息。
更进阶的玩法是结合条件触发。比如你可以设定"当某个商品的价格低于某个阈值时通知我"，或者"当某个政策文件更新后，自动把新版本的关键段落提取出来发给我"。这种基于条件的智能监控，能让你从繁琐的手动检查中彻底解放出来。
如果你需要从多个网站收集信息并汇总到一起，比如从不同的招聘网站上汇总同一个岗位的市场行情，或者从多个新闻网站收集某个话题的报道进行对比分析，Ocbot 可以按照你的指令依次访问多个网站，提取相关信息，最后整理成统一的格式输出。
这种跨平台的信息整合能力，在日常工作中的价值远比想象中大。举个例子，你正在调研某个技术方案，需要从官方文档、技术博客、论坛讨论、GitHub 仓库等多个来源收集信息。以前你需要逐个打开这些网站，手动复制粘贴关键信息，然后在文档中整理归纳。现在你只需要给 Ocbot 下达一条指令，告诉它你需要哪些方面的信息、从哪些网站获取，它就能自动完成整个收集和整理的过程。虽然最终的分析判断仍然需要你自己来做，但前期的信息收集工作量可以大幅减少。
根据官方介绍，Ocbot 还支持通过 Telegram、WhatsApp 等即时通讯工具远程发送指令。也就是说，即使你不在电脑前，也可以通过手机向运行在家里或办公室电脑上的 Ocbot 发送命令，让它帮你完成一些浏览器操作。不需要 VPN，不需要远程桌面软件，只要一条消息就行。
这个功能在一些特定场景中会非常实用。比如你正在外面参加会议，突然想起来忘记从某个网站下载一份重要的报告了。这时你只需要掏出手机，给 Ocbot 发一条消息"帮我登录某某平台，下载今天的数据报告"，它就会在你办公室的电脑上自动完成操作。等你回到办公室时，文件已经下载好了，等着你去查看。
又比如，你在家里的电脑上设置了一个定时监控任务，突然需要临时修改监控参数（比如调整价格阈值），这时候也可以直接通过手机发送修改指令，不需要专门回到电脑前操作。
不过需要注意的是，远程操作功能意味着你的电脑需要保持开机和联网状态，而且 Ocbot 需要保持运行。如果你的电脑进入了休眠状态或者网络断开了，远程指令就无法执行了。建议需要长期运行远程任务的用户，在电源管理设置中关闭自动休眠功能，并确保网络连接的稳定性。
为了帮助大家更深入地理解 Ocbot 背后的技术逻辑，我在这里展开讲一下 AI Agent 驱动浏览器的通用技术原理。这不仅适用于 Ocbot，对理解整个 AI 浏览器自动化赛道都有帮助。
AI Agent 驱动浏览器的核心是一个不断重复的"感知 - 决策 - 执行"循环：
┌──────────────────────────────────────────┐
│ │
│ 用户下达任务指令 │
│ │
│ ▼ │
│ ┌──────────┐ │
│ │ 感知阶段 │ ◄─── 获取页面状态 │
│ (DOM+ 截图) │ (DOM 树 + 截图) │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ 决策阶段 │ ◄─── LLM 分析并决定 │
│ (LLM) │ 下一步动作 │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ 执行阶段 │ ◄─── 通过浏览器 API │
│ (Browser) │ 执行操作 │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ 任务完成？──否──→ 回到感知阶段 │
│ │ │
│ 是 │
│ ▼ │
│ 输出执行结果 │
│ │
└──────────────────────────────────────────┘
感知阶段：Agent 通过两种方式获取当前页面的状态信息。一是提取 DOM 树的结构化数据，包括页面上所有可交互元素（按钮、链接、输入框等）的位置、属性和文本内容；二是对页面进行截图，生成视觉快照。这两种信息会一起发送给 LLM 进行分析。
决策阶段：LLM 接收到页面状态信息后，结合用户的任务指令和之前的操作历史，分析当前应该执行什么动作。比如"点击'登录'按钮""在用户名输入框中输入 xxx""向下滚动 500 像素"等。LLM 的输出是一个结构化的动作指令。
执行阶段：Agent 解析 LLM 返回的动作指令，通过浏览器底层 API（如 CDP 协议或直接的内核 API）在页面上执行对应的操作。执行完成后，Agent 会检查操作是否成功，如果成功则进入下一轮循环，如果失败则可能需要重试或调整策略。
这个循环会一直持续，直到 LLM 判断任务已经完成，或者达到了预设的最大步骤数。
在感知阶段，仅依赖 DOM 选择器来定位元素存在明显的局限性：网页的 DOM 结构是动态的，同一个按钮在不同时间可能有完全不同的 ID、Class 或 XPath。
因此，现代的 AI 浏览器自动化方案普遍采用了"DOM + Vision"双模式定位策略：
DOM 模式的优势在于精确和高效。当选择器能够正确匹配时，DOM 定位的速度非常快，而且可以获取元素的精确属性信息（比如是否可点击、是否可见、当前值是什么等）。
Vision 模式的优势在于鲁棒性。即使 DOM 结构完全变化了，只要按钮的视觉外观没有发生根本性的改变（比如仍然是一个蓝色的"提交"按钮，只是位置挪了一下），AI 通过视觉识别仍然能够找到它。视觉模式的工作原理是这样的：Agent 对当前页面截一张完整的截图，然后将这张截图连同任务描述一起发送给多模态大模型（支持图片理解的大模型，比如 GPT-4 的视觉版本或者 Gemini 等）。大模型会分析截图中的视觉元素，找到和任务描述匹配的目标元素，并返回该元素在页面中的位置坐标。Agent 再根据这个坐标去执行点击或其他操作。这种方式的准确率在很大程度上取决于底层大模型的视觉理解能力——模型越强，识别越准确。
Ocbot 的做法是以 DOM 模式为主、Vision 模式为辅：正常情况下使用 DOM 选择器定位元素（效率更高），当 DOM 定位失败时自动切换到 Vision 模式进行兜底。这就是"自愈"能力的技术基础。
前面提到了 Ocbot 的 Token 优化策略：首次执行任务时完整分析，后续执行时复用已学习的路径。这里展开说一下这个机制的技术细节。
当 AI Agent 首次完成一个任务后，整个执行过程中的每一步操作都会被记录下来，形成一条"执行路径"。这条路径包含了每一步的动作类型（点击、输入、滚动等）、目标元素的定位信息（选择器 + 视觉特征）、以及操作的参数（输入的文本、滚动的距离等）。
当用户下次触发同样的任务时，Agent 不再需要从头调用 LLM 来规划每一步，而是直接按照已保存的路径执行。只有当某一步执行失败时，Agent 才会重新调用 LLM 来分析当前页面状态，修复失败的步骤，并更新路径记录。
这种"记录 → 复用 → 按需修复"的策略，既保证了执行的可靠性，又大幅降低了重复执行时的 LLM 调用成本。
除了前面和 OpenClaw 的对比之外，我再帮大家梳理一下 Ocbot 在整个 AI 浏览器自动化赛道中的位置。
Browser-Use：这是目前最流行的开源 AI 浏览器自动化库之一，基于 Python 开发，使用 Playwright 作为底层浏览器驱动。它的定位是一个库/框架，需要开发者写代码来使用。优点是灵活性高、社区活跃、支持的模型多；缺点是需要编程能力，不适合非技术用户。如果你是 Python 开发者，并且需要将浏览器自动化能力集成到自己的项目中，Browser-Use 是一个非常成熟的选择。它的多 Agent 协作机制也比较完善——一个 Planner Agent 负责任务规划，一个 Navigator Agent 负责实际的页面操作，各司其职。
BrowserOS：这是另一个开源的 AI 原生浏览器项目，同样基于 Chromium 开发。和 Ocbot 的定位比较接近，都是将 AI Agent 直接嵌入浏览器。BrowserOS 的特色是强调隐私保护（所有操作都在本地），支持的工具集成比较丰富（Gmail、Slack、Notion 等四十多种应用集成）。它目前已经支持 macOS、Windows 和 Linux 三个平台，平台覆盖面比 Ocbot 更广。BrowserOS 的社区也比较活跃，有专门的 Discord 社区用于交流。
Nanobrowser：以 Chrome 扩展的形式存在，不需要安装独立的浏览器。优点是安装简单、和现有浏览器无缝集成，可以直接从 Chrome 网上应用店安装；缺点是作为扩展的权限和能力不如独立浏览器，某些底层操作可能受限。对于不想更换日常浏览器、只是偶尔需要自动化功能的用户来说，Nanobrowser 是一个轻量级的选择。它也支持为不同的 Agent 角色配置不同的大模型，实现成本和性能的灵活平衡。
Skyvern：主要面向企业级的浏览器自动化场景，强调对陌生网站的适应能力（不需要预先配置选择器）。提供了商业化的云服务版本，也有开源的自部署版本。Skyvern 的技术特点是完全基于视觉理解来进行元素定位和操作，不依赖 DOM 选择器。这种纯视觉的方案在面对完全陌生的网站时表现更好，但在执行效率上可能不如 DOM + Vision 混合方案。
从这些对比中可以看出，Ocbot 的差异化特征主要体现在三个方面：一是自愈工作流的路径复用机制对 Token 消耗的优化，二是内核级的深度定制而非扩展/插件模式，三是对多种 LLM（包括本地模型）的灵活支持。不过也需要客观地说，Ocbot 作为一个相对较新的项目（GitHub 上目前有 14 个 Star 和 229 次提交），社区规模和生态成熟度还远不及 Browser-Use 或 OpenClaw 等项目，这是选型时需要考虑的因素。
如果你对 Ocbot 的技术方案感兴趣，想要参与到项目的开发中，这里提供一些入门指引。
Ocbot 对 Chromium 的定制主要通过补丁机制实现。在项目的 patches/ 目录下，存放着所有的补丁文件。这些补丁会在执行 ./scripts/dev.py patch 命令时自动应用到 Chromium 源码上。
如果你想要新增一个内核层面的功能，大致流程是：先在 Chromium 源码中进行修改和调试，确认修改可以正常工作后，通过 ./scripts/dev.py 工具将修改导出为补丁文件，提交到 Ocbot 仓库中。
相比内核层的开发，扩展层的开发门槛要低得多。web/ 目录下是一个标准的 TypeScript 项目，使用 wxt 框架进行开发。如果你熟悉前端开发和浏览器扩展开发，可以直接在这个目录下进行修改。
扩展层的构建会在执行 ./scripts/dev.py build 时自动完成，也可以单独进入 web/ 目录运行 npm 相关命令进行独立开发和调试。
Ocbot 的项目管理采用了一种叫做"计划驱动开发"（Plan-Driven Development）的工程规范。在 plans/ 目录下，每个功能特性都有一个对应的计划文件，详细描述了这个功能的目标、设计方案、实现步骤和验收标准。这种做法让项目的开发过程更加透明和可追溯，也方便新加入的贡献者快速了解项目的当前状态和发展方向。
如果你计划从源码编译 Ocbot，以下是一些实用的环境配置建议：
对于 macOS 用户，推荐使用 Apple Silicon 芯片的 Mac（M 系列），编译速度会比 Intel 芯片快很多。内存至少 16GB，推荐 32GB 以上。磁盘空间至少预留 100GB（Chromium 源码 + 编译产物）。
对于 Linux 用户，推荐使用 Ubuntu 22.04 或更高版本。确保系统安装了编译 Chromium 所需的各种依赖包，可以参考 Chromium 官方的构建文档。在 Linux 上编译的一个常见问题是依赖库版本不匹配，建议在一个干净的系统环境中进行编译，避免因为已有的开发环境中存在版本冲突而导致编译失败。如果你使用的是云服务器，建议选择至少 8 核 32GB 内存的配置，磁盘类型选择 SSD 以加快编译过程中的文件读写速度。
Windows 用户需要注意，Ocbot 的开发团队目前尚未对 Windows 平台进行完整的测试，可能会遇到一些兼容性问题。如果你一定要在 Windows 上编译，建议使用 WSL2（Windows Subsystem for Linux）环境。
我在这里也想坦诚地提一些需要注意的点，帮助大家做出更理性的判断。
第一，项目成熟度。Ocbot 目前还处于比较早期的阶段，GitHub 上的 Star 数量不多，社区规模较小。这意味着你可能会遇到一些 Bug 或者不完善的功能，而且获取社区支持的渠道相对有限。如果你需要一个生产级别的稳定方案，可能需要再观望一段时间。
第二，硬件要求。如果你选择从源码编译，对硬件配置的要求是比较高的。编译 Chromium 需要大量的内存和磁盘空间，编译时间也很长。普通用户建议直接使用预编译安装包。
第三，模型选择的影响。AI Agent 的执行效果很大程度上取决于底层大模型的能力。使用更强大的模型（如 GPT-4、Claude）通常会获得更好的任务理解和执行效果，但 API 调用成本也更高。使用本地的开源模型虽然免费，但在复杂任务的处理能力上可能不及商业模型。这需要根据自己的实际需求和预算来权衡。
第四，自动化操作的边界。虽然 AI Agent 能够自动操作浏览器，但它并不是万能的。对于需要复杂判断、多步骤跨页面操作、或者涉及验证码/双重认证的场景，Agent 的成功率可能会降低。建议从简单的任务开始，逐步尝试更复杂的场景。另外，某些高度动态的页面（比如大量使用 Canvas 渲染的可视化图表、复杂的拖拽交互界面等）对 AI Agent 来说也是有难度的，因为这些元素在 DOM 中可能没有清晰的结构化信息，视觉识别的准确率也可能不够高。遇到这类场景，建议拆分任务，把 AI 能做好的部分交给 AI，把需要人工判断的部分留给自己。
第五，合规使用。使用 AI 自动化工具操作网站时，务必遵守目标网站的服务条款和 robots.txt 规则。不要用来做恶意爬取、大规模自动注册、刷量等违规操作，这些行为可能违反相关法律法规。在国内使用时，还需要特别注意《网络安全法》和《数据安全法》的相关规定，确保数据采集和使用的合法合规。
第六，网络环境的影响。由于 Ocbot 的 AI 推理依赖大语言模型的 API 调用，如果你使用的是云端模型，网络环境的稳定性会直接影响 Agent 的执行效率。在网络延迟较高或者不稳定的情况下，Agent 的响应速度会变慢，甚至可能出现超时错误。如果你的网络环境不太理想，建议优先考虑使用本地大模型方案，虽然模型能力可能稍弱一些，但执行的稳定性会好很多。
站在 2026 年这个时间节点来看，AI 原生浏览器正在成为一个越来越重要的赛道。从 OpenAI 推出的 ChatGPT Atlas，到 Perplexity 的 Comet，再到各种开源项目的涌现，"让 AI 来操作浏览器"这件事已经从概念走向了现实。
回顾一下整篇文章的核心要点：Ocbot 是一款基于 Chromium 深度定制的 AI 原生浏览器，采用了分层模块化的架构设计，将 AI 智能体运行时直接嵌入浏览器内核。它最核心的技术亮点是"自愈工作流"——通过 DOM 和视觉识别的双模式定位策略，让自动化任务能够在网站改版后自动修复执行路径。同时，它的"一次学习、长期复用"机制有效地降低了重复执行任务时的大模型调用成本。在模型支持方面，它提供了云端模型、本地模型和官方推理网关三种选择，兼顾了灵活性和隐私保护的需求。
Ocbot 作为这个赛道中的一个开源方案，有着清晰的设计理念和扎实的技术架构。虽然在社区规模和功能完善度上还有提升空间，但作为一个开源项目，它提供了一个很好的学习和实践平台。对于想要了解 AI 浏览器自动化技术原理的开发者来说，阅读 Ocbot 的源码——特别是 web/ 目录下的 Agent 运行时代码和 chromium/ 目录下的内核补丁文件——是一个很好的学习路径。
展望未来，AI 原生浏览器的发展趋势可能会朝着几个方向演进：一是 Agent 的执行能力会越来越强，能够处理更加复杂和多样化的网页操作场景；二是大模型的推理成本会持续下降，让 AI 驱动的自动化任务在经济上更加可行；三是隐私和安全方面的技术方案会更加成熟，让用户在享受 AI 便利的同时不必担心数据泄露的风险；四是不同的 AI 浏览器工具之间可能会形成标准化的协议和接口，让生态更加开放和互通。
如果你是一个对 AI 自动化感兴趣的开发者，Ocbot 的代码质量和架构设计值得一看。如果你是一个想要提升工作效率的普通用户，可以先下载预编译包体验一下，感受一下 AI 原生浏览器的魅力。无论你处于哪个技术水平，理解"AI 驱动浏览器自动化"这个方向的底层逻辑和发展趋势，对于把握未来的技术浪潮都会有所帮助。
以上就是我为大家带来的 Ocbot 详细解读。
相关资源汇总：
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML 转 Markdown 互为补充。 在线工具，Markdown 转 HTML在线工具，online
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML 转 Markdown在线工具，online