Scrapewright 开源：让 AI 代理的重复网页抓取告别「掷骰子」

2026 年"AI + Web"的默认形态是 agentic browsing：给模型一个浏览器，让它按任务执行 look-click-wait-extract。看着它工作的感觉像是未来。把它放进生产环境会让你真正体会到它的经济学真相：每次运行都要重新感知同一批页面，每次运行都要为每次翻页支付 token，每次运行都是一次全新的掷骰子——它今天点的按钮和昨天点的是否一样。对于探索性任务，很美好。对于重复提取——每日看板拉取、逐项查询、定时监控——这个模式完全不对。

更老派的工程直觉是：重复的工作应该放在工具里，而不是放在方向盘上。Scrapewright 就是这个直觉的产品化——一个开源平台，LLM 构建一次爬虫服务，之后的一切都是你 agent 可以发出的确定性 HTTP 调用。

分工

构建时（LLM，一次）：用自然语言描述要提取的内容。向导的 AI 在你真实的浏览器中打开目标页面，多轮研究其结构（候选选择器对照实际元素 HTML 确认，而非猜测），针对一个 19 个原语的 DSL 生成步进图程序，测试运行，失败时自我修复。结果：一个已部署的服务，声明了输入/输出的 JSON Schema。

运行时（无 LLM，永远）：你的 agent——或者 cron、或者你的应用——调用：

POST /api/v1/services/{name}/execute   {"input": {"query": "..."}}
GET  /api/v1/jobs/{id}/wait?timeout=120

结构化的 JSON 返回，每条记录都标注了它来自哪个页面。快速（无模型延迟）、免费（无 token 消耗）、确定性（每次运行步骤一致）。

修复时（LLM，失败时）：当网站重新设计导致服务报错，Auto-Fix 将失败的步骤 + DOM 快照反馈给模型并重写它。工具无需人工介入或 agent 重新学习页面即可自我修复。

我最希望你注意的 agent 面向细节

每个 Scrapewright 服务都可以导出其 Markdown 格式的 API 文档——端点、schema、示例，均从服务定义生成。README 中明确说明了预期工作流：把这个文档交给你的 agent（文档中以 Hermes Agent、WorkBuddy 和 Lobster 为例），让 agent 为调用该服务构建自己的工具封装。这是比大多数"agent + 爬虫"集成更清晰的模式，因为它分离了两个一直被混为一谈的工作：

判断需要什么数据、何时需要 → agent（擅长判断，拙于重复）。

获取数据 → 稳定的 HTTP 服务（擅长重复，重复时免费）。

agent 不需要看到目标网站的 DOM、不需要在页面感知上消耗 context、也不需要保持浏览器会话打开。它只需要一次工具调用以及一个被交付给它的 schema。你的 context 窗口——以及你的 token 账单——可以把消耗留在你真正雇佣模型做的事情上。

为什么"客户端"让工具层更强

服务运行在真实的 Chrome 上，通过扩展实现——你的登录态、你的会话、你的指纹。所以工具层可以覆盖服务端爬虫在结构上无法覆盖的来源：SSO 后的 SaaS 仪表盘、付费档案库、内部门户。当你的 agent 需要"运营仪表盘昨天的数字"时，以前的可行选项是 (a) 用存储凭证做 agentic browsing，或 (b) 一个不存在的集成。现在有了 (c)：一个确定性的本地端点，它就是你的凭证访问渠道，用 schema 封装起来。完全自托管，localhost 上一个 API key，运行时路径中没有任何东西向任何云端打电话——LLM 或其他。

编译时工具假设任务会重复。真正探索性的、一次性的、每个网站都不同的工作仍然是 agentic browsing 的领地，项目自己的文档也这么说了。有趣的设计空间是混合形态——一个 agent 自主地为它检测到的重复任务构建 Scrapewright 服务，然后不再操心它们。这方面的所有部件都在盒子里：向导 API、服务导出/导入为 JSON、每个服务的 Markdown 文档 agent 可以消费。

仓库：github.com/singhand-labs/scrapewright — GPLv3，README 中有快速入门，白皮书里有架构说明。如果你在构建会接触 Web 的 agent，花一个晚上做一个服务，然后把你的 agent 指向它的 API 文档——延迟、成本和抖动的下降就是全部的理由。