无需共享凭证的AI驱动浏览器自动化方案
如果你只是偶尔让 AI 帮忙查询信息，直接用 ChatGPT、Codex、Claude Desktop 内置的浏览器就够了，不必继续阅读。
本文要解决的是另一类需求：需要定时执行、按队列运作的智能体自动化。例如每日自动填写表单、定期刷新某个门户、处理内部系统的重复任务，或者合上电脑后还要在服务器上持续运行的工作流程。
复制
你通过 noVNC 开启一个可视浏览器自行登录。AI 只能向封装器发送结构化指令，比如"帮我填写这份草稿"、"截个图给我看看"。登录信息不会进入 AI 对话，也无需让计算机操控智能体直接操作你的设备。
一句话概括使用场景：网站需要登录、没有公开接口、但你又希望智能体运行在小型服务器上，而不是靠你的笔记本全天开机。
很多真正有价值的流程，都卡在网页背后。
合作伙伴门户、内部后台、学校表单、会员站点，或者某个只能在浏览器中点击的旧系统——你清楚 AI 可以帮你准备数据、填好表单，但网站就是没有接口。
最直接想到的捷径，往往风险最大：
复制
这样做等于把多项责任混在一起：AI 看到了密码，AI 可以随意点击，你的笔记本也被拖入了生产流程。万一这个任务要半夜运行、出差时也要执行，难道你的个人电脑要 24 小时开机？
更合理的分工如下：
复制
本文要搭建的，就是这套架构。
AI 自带的浏览器，适合交互式任务：你人在旁边，问一句，它打开页面、读取内容、点击按钮、把结果汇报给你。
但智能体自动化是另一种形态。它可能每天早上 8 点自动启动工作，可能从队列中逐条取任务，可能在网站超时时自行重试，可能在你睡觉时填好草稿，只在会话掉线需要重新登录时才通知你。
这里不是说自带浏览器不好——它解决交互场景，这套模式解决自动化场景，各司其职。
假设你有一个没有接口的供应商门户。每个工作日早上，你想让智能体根据昨天的运营笔记，自动起草一批请求。
复制
这与"让聊天工具临时帮我浏览一下"完全不同。智能体有固定任务、有重试路径、有明确的工具接口，也有"该停下来等人"的暂停机制。
第一版建议把最后一步留给人。让智能体起草，让封装器返回截图，只要动作有风险，最终点"提交"的还是人。
教程中使用的目标网站，是一个有"新建请求"表单的私有供应商门户。表单包含主题、详情、优先级，以及一个"保存草稿"按钮。你实际的网站肯定不同，但架构是通用的。
官方的 Docker Selenium README 里写明了独立浏览器镜像、WebDriver 端口、noVNC 端口，以及常见的--shm-size 2g配置。下面我们要做的，是在这层浏览器外面再包一个更小的封装器，让 AI 不直接跟 WebDriver 交互。
动手之前先查看网站的条款和频率限制。这套模式是给合法的个人/内部流程用的，不是用来绕过访问控制、抓取私有数据、或者与反爬系统对抗的。
先建个目录：
bash
复制
新建docker-compose.yml：
yaml
复制
启动服务：
bash
复制
打开实时浏览器：
复制
用这个浏览器自己登录目标网站。不要让 AI 帮你登，更不要把密码粘到 AI 对话框里。从这一刻起，浏览器会话就活在容器里了。
WebDriver 权限非常大——谁能访问它，谁就能完全控制浏览器。这就是为什么 compose 文件里要把4444和7900都绑到127.0.0.1。
这是整套方案最关键的安全边界。AI 不应该拿到一个"通用浏览器控制"端点，它应该只有一个小小的 API，里面装的都是你审核过的动作。
写代码之前，先把任务用文字描述清楚。拿示例门户来说：
复制
这正是封装器比计算机操控智能体更安全的地方：智能体没法临时起意去点"账号设置"，因为你的 API 里压根没这个动作。
下面这段提示词可以直接丢给你的编程 AI。用之前先打开目标页面看一下，把里面假的门户 URL 和选择器名换成你真实网站的信息。
复制
这段提示词本身比用什么框架更重要。它把边界讲清楚了：不碰登录、不接受任意浏览器控制、不公开 WebDriver。
按上面的提示词生成的封装器，大概长这样。新建form-wrapper/main.py：
python
复制
这个示例故意做得很窄：不能浏览任意 URL，不能执行任意 JavaScript，也不能填 AI 临时指定的选择器。选择器要你自己看过目标页面之后，在服务端改。
新建form-wrapper/Dockerfile：
dockerfile
复制
更新docker-compose.yml：
yaml
复制
新建.env：
bash
复制
带上封装器一起重启：
bash
复制
先把令牌加载到终端：
bash
复制
调用一下封装器：
bash
复制
如果返回需要登录，就打开 noVNC 自己登一次，再重发同一个请求。
在你亲眼看到浏览器把字段填对之前，干运行一直开着。确认没问题了，再允许封装器去点"保存草稿"。对敏感流程来说，最终那个"提交"按钮最好永远留给人。
封装器手动跑通之后，智能体工作流就可以像调用普通 HTTP API 一样调用它了。这个工作流可以是 n8n、定时任务、一个小工作器、队列消费者，或者任何一个支持 HTTP 工具的智能体框架。
复制
分工就清楚了：AI 负责语言和结构，封装器负责浏览器动作，已登录的浏览器负责跟网站打交道。边界一清楚，整个流程就好理解、好排查了。
这里最关键的是智能体的"暂停机制"。如果封装器返回需要登录，智能体不应该试图通过问你要凭证来自己解决登录问题——它应该通知你、暂停任务，等你在 noVNC 上登完再继续。
本地是最稳妥的第一步。真要全天候运行，就把同一套 Docker Compose 搬到一台小 VPS 上。
在远程服务器上，千万别把 noVNC 直接暴露到公网。需要登录或调试时，用隧道连过去就行：
bash
复制
然后在自己电脑上打开：
复制
如果你的 AI 平台需要从服务器外部调用封装器，那就只暴露封装器一个端口，用 HTTPS + 强持有者令牌保护起来，再配合 IP 白名单或私有网络。4444和7900继续藏着别动。
入门版的做法是：只要 Selenium 容器不挂，浏览器会话就一直活着。对第一个工作流来说，这通常够用了。
如果你希望容器重启后登录态还在，可以后面再挂一个 Chrome 配置文件卷，但要小心测试。有些网站会让 cookie 过期，会要求重新做双重认证，会在 IP 变了之后直接作废会话。Chrome 配置文件在浏览器非正常退出时还可能留下锁文件，重启时挺烦的。
建议先守住这条简单规则：
复制
如果网站有正规接口，那就用接口，别折腾这套。接口更稳、更好监控，也不会因为页面一改就挂。
如果网站明确禁止自动化，或者用验证码画了一条清晰的反自动化红线，又或者某个操作点错一次代价很高，也别硬上。这种情况下，让 AI 准备数据就好，浏览器里的关键动作还是得人来做。
这套方案的重点不是 Selenium——Selenium 随时可以换掉。真正有用的是那条边界。
复制
这是自动化无接口网站时一种更稳的做法。你照样能拿到 AI 起草的内容、全天候的服务器端执行、看得见的浏览器调试——但不必把密码交给智能体，也不必让它操作你的个人电脑。