浏览器自动化并不是新技术。Selenium、Playwright 已经可以稳定完成网页访问、元素定位、表单填写和数据抓取，但它们解决问题的基本方式没有改变：开发者先确定操作流程，再让程序严格执行。打开哪个页面、点击哪个按钮、读取哪个字段，最终都要落实成代码。

Browser Agent 改变的是这一层。

现在可以直接给 AI 一个目标，例如：

检查今天退款金额超过 500 元的订单，把订单号、退款金额和退款原因整理出来。

至于从哪里进入订单管理、怎么找到退款页面、是否需要打开订单详情，可以由 Agent 根据实际页面决定。

这项能力本身已经不稀奇。以 Codex 为例，截至 2026 年 9 月，OpenAI 官方已经支持通过 Chrome 扩展使用现有 Chrome Profile、登录 Session、标签页和扩展。换句话说，专业 Agent 已经可以进入真实的登录环境处理网页任务。

既然如此，为什么还要用 Python + Browser Use 再做一个数字员工？（本文不对Browser Use本身做过多详细介绍，可自行参阅官方文档。）

答案并不是 Browser Use 比 Codex 更会操作网页。恰恰相反，这个项目真正要解决的是另一个问题：

能否把 Browser Agent 从一个通用工具，变成自己的业务程序里长期运行的一名专业员工？

例如它不需要会写代码、查资料或者处理各种临时任务，只负责订单、退款和库存；使用固定的业务后台，遵守固定规则，任务和结果进入自己的系统，需要时再调用内部 API 或数据库。

Browser Use 官方目前对 Python Library 的定位正好覆盖了这种场景：从自己的代码运行可重复的 Web 自动化、将 Browser Agent 嵌入自己的产品，并允许自定义 Tools、System Prompt、结构化输出和浏览器控制。

本文实现的，就是这样一个极简的浏览器数字员工。

---

从自动化“操作步骤”到自动化“业务目标”

假设每天需要检查电商后台的大额退款。使用 Playwright 时，通常需要先把业务流程转换成确定的操作：

page.goto("https://example.com")

page.click("#order-management")
page.click("#refund-management")

page.fill("#start-date", today)
page.fill("#end-date", today)

page.click("#search")

rows = page.locator(".refund-row")

这种方式的优势很明显：执行快、行为确定、方便测试。但程序必须提前知道页面结构和操作路径，业务流程或者页面发生变化时，相应代码也可能需要维护。

Browser Agent 接收的可以直接是业务目标：

检查今天退款金额超过 500 元的订单，
整理订单号、退款金额和退款原因。

Agent 根据当前页面决定下一步：寻找订单入口、进入退款页面、设置查询条件、读取列表、打开详情，最后按照任务要求整理结果。

两种方式的差异可以简单概括为：

传统浏览器自动化

业务目标
   ↓
开发者编写操作流程
   ↓
Playwright / Selenium
   ↓
浏览器


Browser Agent

业务目标
   ↓
Agent 根据页面动态决定操作
   ↓
浏览器

因此，Browser Agent 真正改变的不是“点击按钮的方法”，而是开发者需要编写的内容。过去主要编写操作步骤，现在可以把一部分执行过程交给 Agent，只定义任务目标和约束。

这也决定了两者不同的适用范围。流程固定、执行频率高、确定性要求强的任务，Playwright 或 API 仍然更合适；目标明确但操作路径不完全固定，中间还需要读取页面、判断情况的任务，更适合交给 Browser Agent。

---

Browser Use 能把这件事简化到什么程度

Browser Use 已经把 Agent 和浏览器操作封装在一起。其当前 Browser Actor 基于 CDP（Chrome DevTools Protocol）构建，提供页面导航、标签页管理和页面元素操作等底层能力。业务程序不需要重新实现一套 Browser Agent。

核心调用可以很简单：

agent = Agent(
    task=instruction,
    llm=llm,
    browser_profile=browser_profile,
    max_steps=50,
)

history = await agent.run()

真正变化的是 instruction。

今天可以是：

检查今天所有退款订单，
找出金额超过 500 元的记录，
进入订单详情查看退款原因，
最后只汇报需要关注的订单。

下一次可以换成：

查询订单 20260907001 为什么还没有发货。

或者：

检查今天库存低于 20 的商品。

程序没有为这三项工作分别准备三套固定流程。Agent 会根据任务和当时的页面决定具体操作。

Browser Use 官方目前也明确区分了 CLI 和 Python Library 的使用场景：已经拥有 Codex、Claude Code 等 Agent，只是希望它们临时完成浏览器任务，可以直接使用 CLI；如果是在开发自己的软件，需要可重复的网页自动化、嵌入 Browser Agent、自定义 Tools 或控制 Agent 行为，则使用 Python Library。

这个区别非常重要，因为本文要做的并不是给 Codex 再增加一个浏览器工具，而是把 Browser Agent 直接放进业务程序。

---

数字员工的实现并不需要复杂架构

第一版没有引入 Multi-Agent、RAG、Workflow Engine 或向量数据库，整个系统只有几层：

┌─────────────────────┐
│       Web UI        │
│   下达任务 / 看结果  │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│   Python Backend    │
│    Task Manager     │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│  Browser Use Agent  │
│                     │
│  LLM + Agent Loop   │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│       Chrome        │
│ Persistent Profile  │
└──────────┬──────────┘
           │
           ▼
      ERP / CRM / 后台

Python 后端负责接收任务和管理状态，Browser Use 负责执行浏览器任务，Chrome 提供实际工作环境，SQLite 保存任务和执行结果。

应用层并不需要提前知道一项任务最终经过三个页面还是十个页面，只管理任务本身：

任务是什么
→ 是否开始执行
→ 当前状态
→ 是否需要停止
→ 最终结果

这种结构的重点不是“架构简单”，而是职责清晰。Browser Use 已经解决的 Agent 和浏览器问题不再重复开发，自己的代码主要处理业务规则、任务生命周期和产品交互。

---

持久浏览器让 Agent 进入真实业务环境

真正把 Browser Agent 用在 ERP、CRM 或电商后台，很快就会碰到登录问题。Cookie、Session、验证码、二次认证都可能让“每次启动一个全新浏览器”变得不现实。

这个项目使用独立的持久 Chrome Profile。首次运行时由用户完成登录，后续任务继续使用这个浏览器环境：

首次使用
用户完成登录
      ↓
Chrome Profile 保存状态
      ↓
后续任务继续使用
      ↓
Agent 进入业务后台

Browser Use 当前官方文档明确提供了真实 Browser Profile 的认证方式，可以复用 Chrome Profile 中已经保存的登录状态。

不过，这一点不能算本方案相对 Codex 的优势。OpenAI 当前官方文档同样明确：当任务需要现有 Chrome Profile、登录 Session、已打开标签页或 Chrome 扩展时，可以使用 Codex Chrome extension。

真正的区别在上一层：**这个 Chrome 不是临时交给某个通用 Agent 使用，而是可以成为自己数字员工运行环境的一部分。**什么时候启动、哪个任务使用它、任务状态存在哪里、完成后如何进入后续业务，都由自己的程序决定。

---

既然 Codex 已经这么强，为什么还要 Browser Use？

这是这个方案最需要回答的问题。

如果只是偶尔让 AI 登录某个后台、查一条订单或者填写一个网页，直接使用 Codex 这样的专业 Agent 更方便，没有必要为此开发一套系统。

Python + Browser Use 的优势出现在另一种需求里：

当浏览器操作本身需要成为业务软件的一项长期能力时。

Browser Use 官方对 Python Library 的描述非常直接：可以从自己的代码自动化 Web、嵌入 Browser Agent 到自己的产品，并提供自定义 Tools、System Prompt、结构化输出和细粒度浏览器控制。

这意味着开发者可以决定的不只是“一次任务怎么描述”，而是整个数字员工如何工作。

例如，一个电商运营数字员工可以长期固定为：

职责：
- 检查订单
- 检查退款
- 检查库存
- 汇总异常

业务规则：
- 退款金额超过 500 元重点标记
- 查询、统计、整理可以自主完成
- 页面没有提供的信息不得推测
- 付款、退款、删除等操作必须获得确认
- 工作完成后按照固定格式返回结果

它面对的用户也不需要知道 Browser Use，甚至不需要知道背后使用了哪个模型。产品界面完全可以只有“安排工作、停止任务、查看进度、查看结果”。

更重要的是，浏览器只是这个数字员工的一种执行能力。Browser Use 官方支持自定义 Tools，因此 Agent 可以一边操作 ERP，一边调用内部 API、查询数据库或执行自己的 Python 工具。任务结束以后，结果也可以继续进入自己的数据库、报表或其他业务流程。

最终形成的不是：

用户 → 通用 Agent → 浏览器

而是：

                  ┌─ 业务规则
                  ├─ 任务系统
                  ├─ 历史记录
                  ├─ 安全策略
                  ├─ 内部 Tools
                  └─ 结果处理
                        │
用户 → 数字员工程序 ────┤
                        ↓
                      LLM
                        ↓
                  Browser Use
                        ↓
                     Chrome
                        ↓
                    业务系统

这才是本方案相对直接使用 Codex 最重要的区别。

Codex 更像一个已经做好的专业 Agent；Browser Use Python Library 更适合作为自己产品中的 Browser Agent 基础设施。

前者拿来就能完成很多任务，后者则允许开发者围绕具体岗位重新组织浏览器、模型、工具、规则、任务和数据。

所以这不是“谁的浏览器能力更强”的比较，而是产品形态不同。

---

专业化之后，数字员工才开始有实际意义

通用 Agent 需要面对各种任务，一个业务数字员工则可以非常“偏科”。

例如只负责三个后台：

电商后台
物流后台
供应商后台

每天只处理：

订单
退款
库存
物流异常

程序可以逐渐积累针对这些业务的规则和工具。例如查询商品时顺便调用内部 API 获取成本；发现退款时根据业务规则判断风险；任务结束后按照固定结构写入数据库。

Browser Use 当前支持自定义 Tools，这使 Agent 的能力不必局限在浏览器里：

from browser_use import Tools

tools = Tools()

@tools.action(description="查询商品内部成本")
def get_product_cost(sku: str) -> str:
    ...

这样，网页负责提供人类可见的业务入口，内部 Tool 负责补充网页之外的数据。

专业化的意义也正在这里体现出来：并不是通过一段越来越长的 Prompt 让 Agent“更懂业务”，而是逐渐把稳定的业务规则、数据和能力固化到程序里。

---

模型也可以独立选择

Browser Use 并没有把 Agent 固定到单一模型上。

截至 2026 年 9 月，官方 Python Library 支持自带不同 LLM Provider；ChatBrowserUse 也支持通过带 Provider 前缀的 Model ID 调用 GPT、Claude、Gemini 等模型。

因此整个系统可以拆成相对独立的几层：

业务程序
   │
   ├── 业务规则
   ├── 任务管理
   ├── 数据
   │
   ▼
Browser Use
   │
   ├── LLM
   │
   ▼
Chrome

底层模型发生变化，并不意味着整个数字员工需要重新开发。可以根据实际任务效果、速度和成本调整模型，而业务规则、任务系统和浏览器环境继续保留。对于需要长期运行的业务程序，这比“固定使用哪个模型”更重要。

---

一个数字员工还需要管理任务状态

如果程序只有：

await agent.run()

那它仍然只是 Browser Use 的调用示例。

要变成一个可以日常使用的数字员工，还需要最基本的任务生命周期。当前项目保存五种状态：

pending
running
completed
failed
cancelled

任务提交后由后台执行，界面可以查看当前任务、执行进度和最终结果，也可以停止正在运行的任务。历史任务写入 SQLite，因此能够知道数字员工过去执行了什么、成功还是失败、返回了什么结果。

整个闭环仍然很简单：

安排工作
   ↓
执行
   ↓
查看进度
   ↓
完成 / 失败 / 停止
   ↓
保存结果

第一版并没有必要引入复杂 Workflow Engine。真正出现定时调度、审批、多员工协作等需求以后，再增加相应组件即可。

---

AI 目前适合处理哪些浏览器业务？

从 Browser Use 当前官方展示的能力来看，Agent 已经能够完成表单填写、网页数据提取和需要认证状态的网页任务；底层 Browser Actor 基于 CDP，可以进行页面导航、标签页管理和页面元素操作。

放到实际业务里，更值得尝试的是下面这类任务：

业务类型	更适合的方案
固定、高频、强确定性流程	API / Playwright
查询、检查、整理类网页任务	Browser Agent
页面变化较多、需要动态判断	Browser Agent
大规模批处理	API / 确定性程序
付款、删除等高风险操作	Agent + 人工确认
固定步骤与动态判断混合	确定性代码 + Agent

例如：

查询某个订单当前状态

筛选今天的大额退款并进入详情核对原因

检查库存异常并整理需要补货的商品

浏览多个后台页面后汇总异常情况

按照业务条件查找数据并形成结果

这些任务有一个共同点：目标比较明确，但操作路径未必固定，而且中间通常夹杂一些原本需要人完成的判断。

反过来，如果一个任务每天执行几十万次，操作路径完全固定，就没有必要为了使用 AI 而使用 AI。API 和 Playwright 在速度、成本、确定性上仍然更合适。

Browser Agent 与传统自动化也不必二选一。固定步骤用程序，需要理解页面和处理变化的部分交给 Agent，通常比让 Agent 从头做到尾更合理。

---

AI 能把浏览器玩转到什么程度？

现在可以回到文章标题。

截至 2026 年 9 月，“AI 操作浏览器”已经不只是看着截图模拟鼠标。Codex 可以使用现有 Chrome Profile 和登录 Session；Browser Use 则把 Agent 与浏览器控制进一步开放给 Python 程序，并允许开发者自定义模型、Tools、Prompt 和运行方式。

因此，目前真正发生变化的不是 AI 又学会了几个浏览器动作，而是浏览器开始成为 Agent 执行业务的一种通用界面。

过去面对一个没有 API 的业务后台，如果要自动化，通常只有两种办法：人工操作，或者把人的操作步骤重新写成 Selenium / Playwright 脚本。现在多了一种选择——让 Agent 理解任务和当前页面，在运行过程中决定操作路径。

它还远没有达到可以无条件接管浏览器的程度。固定程序依然更快、更稳定；涉及付款、退款、删除等高风险操作，也必须设置更严格的确认和验证机制。但对于查询、核对、检查、整理这类原本需要人在多个页面之间来回操作的工作，Browser Agent 已经具备实际使用价值。

而本文方案与直接使用 Codex 的区别，也最终落在这里：

Codex
更适合直接把任务交给一个成熟的专业 Agent

Python + Browser Use
更适合把浏览器 Agent 变成自己软件的一部分

当需求从“帮忙操作一次网页”变成“长期替某个岗位处理一类网页业务”时，后者的价值才真正体现出来。浏览器、模型、任务、规则、内部工具和业务数据都可以围绕这个岗位重新组织，最后形成一个非常具体的数字员工。

这也是本文真正的意义所在。我们真正值得做的，早就不是继续证明 AI 会不会点击按钮，而是把这种能力收进具体业务里，看它究竟能替人完成多少真实工作。