📌 项目地址：microsoft/Webwright | ⭐ 5,613 颗星 | 🔧 Python | 📜 未标注
传统Web Agent的模式与瓶颈
目前主流的浏览器Agent方案，都遵循一个基本范式：LLM在浏览器会话中逐步交互，每一步接收当前页面状态，然后预测并执行单一操作——点击、输入、选择DOM元素或调用某个工具。这种“状态化浏览器会话”在当时LLM能力有限时是合理的，但如今模型已经能熟练写代码和调试，这个框架反而成为瓶颈。每个Web任务被切割成数百个微小步骤，每一步都需要重新理解页面，遇到动态加载或重渲染时尤为脆弱。更重要的是，交互轨迹不可复现、不可审计、难以迁移——这次跑通了，下次换环境又要重来。
Webwright的解决方案：终端即Agent的工作台
Microsoft推出的Webwright（Star 5600+）颠覆了这个模式。它的核心理念只有一句话：
LLM获得一个终端，在终端里它可以启动多个浏览器会话，只在必要时捕获页面截图或状态。最终，每个Web任务被强制写成一个可重复运行的Python脚本。整个浏览历史就是一份代码文件。
没有多Agent系统，没有图引擎，没有插件层，没有隐藏编排——只有一个终端、一个浏览器和一个模型。Webwright将Agent和浏览器彻底分离：浏览器只是Agent可以随时启动、检查、丢弃的资源，而持久的产物是本地工作区中的代码和日志。
这种做法带来了几个关键变化：
- 鲁棒且可复用的交互：Agent用代码查询元素、等待条件、处理懒加载或重新渲染，而不是依赖脆弱的像素级坐标。生成的脚本可以反复运行、修改、分享。
- 复杂工作流的高效组合：多步骤操作（比如选择日期、填写表单）被压缩成紧凑的循环和函数。Agent可以利用编程抽象（循环、分支、函数调用）来处理同类任务，不需要每次从头推理。
- 完整的可审计性：最终产物是一个Python脚本，记录了Agent每一步决策和操作，任何人都可以检查、调试、重放。
如何上手
Webwright目前是Python项目，安装方式推荐直接查看官方仓库的README或文档。据README透露，它支持OpenAI、Anthropic、OpenRouter后端，运行环境依赖Playwright。对于已经在使用Claude Code、Codex、OpenClaw或Hermes Agent的用户，Webwright提供了插件/技能包，可以直接通过命令加载：
/plugin install webwright@webwright
该技能包位于仓库的 skills/webwright/ 文件夹，可以在上述Agent间共享使用。
注意：由于README没有给出独立的 pip install 或启动命令，首次使用时请以官方文档的最新说明为准。
独特优势：放弃会话持久化，拥抱代码持久化
如果拿Webwright与同类工具（如Browser Use、LangChain的Web Agent、AutoGPT等）对比，最核心的不同在于：
| 方面 | 同类工具 | Webwright |
|---|---|---|
| 交互记录 | 浏览器会话日志、截图 | 可重跑的Python脚本 |
| 错误恢复 | 依赖模型重新理解上下文 | 可直接修改脚本重新执行 |
| 跨任务复用 | 几乎为零 | 脚本可被复用、参数化、组合 |
| 调试成本 | 高，需要回放每一步 | 低，直接调试代码 |
| 架构复杂度 | 有多Agent编排、工具链 | 极简：终端+浏览器+模型 |
Webwright追求的是：让Agent像程序员一样写自动化脚本，而不是像人类一样在浏览器里点来点去。这抓住了当前LLM代码能力强的红利，也解决了Web自动化长期存在的可复现性痛点。
注意与局限
- Webwright非常新（2025年5月发布），仍在快速迭代中。目前支持Task2UI模式，可以将任务结果渲染为HTML应用，但整体生态尚不成熟。
- 对LLM的代码生成能力要求较高。如果模型本身写代码能力弱（比如小参数模型），可能无法有效生成正确的浏览器操作脚本。
- 依赖Playwright后端，需预先安装浏览器驱动。
- 许可证信息请查看项目仓库，当前README未明确指出。
- 目前仅支持OpenAI/Anthropic/OpenRouter，对于私有模型或本地部署模型需要额外适配。
对于什么样的用户值得关注？ 如果你的工作流需要多次重复执行某个Web任务（例如每日数据抓取、每周表单填报），或者你希望Web Agent的行为完全可审计、可调试、可版本控制，那么Webwright提供的代码化方案比传统会话式Agent更适合。相反，如果你只需要一次性的简单交互（如“帮我查个天气”），传统Agent可能更直接。
本文基于 microsoft/Webwright 的README撰写，所有引用均来自官方描述。