OpenAI Agents SDK 实战：让 AI 自己打开浏览器完成任务

Web极客码

72人浏览 · 2026-07-27 13:00:41

Web极客码 · 2026-07-27 13:00:41 发布

最近一段时间，越来越多人开始讨论 Browser Agent。

大模型已经越来越聪明了，但真正落地到业务里，还有最后一道坎没有跨过去——它不会操作浏览器。

想象一个很常见的工作场景：

客服收到一张售后工单，需要登录后台查看订单、确认库存、查询售后政策，最后填写处理结果。

对于人来说，这只是几分钟的操作；但对于 LLM 来说，它根本不知道浏览器里发生了什么，更别说自己点击按钮、填写表单了。那么，有没有办法让 Agent 像真人一样，自己打开浏览器，把整个流程走完？

最近体验了一下 OpenAI Agents SDK 配合 Playwright MCP，发现整个过程比想象中简单得多。

今天就聊聊 Browser Agent 是怎么工作的，以及为什么很多人认为它会成为 AI Agent 落地的重要方向。

Browser Agent 到底难在哪？

很多人第一次接触 Agent，会觉得它和普通聊天机器人没什么区别，实际上，两者最大的差别在于有没有行动能力（Action）。

传统的大模型只能根据你提供的内容进行推理，如果你没有把网页内容发给它，它就不知道网页是什么样；如果没有提供工具，它也无法点击页面上的任何按钮。所以，一个 Browser Agent 本质上就是不断重复下面这个过程：

看网页 → 理解页面 → 决定下一步 → 操作浏览器 → 再看网页……

听起来有点像人在电脑前工作的过程。

事实上，这也是目前大多数 Browser Agent 的基本运行逻辑。

它真的"看得见"网页吗？

很多人的第一反应是：

是不是不停给模型截图？

其实不是，至少 Playwright MCP 默认不是这么做的，它读取的是浏览器里的 Accessibility Tree（无障碍树）。

可以把它理解成浏览器整理出来的一份"页面说明书"。例如，一个网页里的按钮、输入框、链接，在模型眼里可能长这样：

Button
id=15
text="Submit"

Textbox
id=22

Link
id=37

这样模型根本不用识别图片，它只需要告诉浏览器：

点击 Button 15。

或者：

在 Textbox 22 输入内容。

相比截图识别，这种方式不仅速度更快，也更稳定，Token 消耗也更低。

当然，这种方式更适合网页，如果以后要操作 Photoshop、Excel、微信之类的软件，那还是需要依赖截图和鼠标坐标，也就是大家常说的 Computer Use。

Playwright MCP 到底做了什么？

如果你用过 Playwright，那么理解 MCP 就很容易了，Playwright 本身就是浏览器自动化框架，开发者平时写自动化测试时，会写这样的代码：

page.goto(...)
page.click(...)
page.fill(...)

而 MCP 的作用，就是把这些能力包装成 Agent 可以调用的 Tool，于是模型就拥有了打开网页、点击按钮、输入文本、获取页面内容、页面跳转和上传文件这些原本属于浏览器自动化的能力，整个过程不用开发者提前规划流程，Agent 会根据当前页面，自主决定下一步调用哪个 Tool。

用 Agents SDK 接起来，其实没有想象中复杂

整个 Agent 的定义只有几十行代码，核心代码基本就是：

agent = Agent(
name="Support Browser Agent",
model="gpt-5.4",
instructions="You are an agent that can interact with a web browser.",
mcp_servers=[playwright_server],
)

真正关键的是最后这一句：

mcp_servers=[playwright_server]

相当于告诉 Agent：

以后如果需要浏览器，就去调用这个 MCP Server。剩下的事情，交给模型自己决定。

我做了一个客服后台 Demo

为了验证 Browser Agent 的能力，作者搭建了一个非常简单的客服后台。

页面没有什么复杂逻辑，就是几个常见模块：

工单列表

用户信息

订单详情

库存状态

售后策略

操作日志

然后只给 Agent 一句话：

打开后台，把订单 ORD-1042 的售后工单处理完成，没有告诉它先点哪里，也没有告诉它按钮在哪，接下来发生的事情还挺有意思，Chrome 自动打开之后，Agent 开始自己一步一步操作：

先找到对应工单；

查看订单详情；

阅读客户反馈；

确认库存状态；

查找售后政策；

判断应该补发商品；

填写内部备注；

点击提交；

最后再检查 Audit Log，确认后台已经记录成功，整个过程几乎就是客服每天工作的缩小版。最后 Agent 返回的结果也很简单：

已完成订单 ORD-1042 的补发处理，后台状态更新成功，审计日志已记录。

第一次看到浏览器自己一点一点操作的时候，还是挺有意思的。虽然知道背后本质上还是 Tool Calling，但整个过程已经很接近真人完成任务的感觉了。

Browser Agent 真正适合什么场景？

我觉得很多人容易高估 Browser Agent，也容易低估它，如果业务已经提供了完善的 API，那么直接调用 API 永远比操作网页效率更高，但现实情况是，很多企业系统根本没有开放接口。CRM、ERP、客服后台、运营平台……大量内部系统依然只能通过浏览器访问。

这种时候，Browser Agent 就有价值了。

它不需要企业重新开发接口，也不用改造原有系统，而是直接按照现有流程完成操作。对于很多传统企业来说，这反而是成本最低的一种 AI 落地方式。

部署时，一个容易被忽略的问题

本地跑 Demo 很容易，真正上线之后，事情就没那么简单了。因为 Browser Agent 一般需要长期保持浏览器运行，同时 MCP 服务也需要一直在线。如果多个 Agent 同时工作，对服务器的 CPU 和内存都会有一定要求。所以实际部署时，大多数团队都会把 Playwright、Python 和 MCP 服务放到云服务器上统一运行，而不是依赖开发电脑。

我自己测试时，也是直接部署在 Hostease 的 Linux 云服务器上。对于这类需要长期运行浏览器实例的项目来说，云端环境明显更省心一些，不用担心本地电脑关机、网络中断或者环境变化导致 Agent 停止工作。Node.js、Python 和 Playwright 的部署流程也比较顺手，后续扩容也方便。