从浏览器会话到写代码：终端原生 Web Agent 如何改变自动化

很多人一想到网页自动化，就觉得 AI 必须一直控制浏览器——点按钮、填表单、翻页面，一口气做完。看起来很自然，但其实这可能就是限制自动化的最大瓶颈。

有状态浏览器的麻烦

传统的 Web Agent 跟浏览器会话绑得太死。就像飞行员被锁在驾驶舱里，每一步操作都依赖上一步。如果中途出问题，你就得去排查一堆纠缠在一起的动作。Agent 只能按顺序预测下一步点哪里、输什么，但「做决策的大脑」和「真正执行的浏览器」之间没有清晰的分界。

这带来几个实际问题：

• 状态越来越乱：长会话会堆积各种意外情况
• 调试困难：想单独检查或重跑某一部分，几乎不可能
• 无法复用：每个任务都从零开始，哪怕之前解决过类似问题

Webwright 的做法：浏览器用完即弃，代码留下来

Webwright 完全反其道而行。它不保留一个浏览器会话，而是需要的时候就开一个新的浏览器实例。用完就扔，只保留代码、日志、截图和输出文件——这些都存在你本地的文件夹里。

浏览器只是一个临时工具，真正有价值的是你写出来的代码。

三个核心思路

1. 用代码代替一连串操作

不用写「点按钮 → 等加载 → 填文字 → 提交」这种长链条，Webwright 让 Agent 写成可复用的函数。日期选择、填表、筛选、比对、提取数据——这些都可以封装成循环和函数，而不是一堆原始的浏览器动作。代码更干净，也更容易维护。

2. 留下能长期保存的成果

每次任务都会生成一些实际文件：探索用的脚本、操作日志、关键步骤的截图，最后还能产出一个可复用的任务程序。这些东西留在工作区里，可以反复查看、分享，也能作为下次自动化的基础。

3. 架构尽量简单

整个系统就三样东西：Runner、Model Endpoint 和终端环境。加起来大概 1000 行代码。没有复杂的多 Agent 调度，也没有层层规划逻辑，就是一个简单的反馈循环。

工作循环是怎么跑的

Webwright 的核心逻辑其实很简单：

1. Runner 把任务描述、工作区状态和最近的观察结果发给模型
2. 模型思考后返回一条 shell 命令，通常是写一段 Playwright 脚本去探索页面
3. 环境执行命令，把输出、日志、截图、文件或错误信息返回
4. 循环继续，直到 Agent 写出最终脚本、在干净环境里跑一遍、通过自我检查

没有复杂的路由，也没有决策树，就靠终端、模型和不断积累的工作区。

实际效果

在真实网页任务上的测试结果相当亮眼：

• Odyssey 长周期浏览基准：准确率 60.8%，比之前的最优水平提升了 35.1%
• Online-Mind2Web 300 个跨 136 个网站的实时任务：准确率 86.7%，限制在 100 步内完成
• 即使只用 Qwen 3.5-9B 这种小模型，加上可复用的工具后也能达到 66.2% 准确率

这些都不是玩具级测试，而是真实网站和真实任务。

如何控制终端操作带来的风险

让 Agent 直接操作终端，能力强，但也容易出问题。Webwright 加了几道简单的限制：

完成前检查：Agent 不能直接说「我做完了」。它必须先生成最终脚本，在全新环境里跑一遍，保存日志和截图，再通过自我反思检查。

压缩上下文：长任务容易撑爆模型的上下文窗口。Webwright 会定期把历史对话压缩成摘要，但把实际文件保留在工作区里。这样既不丢信息，上下文也不会太长。

复用工具：一旦解决了一个任务，脚本可以改成带参数的 CLI 工具，分享给其他 Agent 用。下次遇到类似问题就不用再从头写了。

对开发者的启发

如果你在做自动化系统、爬虫，或者 AI 辅助工作流，Webwright 的思路值得参考：

• 把「决策」和「执行环境」分开
• 浏览器可以丢，代码和文件要留下来
• 多写函数和循环，少写一连串原始操作
• 让 Agent 在真正完成前，先验证一遍自己的方案

终端在这里不只是个界面，它就是工作区。代码、日志、文件都留在这里。浏览器是临时的，终端才是长期存在的。

更大的意义

以前的网页自动化，基本思路是把状态机做得更复杂。Webwright 给出了另一种思路：让 Agent 去写代码，而不是去操作状态。浏览器可以随时扔掉，工作区才是真正持久的东西。

这个方向还很新，但它提示我们：构建更可靠、更容易维护的 AI 系统，可能不需要越来越复杂的架构。只要让 Agent 学会写代码、迭代、复用，就能走得更远。

如果你也在研究 Agent 系统、网页自动化或 AI 辅助开发，Webwright 的终端原生思路值得看看。代码在 GitHub 上开源，效果也经过验证，核心理念就一句话：一个终端就够了。