用 OpenAI Agents SDK 配合 Playwright MCP 实现真·浏览器自动化

最近在尝试把 LLM Agent 从简单的“对话框”升级为能够实际操作网页的“执行体”，在对比了多种方案后，我发现使用 OpenAI Agents SDK 配合 Playwright MCP（Model Context Protocol）的组合效率最高。以往我们给 AI 加浏览器能力，通常得自己写一套复杂的 Selenium 脚本，然后通过 API 传给模型，这种方式不仅开发周期长，而且模型对页面结构的理解极其碎片化。

而 MCP 协议的出现，本质上是将 Playwright 的浏览器控制能力直接“标准化”并暴露给模型。这意味着 Agent 不再是通过调用一个死板的 API 来抓取数据，而是直接获得了操作浏览器的权限，能够像人类一样执行点击、输入和页面跳转。

在具体的实操过程中，环境搭建是第一步。你需要先全局安装 MCP 的 Playwright 服务端，并确保浏览器内核已正确安装，否则在调用阶段会直接崩溃。执行以下命令即可完成基础环境部署：
npm install -g @modelcontextprotocol/server-playwright
npx playwright install

接下来的核心步骤是在 OpenAI Agents SDK 的配置中，将 Playwright MCP 作为一个 Tool 挂载进去。在这个架构下，模型在面对需要实时信息或交互的任务时，会自动触发相应的指令。比如，当你要求它“去某个电商平台对比两款产品的价格”时，Agent 会在内部逻辑中自动调用 browser_navigate 进入目标页面，随后通过 browser_click 或 browser_type 等指令与页面交互。

但在实际跑通这个链路时，我踩了两个非常关键的坑，分享给准备尝试的开发者：

首先是关于“选择器失效”的问题。LLM 在解析 DOM 树时，有时会倾向于通过视觉或文本猜测元素的 ID。但现在的动态网页（尤其是 React 或 Vue 构建的页面）其 ID 往往是随机生成的，每次刷新都会变。如果 Agent 依赖这些动态 ID，操作很快就会失败。我的经验是，在 System Prompt 中明确引导 Agent：优先使用更稳定的 CSS Selector 或 ARIA 属性，而不是依赖 ID。

其次是异步等待的机制。Playwright 的页面加载是异步的，而 LLM 的推理速度与网页渲染速度之间存在时间差。如果 Agent 在页面尚未完全加载完成时就尝试执行点击操作，控制台会频繁弹出 element not found 错误。为了解决这个问题，我建议在工作流中加入一个简单的验证步骤，或者在 Prompt 中要求 Agent 在执行关键操作前，先确认目标元素是否已在当前 Viewport 中可见。

这种部署方式最大的价值在于，它彻底打破了 LLM 的知识截断限制。Agent 不再依赖于过时的训练数据或不稳定的第三方搜索 API，而是直接面对实时网页。从一个只能聊天、写代码的机器人，变成了一个能够自主完成比价、订票、数据采集等复杂任务的自动化执行体，这才是 Agent 真正走向实用的方向。