别再手搓脚本了：Libretto 想把 AI 浏览器自动化从“能跑”带到“可维护”
一个新项目，盯上了浏览器自动化最烦人的老毛病
GitHub 上最近冒出一个叫 Libretto 的开源项目，来自 saffron-health。项目给自己的定位很直接：The AI toolkit for building and maintaining browser automations。翻成大白话，就是一套用来构建、维护浏览器自动化的 AI 工具箱。
这听起来像是又一个“让 AI 帮你操作网页”的项目。但如果你做过一点 RPA、Selenium、Playwright，或者只是写过公司后台自动填表脚本，你就会知道，真正折磨人的从来不是“让它第一次跑起来”，而是“让它三个月后还跑得起来”。页面一改版、按钮文案一变、DOM 结构一挪，昨天还勤勤恳恳的自动化脚本，今天就像喝醉了一样，到处点错。
Libretto 的价值，恰恰就落在这个行业老毛病上。它不是只想做一个炫酷的 AI 演示，而是试图把“浏览器自动化的生命周期”这件事认真做一遍：从生成 workflow，到处理下载、错误恢复，再到跑 benchmark 做评估。换句话说，它关心的不只是自动化能力本身，还关心自动化在真实环境里怎么活下去。
从仓库状态看，这不是一个随手丢上来的实验品。项目已经有上千次提交，分支和标签都不少，最近还在持续发版，文档、CLI、benchmark 框架也在演进。Star 数不算夸张，但这类偏工程基础设施的项目，本来也不是靠“爆红”吃饭，而是靠能不能帮团队少熬夜。
AI Agent 正在补上“从 Demo 到生产”的断层
过去两年，浏览器 Agent 是 AI 圈最热闹也最容易翻车的赛道之一。OpenAI、Anthropic、Google 以及一批创业公司都在展示：模型可以看网页、理解页面、点击按钮、填写表单，像真人一样完成任务。演示视频都很惊艳，问题是，演示结束之后怎么办？
浏览器是一个非常不稳定的环境。网页不是 API，不会老老实实保持字段一致、响应可预测。前端团队今天换个 className，明天调一下按钮层级，后天弹个新浮层，自动化系统就可能原地崩溃。传统 RPA 工具对此的解法往往是更精细地写规则，结果规则越堆越多，维护成本也越高。AI Agent 的解法则是让模型“看懂”页面并临场发挥，但这又带来另一个问题：智能是有了，稳定性和可追责性却未必跟得上。
Libretto 的思路有点像在这两种路线之间搭桥。它没有把希望全押在模型即兴发挥上，而是把 workflow、命令行工具、文档生成、评估基准这些工程化组件也拉进来。这很关键。因为企业真正需要的不是“AI 偶尔能神奇地做对一次”，而是“AI 大多数时候都能可预测地完成任务，出了问题还能复盘”。
从仓库提交记录里也能看出这个方向。项目在 benchmark 上做了不少调整，甚至把测试框架简化到围绕 WebVoyager 这类任务来跑，还加入了 transcript、prompt、result 等运行产物保存。这说明开发团队越来越在意：不是只看最后成没成功，而是要能看到它中间是怎么一步步做决定的。说得再直白点，Agent 时代最值钱的不是“自动操作”，而是“自动操作的可观测性”。
它为什么值得关注：因为行业正在从“会操作”转向“能交付”
如果把这波 AI 浏览器工具分成两类，一类偏消费级，主打“你说一句，它替你订票、找商品、填表”；另一类偏开发者和企业，主打“让团队把浏览器里的重复流程系统化”。Libretto 显然更接近后者。
这在当前时间点尤其值得看。原因很简单，大家已经逐渐接受一个现实：大模型会用浏览器，不再是新闻；真正的新闻，是谁能把这种能力包装成可靠的生产工具。过去一年，无论是网页 Agent 还是电脑操作 Agent，行业都在经历相似的降温过程——不是热度没了，而是滤镜淡了。投资人和企业用户都开始追问同一个问题：除了 demo，这东西到底怎么上线？
Libretto 给出的答案还谈不上完美，但方向是对的。它在文档里覆盖安装、API key 设置、文件下载、workflow 生成等内容，还在 CLI 帮助文本上持续做简化，说明团队正在降低使用门槛。这种工作很不性感，却很重要。很多开源 AI 项目死得并不冤：模型接得很炫，开发体验却一团糟，最后只能留下一堆 README 里的“coming soon”。
而 Libretto 让我比较在意的一点，是它没有把 benchmark 当成装饰品。Agent 产品最怕“自我感动式指标”——自己定义任务、自己评分、自己宣布胜利。引入更接近真实网页任务的数据集和评估流程，至少是在逼自己面对现实。哪怕 benchmark 也远远不能代表生产环境，它依然比“我这边跑得挺好”要诚实得多。
但它也绕不过一个争议：AI 自动化越聪明，系统边界就越模糊
我对这类项目一直有一个复杂的情绪：一方面真心期待，另一方面也会警惕。期待是因为谁都知道，浏览器里埋着大量低价值重复劳动。医院后台、保险录入、供应链系统、政府门户、老旧 ERP，多少人每天都在和一堆并不友好的网页互相折磨。如果 AI 真能把这些工作接过去，人类至少能少点机械点击，多做点判断。
但警惕也是真的。浏览器自动化一旦接入大模型，边界会变得比传统脚本更模糊。它不再只是“按照固定规则执行”，而是会“理解上下文后行动”。这会带来更强适应性，也会带来更高风险：它看到的页面信息是否包含隐私？它在下载、上传、点击确认时有没有权限控制？一旦模型误判，它会不会在错误的系统里提交错误的数据？
尤其 Libretto 背后是 saffron-health，这个名字天然让人联想到医疗场景。医疗是最需要自动化的行业之一，也是最不能出错的行业之一。AI 自动化如果进入这样的高敏感领域，工程能力和合规能力必须一起长大。否则，“省下几分钟人工点击”可能换来的是更昂贵的事故成本。
这也是我觉得 Libretto 接下来最值得观察的地方：它能不能把“维护自动化”这件事继续往前推进到权限管理、审计追踪、失败恢复、人工接管这些更现实的层面。浏览器 Agent 只有学会优雅地失败，才有资格谈大规模上线。
开源世界正在给 Agent 赛道打地基
放到更大的背景里看，Libretto 的出现有点像一块地基，而不是一座摩天楼。它不像面向消费者的 AI 产品那样容易出圈，却可能对整个 Agent 生态更重要。因为任何一个行业要成熟，都需要一批“不那么耀眼但非常必要”的基础设施：测试框架、可复用 workflow、CLI 工具、调试日志、发布流程、文档规范。
过去开源自动化世界里，Selenium 解决的是浏览器控制，Playwright 把现代网页测试和自动化做得更优雅，RPA 厂商则在企业流程层面做封装。现在到了大模型时代，新的空白是：怎么把模型能力嵌进这些传统栈里，同时不丢掉工程纪律。Libretto 某种程度上正在回答这个问题。
它未必会成为这个领域最后的赢家，甚至未必会成为最知名的名字。但它代表了一种越来越清晰的趋势：AI Agent 竞争的下半场，拼的不是谁更会讲“智能故事”，而是谁更会做“维护系统”。这听上去不够性感，却恰恰是技术真正开始落地的信号。
对开发者来说，Libretto 这类项目还有一个现实意义：它提醒大家，别再把浏览器自动化只当成“让脚本替我点网页”的老问题。今天的浏览器自动化，已经在变成一个融合了模型推理、工具调用、任务评估和可靠性工程的新系统工程。你需要的不只是 prompt，还需要日志、回放、测试、回滚，以及对失败保持敬畏。
说到底，真正成熟的自动化从来不是“它会不会点击”，而是“出了问题后，谁能看懂它为什么这么点”。如果 Libretto 能继续沿着这条路走下去，它可能不会成为最喧闹的明星项目，却很有机会成为很多团队 quietly depend on 的那种底层工具——平时没人夸，一停机全公司都知道它的重要。