Agent 浏览器卡在验证码时，别把会话交给另一个脚本：BrowserAct 的隔离会话与人工接力
让 AI Agent 打开网页、采集信息、填写表单，看起来像是浏览器自动化的常规任务。但真正上线后，故障往往不在“能否点击按钮”，而在三件更具体的事：站点触发反爬或验证码、任务需要登录态而 Agent 无法完成验证、多个并行任务误共享 Cookie 或浏览器上下文。
许多团队处理这些问题时，会把任务拆成 Playwright 脚本、人工远程桌面和不同的爬虫服务。这样虽然各自可用，却会让“谁正在控制哪一个会话”“人工介入后任务如何继续”“失败后哪些数据还能复用”变得不清楚。开源的 BrowserAct Skills 则把浏览器操作做成面向 Agent 的 CLI 与 Skill：强调会话隔离、索引化交互、人工接力和渐进式应对受保护页面。
它的核心价值不在于承诺“任何网站都能自动化”，而是把自动化难以完全自主解决的边界显式纳入工作流。当前仓库采用 MIT 许可证，支持 Windows、macOS 与 Linux；README 列出的兼容对象包括 Claude Code、Cursor、VS Code、OpenCode、OpenClaw、Codex 和 Gemini CLI 等能够执行 Shell 命令并加载 Skills 的 Agent。
不要先写 DOM 选择器，先决定任务是否需要稳定身份
对 Agent 来说，浏览器会话不是一个无状态 HTTP 客户端。采集公开页面、使用本机已有登录态、维护一个长期账号，三者需要的隔离级别不同。BrowserAct 在文档中区分三类使用模式：
| 模式 | 适合的任务 | 关键边界 |
|---|---|---|
chrome | 复用本机 Chrome 的登录状态 | 可导入 profile 或通过 CDP 连接 |
隐私 stealth | 不需要登录的批量读取 | 每个会话使用新的指纹，结束后不保留状态 |
固定身份 stealth | 已登录账号的长期或并行任务 | 稳定指纹与稳定 IP，避免多任务互相污染 |
这张表并不意味着可以绕过任何站点的访问控制。正确的工程决策是先把任务按身份需求分开：公开数据任务使用短生命周期会话；需要本人账号的任务只在经过授权的会话内执行；多个 Agent 同时工作时，为每个任务显式命名会话。不要为了省事让所有任务复用默认浏览器，那会让登录态、Cookie 和失败原因混在一起。
README 提供的交互方式也体现了这个设计。Agent 不必先解析整页 HTML 或编写复杂选择器，可以先获得带索引的页面状态，再根据索引操作元素：
browser-act --session supplier-research browser openhttps://example.com browser-act --session supplier-research state browser-act --session supplier-research click 3 browser-act --session supplier-research input 2 "search term"
state 返回供模型推理的索引化文本，而不是把完整 DOM 或大量 HTML 直接塞回上下文；click 3、input 2 则让后续动作引用当前状态中的编号。它降低了模型从冗长页面结构中定位元素的负担，但不消除页面变化风险：每次跳转、刷新或人工操作后，都应重新读取状态，不能复用旧索引。
验证码出现时，关键是会话接力而不是“自动破解”
受保护页面的处理通常有三层。第一层是运行环境，如指纹、TLS 与代理配置；第二层是执行能力，项目提供 stealth-extract 和 solve-captcha 等命令；第三层才是人工接力：remote-assist 生成一个可从其他设备打开的链接，用户接手完成需要本人判断或验证的步骤后，Agent 在原会话继续。
这条链路的价值在于保住上下文。人工完成验证后，不必重新启动一个无 Cookie 的脚本，也不需要让 Agent 重新猜测网页进度。实际任务中，应把“需要人工确认”当作明确状态，而不是不断重试：记录任务会话名、当前 URL、已完成步骤和等待的动作；待人工完成后先执行 state，再恢复后续操作。
一个最小的受保护页面读取起点可以是：
browser-act stealth-extract https://example.com
这适合先验证工具能否取得页面内容。若任务要进入完整浏览器流程，则应在隔离会话内逐步执行，并只对已获授权的网站和账号操作。自动化工具不应被用来规避服务条款、规避访问控制或替代用户对敏感操作的确认。
并发的重点不是“同时开很多浏览器”，而是避免跨任务污染
BrowserAct 将并行性描述为独立浏览器、同一浏览器下独立会话，以及隐私模式下的无残留会话。对开发者而言，最值得落实的不是并发数字，而是命名与归属规则：每个 Agent 任务必须有唯一 --session；含登录态的任务不得与公开抓取任务共用会话；失败重试尽量在同一会话中进行，只有明确需要重置身份或状态时才新建会话。
此外，项目说明有一组确认门：浏览器创建或删除、Profile 导入、代理修改以及安全/隐私设置等敏感操作需要用户明确批准，且既往批准不会自动沿用。把这类交互放在 Skill 层，比让 Agent 在任意时刻隐式改变网络或身份配置更容易审计。团队仍应在自己的编排层保留任务日志，例如发起者、会话名、账号归属、人工接力原因和最终结果。
让 Agent 的命令执行保持可复现
面向 Agent 的 CLI 还有一个容易被忽略的优点：它把操作轨迹变成可记录的命令，而非散落在人工鼠标动作中。以一次“登录后检索供应商页面”的任务为例，编排器可以在开始时生成任务 ID，并把 --session、目标域名、账号环境、是否允许人工接力写入任务清单。Agent 每完成一个高层动作，就保存当前 URL、最近一次 state 的摘要、提取到的字段和下一步意图。这样即使模型上下文被截断、工作进程重启，恢复者也知道应回到哪个会话检查，而不会误开新窗口再次触发登录或风控。
这也为质量检查提供了具体抓手。对于只读采集，可在任务结束时验证：目标字段是否存在、来源页面 URL 是否被保存、会话是否按策略清理。对于填写或提交类操作，应把“读取页面”“填入草稿”“用户确认”“最终提交”拆开，最终提交前重新读取页面状态，并把确认事件关联到同一个会话。所谓人工接力不应成为绕过审批的通道；它应当让人完成必须由人判断的步骤后，把可验证状态交回 Agent。
当页面使用动态加载或内容频繁变化时，也不要把一次 state 当成永久真相。模型应在点击后、表单提交前、人工接力返回后重新获取状态；若索引不再存在，则停止而不是按旧编号盲点。将这种“读取—判断—执行—再读取”循环作为编排协议，比不断增加脆弱的 CSS 选择器更能降低网页变化造成的误操作。
成本、权限与可复现性的取舍
BrowserAct 并非所有能力都完全免费。README 标明，基础浏览器自动化以及 Chrome/Chrome-direct 可免注册使用；登录后可使用不超过五个 stealth 浏览器、stealth-extract、验证码处理、人工接力和隐私模式；受管代理、静态代理及超过五个 stealth 浏览器属于付费范围。生产设计不能把“本地可以运行”直接等同于“高并发可长期零成本运行”。
更实际的落地顺序是：先选一个已获授权的站点和只读任务，验证会话命名、页面状态读取和失败日志；再测试一次人工接力如何回到同一会话；最后才引入多 Agent 并行和带账号的流程。若页面只需要常规、稳定的 API，优先使用官方 API；浏览器自动化应留给确实需要页面语义、用户登录流程或人工确认的场景。
BrowserAct 的思路提醒我们：面向 Agent 的浏览器不只要“会点页面”，还需要把身份、会话、人工判断和并发隔离当作一等概念。把这些边界先设计清楚，自动化才能在复杂网页环境中保持可控，而不是在一次验证码或一次并发冲突后变成不可复现的黑盒。
相关链接