开源浏览器自动化智能体 DomA：邀请码、自定义模型与常见坑

让 AI 直接在浏览器里帮你点按钮、填表单、翻页、抓数据，这类「网页智能体」最近冒出来不少。DomA 是其中一个把核心能力开源的实现：以浏览器扩展的形式运行，源码可查、可本地构建，用户自己填模型 API Key；商店版本也会基于同一套开源代码继续迭代。

讨论集中暴露了几个很实际的问题：商店版要邀请码而开源版不用、开源版一开始既没有 Claude 供应商也没有自定义 base URL 的入口、扩展缺少 userScripts 权限声明导致相关开关点不开、canvas 渲染的页面（比如网页小游戏）能不能操作，以及这类工具和已有的脚本、插件到底差在哪。下面按「怎么装、怎么配、哪里会翻车」的顺序整理。

它解决的是什么问题

传统做法里，想自动化一个网页，要么写脚本抓 DOM，要么装一个专门的「AI 浏览器」。前者遇到页面改版就崩，后者等于再装一个浏览器、还得重新登录所有账号。扩展形态的好处是复用你已经登录好的浏览器环境，用自然语言下指令即可，例如：

• 整理标签页、清理历史记录这类浏览器自带功能操作；
• 在页面上按引导自动点击、填写、翻页；
• 提取当前页面信息（视频资源、商品参数、表格内容）；
• 根据页面内容生成广告屏蔽规则。

它的本质是「把自然语言翻译成页面上的具体动作」，所以能力上限取决于两件事：页面是否暴露可读的 DOM，以及模型对页面结构的理解是否准确。

开源版与商店版：先分清两套东西

很多困惑来自把两者混为一谈。

所以「没有邀请码怎么用」的标准答案是：走开源版，自己准备 Key。公开贴出来的邀请码基本是秒没的，蹲码的效率远低于自己构建。另外不建议从第三方购买或共享账号、邀请码，存在被回收、凭据泄露、连带封禁的风险，走官方渠道排队更稳妥。

三个最高频的配置问题

1. 开源版没有 Claude 供应商 / 没有自定义地址

早期版本的模型提供商列表不完整，想填一个中转出来的 OpenAI 兼容地址也找不到输入框。维护者给出的时间线是相关特性会陆续合并。在合并之前，稳妥的做法有两种：

• 等：关注仓库的 release 与相关 PR，合并后升级扩展即可，不要用来源不明的第三方构建包。
• 自己加：在模型配置模块里新增一个兼容 OpenAI 协议的服务商条目（通常是名称、base URL、模型名、Key 四个字段），指向你的网关或中转服务。具体字段名和调用路径以仓库当前代码为准，这部分需要自己读一遍再动手。

接入中转服务时要注意两点：一是该服务是否记录你的请求内容，涉及内部系统时风险很高；二是模型名要和网关实际暴露的保持一致，写错通常表现为「请求发出去了但一直转圈」。

2. userScripts 权限缺失，开关打不开

现象是扩展详情页里「允许用户脚本」这一项是灰的，点不动。原因不复杂：manifest 里没有声明 userScripts 权限。

处理步骤：

1. 打开扩展目录，找到 manifest.json；
2. 在 permissions 数组里补上 "userScripts"；
3. 回到扩展管理页重新加载（或重启浏览器）；
4. 新版 Chrome 还需要在扩展详情页手动打开「允许用户脚本」开关，这一步必须由使用者本人操作，代码里替不了。

不同浏览器内核版本对这个 API 的要求有差异，遇到行为不一致时以官方扩展文档为准。该问题维护者已确认会修，追新版即可。

3. 登录态与账号环境

智能体跑在你已登录的浏览器里，这既是优势也是风险：一旦指令理解偏了，它可能在你已登录的后台里点了不该点的按钮。建议第一次使用时只给只读类任务（提取、汇总、整理），确认行为符合预期后再放开写操作；涉及支付、删除、提交表单的站点，保留人工确认环节。

能力边界：哪些页面它搞不定

• 普通 DOM 页面：主要靠选择器加模型理解，页面结构大改后容易失效。
• canvas 渲染的页面：网页小游戏、部分地图和在线编辑器把内容画在画布上，没有可读 DOM，只能靠视觉识别加坐标点击。项目方表示做了这方面的考虑，但没有经过充分测试，属于「可以试，别当生产力工具」。
• 强风控站点：验证码、设备指纹、行为检测会直接卡死流程。这类场景不建议想办法绕过，既有账号风险也可能违反站点条款；能走官方 API 或开放数据接口的，优先走接口。
• 需要多步状态保持的长流程：中间任何一步等待时机不对，后续全会错位，通常要在指令里显式写清「等某元素出现再继续」。

把重复流程固化成技能，而不是每次重新对话

讨论里最有价值的一条经验是：不要指望每次都用一段自然语言让模型从头推理一遍。页面结构随时可能变，纯靠对话的做法维护成本极高。更合理的分层是：

• 智能体只提供基础原子能力（点击、输入、滚动、提取、截图识别）；
• 具体业务流程由它自己探索一遍后保存成可复用的技能（skill）/ 流程脚本；
• 页面改版时只修那一个技能，其余不受影响。

这样既保留了「用对话生成流程」的便利，又避免了每次都重新推理带来的不稳定和 token 开销。对高频、固定路径的任务（每日签到、固定报表拉取），固化成技能后甚至可以脱离对话直接触发。

和同类方案怎么选

有人会问「现在的 AI 不都支持操作浏览器吗」，差别主要在三点：运行在浏览器内还是云端、能否复用你现有的登录态、以及是否允许换成自己的模型和网关。对数据敏感或需要接入自建模型的团队，最后一点往往是决定性的。

二次开发与内部使用

出于内部安全管理要求而 fork 自建是常见需求，注意几件事：

• 先看仓库的 LICENSE，确认内部使用与再分发的边界；
• 把模型地址指向公司自建网关，Key 不下发到终端，便于审计和限额；
• 保留 upstream 的同步路径，避免改到最后无法跟进官方修复；
• 内部改造版不要对外分发，也不要打包上传到扩展商店。

上线前的检查清单

• 确认用的是哪种版本（开源自建 / 商店版），别在邀请码上浪费时间；
• API Key 可用，模型名与网关一致，额度充足；
• manifest 权限齐全，userScripts 开关已手动打开；
• 先用只读任务验证行为，再放开写操作；
• 高频流程已固化为技能，并记录了失败时的重试方式；
• 敏感站点保留人工确认，必要时在测试账号上先跑。

一个可选的运行环境思路

如果任务需要长时间挂着跑，或者目标站点在海外、本地网络访问经常超时，可以把浏览器和智能体放到一台常年在线的机器上运行，再用远程桌面连过去操作。例如整机托管在新加坡机房的独享 Mac mini，按月租用、远程连接，任务不会因为合盖休眠或本地断网中断。这只是其中一种省事的选项，本地能稳定跑通就没必要额外折腾。

小结

这类开源浏览器智能体的定位不是「全自动替你把事办完」，而是「把网页操作的门槛降到一句话」。目前它更擅长信息提取和流程引导，遇到 canvas 页面、强风控站点、复杂登录流程仍会失手。真正决定长期可用性的，不是模型多聪明，而是你有没有把重复流程固化成可维护的技能、有没有把关键操作留在人工确认这一侧。版本特性变化较快，具体支持哪些模型供应商、权限声明怎么改，请以仓库最新代码和官方文档为准。