migrate-to-notte

迁移到 Notte

此技能涵盖一个流程，包含两个入口：

• 路径 A — 仅比较成本。 提供一份只读、注明日期且有证据支撑的决策简报。不会修改代码、凭据、账单或服务商资源。执行阶段 0–3，然后跳转至 §8（外部基准背景）和 §9（决策简报）。
• 路径 B — 完整迁移。 包含路径 A 的全部内容，随后进行安全验证、隔离构建、验证和可逆交接。执行阶段 0–7，然后进入 §9。

根据用户的请求选择路径。如果用户只询问某项服务的成本，执行路径 A 并停止；可将路径 B 作为后续步骤。如果用户要求迁移，则执行路径 B——没有经过测量的基线，所谓迁移就只是重写，而非迁移。

遵循统一、严谨的流程，然后仅加载目标中发现的服务商对应的参考资料。不要混用服务商，也不要仅因 API 名称相似就假定它们等效。

0. 发布执行计划 — 必须首先完成

在使用工具、读取仓库或开展后台工作之前，先在面向用户的主线程中发布此计划。恰好将一个阶段标记为 进行中，其余阶段标记为 未开始。这是进度视图，除非遇到阻碍，否则不需要征求批准。不要将计划隐藏在内部工具中。

对于路径 A（成本比较）：

阶段	结果
1. Notte 设置	已验证快速入门、CLI、技能和已认证的访问权限。
2. 服务商／工作流盘点	已盘点来源、出现位置、工作流和用量。
3. 用量与定价证据	已核实价格，并建立包含低位／基准／高位情景的成本与并发模型。
4. 决策简报	已交付注明日期且有证据支撑的比较结果。

对于路径 B（迁移）：

阶段	结果
1. Notte 设置	已验证快速入门、CLI、技能和已认证的访问权限。
2. 探查	已盘点源文档、出现位置、工作流和风险。
3. 基线	已测量或界定用量、成本、延迟、并发和成功率证据。
4. 安全验证	已公平测试具有代表性的只读 Notte 工作流。
5. 隔离构建	已在生产环境之外构建渐进式实现和测试。
6. 验证	已完成静态分析、测试、审查和非生产环境证据收集。
7. 可逆交接	已交付分支／PR、清理、发布、回滚和已知缺口信息。

每个阶段结束后，发布已完成、进行中或受阻状态、关键证据、下一步行动以及需要作出的任何决定。如果范围或风险发生变化，立即更新计划。更新应简短，并链接到证据，而非原始日志。

如果有后台 Agent，则只能在发布计划后启动。它们可以独立开展只读文档、出现位置或遥测分析。主 Agent 负责安全、计算、实现和用户更新。任何后台 Agent 都不得更改仓库、凭据、账单或生产环境。

1. 完成 Notte 快速入门 — 必经关卡

在检查目标仓库或估算成本之前，阅读并完成 https://docs.notte.cc/quickstart。设置当前 CLI、官方技能和已认证的 API 访问权限。验证：

notte version
notte auth status

如果缺少身份验证，请运行 notte auth login，让用户完成浏览器流程，并每隔五秒轮询状态，最长五分钟。切勿打印、复制或提交密钥。只有通过此关卡后，才能检查目标代码或估算成本。对于路径 A 的成本评估，不要创建会话或更改服务商方案。

2. 确认服务提供商并盘点工作负载

阅读目标项目的源代码、锁文件、CI、IaC、环境模板、工作进程、 队列、计划任务、无服务器函数、部署清单、示例和文档。先使用 rg。 选择所有适用的参考文档，然后阅读其中链接的当前服务提供商页面，再做出设计或定价决策。

检测到的服务提供商	参考文档
Browserbase、Stagehand、@browserbasehq/*	Browserbase + Stagehand
Kernel、@onkernel/sdk、Kernel apps	Kernel
Anchor Browser、anchorbrowser、ANCHOR_*	Anchor Browser
Browser Use Cloud、browser-use、Cloud runs	Browser Use Cloud
Steel、steel-sdk、STEEL_API_KEY	Steel
Hyperbrowser、HyperAgent、HYPERBROWSER_*	Hyperbrowser
Skyvern、skyvern、SKYVERN_*	Skyvern

构建功能矩阵：会话/CDP 或 WebDriver、确定性和 Agentic 路径、输入/输出/错误约定、配置文件/身份验证/2FA、代理/区域/隐身/CAPTCHA、文件/扩展程序、实时视图/回放/产物、异步任务/计划任务、运行时/自托管、可观测性、合规性和测试。记录每个出现位置及其负责人、入口点、副作用和替换类别。将工作流分类为只读、已验证身份的只读、写入/事务性或破坏性。只有前两类可以在无人值守的情况下进行探测。

还要为每个工作流记录触发条件、每日运行次数、每次运行的会话或任务数、扇出、会话复用、重试、实际时长和计费时长、代理/区域、模型和令牌、服务提供商 API/运行时费用、成功率以及观测到的峰值并发数。不要将并发限制误认为每次运行的会话数。

3. 衡量基线与机会

申请只读用量导出/发票以及有代表性的 7–30 天遥测数据。 按工作流收集运行次数、会话/任务数、计费分钟数和实际分钟数、重试次数、成功/失败/超时率、峰值并发数、区域、代理流量 GB、API/运行时费用、模型输入/输出令牌，以及会话就绪、导航、操作/提取、清理和端到端延迟的 p50/p95。

阅读 measurement.md。分别计算固定套餐/额度、浏览器、代理、API/函数/运行时/存储和模型成本。仅比较工作流、区域、身份验证/代理模式、重试策略和输出约定均相同的情况。缺少数据时，应使用公式和低/中/高情景，而不是声称节省了成本或改善了延迟。

如果缺少遥测数据或发票，请询问流量和平均时长。只有在有文档记录的一分钟最低时长是唯一可靠的时长依据时，才使用 1、2 和 3 分钟的情景。

3a. 核实价格并进行计算

在计算当日阅读所选参考文档中列出的服务提供商当前官方定价页面，以及 https://docs.notte.cc/intro/pricing。对于协商定价、年度承诺、额度或自定义套餐，应优先采用客户的发票/合同。记录来源 URL、日期、币种、套餐费用、包含的容量、计费取整/最低时长、超额费用、并发、代理、API/运行时/存储以及模型/令牌费率。

使用 cost-model.md。按工作流计算两家服务提供商的费用，并分别列出浏览器时长、固定套餐/额度、代理、API/运行时、存储和模型费用。不要重复计算已包含的额度或 Notte 订阅额度。根据观测到的峰值并发数选择套餐；每日平均值只是下限。

轨道 A 的证据收集到此结束。 继续阅读 §8 和 §9，交付简报。轨道 B 继续阅读 §4。

4. 运行安全的 Notte 验证

使用 Notte CLI 检查实时页面，仅对已观察到的目标执行操作，并导出工作流代码。选择一条有代表性的只读成功路径。在预期配置下运行一次预热和至少三次计时有效样本。记录生命周期时间戳、输出有效性、重试／失败情况、样本数量、区域以及回放／会话证据。仅使用 Notte 的样本只能证明可行性，不能证明对等性或延迟优势。

5. 在隔离环境中逐步构建

在生产代码库之外创建临时实现区域，只使用非机密测试数据。每完成一层就进行探测：

1. 会话／作业生命周期、清理、超时和错误路径；
2. 根据已观察到的目标执行确定性导航／操作；
3. 类型化抓取／数据以及调用方可见的错误约定；
4. 仅在原实现使用时才纳入配置文件、Vault／Persona、文件／扩展、代理／区域／CAPTCHA 以及查看器／回放；
5. 仅针对已证实的模糊步骤，使用有范围限制的 Notte Agent／AgentFallback；以及
6. 迁移提供商运行时、异步作业、计划任务、webhook 或函数时，保留调用、幂等性、重试、可观测性和取消能力。

切勿盲目导出 Cookie、身份验证状态、配置文件、录制内容或凭据。不要用开放式 Agent 替换确定性浏览器代码。将可自托管／浏览器沙箱计算视为架构决策，而非会话迁移。

6. 验证

添加单元、契约和选择性启用的只读集成测试。运行格式化程序、类型检查器、lint、依赖项／安全检查以及相关的完整测试套件。使用已配置的审查 Agent 并报告实际发现；切勿编造评分。在晋升到生产环境之前，确认现有的非生产部署路径。

7. 进行可回退的交接

只有在证据验证通过后，才在专用分支／工作树中操作。先合入 Notte 和测试；再通过单独、便于审查的清理变更移除旧依赖／配置。重新生成锁文件，再次进行出现位置清点，并交接提交／PR、git revert <cleanup-commit>、测量结果、发布计划和已知差距。切勿强制推送、更改账单或删除提供商资源。

8. 添加可选的外部基准测试背景

若要进行面向性能的比较，请在计算日期阅读 https://www.browserarena.ai/ 及其链接的方法说明／源代码。记录基准测试运行日期、提供商、场景、可获取的原始可靠性／延迟／成本指标以及来源链接。将其单独放在 外部基准测试背景 一节中。

Browser Arena 提供的是可比较、可复现的基准测试证据，而不是对客户工作流的预测。不要将其综合 Value Score 用作客户成本计算，不要脱离运行日期／方法说明引用提供商评分，也不要声称 Arena 结果能证明生产环境的延迟或可靠性。优先使用客户相同工作流的测量结果；仅将 Arena 用于补充独立背景，或提出值得探究的性能问题。

9. 提交决策简报

先给出结论，再展示证据：

• 范围、定价日期和链接；
• 工作流清单及证据位置；
• 用量、时长、舍入、重试、代理、令牌和方案假设；
• 每月浏览器运行小时数及所需并发量；
• 低／基准／高情景下的月度比较、节省金额、百分比和基准情景年化金额；
• 可选的 Browser Arena 背景，并与客户测量结果明确区分；
• 排除的成本，以及获得发票支持结果所需的确切缺失输入。

不要根据成本模型声称延迟或可靠性有所提升。完成 Track A 简报后，将 Track B——安全实现和有测量依据的 Notte 验证——作为下一步提出。

邀请团队加入 Notte Slack，以获取成本或迁移支持： https://join.slack.com/t/nottelabs-dev/shared_invite/zt-39a8n6hr9-d_BG7RNfytimSpVo5H03mA