来源：市场资讯
（来源：石臻说AI）
石臻说AI
编辑：石臻
导读： 微软研究院开源了一个叫 Webwright 的浏览器 Agent 框架。它最有意思的地方，不是让模型更会“点击网页”，而是干脆把网页任务变成一段可以复跑的 Python 脚本。
这件事听起来有点反直觉：浏览器 Agent 的下一步，可能不是更精细地模拟人手，而是回到开发者最熟悉的终端。
不是再学会点击，而是先写出程序
过去很多 Web Agent 的思路，是把浏览器当成一个持续存在的工作台：模型看一眼页面，决定下一步点哪里、输入什么、滚到哪里。这个范式很像人在远程操控网页，只是把手换成了模型。
Webwright 的想法更偏“工程师脑回路”。
它给模型的不是一个固定浏览器窗口，而是一个终端、一个本地工作区，以及可以随时启动和丢弃的浏览器会话。模型要完成网页任务，就写 Playwright 脚本，跑脚本，保存日志和截图，再根据报错继续修。
说白了，浏览器不再是 Agent 的记忆。真正留下来的，是代码、日志、截图和最终脚本。
这点很关键。一次订机票、筛选职位、比较票价、填写复杂表单，如果只是“点、输、滚”的动作链，出错后很难复用。但如果它变成一段脚本，下次换个日期、换个城市、换个筛选条件，就有机会直接改参数跑。
Webwright 到底怎么跑
官方把 Webwright 讲得很克制：三块东西，一个 Runner，一个 Model Endpoint，一个 Terminal Environment。项目页说整个 harness 约 1K 行代码，README 里也强调没有多 Agent 系统、没有图引擎、没有隐藏编排层。
它的循环大致是这样：
环节Webwright 做什么给任务Runner 把用户任务、工作区状态和最近观察交给模型写命令模型输出思考块和 shell 命令，常见动作是写 Playwright 脚本跑脚本环境执行命令，返回终端输出、截图、日志或报错修到完成模型根据观察修脚本，最后在新目录复跑并做自检
这个设计的好处，是把复杂网页操作压回到了代码能力里。日期选择、分页抓取、筛选条件、表格抽取，都可以变成循环、函数和等待条件，而不是让模型每一步都猜一个坐标。
但它也带来两个麻烦：模型可能过早宣布完成，长任务又容易把上下文撑爆。
Webwright 的处理方式也很“轻”：完成前必须生成 final script，在新目录里复跑，保存日志和截图，再跑自我检查；长轨迹每 20 步压缩成摘要，具体证据仍然留在工作区文件里。
Webwright 真正押注的，不是“浏览器会话”，而是“可检查、可复跑、可改造的工作区”。
为什么这组成绩值得看
官方给了两组核心 benchmark。
第一组是 Online-Mind2Web：300 个真实网站任务，覆盖 136 个站点。Webwright 搭配 GPT-5.4，在 100 步预算下做到 86.7% 自动评测准确率；Claude Opus 4.7 是 84.7%。更细一点看，GPT-5.4 在简单和中等任务上更强，Claude 在 hard split 上更强。
第二组是 Odysseys：200 个长链路网页任务，任务描述平均 272.3 个词，更接近现实里那种“跨多个页面查资料、比较、筛选、输出结果”的工作流。Microsoft Research 博客里写，Webwright + GPT-5.4 达到 60.1%，平均 76.1 步；当时榜单前一个 SOTA 是 Opus 4.6 的 44.5%。
这里最值得看的，不是单纯分数高。
真正有信号的是：同一个底座模型，从“看截图猜 xy 坐标”换到“写代码控制浏览器”，成绩明显上来了。也就是说，模型能力没有变，动作空间变了，结果就变了。
这对做 Agent 的人是个提醒：很多时候，瓶颈不在模型有多聪明，而在我们把它关进了怎样的操作框。
浏览历史，开始变成可复用资产
Webwright 最有想象力的部分，是它把一次网页任务的“浏览历史”沉淀成了脚本。
官方博客提到，GPT-5.4 在 Online-Mind2Web 上平均每个任务成本约 2.37 美元。这个数字单看不低，但产物不是一次性的点击轨迹，而是一段可复用的 RPA 风格脚本。更有意思的是，当这些脚本被包装成参数化 CLI 工具后，小模型也能吃到红利。
官方给的例子里，Qwen3.5-9B 在有 5 个以上工具可用的网站任务上，能通过选择正确工具完成任务；项目页还写到，在 Online-Mind2Web hard split 上，Qwen3.5-9B 加上 crafted reusable tools 能到 66.2%。
这就是 Webwright 比“浏览器自动化 demo”更值得关注的地方。
一次成功任务，如果只停留在浏览器状态里，结束就消失了。一次成功任务，如果留下的是脚本、参数、截图和日志，它就可能进入工具库，被下一个 Agent 调用，被小模型复用，被人类审查和维护。
这也是为什么 Webwright README 里专门写了插件形态：它已经提供 Claude Code 和 OpenAI Codex 的插件 manifest，共用 skills/webwright/ 目录。换句话说，微软不是只在做一个独立 Agent，而是在把“网页任务写成程序”这套能力塞进现有 coding agent 的工作流里。
但它不是银弹
要说实话，Webwright 这条路也有边界。
第一，脚本会老。网页结构一改，按钮文案一换，原本能跑的 Playwright 脚本就可能静默失败。所以脚本库不是越大越好，它需要验证、淘汰和更新机制。
第二，脚本粒度很难拿捏。太细，就会碎成一堆“点日期”“填表格”的小工具；太粗，又变成只适用于某个具体任务的大块自动化。这个分寸，可能比模型写出第一版脚本更难。
第三，低层动作仍然有价值。不是每个网页都能被结构化地操作，也不是每个任务都值得写脚本。对于新奇、脆弱、临时性的页面，回到截图、点击、输入这些人类式动作，反而更通用。
所以我更愿意把 Webwright 看成一个方向信号：当模型越来越会写代码，Web Agent 不一定非要沿着“更像人类鼠标”的路线往前走。它也可以更像一个会调试自动化脚本的工程师。
Webwright 的核心启发是：网页任务不该只是一串会话动作，也可以是一段留下来的程序。短期看，它是一个轻量级开源 harness；长期看，它在提示我们，Agent 的记忆可能不在聊天记录里，而在可复跑的工作区里。
- Webwright 项目页：https://microsoft.github.io/Webwright/
- Webwright GitHub 仓库：https://github.com/microsoft/Webwright
- Microsoft Research 博客：https://www.microsoft.com/en-us/research/articles/webwright-a-terminal-is-all-you-need-for-web-agents/
热门跟贴