本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。
快速摘要
如果你在用 AI Agent 做网页任务，最容易翻车的地方从来不是写代码，而是网页本身：Cloudflare 拦下来、验证码弹出来、登录态悄悄失效、页面结构一改脚本就崩。真正能把 Agent 送进真实网页的，不是某一个单点技巧，而是一套分层的能力体系——环境层负责让浏览器不像机器人，执行层负责能自动过的验证先自动过，人机层负责在该停的地方把控制权交回给人；跑通之后，再把摸清的流程固化成一个可以反复调用的 Skill。这套思路最近有个很典型的开源代表，叫 browser-act，它把浏览器、会话、反检测、验证码处理、人工接力和 Skill 复用塞进了同一套命令行工具里，遵循 MIT 协议，可以配合 Claude Code、Cursor、Codex 这类 Agent 一起用。但有一句话必须放在最前面：这类能力在国内落地，合规是前提不是选项。robots 协议、目标平台的服务条款、《个人信息保护法》《数据安全法》，一条都不能踩；只在你自己有权访问、自己的账号、公开且允许的数据范围内做自动化，才是安全的用法。
我自己花了不短的时间，把这类工具在各种真实网页任务上跑了一遍，踩了不少坑，也搞清楚了它到底解决了什么、边界在哪。下面这篇长文，我会把这套能力体系一层层拆开：从"看—做—再看"的交互循环，到三层反检测的分工，到验证码与人机协作的边界，再到 Skill 复用、和 Playwright 的关系、成本与隐私模式，最后单独用一大节讲清楚国内合规怎么把握。想看完整拆解，往下翻。
一、为什么 Agent 很会"想"，却经常进不去真实网页
这两年大模型的"想"这件事，进步是肉眼可见的。写代码、做规划、拆任务、多步推理，很多环节已经能自己转起来。但真要让它去干一件特别朴素的活——打开一个真实网站、读到里面的正文、点几个按钮、把数据拿回来——翻车的概率高得离谱。
我自己第一次被这件事绊住，场景特别普通。我想让 Agent 去读一篇公开网页上的正文，指令写得清清楚楚，结果工具回来一句"读取失败"。翻日志一看，页面根本没给我正文，而是抛回来一段环境校验：它怀疑请求方不是真人浏览器，直接把内容挡在门外了。
这不是个例。你只要用 Agent 认真做过几次网页任务，大概率都撞过下面这几堵墙：
- 任务一开始跑得挺顺，走到某一步 Cloudflare 的盾突然弹出来，后面全停。
- 页面明明加载出来了，点着点着就点不动了，像是页面在中途换了一套结构。
- 登录这一步过了，结果下一次跳转会话就悄悄断了，等于白登。
- Agent 吭哧吭哧跑了好几分钟，最后什么都没带回来。
这些失败有个共同点：它们都不发生在"模型不够聪明"这一层，而发生在"网页不认它是人"这一层。传统的抓取工具，比如各种 web fetch、curl，本质上就是发一个 HTTP 请求把 HTML 拿回来。这套办法对付十年前的静态页面还行，但今天的网页早就不是这样了：内容靠 JavaScript 动态渲染、登录态藏在 Cookie 和会话里、前面还架着一层专门识别自动化流量的风控。你用一个"一看就是脚本"的请求去敲门，人家凭什么给你开。
我把这件事想明白之后，思路就变了。问题不在"怎么点按钮"，而在"怎么让一个自动化程序，在一个默认对自动化不友好的真实网页里，稳定地把一件事做完"。 这里面要处理的东西，远不止点击：得让浏览器不那么像机器人，得能应付突然冒出来的验证，得在遇到该由人来做的步骤时懂得停下来，还得让今天跑通的流程明天换个人、换个会话也能重来一遍。
这几件事，过去是散在不同工具里的。反检测浏览器解决"像不像真人"，验证码平台解决"过不过得了验证"，会话管理是另一套，人工接管又是另一套，最后你还得自己写一堆脚本把它们粘起来。粘合层一多，出错的地方就多，维护成本也水涨船高。
最近圈子里讨论比较多的 browser-act，就是冲着"把这些揉进一套体系"去的。它由一家叫 ECOCREATE TECHNOLOGY 的公司做出来，2026 年 5 月把两个核心 Skill 开源到了 GitHub 上，用的是相对宽松的 MIT 协议。我不打算把它吹成银弹——它有明确的边界，尤其在国内用的时候合规这根弦得一直绷着——但它对"Agent 到底缺什么"的判断，我是认同的：缺的不是脑子，是一双能在真实网页里稳住的手。
莫潇羽@源码七号站 这篇文章想做的，不是给你一份"照抄就能跑"的脚本，而是把这套能力体系背后的道理讲清楚。你理解了每一层在解决什么问题、边界画在哪，无论以后用哪个工具，判断力都是通用的。工具的名字、命令的参数、免费和付费的分界，这些都会随版本变，但"真实网页难在哪、一套完整能力体系该长什么样"这个框架，是能陪你走很久的。我自己也是先想通了框架，再回头看具体工具，才不至于被一个个花哨的功能名词绕晕。所以这篇你可以当成一张"地图"来读——先有地图，再谈选哪条路。
二、先分清两件事：网页内容，和网页任务
聊具体能力之前，我想先掰扯一个特别容易混的概念。因为我发现很多人一上来就把工具选窄了，根子就在这里没分清楚。
第一件事叫"网页内容"，第二件事叫"网页任务"，这俩不是一回事。
网页内容，说白了就是"我想读到这个页面里的东西"。比如一篇公开文章的正文、一个页面上的一张表格、一段结构化的数据。你要的是"读"，是把渲染完的内容干净地拿出来。
网页任务，是"我要在这个页面里把一件事做完"。比如登录进后台、在搜索框里输入关键词、点开某一条结果、翻到第三页、把筛选条件切一下、再把最终结果导出来。你要的是"做",是一连串带状态、带前后依赖的操作。
这两件事对工具的要求完全不同。
只读内容的场景，最怕的是"拿不到"和"拿回来一坨"。拿不到，通常是被环境校验挡了，或者页面靠 JS 渲染、你发个静态请求根本看不到正文。拿回来一坨，是指你拿到的是几百 KB 的原始 HTML，里面广告、脚本、埋点、样式全混在一起，Agent 得先在里面淘半天才能找到真正有用的那几段，既慢又费 token。
针对这一类，browser-act 里有个叫 stealth-extract 的命令，思路值得说一下。它不是发个静态请求就完事，而是真的起一个带反检测能力的浏览器把页面渲染出来，再把正文结构化地抽出来。拿回来的不是原始 HTML，而是可以直接读、直接分析、直接往下推理的内容。一条命令，零配置：
# 提取一个需要 JS 渲染、带环境校验的公开页面的正文
# 注意：仅用于你有权访问、且目标站点允许抓取的公开内容
browser-act stealth-extract "https://example.com/some-public-article" --content-type markdown我拿它试过一些"用普通 fetch 读不到正文"的公开页面，确实能把标题、正文这些结构化地带回来。这里我要特别停一下强调：能不能技术上抓到，和该不该抓、允不允许抓，是两码事。 后面第九节我会专门讲合规，这里先记住一句——stealth-extract 是个能力，不是许可证。你要抓的必须是公开、你有权访问、且目标平台的 robots 协议和服务条款没有禁止的内容；涉及版权的正文，拿来做个人学习分析可以，拿去大规模复制搬运就越线了。
做任务的场景就完全是另一个世界了。它的难点不在"读一次",而在"读—做—再读"要循环很多轮，而且每一轮页面都可能变。你在第一页拿到的那个"第 3 个按钮"，翻页之后可能已经是另一个东西了。传统脚本最容易死在这里：选择器写死了，页面一动就对不上号。
所以在往下讲之前，先把这条分界线记住。后面你会看到，stealth-extract 主要服务"读内容"，而 state / click / input / wait 这套组合拳服务"做任务"，两者的设计取向是不一样的。很多人用着用着觉得别扭，往往就是拿"读内容"的工具去硬扛"做任务"的活，或者反过来。
我自己的经验是：先判断你到底要"读"还是要"做"，再决定用哪套能力。 这个判断花不了几秒钟，却能省掉后面一大堆无效折腾。这也是我写这篇的一个小执念——工具会换，但"先分清内容和任务"这个习惯，是能一直帮到你的。
三、"看—做—再看"：Agent 操作网页的核心循环
如果只让我挑一个"传统网页自动化脚本"和"给 Agent 用的浏览器"最本质的区别，我会挑这个：执行的顺序，从"写死—执行"变成了"先看—再做—看变化再重新看"。
传统脚本的写法，本质是一条直线。你提前把选择器写好，脚本按顺序去执行：找到这个元素、点它、等一会、再找下一个元素、再点。问题是这套逻辑对页面有个隐含假设——页面是它想象中那个样子。可现实里页面会变：弹窗冒出来了、布局重排了、内容异步加载慢了半拍，任何一点风吹草动，写死的选择器就对不上，脚本当场崩掉。写过网页自动化的人都懂，这类"页面一变就挂"的失败，占了故障里相当大的一块。
给 Agent 用的浏览器，换了个思路。它不预设页面长什么样，而是每一步都"先看一眼现在的页面，再决定怎么动;动完等页面稳下来，再看一眼"。这个循环，我把它拆成三步。
第一步：获取当前页面状态，每个元素都带编号
先让工具把当前页面能交互的元素列出来，每个都给一个编号：
browser-act --session demo state它回给你的大概是这样一份紧凑的清单（示意）：
[1] <a> 了解更多
[2] input "搜索"
[3] button "开始"注意这里的形态：不是一坨 HTML，也不是一大段 JSON，而是"编号 + 元素类型 + 语义标签"的索引文本。Agent 一眼就能看懂第 2 个是搜索框、第 3 个是开始按钮。
第二步：用编号交互
看清楚之后，直接用编号去操作，不用再去纠结那一长串选择器：
browser-act --session demo input 2 "关键词"
browser-act --session demo click 3input 2 就是往第 2 个元素里输入，click 3 就是点第 3 个。语义清楚，指令干净。
第三步：等页面稳定，重新获取状态
这一步是整个循环里最关键、也最容易被忽略的一环：
browser-act --session demo wait stable
browser-act --session demo state点完之后页面大概率变了——可能跳转了、可能弹窗了、可能异步加载了新内容。这时候一定要先等它稳下来，再重新 state 一次，拿到一份全新的元素编号。旧的编号在这一刻就作废了。 你绝不能拿上一屏的"第 3 个按钮"去点这一屏的东西，因为这一屏的第 3 个，很可能已经是完全不同的元素。
这个细节看着小，但它恰恰堵住了传统脚本一大类失败的来源。因为每一轮都是"重新看一遍当前页面"，页面怎么变都不怕——变了就重新看，看到什么按什么。我把这个循环画成流程图，会更直观：
flowchart TD
A[获取当前页面 state<br/>每个元素带编号] --> B[按编号交互<br/>input / click]
B --> C[wait stable<br/>等页面稳定]
C --> D[旧编号作废<br/>重新 state]
D --> E{任务完成?}
E -->|否| B
E -->|是| F[结束 / 提取结果]除了"抗变化"，这套交互方式还有两个我很喜欢的附带好处。
一个是省 token。 state 返回的是紧凑的索引文本，比直接把 JSON 或者原始 HTML 喂给模型，能省好几倍的 token。这一点对成本影响很大。官方给过一个对比口径：相比直接处理原始 HTML 的流程，这类做法能砍掉九成以上的 token 消耗——它会在把内容交给模型之前，先把大约九成的垃圾 HTML 剥掉。数字未必要照单全收，但方向是对的：你喂给模型的信息越干净，它越不容易被无关内容带偏，花的钱也越少。
另一个是"语义记忆"。 在多浏览器、多会话并行的时候，每个浏览器实例可以自带一段描述（desc），说明它是干嘛的。Agent 按语义去匹配"这个任务该用哪个浏览器"，不用每次都从头摸索。配合会话隔离，多个任务、多个账号可以各跑各的，互不串味。
把它串成一个完整的小例子
光看单个命令可能还是有点抽象，我把一个"在搜索框里查东西、点开第一条结果"的完整流程串一遍，你就明白这个循环在实际里长什么样了（下面是示意）：
# 1) 先看当前页面有哪些能交互的元素
browser-act --session demo state
# [1] <a> 了解更多
# [2] input "搜索"
# [3] button "搜索"
# 2) 在搜索框里输入关键词，点搜索
browser-act --session demo input 2 "我要查的内容"
browser-act --session demo click 3
# 3) 等页面稳定——搜索结果是异步加载的，急不得
browser-act --session demo wait stable
# 4) 旧编号已作废，重新看一遍新页面
browser-act --session demo state
# [1] <a> 结果标题一
# [2] <a> 结果标题二
# [3] button "下一页"
# 5) 点开第一条结果，再进入下一轮"看—做—再看"
browser-act --session demo click 1你注意到没有？第 4 步重新 state 之后，编号 1、2、3 指向的已经是搜索结果页的元素，和第 1 步搜索页的编号完全不是一回事了。如果你在第 5 步还用第 1 步记下的编号去点，点到的就是南辕北辙的东西。 这就是为什么"每一轮都重新看"不是啰嗦，而是刚需。整个过程里，Agent 不需要你提前把任何一个选择器写死，它是"走一步、看一步、再走一步"，页面怎么变都能接得住。
这里插一句我踩过的坑。刚上手那会儿，我图省事，跳过了 wait stable 直接连着点，结果就是概率性地点空、点错。后来老老实实每一步都"点完等稳、重新看状态"，稳定性立刻上了一个台阶。别小看"重新看一眼"这个动作，它是这套循环里最不该省的一步。 莫潇羽@源码七号站 这里给你一个可以直接抄走的心法：宁可多 state 一次，也别拿旧编号赌新页面。
四、真实网页的第一道坎：环境层的"反检测"到底在做什么
聊到这里，就绕不开这类工具最被人津津乐道、也最需要小心措辞的部分——反检测。我先把话说在前头：这一节是科普，讲的是"网站怎么识别自动化流量、工具又怎么让浏览器更像真人"的原理，帮你理解能力边界；它不是教你去突破谁家的风控。 怎么合规使用，第九节会专门讲。
要理解反检测，得先理解"网站怎么知道你是机器人"。今天的风控早就不是看看 IP 那么简单了，它会从几十个维度给你的浏览器"验明正身"。这些维度大致分几类。
任何一处露馅，都可能被判成"疑似机器人"，轻则弹验证，重则直接拦。所谓反检测浏览器（业内常叫 Stealth 浏览器，直译就是"隐身"浏览器），干的事情就是在这几十个指纹点上，尽量让自己看起来是一台普通真机。
具体到 browser-act 这类工具，环境层大致做了这么几件事：
- 指纹伪装：把 navigator.webdriver、Canvas、WebGL、GPU、音频、字体、屏幕参数等几十个指纹点统一处理，减少自动化痕迹的暴露。
- TLS 指纹轮换：让网络层的握手特征更贴近真实浏览器，而不是一眼就能认出的脚本客户端。
- 代理轮换：为不同浏览器实例配置不同的出口，避免同一来源被高频访问的模式盯上。这里的"代理"指的是反检测用的出口 IP 轮换，和"突破网络管控"是两回事，别混淆；后面合规一节我会再点一句。
- 行为模拟：模拟更接近真人的鼠标轨迹和操作节奏，进一步降低被行为风控识别的概率。
官方公开过一些指纹检测和人机检测的对照，包括在 reCAPTCHA v3 这类打分型验证里能拿到 0.9 这个偏"像真人"的分数（满分 1.0，分越高越像真人）。这些数字我不逐条搬运，也建议你别把它当成"永远有效"的承诺——风控和反检测本来就是一直在互相升级的动态博弈，今天的高分不代表明天。你要记住的是这一层的定位：它负责让浏览器在底层尽量不像机器人，从而让大部分拦截压根不触发。
这里还有个认知我想帮你校准：反检测和风控之间，是一场没有终点的动态博弈。网站的识别策略在升级，反检测的手段也在跟着变，谁都不可能一劳永逸。所以你会看到，这类工具很少承诺"百分百不被识别"，靠谱的说法都是"降低被识别的概率""让大部分拦截不触发"。理解了这一点，你对它的预期就会更理性——它是把摩擦从"经常撞墙"降到"偶尔遇阻"，而不是给你一件永远有效的隐身衣。也正因为是动态博弈，你更不该把"能不能过"当成决策依据，而要把"该不该做"放在前面：一个你本来就有权访问、平台也允许自动化的场景，摩擦小、心里也踏实；一个明摆着禁止自动化的场景，你就算这次侥幸过了，也随时可能在下一次策略升级里翻车，还得担违约甚至违法的风险。
为什么说这是"第一道坎"？因为它是整套体系里最靠前、也最省事的一层。绝大多数拦截，如果环境层做得足够到位，是根本不会弹出来的。只有环境层没兜住的那部分，才会往后交给下一层去处理。这就引出了它的分层设计——一层兜一层，而不是指望某个单点包打天下。
不过我也想给这一层泼一点冷水，免得你产生不切实际的期待。反检测不是"隐身衣"，它降低的是被识别的概率，不是把概率归零。 尤其是那些风控做得很重、专门盯着自动化流量的平台，你越是想跟它硬碰，越容易撞上更严的策略。所以从工程角度，我更愿意把这一层理解成"减少不必要的摩擦"，而不是"强攻别人的城墙"。从合规角度更是如此：技术上能不能更像真人，和你有没有资格去访问那份数据，完全是两个问题。莫潇羽@源码七号站 的态度一直很明确——能力是中性的，怎么用才决定它是不是踩线。
五、遇到验证怎么办：能自动的先自动，该停的一定停
环境层做得再好，也总有兜不住的时候——验证还是弹出来了。这时候一个工具的设计成熟不成熟，差距就出来了。
很多产品做到环境层就收工了：浏览器指纹像真人了，剩下的你自己想办法。而一套完整的能力体系，会把这一层继续往下接。browser-act 的处理分成两段，界限画得挺清楚。
能自动解决的，先自动解决
第一段是执行层。遇到验证弹出来，先用 solve-captcha 尝试自动处理：
browser-act --session demo solve-captcha它目前支持了主流几家的多种验证类型，内置自动求解，不依赖第三方打码服务。但注意它的设计哲学不是"所有验证码都能自动过"，而是"能自动解决的先自动解决，处理不了的，往下交。"这个态度我觉得很重要——它没把自己吹成万能钥匙，而是老老实实承认有它搞不定的场景。
这里必须再插一句合规提醒，而且要重一点：自动处理验证码这件事，本身就有明确的适用边界。 你在自己的账号、自己有权操作的系统里，让 Agent 帮你过一道常规的人机校验，这是一回事;去批量突破一个明确禁止自动化、专门用验证码保护的公共服务，那是另一回事，后者在很多平台的服务条款里是直接违约的，严重的还可能碰法律红线。技术能做到，不等于你可以做。这条线，第九节还会再强调。
该让人接手的，绝不自己乱闯
第二段，是我最欣赏的设计——人机协作。
道理其实很朴素：真实网站里，不是所有验证都能、也都该自动处理。扫码登录、短信验证码、企业 SSO、OAuth 授权、支付确认、人脸或指纹核验……这些步骤，本来就不应该让一个 Agent 偷偷绕过去。它们存在的意义，恰恰是"确认这件事是本人在做"。
那 Agent 怎么知道什么时候该停？是瞎猜吗？不是。这类工具内置了一套场景识别：遇到密码输入、支付确认、扫码登录、短信验证、安全密钥、人脸/指纹核验、SSO 跳转这类操作，Agent 不会硬闯，而是触发 remote-assist，生成一个远程协作链接，明确告诉你——这一步得你来。
# 遇到需要本人完成的步骤，生成一个远程协作链接交回给人
browser-act --session demo remote-assist这个设计有两个地方特别巧。
第一，人接管不是"接管全部"。 你只需要处理当前卡住的那一步——扫个码、输个验证码、点个确认——做完之后 Agent 从断点继续往下走，浏览器会话原封不动，前面的进度不会丢。
第二，不要求你必须守在电脑前。 拿到链接后，你可以在已经接入 Agent 的移动设备上远程完成这一步，点一下"已完成"，Agent 就从刚才断掉的地方接着跑。跨设备接力，这一点在实际用起来的时候真的很省心。
我举个自己实际遇到过的场景，你会更有体感。有一次让 Agent 帮我在一个我自己的后台里整理一批数据，跑到登录环节，系统要求扫码确认。换成传统脚本，这里要么直接卡死、要么得我提前把凭证硬塞进去（这本身就不安全）。而这套流程的处理是：Agent 识别到这是一个"需要本人扫码"的步骤，自动停下来，生成了一个协作链接。我掏出手机打开链接，扫了个码，点一下"已完成"，Agent 就从登录后的那一步继续往下跑，前面已经打开的页面、已经填好的筛选条件，一个都没丢。
整件事最舒服的地方在于"最小打扰"——它没让我从头接管，只把真正需要我这个"人"来确认的那一下交给了我，其余的活它自己接着干。这种"该我出手时才叫我、平时它自己扛"的分工，比"要么全自动、要么全手动"的二选一体验好太多了。
我把整个"遇到验证"的处理逻辑整理成一张表，一眼就能看清三层是怎么配合的：
这套"一层兜一层"的分工，我觉得比"某个单点特别强"要靠谱得多。因为真实网页的复杂度，本来就不是一招能吃遍的。把"必须人帮一下"的步骤正大光明地纳进工作流，任务就不会莫名其妙死在中间——这不是缺点，这是个安全阀。 它既保证了流程能往下走，又守住了"该本人确认的事，就得本人确认"这条底线。对国内用户来说，这个安全阀的意义还多一层：登录、支付、发布这些敏感动作留一道人工确认门，本身就是合规友好的做法。
六、把"摸网页"的经验固化下来：可复用 Skill 才是长期价值
前面讲的都是"单次怎么把网页跑通"。但真正让我眼睛一亮的，是另一件事——怎么让今天跑通的流程，明天、下个月、换个人换个会话，还能一模一样地重来。
这就要说到 browser-act 配套的那个"造工具的工具"：Skill Forge（技能锻造）。
一听到 Skill，很多人第一反应是："是不是又得写一堆代码?"如果全靠手搓，那确实不轻松。但 Skill Forge 的思路反过来了：它让 Agent 先跟着你的需求把网站摸一遍，再把"怎么摸的"整理成下次能直接调用的能力。你要做的，只是把需求用大白话说清楚。
你需要交代的其实就三件事：目标网站是哪个、支持什么输入方式、想提取哪些字段。有了它，哪怕完全不会写代码，也能把一个重复的网页任务变成一个可复用的工具。
它的工作流程大致是这样：
flowchart LR
A[用大白话描述需求] --> B[Agent 探索网站一次]
B --> C{有没有更稳的路径?}
C -->|优先| D[找可复用的数据接口<br/>API-first]
C -->|退而求其次| E[回退到 DOM 路径<br/>确认稳定DOM 元素]
D --> F[验证并测试]
E --> F
F --> G[封装成 Skill 包<br/>SKILL.md + 脚本]
G --> H[以后直接调用<br/>无需重新探索]这里有个技术细节值得单独夸一下：它探索时是"接口优先，DOM 兜底"。 先看这个页面在加载数据时有没有走某个内部接口——如果有，直接用接口拿数据，比在 DOM 里一层层扒稳定得多（业内一般认为接口路径的稳定性能高出一个量级）。接口不合适，才退回到 DOM，去确认哪些DOM 元素能稳定拿到数据。选DOM 元素的时候它也有讲究，优先用 data-testid、id、name、aria-label 这类语义化的标识，尽量少用"第几个子元素"这种一变就废的位置索引。
探索、验证之后，它会把跑通的方法封装成一个 Skill 包：一个 SKILL.md 执行说明，加上配套脚本。之后你（或者别的 Agent）再要处理同样的任务，直接调用这个 Skill 就行，不用重新解释"标题在哪个DOM 元素""发布时间怎么读""正文怎么保存"。官方给这套模式起了个口号，叫"探索一次，永久复用"。
用起来是什么感觉
举个贴近实际的例子。假设你经常要从某个你有权访问的公开信息站上，按关键词把若干条记录的"标题、链接、更新时间"整理出来。装好 Skill Forge 之后，你要做的不是写脚本，而是用大白话把需求交代清楚，类似这样：
帮我做一个从这个网站按关键词提取记录的 Skill。
输入是一组关键词，输出每条记录的标题、链接和更新时间。它确认需求后就自己开跑了：先打开真实浏览器把网站摸一遍，优先去找这个页面加载数据时走的内部接口——如果找到了，就用接口拿数据，又快又稳；找不到合适的接口，就回退到 DOM，去确认哪几个DOM 元素能稳定拿到标题、链接、时间这几个字段。字段、翻页、边界情况、失败场景，它都会试一遍，验证哪条路真的能走通。全程基本不用你在旁边盯着。
探索、验证之后，它会把跑通的方法封装成一个 Skill 包：一个 SKILL.md 执行说明，加上配套脚本。之后你（或者别的 Agent）再要处理同样的任务，直接调用这个 Skill 就行，不用重新解释"标题在哪个DOM 元素""更新时间怎么读""结果怎么保存"。官方给这套模式起了个口号，叫"探索一次，永久复用"。
这里我要把前面那句技术细节再展开一点——它探索时"接口优先、DOM 兜底"的顺序，不是随便定的。页面上你看到的内容，很多是先通过一
