Notte：把脚本的确定性和 AI 的灵活性拼进同一个浏览器会话
Cloud browser infrastructure and web automation platform for your AI and coding agents
秒懂
- 它是什么？
- Notte 是一个 Python 网页自动化框架，本地开源核心负责 Agent 运行与结构化输出，托管 API 负责反检测浏览器、凭证库和数字身份。它的核心判断是：能用脚本写死的地方不要交给模型。
- 适合谁用？
- 适合已经在用 Playwright 或 browser-use、但被 LLM 调用成本和步骤不稳定拖住的人：先在本地模式跑通 notte.Session 与 notte.Agent，确认自己的任务里有多少步骤可以改写成确定性脚本，再决定是否注册 Console 换托管会话。不适合两类人：一是不能接受 SSPL-1.0 的组织，二是必须完全离线自托管、又不愿意自己实现反检测与凭证管理的人，因为 Vault、Persona、CAPTCHA 处理都写在 API 服务那一侧。
- 能商用吗？
- 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
Notte 想省掉的不是代码，是模型调用次数
多数网页 Agent 框架的默认姿势是把整个流程交给模型：打开页面、看无障碍树、决定点哪里、再看、再决定。步骤一多，token 账单和失败率一起涨。Notte 的 README 把这件事说得很直白，它主张把确定性部分写成脚本，只在需要判断的地方调用 AI，并称这样可以降低 50% 以上的成本。这个说法来自项目方自己的表述，没有第三方复现，读者应当把它当作设计目标而不是实测结论。
目标用户因此比较明确：已经写过 Playwright 脚本、知道登录和翻页这类步骤根本不需要模型的人。Notte 提供的不是又一个「一句话完成任何网页任务」的黑盒，而是一套把脚本和 Agent 混在同一个 session 里的接口。README 里那句「combines AI agents with traditional scripting」是整篇文章里最值得记住的一句。
本地核心与托管服务的分界线画在哪里
仓库把功能切成两半。开源核心包含三样：给 Agent 下达自然语言任务、用 Pydantic 模型约束返回值、以及观察页面状态并执行动作（README 称其为一组与 Playwright 兼容的原语加自然语言命令）。托管 API 那一侧则是隐身浏览器会话、CAPTCHA 处理、代理、反检测、Secrets Vault、Digital Persona 和所谓混合工作流。
这条分界线决定了你迁移的代价。README 给出的迁移方式是把 import 从 notte 换成 notte_sdk，并把对象前缀从 notte 换成 client。听起来很轻，但真正被换掉的是运行位置：本地模式跑在你自己的机器上，需要自备 LLM API key；SDK 模式跑在 Notte 托管的浏览器里，需要先在 console.notte.cc 注册并拿到 NOTTE_API_KEY。也就是说，本地能验证的是 Agent 逻辑，验证不了的是反检测和凭证托管。
一次 agent.run 里发生了什么
从 README 的示例看，数据流是三层嵌套。最外层是 Session，它持有浏览器实例，本地模式下接受 headless 参数，SDK 模式下接受 open_viewer 和 browser_type 参数。中间是 Agent，构造时接收 session、reasoning_model 和 max_steps。最里面是 agent.run，接收 task 字符串，可选地接收 response_format。
reasoning_model 用的是 LiteLLM 风格的字符串，例如 gemini/gemini-2.5-flash，这意味着模型选择不在 Notte 内部硬编码，而是交给 LiteLLM 路由。max_steps 是显式的步数上限，默认示例里从 10 到 30 不等。这个参数很重要：它既是成本闸门，也是失败模式。任务比预期复杂时，Agent 会在步数耗尽后停下，而不是无限重试。README 没有说明耗尽时的返回结构长什么样，这是文档里一处明显的空白。
结构化输出走的是 response_format 参数。示例里定义了 HackerNewsPost 和 TopPosts 两个 Pydantic 模型，把标题、URL、积分、作者、评论数固定成字段。相比让模型自由返回 JSON 再自己解析，这种做法把校验前移到了框架层。代价是任务描述必须和模型字段对得上，模型写错字段名时 Agent 会去凑一个不存在的结构。
Vault 和 Persona：便利与锁定是同一件事
Vault 的用法是在 with 语句里和 Session 并列打开，用 vault.add_credentials 传入 url、username、password，然后把 vault 作为参数交给 Agent。之后 Agent 在遇到登录页时会自己去取这些凭证。README 的原话是「the agent automatically uses these credentials when needed」，但自动匹配的规则没有在 README 里展开，只给了 x.com 这一个例子。
Persona 走得更远，它提供唯一邮箱、电话号码和自动 2FA，示例里用 create_phone_number=False 控制是否申请号码，面向的是批量注册账号这类场景。这两个功能都只在 API 服务侧，本地开源核心没有对应实现。对个人开发者来说这是省事，对合规敏感的组织来说这是把账号和密码交给了第三方。README 用「Enterprise-grade credential management」形容 Vault，但仓库里没有给出加密方式、密钥托管位置或审计日志的任何细节，选型时应当直接向官方索取这部分材料。
安装命令短，环境假设不少
README 给出的安装只有两行：pip install notte，然后 patchright install --with-deps chromium。第二条命令值得注意，它说明浏览器层用的是 patchright 而不是上游 Playwright。patchright 是 Playwright 的一个补丁分支，通常用于规避自动化检测。README 在描述站点交互时说的是「Playwright compatible primitives」，兼容不等于相同，如果现有脚本依赖 Playwright 的某些内部行为，迁移时可能要逐条验证。
Python 版本要求写在徽章里：3.11+。本地模式还需要自己准备 LLM key，示例用 dotenv 从环境变量读取。SDK 模式则需要 NOTTE_API_KEY。这两套凭证是分开的，本地跑通不代表 SDK 跑得通。
另一个容易忽略的点是 --with-deps，它会尝试安装系统级依赖。在没有 root 权限的容器或受限 CI 环境里，这一步可能失败，而 README 没有给出替代路径。
基准表是自家评测，读的时候要打折
README 里有一张对比表，Notte 在自报得分 86.2%、LLM 评估 79.0%、单任务 47 秒、任务可靠性 96.6% 四项上都排第一，对比对象是 Browser-Use 和 Convergence 的 proxy-lite。表格下方指向的仓库是 nottelabs/open-operator-evals，也就是评测方法由项目方自己维护。
这不是说数字有问题，而是说它回答的是「在 Notte 选的这套任务和评分口径下谁更好」。任务集构成、LLM 评估用的裁判模型、可靠性如何定义，这些都不在这份 README 的范围内。真正有参考价值的是那列时间：47 秒对 113 秒，如果这个差距在你自己的任务上成立，它对应的是真实的等待时间差异。判断方法只有一个，拿你自己最常跑的三个任务，用同一套模型分别测一遍。
什么时候 Notte 是错的工具
如果目标站点只有固定几个页面、字段长期不变，直接写 Playwright 更省事。引入 Agent 意味着引入一个每次运行都可能走不同路径的组件，调试成本远高于选择器。Notte 的价值出现在页面结构会变、或者需要模型判断「这条信息算不算我要找的」的场合。
另一个边界是许可。仓库的 License 字段是 NOASSERTION，README 徽章指向 SSPL-1.0。SSPL 不是 OSI 认可的开源许可，它对「把功能作为服务提供给别人」有额外要求，通常需要公开服务化部分的源码。把 Notte 嵌进内部工具和把它做成对外 SaaS，是两件法律后果完全不同的事。这里不构成法律意见，但选型会上应该有法务在场。
还有一类情况要提前想清楚：任务本身需要登录态长期保持、或者需要跨会话复用浏览器指纹。本地模式的 Session 是上下文管理器，退出即关闭，README 没有展示持久化配置。
版本节奏说明的维护成本
最近的三个发布是 v1.8.41、v1.8.40、v1.8.39，日期分别是 9 月 9 日、8 日和 7 日，基本一天一个补丁版本。这种节奏对使用者意味着两件事：项目在活跃维护，同时 API 表面可能还在动。1.8.x 这个号段说明它已经过了早期重构阶段，但日更补丁通常对应的是修 bug，而不是加功能。
对采用方的实际影响是锁定版本。pip install notte 会拉最新版，如果你把 Agent 逻辑写进生产流水线，应当固定到具体版本号并定期手动升级，而不是让 CI 每次装最新的。升级时要重点看两处：Agent 构造参数和 run 的签名，因为这两个地方直接决定你的调用代码能不能跑。
托管 API 那一侧的升级成本不由你控制。Session、Vault、Persona 的行为变更会直接作用到线上，README 没有提到 API 版本协商机制。这一点在评估阶段就该问清楚。
编辑结论
适合已经在用 Playwright 或 browser-use、但被 LLM 调用成本和步骤不稳定拖住的人：先在本地模式跑通 notte.Session 与 notte.Agent，确认自己的任务里有多少步骤可以改写成确定性脚本，再决定是否注册 Console 换托管会话。不适合两类人：一是不能接受 SSPL-1.0 的组织，二是必须完全离线自托管、又不愿意自己实现反检测与凭证管理的人，因为 Vault、Persona、CAPTCHA 处理都写在 API 服务那一侧。动手前先验证三件事：patchright install --with-deps chromium 在你目标系统上是否装得上、你选的 reasoning_model 在本地模式下是否被 LiteLLM 正确路由、以及 agent.run 的 max_steps 在你的真实任务上够不够用。
社区笔记