Playwright-MCP vs Agent-Browser：选型实录

核心差异：嫁接还是重写？

Playwright-MCP 和 Agent-Browser 解决的是同一类问题：让 AI agent 能可靠、可复现地操作网页。但它们的实现路径截然不同。

Playwright-MCP：在旧引擎上加装协议适配器

它把 Playwright 当作底层驱动，再套一层 MCP 协议外壳。本质是“用 MCP 的壳，跑 Playwright 的逻辑”。

• 输出格式：返回 HTML、JSON 或截图，但每次都要手动解析成 MCP 兼容结构
• 元素定位：沿用 Playwright 的 CSS/XPath 选择器，写法熟悉，但无法利用 MCP 的语义化定位能力（比如 aria-label="搜索" + role="button" 的组合意图）
• 通信机制：MCP 请求进来后，转成 Playwright 的 WebSocket 指令；响应再反向封装。多一层序列化/反序列化开销
• 会话：依赖 Playwright 的 BrowserContext，不感知 MCP 的 session_id 生命周期，跨请求状态难保持
• 性能瓶颈：单实例吞吐受限于 Playwright 进程模型；高并发时容易堆积未完成的 page.goto()
• 移动端：需额外配置 deviceScaleFactor、isMobile 等参数，且手势模拟（如 swipe）支持不完整
• 云部署：无状态设计弱——每个请求都可能新建 browser 实例，冷启动延迟明显
• DOM 更新：只在动作完成后返回快照，无法推送 DOM 变更流（例如表单输入实时校验反馈）

Agent-Browser：为 MCP 从零构建的浏览器运行时

不是包装，是重写。所有模块（导航、交互、事件监听、DOM 序列化）都按 MCP 规范设计。

• 输出格式：直接生成符合 MCP browser.* 方法规范的流式 JSON 响应（如 browser.dom.update 事件）
• 元素定位：支持 MCP 原生定位器（{ "type": "text", "value": "提交" }），也兼容 CSS，但优先走语义路径
• 通信机制：全链路 MCP-native：请求直接映射到内部状态机，响应通过 MCP event stream 推送
• 会话管理：session_id 绑定到内存中的 BrowserSession 实例，自动清理超时会话，支持 session 复制与迁移
• 性能：单进程支持 50+ 并发页面（基于 Chromium 的 --single-process 优化），DOM diff 增量推送降低带宽占用
• 移动端：预置主流设备指纹模板，touchstart/touchend 事件原生支持，无需额外配置
• 云原生：无本地依赖（不调用 chromium 二进制，用 @puppeteer/browsers 动态下载），K8s 下 Pod 启动 < 800ms
• 流式 DOM：启用 stream: true 后，页面加载过程中的 DOMContentLoaded、load、input 事件实时透传，AI 可即时响应

场景验证：什么情况下必须换？

Playwright-MCP 足够用的场景

• 内部工具的自动化测试（CI 中跑一次，不追求实时性）
• 定时爬取静态列表页（如商品价格监控，每小时拉一次）
• 简单表单提交（3 步以内，无动态校验、无 JS 渲染依赖）

Agent-Browser 显著胜出的场景

• 客服对话中实时填单：用户语音说“查我上月账单”，agent 需在登录页输入手机号 → 等待短信 → 输入验证码 → 点击“账单查询” → 截图返回。整个链路要求 DOM 变更毫秒级可见，否则等待超时。
• 金融看板数据联动：打开交易页面后，agent 监听 #portfolio-value 元素数值变化，一旦波动超 2%，立即触发 browser.screenshot 并告警。Playwright-MCP 无法监听 DOM 变化，只能轮询。
• 跨端一致性工作流：同一套脚本在 iOS Safari、Android Chrome、桌面 Edge 上执行相同操作。Agent-Browser 的设备抽象层自动处理 viewport、触摸事件、UA 差异；Playwright-MCP 需为每个平台写分支逻辑。
• SaaS 服务集成：客户要求审计日志精确到“第 3 步点击了哪个按钮（含 aria-label）”，Agent-Browser 的 browser.element.click 响应体自带 locator 和 matchedText 字段；Playwright-MCP 日志只有 click(selector)，无法还原用户真实意图。

商业落地：成本与回报怎么算？

Playwright-MCP 的隐性成本

• 维护成本：当网站改版（如按钮 class 名变更），90% 的 selector 失效，需人工修复脚本
• 扩展瓶颈：客户提出“需要支持语音输入”，得在 Playwright 层外再加一层 Web Speech API 封装，架构变重
• 合规风险：GDPR 审计要求记录“谁在何时操作了哪个元素”，Playwright-MCP 的日志缺少 MCP 标准的 actor_id、trace_id 字段，需额外开发日志中间件

Agent-Browser 的确定性收益

• 开发效率：某电商客户用 Agent-Browser 重构比价机器人，脚本行数减少 60%（语义定位替代 20 行 CSS 选择器），上线周期从 3 周压缩到 5 天
• 运维成本：某银行将网银操作 agent 迁移到 Agent-Browser 后，错误率下降 73%（归因于 DOM 流式响应避免了“等待元素出现”的竞态条件）
• 变现能力：Yitb 生态内，Agent-Browser 开发的智能客服系统定价比 Playwright-MCP 方案高 40%，客户接受度更高——因为 SLA 承诺“操作失败时提供可回放的 DOM 变更轨迹”，这是嫁接方案做不到的

快速上手：一个真实 Server 示例

const express = require('express');
const { AgentBrowser } = require('agent-browser');

const app = express();
app.use(express.json());

// 复用单例，避免重复创建浏览器进程
const agentBrowser = new AgentBrowser({
  headless: true,
  maxPages: 100, // 并发页面上限
  sessionTimeout: 300000 // 5 分钟无操作自动销毁
});

app.post('/run', async (req, res) => {
  const { script, sessionId } = req.body;
  
  try {
    const result = await agentBrowser.run({
      script,
      sessionId,
      stream: true // 启用流式响应
    });

    // result 是 AsyncIterable，逐块返回 MCP event
    res.writeHead(200, {
      'Content-Type': 'application/x-ndjson',
      'X-Session-ID': result.sessionId
    });

    for await (const event of result) {
      res.write(JSON.stringify(event) + '\n');
    }
    res.end();
  } catch (err) {
    res.status(500).json({ error: err.message });
  }
});

app.listen(3000);

部署要点：

• 不要 npm install playwright —— Agent-Browser 自带精简版 Chromium
• 在 K8s 中设置 resources.limits.memory: "2Gi"，单 Pod 可稳定支撑 30 并发
• 用 curl -N http://localhost:3000/run -d '{"script":"go to https://example.com"}' 测试流式响应

下一步：别评估，先跑通一个用例

1. 挑一个痛点场景：比如你当前用 Playwright-MCP 抓取的某个页面，经常因动态加载失败
2. 用 Agent-Browser 重写 3 行核心逻辑：go to url → wait for element "登录" → fill input "用户名" with "test"
3. 对比两者的日志：看 Agent-Browser 是否输出了 browser.dom.update 事件，以及 browser.element.click 响应里是否包含 matchedText: "登录"
4. 压测：用 autocannon -c 20 -d 30 http://localhost:3000/run 对比错误率和 P95 延迟
5. 检查审计字段：确认响应体里有 trace_id、actor_id、timestamp —— 这些是商用交付的硬性要求

如果第 3 步能看到语义化匹配结果，第 4 步错误率低于 0.5%，第 5 步字段齐全，升级就已具备技术合理性。