传统的 LLM 只是一个文本语言模型，只能以 chat bot 的形式和我们进行对话。但是在日常工作生活中，浏览器是一个占据我们大多数时间的工具，如何让大语言模型也具备操作浏览器的能力呢？

最近我做了一个小实验：用 Agent + Playwright，让大模型自己打开网页、看懂页面结构、决定点哪个按钮，最终完整处理了一个客服工单。这篇文章把原理、落地过程整理出来。

从宏观上看，给 LLM 配置上工具、组成一个 Agent，就能实现与浏览器的交互。这个 Agent 不断执行「观察 + 执行」的循环：

1. Agent 接受任务和当前浏览器状态

2. 根据任务分析当前状态，决定下一步操作

3. 把操作交给工具执行

4. 执行后浏览器产生新的状态，作为下一次循环的输入

循环一直持续，直到 Agent 认为任务完成。

为了使循环正常工作，我们需要在代理和浏览器之间建立两个连接：

1. 观察通道 ，让 Agent 能接收当前浏览器状态
2. 操作通道 ，让 Agent 能与浏览器交互

两种落地方案

方案一需要 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. 打开客服控制台页面
2. 找到工单 ORD-1048（客户投诉收到了错误的商品）
3. 搜索关联订单，查看订单详情和客户档案
4. 对照解决方案规则，判断应该换货还是退款
5. 提交解决方案并添加内部备注
6. 验证工单状态变为"已解决"

关键点：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
- 内部备注及操作已写入**审计日志**，处理结果**成功保存**。✅