点击上方 前端Q关注公众号回复加群加入前端Q技术交流群5 月 24 日微软研究院 AI Frontiers 实验室在 GitHub 扔出了一个名叫Webwright的开源项目。我第一眼看到 README 的时候反应是有点没看懂——这玩意儿真的就只有 1000 行核心代码往下翻到 benchmark我又愣了一下模型 / 框架Odysseys 得分Webwright GPT-5.460.1%Claude Opus 4.64 月 leaderboard 第一44.5%基线 GPT-5.4裸调33.5%Webwright 加上 GPT-5.4把 Claude Opus 4.6 干翻了 15.6 个百分点。而 Webwright 本身只有大约 1000 行 Python 代码没有多 Agent 编排、没有 graph engine、没有 plugin layer依赖只有httpx、pydantic、playwright、typer四个。我读完整套源码和论文页microsoft.github.io/Webwright有个非常强烈的感受这是过去半年我看到的最像工程范式宣言的一篇 paper。它在告诉所有人Web Agent 这个赛道过去一年大家都做得太复杂了。这一篇我把这件事完整梳理一遍Webwright 到底干了什么、它凭什么 1000 行就能反超 Claude、它背后的设计哲学是什么、对你今天做 AI Agent 的方式意味着什么。先把 benchmark 数字拆开看很多人看到开源框架反超 Claude会怀疑是不是 cherry-pick 了某个特殊场景我把微软官方公布的 4 个测试数字摆出来你就知道这次不是营销话术。▎Odysseys长链路多网站任务Odysseys 是个相对硬的 benchmark任务平均 272.3 个词的指令长度要跨多个网站完成长链路操作。▸Webwright GPT-5.460.1%▸4 月份 leaderboard 第一名Claude Opus 4.644.5%▸单跑 GPT-5.4 基线33.5%也就是说——给 GPT-5.4 套上 Webwright 这层 harness相对提升 79.4%。▎Online-Mind2Web100 步预算的真实网页这是另一个广泛使用的 Web Agent 测试集▸Webwright GPT-5.486.7%▸Webwright Qwen3.5-9B小开源模型在 hard split 上66.2%注意第二条数据——一个只有 9B 参数的开源模型套上 Webwright 几条预置工具脚本就能在 hard split 上跑到 66.2%。这意味着 harness 这一层的设计可以让小模型的工程效用直接对齐大模型。▎我自己最在意的一个数字微软在 paper 里有一段话我反复看了好几遍the harness is approximately 1,000 lines of code across three modules: Runner, Model Endpoint, and Environment.Runner ~450 行Playwright Environment ~570 行CLI ~150 行。加起来 ~1170 行 Python。对比一下项目代码量级LangGraph数十万行CrewAI数万行OpenAI Agents SDK数万行Claude Code (源码泄露版)51 万行Webwright~1000 行它在做减法做到了一种极致。Webwright 的设计哲学把模型当成程序员不是当成点击工人这才是真正值得反复品的部分。过去一年所有的浏览器 Agent思路是这样的▸给 Agent 一个有状态的浏览器会话▸每一步让 Agent 预测一个离散动作点击哪里、输入什么、滚到哪▸用 DOM 或者无障碍树作为模型的输入▸模型一步一步指挥浏览器Cursor 的 BrowserUse、OpenAI 的 Operator、Anthropic 的 Computer Use本质上都是这一套。Webwright 反着来。它的核心思路用一句话讲A terminal is all you need for web agents.一个终端就够了具体怎么做▸给 Agent 一个本地终端 工作目录▸Agent 不预测点击/输入动作而是写 Playwright 代码 bash 命令▸执行完之后 Agent 看终端输出日志、截图、错误栈然后继续写下一段代码▸任务跑完留下的是一个可重跑的 Python 脚本它不是把 Agent 当点击工人而是当成了一个能写代码的实习生——你说要爬什么它写脚本去爬。这种切换看起来只是一个工程选择但带来的效果是降维的▎优势 1模型擅长的事让模型做LLM 本来就是为写代码训练出来的。让它一步一步预测在 (124, 480) 点击这种事是在用自己最不擅长的能力做事。让它写 Python 脚本这是它训练时见过几亿次的场景。GPT-5.4 在裸调时 Odysseys 33.5%套上 Webwright 跳到 60.1%——这个 26.6 个百分点的差距本质上是从让模型做不擅长的事换成了让模型做最擅长的事。▎优势 2每次任务都留下可复用的脚本传统 Agent 跑完一个任务你得到的是▸一堆点击记录▸一份 DOM 快照▸几个截图▸任务完成的消息下次想做同样的事还得让 Agent 再跑一遍。Webwright 跑完一个任务你得到的是▸一个 Python 脚本▸可以直接重跑▸可以被人手改▸可以扔进 Claude Code / Codex / OpenClaw 当工具复用这是真正的 task → tool 的转化。▎优势 3调试时不像在抓鬼传统 Web Agent 出错你看不出错在哪——模型说我点了这个按钮但 DOM 早就变了你没法精确还原。Webwright 出错是正常的代码报错▸Playwright timeout error▸元素 selector 找不到▸网络请求 4xx / 5xx这些都是程序员日常处理的报错直接贴日志给 Agent 它自己就能改。微软在论文里偷偷讲了一句很狠的话我读 paper 时被一句话戳到了No multi-agent system, no graph engine, no plugin layer, no hidden orchestration — just a terminal, a browser, and a model.翻译过来没有多 Agent、没有 graph engine、没有 plugin 层、没有隐藏编排——就一个终端、一个浏览器、一个模型。这一句话其实是对过去一年整个 Agent 圈的隐含批评。很多框架LangGraph、CrewAI、AutoGen都在做复杂编排——多 Agent 协同、planner-worker 模式、reflection-critique 循环。微软研究院的答案是这些都不需要。最少的 harness 就是最好的 harness。把模型当成有能力的执行者给它合适的工具剩下让它自由发挥。这个理念其实和我之前写 Harness Engineering 系列时反复强调的让模型在能用的层面尽可能简单完全一致。但 Webwright 把这件事做到了极致。它跟 Cursor / Claude Code 的关系聊到这里你可能在想Webwright 这种东西能用在我每天的工具里吗答案是已经可以了。Webwright README 里有一行字Scripts reusable in Claude Code, Codex, OpenClaw意思是 Webwright 跑出来的 Python 脚本直接可以扔进 Claude Code / Codex / OpenClaw 当工具用。我自己已经在想几个落地场景批量爬数据让 Webwright 跑一遍写出脚本扔到定时任务里网页回归测试让 Webwright 写一遍 e2e 流程脚本commit 进项目数据迁移脚本从老后台批量导出数据到新后台跨平台监控每天跑一遍多个网站输出结构化数据给 BI这些都是过去用 puppeteer / playwright 手写脚本要花半天的事Webwright 跑一次就能拿到可复用脚本。它对你今天做 Agent 的方式意味着什么我把这件事的信号梳理给你看三个层面▎信号 1harness 这个层正在被重新评估过去一年的 Agent 框架都在做加法——加更多节点、加更多 agent、加更多记忆机制、加更多 reflection。Webwright 用一组 benchmark 数字证明做减法可能效果更好。这不是说 LangGraph / CrewAI 没用。它们在某些场景复杂的多角色协同依然有意义。但单个 Agent 强工具可能在 80% 的工程场景里就够了。▎信号 2让模型写代码比让模型预测动作更强这是更深一层的信号。未来你做任何 Agent 系统先问自己一个问题这件事能不能让模型直接写代码搞定而不是让模型一步一步指挥工具如果能优先选写代码这条路。模型的 IQ 在这条路上发挥得最足。▎信号 3开源 Agent 框架要重新洗牌5 月份发生的事情其实是连着的▸5 月 14 日Claude Code 上线/goal——把 harness 思想做成一行命令▸5 月 18 日Cursor 发 Composer 2.5——价格腰斩 自研模型路线▸5 月 24 日微软开源 Webwright——1000 行代码反超 Claude三件事连在一起告诉你 Agent 工程范式正在收敛让模型写代码 简洁的 harness 极致的成本控制。那些往复杂编排方向走的项目接下来 3 个月会比较难。我的看法Webwright 这次出来我个人觉得是 2026 年到目前为止最重要的一篇开源工程作品。它不是一个新模型不是一个新产品只是一篇 paper 1000 行代码。但它做了一件更难的事用数据证明了一个反直觉的设计选择是对的。过去做 Web Agent 的所有人都默认浏览器 Agent 应该和浏览器深度耦合。Webwright 把这个假设打穿了浏览器 Agent 应该和浏览器解耦让模型在自己最舒服的语言代码里工作浏览器只是个被驱动的工具。这个思路其实可以拓展到所有 Agent 场景▸桌面 Agent → 让模型写 AppleScript / PowerShell不要让它预测点击▸数据 Agent → 让模型写 SQL / Python不要让它一行一行扫表▸API Agent → 让模型写完整的 fetch 脚本不要让它一个一个调端点Webwright 是这个范式转换的第一个完整证明。接下来 3 个月最值得跟的方向我猜是▸Microsoft Research 会继续在这条 minimalist Agent 路线上发新东西▸OpenAI / Anthropic 的官方 Agents SDK 大概率会内置类似的写脚本模式▸更多垂直 AgentCRM、运营、客服会借鉴 Webwright 的任务即脚本思路如果你想第一时间感受这种范式的差异clone 一下仓库自己跑bashgit clone https://github.com/microsoft/Webwrightcd Webwrightpip install -e .playwright install chromium跑完第一个 demo 你大概率会有一种感觉——原来 Agent 可以做得这么轻、这么稳、这么干净。这才是工程的本来样子。往期推荐Multi-Agent Teams让多个专家 Agent 像团队一样协作AI Agent 是怎么想一步做一步的拆解 ReAct 模式从零开始用 LangChain.js 构建你的第一个 Tool-Calling Agent最后点个在看支持我吧