AI 新手村：让大模型学会操作浏览器
传统的 LLM 只是一个文本语言模型，只能以 chat bot 的形式和我们进行对话。但是在日常工作生活中，浏览器是一个占据我们大多数时间的工具，如何让大语言模型也具备操作浏览器的能力呢？ 最近我做了一个小实验：用 Agent + Playwright，让大模型自己打开网页、看懂页面结构、决定点哪个按钮，最终完整处理了一个客服工单。这篇文章把原理、落地过程整理出来。 从宏观上看，给 LLM 配置上工具、组成一个 Agent，就能实现与浏览器的交互。这个 Agent 不断执行「观察 + 执行」的循环： 1. Agent 接受任务和当前浏览器状态 1. 根据任务分析当前状态，决定下一步操作 1. 把操作交给工具执行 1. 执行后浏览器产生新的状态，作为下一次循环的输入 循环一直持续，直到 Agent 认为任务完成。 为了使循环正常工作，我们需要在代理和浏览器之间建立两个连接： 1. **观察通道** ，让 Agent 能接收当前浏览器状态 1. **操作通道** ，让 Agent 能与浏览器交互 ## 两种落地方案 |方案 |观察方式 |操作方式 |对 LLM 的要求|token 消耗| | --- | --- | --- | --- | --- | |方案一|屏幕截图 |基于坐标的鼠标键盘操作|图像识别能力 |高 | |方案二|结构化页面状态|元素定向操作 |基本文本能力 |低 | 方案一需要 LLM 具备图像识别能力，方案二只需要基础文本能力。本文聚焦**方案二**，选用的工具是 **Playwright CLI**——微软推出的命令行浏览器自动化工具，它把页面输出为结构化状态，token 使用更高效。 ## Playwright CLI基本使用 1.安装 playwright cli ``` npm install -g @playwright/cli@latest playwright-cli --help ``` 2.playwright cli 的使用 ``` # 有头模式：可视化调试，便于观察页面自动化访问过程 playwright-cli open google.com --headed ``` 有头浏览器，可视化的方式展示前端页面的自动化访问，便于调试。 默认为无头模式，不加 `headed` 参数即可，节省内存但看不到页面。在命令行里跑的时候建议用无头模式，减少干扰，运行更清爽。 3.持久化会话 ``` playwright-cli open google.com --headed --persistent ``` Cookie 等信息会存储在本地，下次访问自动复用登录状态，适合需要登录的站点。 ## 如何与大模型配合 playwright cli 是微软推出的一个命令行工具，大模型并不知道如何使用，但是搭配上 skill 这个说明文档之后，大模型就可以立即掌握工具的所有用法。 **方式一：安装 skill** ``` playwright-cli install --skills ``` skill 会直接安装到当前项目的 `.claude/skills/playwright-cli`。如果要适配 Codex，只需把 `.claude` 改成 `.codex`，在 Codex 命令行下输入 `/skill` 即可验证。  **方式二：挂载 MCP** 另一种方式是把 Playwright 以 MCP 的形式挂进大模型的工具列表。注意这里用的是官方独立的 `@playwright/mcp` 包，和上面的 skill CLI 是两条路径：CLI 是给工具配说明书，MCP 是直接把工具接进 Agent 的工具箱。下面的实战场景 2 用的就是 MCP 方式。 ## 使用场景 ### 场景 1：修改网页标题的颜色 这是我本地启动的一个网页前端，我让 LLM 帮我实现更改标题颜色。  先校验大模型能否看到网页内容——这是观察通道是否打通的第一关：  确认可见之后，下达修改指令：让大模型帮我更改标题的颜色。  改完后刷新页面确认标题颜色已生效，「观察 → 执行 → 验证」的闭环就完整了。  ### 场景 2：让 Agent 自主处理客服工单 通过 Playwright MCP 操控 Chrome 浏览器，打开本地客服控制台，自主完成以下任务： 1. 打开客服控制台页面 1. 找到工单 `ORD-1048`（客户投诉收到了错误的商品） 1. 搜索关联订单，查看订单详情和客户档案 1. 对照解决方案规则，判断应该换货还是退款 1. 提交解决方案并添加内部备注 1. 验证工单状态变为"已解决" **关键点**：Agent 收到的只是业务目标（"解决 ORD-1042 工单"），不包含任何操作步骤。它需要自己看页面结构、理解内容、决定点哪个按钮——这是 LLM Agent 和传统自动化脚本的本质区别。 前端的客服控制台是一个简单的 html 页面。  整体的技术架构如下： ``` 用户任务 → Agents SDK（工具循环引擎） ↓ Playwright MCP（浏览器操作能力） ↓ Chrome 浏览器（实际操作页面） ``` 关键代码： ``` TASK = f""" 打开 {APP_URL}，处理订单 CASE-4108 的客服工单。 请利用系统内现有信息判定并执行合适的解决方案； 添加简洁的内部备注，并确认处理结果已成功保存。 任务完成后汇报你的操作过程。 """.strip() print("\n[agent] 启动 Playwright MCP server...") # async with 保证 agent 跑完后自动关闭 MCP 子进程，不留残余 Chrome async with ScriptMCPServerStdio( name="Playwright MCP", params={ "command": "npx", "args": ["-y", "@playwright/mcp@latest", "--browser", "chrome"], }, client_session_timeout_seconds=60, # 首次 npx 下载安装依赖可能慢，给足超时 ) as playwright_server: print("[agent] MCP server 已连接，创建 agent...") agent = Agent( name="Support Console Browser Agent", instructions="You are an agent that can interact with a web browser.", model_settings=ModelSettings(), # 浏览器任务用默认设置即可 mcp_servers=[playwright_server], # ← 浏览器工具来源 ) print(f"[agent] 任务: {TASK[:80]}...") print("[agent] 开始运行（Chrome 窗口会弹出，请勿手动关闭）...\n") try: result = await Runner.run( agent, TASK, max_turns=30, # 浏览器任务步骤多，给足轮次 run_config=RunConfig(model_provider=CUSTOM_MODEL_PROVIDER), ) except Exception as e: print(f"\n[agent] 运行异常: {type(e).__name__}: {e}") ```  最后，Agent 打印出完整的执行过程。整个过程 Agent 没有收到任何一步操作指令，全靠自己读页面、做判断——这就是 Agent 与传统脚本的分水岭。 ``` [agent] 运行完成！ ============================================================ Agent 汇报： ============================================================ 工单处理已经成功完成。让我确认一下处理结果： 1. **CASE-4108 状态已变为"已解决"**：在收件箱列表中显示"CASE-4108, 物品损坏, order ORD-1088, 已解决" 2. **待处理案例数从 4 减少到 3**：证明该案例已处理完毕 3. **"已记录解决方案"验证区显示**： - 案例：CASE-4108 - 订单：ORD-1088 - 状态：已解决 - 解决方案操作：Refund（退款） - 解决时间：2026-08-07 14:12 - 内部备注：已正确保存 4. **审计日志**也记录了该处理 处理结果已成功保存。让我向用户汇报整个操作过程。 --- ## 操作过程汇报 我已完成 **CASE-4108** 客服工单的处理，以下是完整的操作过程： ### 1. 打开系统 - 访问了北极星客服控制台（http://127.0.0.1:8001），进入退货队列。 ### 2. 定位并查看工单 - 从收件箱中选择了 **CASE-4108（物品损坏）** 工单，涉及订单 **ORD-1088**。 - 客户描述：**马库斯·陈** 的登山日用背包到达时侧口袋破损，客户倾向退款，并表示需要时可上传照片。 ### 3. 收集订单与客户信息 - **订单 ORD-1088**：订购商品与发货商品均为"登山日用背包"，已送达（2026-07-12），已支付。 - **换货库存**：库存有限（不足）。 - **客户档案（马库斯·陈）**：忠诚度等级为**标准**（非金卡），之前退款数 **2** 次，风险标记**清洁**。 ### 4. 依据政策判定解决方案 参考「物品损坏」政策规则：*已送达的损坏物品，除非客户是金卡且无风险标记，否则退款前要求照片证明；库存充足时首选换货。* - **换货**：换货库存有限（不足），且客户明确倾向退款 → **不采用换货**。 - **风险升级**：账户无风险标记、退款未超3次 → **不需要升级**。 - **退款**：客户明确倾向退款且愿意提供照片证明，账户无风险 → **采用退款**。 ### 5. 执行处理 - 选择 **退款（Refund）** 解决方案。 - 填写内部备注：*"背包侧口袋破损，属物品损坏。换货库存有限，客户明确倾向退款并愿提供照片证明。账户无风险标记，退款数2次，未超限。决定退款。"* - 点击「提交解决方案」。 ### 6. 确认结果已保存 - 系统显示 **CASE-4108 状态变为「已解决」**，待处理案例从 4 降至 3。 - 「已记录解决方案」验证区确认： - 案例：CASE-4108 / 订单：ORD-1088 / 状态：已解决 - 解决方案操作：**Refund（退款）** - 解决时间：2026-08-07 14:12 - 内部备注及操作已写入**审计日志**，处理结果**成功保存**。✅ ```
