不依赖模型的浏览器自动化：厂商变了，你不必重建

厂商锁定在实践中的真实代价

绑定单一模型的浏览器智能体，会继承该厂商的定价、速率限制、地区可用性、内容政策和产品路线图。这些都不在你的掌控之内，而且都会变化。真正的资产是工作流，模型只是一个应该可以替换的组件。

代价很少来自许可证本身，而是来自重建：一旦条款变化，集成、提示词、工具接线和审批流程都得针对新的接口重新做一遍。

• 涨价会影响你已经搭建好的工作
• 速率限制会让原本运行正常的工作流停摆
• 模型版本弃用会改变你已经调好的行为
• 地区或政策限制可能直接切断访问

把工作流和模型分开

有四样东西应该独立于模型：智能体可以调用的工具、它运行时所依据的上下文、审批节点，以及事情发生过程的记录。如果这些都留在运行时里，而不是留在厂商的产品里，换模型就只是下拉菜单里的一次选择，而不是一个项目。

Melaya 正是这样构建的。同一个浏览器任务，可以运行在已连接的云端服务商上，可以通过 Melaya Runner 运行本地模型，也可以走 Claude Code 或 Codex 的路线，而周围的连接器、常驻上下文、标签页作用范围和审批机制始终不变。

本地模型何时能让工作流的边际成本趋近于零

运行在你自己电脑上的本地模型，没有云端按消息计费。对于重复性的浏览器工作而言，这改变了成本结构：每次运行的边际成本是电费，而不是按 token 计费的账单。本地推理仍然受限于你的硬件、模型的上下文窗口、运行速度以及你的 Melaya 套餐权益，所以并不是真的没有上限。

实际做法通常是混合使用：日常提取用速度快的云端模型，复杂页面用更强的云端模型，每天都要跑的重复性工作则交给本地模型。