用浏览器 agent 做过正经事的人都会碰到同一组失败:页面在"读"和"点"之间变了,选择器指向一个早已不存在的节点,或者站点直接把自动化流量挡在门外。工程社区给这些失败准备了各自的缓解方案,评测榜单也排好了座次。2026 年 10 月 13 日,Outcrawl 把自家的浏览器 agent Scout 开源到了 GitHub,两天拿了 642 颗星,README 首屏写着 92.5% 对 81.4% 的碾压数字。我们把这样一个两天大的项目放进四个基准任务和三个真实业务场景里,结果在第二个场景就撞上了评测榜单从不覆盖的情况:目标品牌官网的域名,本身已经被人劫持了。
这篇评测回答三个问题:Scout 的工程做到了什么程度;92.5% 这个数字到底在测什么;以及当"正确的答案"根本不在你给定的 URL 上时,一个 agent 会怎么表现。所有实测在 2026 年 10 月 15 日完成,环境是本机 headless Chromium,模型走任意 chat-completions 兼容端点上挂的 gemini-3.8-flash,本地浏览器、无云加成。
Scout 是什么
Scout 是一个库,不是一个产品:写一段 TypeScript,new Scout({ browser, models }).run(task),它开一个真浏览器,读页面、点击、输入、滚动,把答案带回来。没有 CLI,没有内置模型——四个模型角色全部自带 key,任何讲 chat-completions 协议的服务都能接,包括跑在自己机器上的模型。
const scout = new Scout({
browser: { launch: {} }, // 本地 Chromium;或 'outcrawl' 云浏览器 / CDP 地址
models: {
hands: { model: 'gemini-3.8-flash', baseURL, apiKey }, // 唯一必选
brain: { model: '…' }, // 可选:规划
eyes: { model: '…' }, // 可选:看截图
extract: { model: '…' }, // 可选:按 schema 抽取
},
});
const result = await scout.run('在 books.toscrape.com 打开 Poetry 分类第一本书,报标题和价格');
仓库规模对两天大的项目来说不成比例:约 6 万行 TypeScript 源码,3.3 万行测试,Apache-2.0(Agent 输入规划子包 agenthands 独立 MIT)。它是 Outcrawl 生产仓库的单向镜像,只有 16 个 sync commit,PR 要等下一次 sync 才会回到主线。仓库最大的一块是 runtime(2.6 万行),其中主循环 loop.ts 一个文件 1.4 万行——这是它工程上最亮也最刺眼的地方,后面都会讲到。
核心机制:一次把 TOCTOU 讲透的设计
浏览器 agent 最经典的翻车姿势是 TOCTOU(time-of-check to time-of-use):agent 读到一页内容,模型思考五到十五秒,这期间页面自己变了,动作落在一个已经不是原来的节点上。Scout 的 loop.ts 文件头用一整段注释把这个问题的行业现状列了一遍:Playwright 的 refs 在页面变更后失效,browser-use 每步重排一遍 index,Stagehand 干脆不冻结页面、靠自愈兜底——注释里引用的实测数字是一次自愈烧掉 21,410 个 token。Scout 的做法是把"读页面"和"执行动作"放进同一把页面级锁里:思考期间页面整个冻结,动作落在加锁那一刻看到的 frame-qualified 节点 ID 上,TOCTOU 窗口被从结构上消掉,而不是被缓解。整个流程里只有一个东西被允许中途解冻:页内 captcha 求解,因为冻结的页面跑不了挑战脚本。这套 runtime 的重法,与去中心化画布 agent 把编排打散到协作面的方向恰好是两个极端:一个把复杂性收进单循环换确定性,一个用结构换扩展性。
第二个值得拆的设计是四角色模型分层。hands 每一步都要调用,决定整场运行的速度和成本;brain 是可选的规划角色,输入被硬预算卡住——每步只喂一行紧凑状态加当前页面摘要,历史步骤以 append-only 的紧凑状态行存在线程里,靠前缀缓存吃掉重复成本;eyes 只在 agent 主动要看截图时出场,缺席时 agent 完全靠可访问性树工作;extract 缺席时由 hands 兼任。每个角色可以指向不同的供应商、不同的 key,结构化输出还有三级降级:端点不支持 function calling 就退到 json_object,再不行退到 json_schema strict,失败信息会告诉你该在哪个角色上改哪个开关。
契约层面同样克制:任何一次运行都返回 result,状态四选一(completed / partial / capped / failed),caps(steps / duration / budget)到限算正常结束;配置错误在任何浏览器启动之前就被拒之门外。实测里我们对着一个不存在的域名发起任务,它返回 status: failed,error 字段一句话说清"域名无法解析",进程退出码为 0——失败是数据,不是异常。
基准实测:四连过,包括失败路径
四个基准任务全部一次跑通,结果如下(2026-10-15,本地 headless Chromium,hands=gemini-3.8-flash):
| 任务 | 结果 | 耗时 | 步数 |
|---|---|---|---|
| books.toscrape 取 Poetry 分类第一本书标题与价格 | 与官方 demo 答案一致 | 35.1s | 4 |
| Poetry 分类全部书目按 JSON Schema 结构化返回 | 19 本书,字段完整 | 31.3s | 3 |
| quotes.toscrape 登录后跨页取数据 | 登录成功,取数正确 | 82.4s | 9 |
| 不可达域名失败路径 | status: failed,错误信息准确 |
27.6s | 3 |
两处细节值得单独说。结构化输出用的是默认的 tool_choice 模式,Gemini 系端点零配置直接工作,19 本书的书目连价格和库存状态一字不差。登录任务 9 步完成表单填写加两个页面的信息采集,没有一次冗余导航。这个成绩对一个"模型 key 自带、无云端加持"的本地运行来说,是合格线以上的。
真实场景:三个素材调研任务,三工具同题
基准过了,我们把它放进真实业务。场景来自一款生成式视频创作产品的素材调研流程——AI 重制视频为什么总是不稳定,我们此前做过赛道全景,这三个任务都是那条管线的日常前置:短视频重制场景下定位一条爆款原片的完整元数据;小众网络品牌官网取一件主推产品的名称、价格、主图和文案;长视频切片场景下定位官方完整版并判断页面上有没有可用于切片定位的热度信息——怎么把「高能片段在哪」变成可计算信号,是短视频工程化里的老问题。同一组任务书,交给三个执行者:Scout、opencli v1.8.8(桥接到真实 Chrome 的命令行浏览器)和一个编码 Agent 内置浏览器,第三个由编码 agent 逐步驱动。
| 任务 | Scout | opencli | 编码 Agent 内置浏览器 |
|---|---|---|---|
| 重制:爆款原片元数据 | ✅ 49.3s / 4 步 | ✅ 7 条命令 | ✅ 78.6s / 4 次调用 |
| 品牌官网(劫持域名) | ⚠️ partial,202.9s / 20 步 | ✅ 2 条命令发现异常 | curl 判定,与工具无关 |
| 品牌官网(正常域名) | ✅ 514.8s / 22 步 | ✅ 12 条命令 | ✅ 69.1s / 2 次调用 |
| 切片:官方完整版定位 | ✅ 169.8s / 6 步 | ✅ 5 条命令 | ✅ 30.8s / 2 次调用 |
可验证字段上三家完全一致:两个 B 站视频的 BV 号、UP 主、时长、播放量互相印证,零幻觉。Scout 在切片任务里甚至主动解释了判断依据——"右侧推荐栏无分 P 列表,简介无时间轴,播放器未见高能进度条"——这是把"没找到"和"没说清为什么没有"区分开了,大多数 agent 做不到后半句。
速度是另一回事。编码 agent 直驱内置浏览器每任务 2 到 4 次调用、31 到 79 秒;opencli 5 到 12 条命令;Scout 每步一次 LLM 调用,四场任务 49 到 515 秒,最慢的一场(品牌官网正常域名)22 步里混着多次探索性导航,慢了一个量级。四场 Scout 运行里还出现了一次 CDP 连接断开(浏览器进程崩溃),任务以 partial 收场——稳定性是它进生产前最硬的一道门槛。
劫持考验:唯一一次自主自救
第二场任务撞上的是榜单从不覆盖的情况。我们选的"小众网络品牌"是三顿半,任务书写的是打开它的官网 saturnbirdcoffee.com。实测当天这个域名在服务端直接 301 到了 crownjunk.com——一个赌博 SEO 垃圾站。品牌官网域名易主,这事在 2026 年不算新鲜,但对浏览器 agent 是个残酷的考题:任务书给的 URL 是错的,而"正确答案"根本不在这个 URL 上。
opencli 两条命令就把异常暴露了出来——页面标题和正文都是赌博站内容,剩下的事由驱动它的人(或编码 agent)判断。真正自己走完全程的是 Scout,它在这场任务里的行为链值得完整记录:
先直连 saturnbirdcoffee.com,落到 crownjunk 的垃圾页;随后它的抽取步骤日志里出现了这句话:"saturnbirdcoffee.com was redirected to crownjunk.com"——它识别了劫持,而不是把垃圾站内容当答案抽回来。接着是一串搜索引擎降级:Google(网络不可达)→ DuckDuckGo → Bing(可达),最后定位到真正的海外官方商店 saturnbird.com,从那里抽到了产品名和官方文案。价格字段在品牌官网上确实不存在,它没有编一个,最终以 status: partial 结束,error 如实写着缺什么。20 步,202.9 秒,外加结尾一次 CDP 断连。
把它和前文的技术设计放在一起看,这场表现并非运气:可访问性树里 crownjunk 的内容与"咖啡品牌"语义相去甚远,Agent 有足够信号判断"不对劲";而"永远返回 result + partial + 缺什么写清楚"的契约,让它不需要在"编答案"和"崩溃"之间二选一。反过来说,这一场也暴露了单 agent 任务的边界——它花了 40% 的步数在搜索引擎之间试错,一个带域名白名单校验的调用方,能在第一步就把这场劫持拦在任务之外。任何把浏览器 agent 接进生产素材管线的人,都应该把这条写进调用方代码:Agent 会自救,但校验域名是调用方的责任,两者不能互相替代。
92.5% 到底在测什么
回到 README 首屏那个数字。Outcrawl 的方法页(2026 年 10 月 7 日发布,三次全量运行)写得很诚实:测的是 Browser Use 那份 80 站点基准里"页面能不能被成功打开",71 个计分站点,Scout 背后的 Outcrawl 云浏览器拿到 92.5%,次一名 Browser Use Cloud 是 81.4%。方法页同时交代了两个对结果影响不小的细节:对手的数字来自 Browser Use 2026 年 3 月发布的自测,由 Browser Use 自家 agent 驱动;Outcrawl 的数字是自家 agent 驱动自家云,时间晚了七个月。也就是说,92.5% 衡量的是云浏览器的反封锁能力(住宅出口、captcha 求解、拟人输入),它不是 agent 智能的成绩,更与 Scout 开源部分的本地运行无关——本地 headless Chromium 跑同一个对照,分数是 2.2%。
给数字归位之后,这份 benchmark 反而更值得尊重:它测的维度真实存在(我们实测中 Google 搜索不可达、B 站登录墙都在提醒这个维度的意义),Outcrawl 也没在自己的开源 README 里把云的成绩说成 agent 的成绩。只是转引这个数字的人,大多没读到方法页。
多维度评分
综合两轮实测与源码走读(2026-10-15):
| 维度 | 评分 | 依据 |
|---|---|---|
| 核心机制设计 | 9/10 | action-lock 从结构上消 TOCTOU;四角色分层带硬预算;三级结构化输出降级 |
| 工程质量与可审计性 | 9/10 | 6 万行源码配 3.3 万行测试;设计约束写在代码现场,可审计性极好 |
| 实测任务成功率 | 8/10 | 8 场任务 7 场全对;唯一 partial 源自外部劫持,且自救路径完整 |
| 速度与成本效率 | 5/10 | 每步一次 LLM 调用,单任务 49 到 515 秒;4 场出现 1 次浏览器崩溃 |
| 生态与成熟度 | 3/10 | 发布 2 天,v0.1.1,单向镜像仓库,API 未定型 |
| 文档诚实度 | 8/10 | 方法页交代了对照日期与驱动方差异;但 README 首屏的 92.5% 对 81.4% 有明显的转引诱导 |
扣掉的两个 9 之外的分,不是给代码的,是给时间的:loop.ts 单文件 1.4 万行,主循环入口在第 8556 行才开始,这在镜像仓库里读起来尤其痛苦;两天、三个 npm 版本,意味着任何接口都可能在下一周变掉。
结论与建议
三句话的结论。第一,Scout 是过去半年里我读过的工程质量最高的开源 agent 代码库,action-lock、四角色分层和"失败是数据"的契约,值得任何在做 agent 运行时的团队整段借鉴,这与它是否成熟无关。第二,今天不要把它接进生产:等 v0.2、等社区 issue 积累、等 CDP 稳定性问题有结论,以它当前的速度和崩溃率,只适合无人值守、容忍分钟级延迟、单次失败可重试的批处理场景。第三,那场域名劫持的教训不属于 Scout,属于所有调用方:Agent 能在被给的 URL 上自救,但"这个 URL 是否还值得去"必须由管线自己校验,域名白名单加指纹比对,一行代码挡掉 40% 的浪费步数。
对具体的采买问题:如果你的目标是"反封锁抓取",要买的是 Outcrawl 云,那是 92.5% 的真正来源;Scout 开源部分的价值在工程范本和本地可控,两笔账要分开算。
参考资料
- Outcrawl — outcrawlai/scout GitHub 仓库(2026-10-13 开源,2026-10-15 时 642 stars、v0.1.1)
- Outcrawl — Browser Use 80 站点基准方法页(运行于 2026-10-07)
- npm — @outcrawl/scout 包页(v0.1.1,2026-10-13)
- loop.ts 文件头注释引用的 TOCTOU 分析 — arXiv:2603.00476
- Browser Use — 80 站点反封锁基准及对照数据(对照运行发布于 2026-03)
- jackwener — @jackwener/opencli(v1.8.8,本文对照组之一)
- 本文全部实测数据(2026-10-15)由作者在本机 headless Chromium + gemini-3.8-flash 环境复现,任务书与原始日志留存于评测工作目录