对比
为智能体打造的 Puppeteer MCP 替代方案
AWI 构建于 Puppeteer 之上——所以这并非 Puppeteer 与 Agent Web Interface 之争。区别在于：是把 Puppeteer 的原始输出（DOM、evaluate() 结果、CSS 选择器）交给 AI 智能体，还是给它一份紧凑的语义页面视图。AWI 替你驱动 Puppeteer，只返回智能体推理和行动所需的内容。以下是原始 Puppeteer MCP 服务器的对比。
一览
| 维度 | 原始 Puppeteer MCP | Agent Web Interface |
|---|---|---|
| 智能体收到的内容 | 原始 DOM / evaluate() 输出 | 紧凑的语义 XML 快照 |
| 元素引用 | CSS / XPath 选择器 | 跨工具调用稳定的 eid |
| 每步 Token 成本 | 40,000 多字节 | 小于 1 KB |
| 所需技能 | JavaScript + Puppeteer API | 自然语言工具调用 |
| 浏览器引擎 | Puppeteer（通过 CDP 驱动 Chrome） | Puppeteer —— 由 AWI 替你驱动 |
| 安装 | 自行构建 MCP 封装 | npx agent-web-interface install |
何时选择 AWI
当由 AI 智能体驱动 Puppeteer 时，选择 AWI。AWI 不把原始 DOM 和选择器查询灌入模型上下文，而是返回带稳定 eid 的语义快照——智能体据此对结构进行推理、跨调用引用元素，并只消耗一小部分 Token。你获得 Puppeteer 真实的 Chrome 渲染，却无需自己编写工具层。
何时原始 Puppeteer 仍然适用
如果你在代码中编写确定性自动化，并希望直接控制 Puppeteer API——自定义 evaluate() 调用、请求拦截、PDF 生成、精细等待——请直接使用 Puppeteer。AWI 面向智能体推理，并非替代你自己编写 Puppeteer 脚本；它构建于其之上。
结论
Puppeteer 是正确的引擎——AWI 也认同，它就运行在 Puppeteer 上。问题在于你的智能体看到什么。原始 Puppeteer 输出用 DOM 淹没上下文；AWI 把同一页面变成紧凑、语义化、可引用、为智能体推理而生的快照。
$ npx agent-web-interface install