【正文开始】说实话我第一次看到 Agent 自己打开浏览器、移动鼠标、把一张演示票成功买下来的时候心里冒出的一句话是“那我这些年手搓的爬虫算什么”以前我们聊“让程序上网拿数据”第一反应永远是写爬虫分析 DOM、找接口、拼参数、过校验、处理登录态、对付反爬。这套手艺干了几年的人都懂每一个环节都是血泪。可当我看到 Claude 这类具备“电脑操作能力”的 Agent 直接像人一样打开网页、看清楚页面、点按钮、填表单、完成交易时我意识到一个问题——爬虫的尽头不是更强的爬虫而是另一种完全不同的东西一个会自己看屏幕、自己动手的 AI“实习生”。这篇文章我想把这个东西彻底讲透。它到底是什么原理、和手搓爬虫有什么本质区别、我实测让它独立完成一次完整购票流程的真实过程、以及它现在还存在的各种坑。如果你也在写自动化脚本、做数据采集或者只是对 Agent 到底能做到什么程度感到好奇这篇文章应该能给你一个非常具体的答案。1. 手搓爬虫的尽头为什么“能买到票”的目标爬虫经常做不到在聊 Agent 之前我想先认真聊聊爬虫这个老伙计。很多人对爬虫的印象是“写个请求、解析 HTML、拿到数据”听起来很简单但真正在线上跑过的人都知道要稳定完成一个需要交互的流程比如买票事情会迅速失控。1.1 爬虫处理“交互”时的天然窘境买票这件事本质上不是“一次请求拿到结果”而是一连串有上下文的状态流转查票→选场次→填信息→确认订单→支付。中间任何一步走错整个会话就废了。传统爬虫处理这种流程通常有两条路一是直接逆向后端接口把每个请求的参数模拟出来二是用无头浏览器驱动按脚本一步步执行。两条路各有各的疼。走后端接口这条路最怕的就是页面改版。我见过太多半夜被报警电话叫醒的情况——不是服务器挂了而是前端把某个字段名从ticketPrice改成了priceInfo.amount脚本直接解析失败。前端和后端的耦合越紧爬虫的维护成本越高。只要产品经理心情好换个交互逻辑你的自动化脚本就要跟着重写一轮。走无头浏览器这条路相对抗改版但依然很脆弱。因为无头浏览器本质上还是在执行一套写死的“按钮路径”点击坐标 (x, y)、输入某个输入框、等待某个元素出现。只要页面结构一变或者某个弹窗提前冒出来脚本就全乱套了。更麻烦的是无头浏览器对动态渲染内容的处理经常慢半拍你明明在代码里写了sleep(3)结果 3 秒后页面数据还没加载完。1.2 风控与验证码绕来绕去的军备竞赛爬虫的第二个大敌是风控。现在的风控早就不是“验证码 IP 限流”这么简单了。我见过比较狠的行为轨迹检测。你鼠标移动的轨迹、点击间隔、输入速度、页面停留时长都会被记录。如果行为特征太像机器人风控系统会直接给你一个“虚拟正常页面”——页面长得一模一样但所有数据都是假的你辛辛苦苦解析半天拿到的全是废数据。为了对抗这些手段手搓爬虫的人练就了一身十八般武艺代理 IP 池、指纹浏览器、行为模拟、验证码识别服务……一个比一个复杂。每次风控策略一升级前面所有努力可能一夜清零。我身边一位做数据采集的老哥说过一句特别扎心的话“我哪是在写爬虫我是在和整个前端团队、风控团队打一场永远赢不了的仗。”1.3 本地临时演示某模拟购票系统的“翻车现场”为了验证我上面说的这些痛点我在一个自己搭的模拟购票网站上做了一个实验。这个网站没有复杂的验证码页面也基本稳定我只是用它来测试一个简单的爬虫脚本查一下指定场次是否还有余票。第一天脚本正常运行输出正确。第二天我在页面上加了一个促销弹窗。结果脚本直接崩了——不是逻辑出错而是它解析的主内容节点被弹窗遮住后HTML 结构里多了一层遮挡层原本的 XPath 定位全部失灵。这个改动说小不小说大也不大但它足够让一个“稳定运行”的爬虫瞬间下岗。这种问题不是技术不够好而是爬虫的思维方式有根本缺陷它假设页面是静态的、结构是确定的、流程是线性的。但现实中的网页是活的、会变的交互是开放的。用一套写死的逻辑去应对一个无限变化的对象这就是手搓爬虫的尽头。2. Agent 的“上帝之手”Claude 到底是怎么自己上网的聊清楚了爬虫的天花板我们再来看看 Agent 是怎么突破这个天花板的。这一章我会尽量把原理讲得通俗对理解后面实操很有帮助。2.1 不再“解析页面”而是“看懂页面”传统爬虫获取信息的方式是解析 HTML 结构比如“找到 id 为 content 的 div 里的第一张图片”。而 Agent 的方式完全不同——它直接把整个网页截图“看”一遍通过视觉理解模型识别出页面上的文字、按钮、输入框、卡片信息然后决定下一步操作。这两者之间的差别你可以这样理解爬虫像一个蒙着眼睛、靠摸墙壁纹理走路的机器人它必须精确记住“第三个转弯处有一块砖是松的”而 Agent 像一个睁着眼睛走路的实习生它看到门就推门看到楼梯就上楼不需要提前背下每个台阶的高度。正是因为 Agent 理解的是“视觉语义”而不是“DOM 结构”所以就算页面改版了、按钮换了个位置它依然能通过观察新的页面获得信息。这个特性从根上解决了爬虫第一大痛点页面改版。2.2 操作链路观察、决策、行动、验证Agent 操作浏览器的完整链路可以分为四个环节观察截取当前浏览器窗口的截图可能还包括浏览器辅助信息如无障碍树、可点击元素列表等让 Agent 知道“现在页面上有什么”。决策大模型根据用户给的指令和当前页面状态决定“下一步做什么”。这一步输出的不是代码而是一个高级动作意图比如“点击位于屏幕上某个区域的‘立即购买’按钮”。行动本地执行器将动作意图转换为真实的鼠标点击、键盘输入、滚动操作。验证操作完成后再次截取屏幕确认页面状态是否如预期变化。如果没变化就继续调整策略。这四个环节循环往复直到完成整个任务。这里有一个非常关键的细节Agent 的决策是基于“当前这一秒的实际页面状态”实时做出的而不是预先写死的脚本。所以即使页面流程中出现了意料之外的情况比如弹窗、加载延迟、临时错误提示它也能根据新的截图做出应对。这就是 Agent 比传统自动化脚本更有“人味”的核心原因。2.3 不是 RPA胜似 RPAAgent 和自动化脚本的本质区别很多人一听到“Agent 操作浏览器”第一反应是“这不就是 RPA 吗”表面看确实像都是模拟鼠标键盘操作但底层逻辑完全不同。RPA 的核心是“录制并回放”你先手动操作一遍它记录步骤然后反复执行同样的步骤。一旦界面稍有变化录制的步骤就失效了。Agent 的核心是“理解并执行”每次操作前它都要“看”一眼当前页面理解现状然后决定做什么。它不是回放而是即兴演出。台本用户指令是固定的但每一句台词操作动作都是根据现场反应生成的。用一句话概括RPA 是复读机Agent 是即兴喜剧演员。后者不需要把每一句话都背下来只需要明白目标然后随机应变。3. 实测全流程让 Agent 独立完成一次购票原理说再多不如上手跑一遍。这一章我完整复盘了我在一个模拟购票测试站点上让 Claude 从打开浏览器到完成下单的全过程。所有操作都是可控的、安全的只是用来验证技术能力。3.1 环境准备想跑起来需要哪些组件在我实测的环境中至少需要以下四样东西组件作用说明支持 Agent 能力的大模型服务负责视觉理解与动作决策需要开通相应 API 权限本地执行器把模型输出的动作转成真实的鼠标键盘操作通常以浏览器插件或本地服务形式存在浏览器环境Agent 实际操作的对象建议使用独立的浏览器配置或用户目录目标站点被测的页面我这里用的是本地搭建的模拟购票站具体的安装方式不同环境差异很大这里不展开每一条命令。我只强调一个容易忽略的点建议给 Agent 单独建一个浏览器用户目录。这样它的登录状态、Cookie、历史记录都是隔离的不会污染你日常使用的浏览器也便于随时重置状态重新测试。我第一次没隔离结果 Agent 在测试过程中登录了我自己的账号虽然没什么严重问题但那种“有东西在替你操作你的账号”的感觉确实让人心里发毛。3.2 核心调用逻辑与代码骨架在实际运行中整个调用的逻辑其实不复杂。以下是一段示意性的代码骨架用来展示整个交互过程的结构。真实使用时需要根据你所用的具体服务调整接口细节# 示意代码展示 Agent 操作浏览器的整体流程 # 具体 SDK 与 API 请以你所用的服务官方文档为准 from agent_runtime import AgentClient, BrowserSession # 1. 启动一个独立的浏览器会话 session BrowserSession( browser_configisolated_profile, headlessFalse, # 建议有头模式便于观察过程 viewport(1280, 800), ) # 2. 创建 Agent 客户端绑定大模型服务 client AgentClient( api_keyyour_api_key_here, modelclaude-computer-use, # 示意名称 max_steps50, # 最大操作步数防止死循环 ) # 3. 下指令让 Agent 开始干活 instruction ( 打开浏览器访问本地模拟购票站点 http://localhost:8080 选择本周五晚上七点的场次选择两张相邻的座位 填写姓名和手机号使用测试信息提交订单。 下单成功后停止并输出订单号。 ) result client.run( instructioninstruction, sessionsession, stop_conditions[订单提交成功, 已生成订单号], ) print(result.action_log) # Agent 每一步操作的记录 print(result.final_state) # 最终页面状态这段代码最核心的一点是stop_conditions。它是你的“安全带”——告诉 Agent一旦检测到任务完成就立即停止不要继续乱逛。我一开始没有设置这个条件Agent 在完成下单后居然开始点击“浏览更多推荐场次”差点跑偏。加上停止条件之后整个流程就干净多了。3.3 Prompt 设计想让 Agent 干活利索指令要这样下也许你会觉得既然 Agent 这么智能那指令随便说说不就行了实测告诉我不行。指令的质量直接影响任务的成功率和效率。我整理了几个关键的指令设计原则明确目标而不是描述步骤。不要说“先点击搜索框输入关键词再点击搜索按钮”这是脚本思维。应该说“查询本周五晚上七点的场次”。Agent 自己会想办法找到搜索框、输入内容、点击搜索。给出约束条件。比如“选择两张相邻的座位”、“使用测试信息填写表单”这些约束条件 Agent 会主动遵守。如果没说它可能选两张分开的座位或者填一个看起来像样的假姓名。定义明确的完成标志。最核心的一句话是“下单成功后停止并输出订单号。”这句话告诉 Agent 什么算“活干完了”。没有这句话Agent 不知道什么时候应该停下来交差。必要时设置任务边界。比如明确告诉它“不要刷新页面”、“不要点击非目标区域的广告位”、“支付环节仅到确认页即可不要真实支付”。安全边界在实测中非常重要尤其是涉及真实账号、真实金额的流程务必要写清楚。3.4 实测过程记录它是怎么一步步完成的我把完整日志简化后附在这里你可以直观感受到 Agent 的“思考过程”启动浏览器访问站点首页。观察页面识别出“演出日历”区域定位到“本周五”标签。点击“周五”后页面刷新出现场次列表。Agent 停顿约 1 秒识别出“19:00”场次的卡片。点击该场次卡片进入选座页。观察座位图识别出可售座位和已售座位的颜色差异。根据“相邻座位”约束选择第 7 排 3 号和 4 号座。点击“确定选座”进入信息填写页。逐项填写测试姓名、测试手机号。其中手机号输入框有格式校验Agent 第一次输入后页面提示“格式错误”它读了提示信息自行纠正后重新输入。点击“提交订单”页面弹出确认框。Agent 点击“确认”。页面跳转到订单成功页页面上显示订单号。Agent 检测到“订单号”出现读取并输出然后停止。整个过程大约用时 2 分多钟一共进行了 18 次“观察-行动”循环。最让我意外的是第 7 步手机号格式错误后Agent 没有乱猜而是读取了页面上的错误提示自行调整输入格式。这种“根据反馈纠正行为”的能力是传统自动化脚本完全做不到的。4. 和传统爬虫的全面对比不是“升级”而是换赛道在这一章里我把传统爬虫和 Agent 做了一次系统性的对比。看完这个表格你应该能明白为什么我说这是换赛道而不是简单升级。4.1 八个维度逐一对比对比维度传统爬虫Agent以 Claude 为例页面理解方式解析 HTML/DOM 结构视觉语义理解看图页面改版应对需要改代码很脆弱自动适应无需改逻辑动态加载处理需要手动等待或轮询自动观察页面状态变化交互能力脚本控制需预先编排实时决策随机应变异常处理几乎无靠 try-catch观察反馈后自动纠正开发门槛需要懂前端、网络协议只需描述目标会写 prompt 即可维护成本高页面一变就要改低指令不变就不用改运行稳定性受限于结构匹配度受限于模型决策能力和上下文长度这里最值钱的一条是“页面改版应对”。我举个例子还是那个模拟购票站我把选座页的座位图从矩形布局改成了圆形布局。传统爬虫如果靠坐标定位直接全崩如果靠元素 id也要改代码。而 Agent 只是重新“看”了一眼新的座位图通过颜色和位置关系就完成了选座一条指令都没改。4.2 为什么说这是“换赛道”而不是“升级”传统爬虫追求的是“你告诉我网页结构我帮你精确提取数据”。它的核心能力是稳定性、速度、解析精度。在这个维度上Agent 目前还比不过爬虫它每一步都要看屏幕、做决策速度和成本都不占优势。但 Agent 追求的是“你告诉我目标我自己想办法完成”。它的核心能力是理解、决策、适应变化。在网页结构千变万化的开放场景下这个能力是传统爬虫永远补不上的短板。一个很形象的类比爬虫是高铁速度快、准时、但必须在固定的轨道上跑Agent 是出租车速度慢一点、贵一点但你想去哪儿它都能把你送到路断了还能绕行。两者的目标压根不一样。4.3 什么场景该用什么我的一点建议经过实测我的判断是这样的如果任务是高频、大规模、结构稳定的数据采集比如每天抓取某个指数行情、监控固定网站的特定价格传统爬虫依然是更靠谱、更省钱的选择。Agent 的“智能”在这里反而是累赘慢、贵、偶尔还会自作聪明。如果任务是低频、复杂、多变、需要交互的操作比如临时买一张票、填写某个表单、处理一个需要多步操作的任务Agent 的体验远超爬虫。你不需要花半小时分析页面结构只需要说一句话。另一个值得注意的场景是“维护历史遗留爬虫”。很多团队都有那种页面早改版十次、全靠修修补补维持的爬虫。这种项目与其继续补丁叠补丁不如直接用 Agent 重写一遍逻辑长期看反而省心。5. 翻车实录Agent 上网买票时会遇到哪些坑写到这里如果我只讲好的那就太不负责任了。Agent 在实际使用中还有不少问题。这一章我用实测过程中遇到的真实问题给你展示完整的翻车现场和排查思路。5.1 坑一页面加载太快Agent 反而“眼花了”第一次实测时我遇到一个很有意思的 bug传统爬虫嫌页面加载慢Agent 倒是嫌加载太快。当时页面有一个loading 动画从列表页跳转到详情页时会出现大约 0.3 秒的过渡。Agent 截屏的时候正好赶上了动画中间帧——页面上所有元素都在半透明状态。它把这种状态识别为“页面载入异常”尝试点击刷新按钮。刷新之后又赶上动画再次误判。要不是我设置了最大步数 50 的限制它能在这个循环里转十分钟。排查过程我先看了 action_log发现 Agent 一直在重复“点击刷新”这个动作。然后我手动放慢了模拟器环境中的渲染速度加了一层延迟问题立刻消失。后来我做了两个改进一是要求 Agent 在点击导航操作后先等待页面稳定再观察二是遇到不确定状态时优先截取新截图确认而不是直接刷新。从此这个坑没有再出现过。5.2 坑二模态框和弹窗会让它“误入歧途”还有一个非常典型的问题是页面里的营销弹窗。在那个模拟购票站里我在“选座页”右下角放了一个“领取优惠券”的浮窗。第一次测试时Agent 并没有理会它直接完成了选座。第二次测试时浮窗延迟了半秒才弹出Agent 的第一次点击“确定选座”正好落在了浮窗上结果触发了一个领券引导页。接下来的剧情就很搞笑了Agent 发现自己到了一个陌生页面没有立刻返回选座页而是在领券页仔细“阅读”了优惠券说明试图找出哪张券能用于本次购票。它花了 3 个循环才发现自己走错了地方才返回选座页重新操作。这个问题暴露了 Agent 的一个弱点它非常尊重页面上可见的交互元素但也因此容易受到诱导。我的解决办法是在指令里显式加上“忽略所有非必要的弹窗和浮窗除非其内容与购票直接相关”效果立竿见影。5.3 坑三上下文窗口是硬天花板第 18 步Agent 在第 18 个循环完成了任务。但如果你任务更长呢每一次“观察-行动”循环都要把一屏截图可能是一张近百万像素的图片输给模型这极其消耗上下文长度。一个比较复杂的任务可能需要 50-80 个循环。如果中途 Agent 因为某个异常多绕了几个弯可能任务还没完成上下文窗口就满了。窗口满了之后Agent 会“忘记”最初的目标开始做一些和主任务无关的事情。这个问题目前没有完美解法只能从设计上缓解尽量把大任务拆成多个小任务每个小任务单独一次会话设置足够小的max_steps宁可任务失败也不要让 Agent 在超长上下文里胡来。5.4 安全与权限边界必须提前立好的规矩最后必须讲的是安全。Agent 在浏览器里能做的事和你自己手动操作浏览器能做的事是一样的它能登录账号、能提交数据、能点击支付。这意味着它的“能力边界”完全取决于你把一个什么样的浏览器交到它手里。我在实测中有几个默认的安全规矩建议每一位准备尝试的人直接照抄专用浏览器环境不要用你日常登录了各种账号的浏览器。给 Agent 单独开一个用户目录或专门的浏览器配置。最小权限原则让 Agent 做的事只限定在任务必需的范围。不要让它“顺便查一下其他信息”它会真的去查。敏感操作留人工确认凡是涉及支付、修改重要设置、对外发送消息的操作最好在流程中加一个人工确认环节。Agent 决定做人类确认做。设置停止条件就像我之前讲的明确告诉 Agent “完成 X 后就停止”防止任务完成后的无意义游走。可观测性运行 Agent 时打开浏览器界面看着它操作。不要设成无头模式就丢后台了。亲眼盯着出了问题还能及时介入。6. 从“买票”到“万物”Agent 的能力边界与下一步想象买票这个场景只是 Agent 能力的冰山一角。当你理解了“看一眼屏幕想一下点一下”这个循环你会发现几乎任何在浏览器里能完成的操作理论上都可以交给 Agent 去做。6.1 哪些场景已经可以放心用从我目前测试过的方向看以下几类场景 Agent 的完成度和稳定性已经相当不错信息查询与汇总让它打开几个网页提取特定信息并整理成表格这类任务 Agents 做得很顺手。表单填写与资料提交只要页面逻辑不是特别反人类填入规范的测试数据问题不大。格式校验出错时它能读提示并重新填写。常规购物流程从搜索商品、加购物车、到结算页不做实际支付整体流程跑通率很高。日程与邮件辅助在网页端日历里创建日程或者根据已有邮件内容整理待办事项。这些场景有几个共同特征目标明确、步骤可验证、出错成本低。在这些领域Agent 的“翻车”基本都能通过重试或人工介入补救。6.2 哪些场景暂时还别抱太大期望反过来说以下几类场景我用下来体验很差建议暂时不要指望高实时性竞争类任务比如某些热门场次的抢购Agent 的决策链路太长从截图到决策再到执行动作需要数秒根本抢不过毫秒级的脚本。复杂验证码场景虽然 Agent 能理解图像语义但应对专门为拦截机器设计的高难度验证码它并没有比专用破解方案高明多少而且合规性也存疑。需要极高精度操作的任务比如在画布上精确圈选某个像素区域模型给出的坐标有时候会偏几个像素精细活还得靠专用工具。超长流程任务超过 100 个交互步骤的任务上下文消耗和错误累积会让成功率急速下降。6.3 我的判断与建议如果你问我未来是不是所有爬虫都要被 Agent 取代我的判断是短期不会但爬虫的形态会进化。传统爬虫会继续在高频、大规模、固定数据结构的数据采集领域存在因为它快、便宜、可控。但凡是需要“理解页面”的场景Agent 会越来越强。而且随着多模态模型能力的提升、上下文窗口的扩大、操作延迟的降低Agent 的适用边界会不断扩展。我个人的下一步计划是把手头一些“病入膏肓”的遗留爬虫项目逐步改造成“Agent 规则兜底”的混合架构。常规流程交给 Agent 临场发挥关键节点用规则校验结果出错时自动回退。既保留了 Agent 的适应能力又避免了它“自由发挥”过度。6.4 写在最后的个人体会从手搓爬虫到看见 Agent 自己操作浏览器我有一种很深的感受我们这行很多人花了大量时间去适应机器的规则——学习 HTML 结构、研究反爬策略、维护脆弱的选择器。而 Agent 的出现把方向彻底掉转了——机器开始学习理解我们的世界理解一个网页的视觉语义理解一个按钮意味着什么理解“买两张相邻的座位”这句话背后的意图。当然它现在还像一个刚入职的实习生会走错路、会误点弹窗、会钻牛角尖。但实习生的成长速度往往超出所有人的预期。也许再过一两年我们不再需要纠结爬虫怎么写只需要学会如何更清晰地表达目标就够了。我个人建议每一个搞自动化、数据采集、Web 工具开发的朋友都抽个下午亲手跑一次 Agent 操作浏览器的 demo。你不用急着上生产环境也不用担心它替代谁。只是亲眼看看“它自己完成了”这个过程你对未来几个月技术走向的判断可能就会完全不一样。最后分享一个操作小技巧调试 Agent 时记得把它的运行日志完整保存下来包括每一步截图。遇到问题回看日志比看任何文档都管用。很多我觉得“玄学”的 bug最后翻日志一看都是 Agent 在某一步理解错了页面状态导致的日志里每一步的截图就是最好的“破案现场”。
【正文开始】说实话我第一次看到 Agent 自己打开浏览器、移动鼠标、把一张演示票成功买下来的时候心里冒出的一句话是“那我这些年手搓的爬虫算什么”以前我们聊“让程序上网拿数据”第一反应永远是写爬虫分析 DOM、找接口、拼参数、过校验、处理登录态、对付反爬。这套手艺干了几年的人都懂每一个环节都是血泪。可当我看到 Claude 这类具备“电脑操作能力”的 Agent 直接像人一样打开网页、看清楚页面、点按钮、填表单、完成交易时我意识到一个问题——爬虫的尽头不是更强的爬虫而是另一种完全不同的东西一个会自己看屏幕、自己动手的 AI“实习生”。这篇文章我想把这个东西彻底讲透。它到底是什么原理、和手搓爬虫有什么本质区别、我实测让它独立完成一次完整购票流程的真实过程、以及它现在还存在的各种坑。如果你也在写自动化脚本、做数据采集或者只是对 Agent 到底能做到什么程度感到好奇这篇文章应该能给你一个非常具体的答案。1. 手搓爬虫的尽头为什么“能买到票”的目标爬虫经常做不到在聊 Agent 之前我想先认真聊聊爬虫这个老伙计。很多人对爬虫的印象是“写个请求、解析 HTML、拿到数据”听起来很简单但真正在线上跑过的人都知道要稳定完成一个需要交互的流程比如买票事情会迅速失控。1.1 爬虫处理“交互”时的天然窘境买票这件事本质上不是“一次请求拿到结果”而是一连串有上下文的状态流转查票→选场次→填信息→确认订单→支付。中间任何一步走错整个会话就废了。传统爬虫处理这种流程通常有两条路一是直接逆向后端接口把每个请求的参数模拟出来二是用无头浏览器驱动按脚本一步步执行。两条路各有各的疼。走后端接口这条路最怕的就是页面改版。我见过太多半夜被报警电话叫醒的情况——不是服务器挂了而是前端把某个字段名从ticketPrice改成了priceInfo.amount脚本直接解析失败。前端和后端的耦合越紧爬虫的维护成本越高。只要产品经理心情好换个交互逻辑你的自动化脚本就要跟着重写一轮。走无头浏览器这条路相对抗改版但依然很脆弱。因为无头浏览器本质上还是在执行一套写死的“按钮路径”点击坐标 (x, y)、输入某个输入框、等待某个元素出现。只要页面结构一变或者某个弹窗提前冒出来脚本就全乱套了。更麻烦的是无头浏览器对动态渲染内容的处理经常慢半拍你明明在代码里写了sleep(3)结果 3 秒后页面数据还没加载完。1.2 风控与验证码绕来绕去的军备竞赛爬虫的第二个大敌是风控。现在的风控早就不是“验证码 IP 限流”这么简单了。我见过比较狠的行为轨迹检测。你鼠标移动的轨迹、点击间隔、输入速度、页面停留时长都会被记录。如果行为特征太像机器人风控系统会直接给你一个“虚拟正常页面”——页面长得一模一样但所有数据都是假的你辛辛苦苦解析半天拿到的全是废数据。为了对抗这些手段手搓爬虫的人练就了一身十八般武艺代理 IP 池、指纹浏览器、行为模拟、验证码识别服务……一个比一个复杂。每次风控策略一升级前面所有努力可能一夜清零。我身边一位做数据采集的老哥说过一句特别扎心的话“我哪是在写爬虫我是在和整个前端团队、风控团队打一场永远赢不了的仗。”1.3 本地临时演示某模拟购票系统的“翻车现场”为了验证我上面说的这些痛点我在一个自己搭的模拟购票网站上做了一个实验。这个网站没有复杂的验证码页面也基本稳定我只是用它来测试一个简单的爬虫脚本查一下指定场次是否还有余票。第一天脚本正常运行输出正确。第二天我在页面上加了一个促销弹窗。结果脚本直接崩了——不是逻辑出错而是它解析的主内容节点被弹窗遮住后HTML 结构里多了一层遮挡层原本的 XPath 定位全部失灵。这个改动说小不小说大也不大但它足够让一个“稳定运行”的爬虫瞬间下岗。这种问题不是技术不够好而是爬虫的思维方式有根本缺陷它假设页面是静态的、结构是确定的、流程是线性的。但现实中的网页是活的、会变的交互是开放的。用一套写死的逻辑去应对一个无限变化的对象这就是手搓爬虫的尽头。2. Agent 的“上帝之手”Claude 到底是怎么自己上网的聊清楚了爬虫的天花板我们再来看看 Agent 是怎么突破这个天花板的。这一章我会尽量把原理讲得通俗对理解后面实操很有帮助。2.1 不再“解析页面”而是“看懂页面”传统爬虫获取信息的方式是解析 HTML 结构比如“找到 id 为 content 的 div 里的第一张图片”。而 Agent 的方式完全不同——它直接把整个网页截图“看”一遍通过视觉理解模型识别出页面上的文字、按钮、输入框、卡片信息然后决定下一步操作。这两者之间的差别你可以这样理解爬虫像一个蒙着眼睛、靠摸墙壁纹理走路的机器人它必须精确记住“第三个转弯处有一块砖是松的”而 Agent 像一个睁着眼睛走路的实习生它看到门就推门看到楼梯就上楼不需要提前背下每个台阶的高度。正是因为 Agent 理解的是“视觉语义”而不是“DOM 结构”所以就算页面改版了、按钮换了个位置它依然能通过观察新的页面获得信息。这个特性从根上解决了爬虫第一大痛点页面改版。2.2 操作链路观察、决策、行动、验证Agent 操作浏览器的完整链路可以分为四个环节观察截取当前浏览器窗口的截图可能还包括浏览器辅助信息如无障碍树、可点击元素列表等让 Agent 知道“现在页面上有什么”。决策大模型根据用户给的指令和当前页面状态决定“下一步做什么”。这一步输出的不是代码而是一个高级动作意图比如“点击位于屏幕上某个区域的‘立即购买’按钮”。行动本地执行器将动作意图转换为真实的鼠标点击、键盘输入、滚动操作。验证操作完成后再次截取屏幕确认页面状态是否如预期变化。如果没变化就继续调整策略。这四个环节循环往复直到完成整个任务。这里有一个非常关键的细节Agent 的决策是基于“当前这一秒的实际页面状态”实时做出的而不是预先写死的脚本。所以即使页面流程中出现了意料之外的情况比如弹窗、加载延迟、临时错误提示它也能根据新的截图做出应对。这就是 Agent 比传统自动化脚本更有“人味”的核心原因。2.3 不是 RPA胜似 RPAAgent 和自动化脚本的本质区别很多人一听到“Agent 操作浏览器”第一反应是“这不就是 RPA 吗”表面看确实像都是模拟鼠标键盘操作但底层逻辑完全不同。RPA 的核心是“录制并回放”你先手动操作一遍它记录步骤然后反复执行同样的步骤。一旦界面稍有变化录制的步骤就失效了。Agent 的核心是“理解并执行”每次操作前它都要“看”一眼当前页面理解现状然后决定做什么。它不是回放而是即兴演出。台本用户指令是固定的但每一句台词操作动作都是根据现场反应生成的。用一句话概括RPA 是复读机Agent 是即兴喜剧演员。后者不需要把每一句话都背下来只需要明白目标然后随机应变。3. 实测全流程让 Agent 独立完成一次购票原理说再多不如上手跑一遍。这一章我完整复盘了我在一个模拟购票测试站点上让 Claude 从打开浏览器到完成下单的全过程。所有操作都是可控的、安全的只是用来验证技术能力。3.1 环境准备想跑起来需要哪些组件在我实测的环境中至少需要以下四样东西组件作用说明支持 Agent 能力的大模型服务负责视觉理解与动作决策需要开通相应 API 权限本地执行器把模型输出的动作转成真实的鼠标键盘操作通常以浏览器插件或本地服务形式存在浏览器环境Agent 实际操作的对象建议使用独立的浏览器配置或用户目录目标站点被测的页面我这里用的是本地搭建的模拟购票站具体的安装方式不同环境差异很大这里不展开每一条命令。我只强调一个容易忽略的点建议给 Agent 单独建一个浏览器用户目录。这样它的登录状态、Cookie、历史记录都是隔离的不会污染你日常使用的浏览器也便于随时重置状态重新测试。我第一次没隔离结果 Agent 在测试过程中登录了我自己的账号虽然没什么严重问题但那种“有东西在替你操作你的账号”的感觉确实让人心里发毛。3.2 核心调用逻辑与代码骨架在实际运行中整个调用的逻辑其实不复杂。以下是一段示意性的代码骨架用来展示整个交互过程的结构。真实使用时需要根据你所用的具体服务调整接口细节# 示意代码展示 Agent 操作浏览器的整体流程 # 具体 SDK 与 API 请以你所用的服务官方文档为准 from agent_runtime import AgentClient, BrowserSession # 1. 启动一个独立的浏览器会话 session BrowserSession( browser_configisolated_profile, headlessFalse, # 建议有头模式便于观察过程 viewport(1280, 800), ) # 2. 创建 Agent 客户端绑定大模型服务 client AgentClient( api_keyyour_api_key_here, modelclaude-computer-use, # 示意名称 max_steps50, # 最大操作步数防止死循环 ) # 3. 下指令让 Agent 开始干活 instruction ( 打开浏览器访问本地模拟购票站点 http://localhost:8080 选择本周五晚上七点的场次选择两张相邻的座位 填写姓名和手机号使用测试信息提交订单。 下单成功后停止并输出订单号。 ) result client.run( instructioninstruction, sessionsession, stop_conditions[订单提交成功, 已生成订单号], ) print(result.action_log) # Agent 每一步操作的记录 print(result.final_state) # 最终页面状态这段代码最核心的一点是stop_conditions。它是你的“安全带”——告诉 Agent一旦检测到任务完成就立即停止不要继续乱逛。我一开始没有设置这个条件Agent 在完成下单后居然开始点击“浏览更多推荐场次”差点跑偏。加上停止条件之后整个流程就干净多了。3.3 Prompt 设计想让 Agent 干活利索指令要这样下也许你会觉得既然 Agent 这么智能那指令随便说说不就行了实测告诉我不行。指令的质量直接影响任务的成功率和效率。我整理了几个关键的指令设计原则明确目标而不是描述步骤。不要说“先点击搜索框输入关键词再点击搜索按钮”这是脚本思维。应该说“查询本周五晚上七点的场次”。Agent 自己会想办法找到搜索框、输入内容、点击搜索。给出约束条件。比如“选择两张相邻的座位”、“使用测试信息填写表单”这些约束条件 Agent 会主动遵守。如果没说它可能选两张分开的座位或者填一个看起来像样的假姓名。定义明确的完成标志。最核心的一句话是“下单成功后停止并输出订单号。”这句话告诉 Agent 什么算“活干完了”。没有这句话Agent 不知道什么时候应该停下来交差。必要时设置任务边界。比如明确告诉它“不要刷新页面”、“不要点击非目标区域的广告位”、“支付环节仅到确认页即可不要真实支付”。安全边界在实测中非常重要尤其是涉及真实账号、真实金额的流程务必要写清楚。3.4 实测过程记录它是怎么一步步完成的我把完整日志简化后附在这里你可以直观感受到 Agent 的“思考过程”启动浏览器访问站点首页。观察页面识别出“演出日历”区域定位到“本周五”标签。点击“周五”后页面刷新出现场次列表。Agent 停顿约 1 秒识别出“19:00”场次的卡片。点击该场次卡片进入选座页。观察座位图识别出可售座位和已售座位的颜色差异。根据“相邻座位”约束选择第 7 排 3 号和 4 号座。点击“确定选座”进入信息填写页。逐项填写测试姓名、测试手机号。其中手机号输入框有格式校验Agent 第一次输入后页面提示“格式错误”它读了提示信息自行纠正后重新输入。点击“提交订单”页面弹出确认框。Agent 点击“确认”。页面跳转到订单成功页页面上显示订单号。Agent 检测到“订单号”出现读取并输出然后停止。整个过程大约用时 2 分多钟一共进行了 18 次“观察-行动”循环。最让我意外的是第 7 步手机号格式错误后Agent 没有乱猜而是读取了页面上的错误提示自行调整输入格式。这种“根据反馈纠正行为”的能力是传统自动化脚本完全做不到的。4. 和传统爬虫的全面对比不是“升级”而是换赛道在这一章里我把传统爬虫和 Agent 做了一次系统性的对比。看完这个表格你应该能明白为什么我说这是换赛道而不是简单升级。4.1 八个维度逐一对比对比维度传统爬虫Agent以 Claude 为例页面理解方式解析 HTML/DOM 结构视觉语义理解看图页面改版应对需要改代码很脆弱自动适应无需改逻辑动态加载处理需要手动等待或轮询自动观察页面状态变化交互能力脚本控制需预先编排实时决策随机应变异常处理几乎无靠 try-catch观察反馈后自动纠正开发门槛需要懂前端、网络协议只需描述目标会写 prompt 即可维护成本高页面一变就要改低指令不变就不用改运行稳定性受限于结构匹配度受限于模型决策能力和上下文长度这里最值钱的一条是“页面改版应对”。我举个例子还是那个模拟购票站我把选座页的座位图从矩形布局改成了圆形布局。传统爬虫如果靠坐标定位直接全崩如果靠元素 id也要改代码。而 Agent 只是重新“看”了一眼新的座位图通过颜色和位置关系就完成了选座一条指令都没改。4.2 为什么说这是“换赛道”而不是“升级”传统爬虫追求的是“你告诉我网页结构我帮你精确提取数据”。它的核心能力是稳定性、速度、解析精度。在这个维度上Agent 目前还比不过爬虫它每一步都要看屏幕、做决策速度和成本都不占优势。但 Agent 追求的是“你告诉我目标我自己想办法完成”。它的核心能力是理解、决策、适应变化。在网页结构千变万化的开放场景下这个能力是传统爬虫永远补不上的短板。一个很形象的类比爬虫是高铁速度快、准时、但必须在固定的轨道上跑Agent 是出租车速度慢一点、贵一点但你想去哪儿它都能把你送到路断了还能绕行。两者的目标压根不一样。4.3 什么场景该用什么我的一点建议经过实测我的判断是这样的如果任务是高频、大规模、结构稳定的数据采集比如每天抓取某个指数行情、监控固定网站的特定价格传统爬虫依然是更靠谱、更省钱的选择。Agent 的“智能”在这里反而是累赘慢、贵、偶尔还会自作聪明。如果任务是低频、复杂、多变、需要交互的操作比如临时买一张票、填写某个表单、处理一个需要多步操作的任务Agent 的体验远超爬虫。你不需要花半小时分析页面结构只需要说一句话。另一个值得注意的场景是“维护历史遗留爬虫”。很多团队都有那种页面早改版十次、全靠修修补补维持的爬虫。这种项目与其继续补丁叠补丁不如直接用 Agent 重写一遍逻辑长期看反而省心。5. 翻车实录Agent 上网买票时会遇到哪些坑写到这里如果我只讲好的那就太不负责任了。Agent 在实际使用中还有不少问题。这一章我用实测过程中遇到的真实问题给你展示完整的翻车现场和排查思路。5.1 坑一页面加载太快Agent 反而“眼花了”第一次实测时我遇到一个很有意思的 bug传统爬虫嫌页面加载慢Agent 倒是嫌加载太快。当时页面有一个loading 动画从列表页跳转到详情页时会出现大约 0.3 秒的过渡。Agent 截屏的时候正好赶上了动画中间帧——页面上所有元素都在半透明状态。它把这种状态识别为“页面载入异常”尝试点击刷新按钮。刷新之后又赶上动画再次误判。要不是我设置了最大步数 50 的限制它能在这个循环里转十分钟。排查过程我先看了 action_log发现 Agent 一直在重复“点击刷新”这个动作。然后我手动放慢了模拟器环境中的渲染速度加了一层延迟问题立刻消失。后来我做了两个改进一是要求 Agent 在点击导航操作后先等待页面稳定再观察二是遇到不确定状态时优先截取新截图确认而不是直接刷新。从此这个坑没有再出现过。5.2 坑二模态框和弹窗会让它“误入歧途”还有一个非常典型的问题是页面里的营销弹窗。在那个模拟购票站里我在“选座页”右下角放了一个“领取优惠券”的浮窗。第一次测试时Agent 并没有理会它直接完成了选座。第二次测试时浮窗延迟了半秒才弹出Agent 的第一次点击“确定选座”正好落在了浮窗上结果触发了一个领券引导页。接下来的剧情就很搞笑了Agent 发现自己到了一个陌生页面没有立刻返回选座页而是在领券页仔细“阅读”了优惠券说明试图找出哪张券能用于本次购票。它花了 3 个循环才发现自己走错了地方才返回选座页重新操作。这个问题暴露了 Agent 的一个弱点它非常尊重页面上可见的交互元素但也因此容易受到诱导。我的解决办法是在指令里显式加上“忽略所有非必要的弹窗和浮窗除非其内容与购票直接相关”效果立竿见影。5.3 坑三上下文窗口是硬天花板第 18 步Agent 在第 18 个循环完成了任务。但如果你任务更长呢每一次“观察-行动”循环都要把一屏截图可能是一张近百万像素的图片输给模型这极其消耗上下文长度。一个比较复杂的任务可能需要 50-80 个循环。如果中途 Agent 因为某个异常多绕了几个弯可能任务还没完成上下文窗口就满了。窗口满了之后Agent 会“忘记”最初的目标开始做一些和主任务无关的事情。这个问题目前没有完美解法只能从设计上缓解尽量把大任务拆成多个小任务每个小任务单独一次会话设置足够小的max_steps宁可任务失败也不要让 Agent 在超长上下文里胡来。5.4 安全与权限边界必须提前立好的规矩最后必须讲的是安全。Agent 在浏览器里能做的事和你自己手动操作浏览器能做的事是一样的它能登录账号、能提交数据、能点击支付。这意味着它的“能力边界”完全取决于你把一个什么样的浏览器交到它手里。我在实测中有几个默认的安全规矩建议每一位准备尝试的人直接照抄专用浏览器环境不要用你日常登录了各种账号的浏览器。给 Agent 单独开一个用户目录或专门的浏览器配置。最小权限原则让 Agent 做的事只限定在任务必需的范围。不要让它“顺便查一下其他信息”它会真的去查。敏感操作留人工确认凡是涉及支付、修改重要设置、对外发送消息的操作最好在流程中加一个人工确认环节。Agent 决定做人类确认做。设置停止条件就像我之前讲的明确告诉 Agent “完成 X 后就停止”防止任务完成后的无意义游走。可观测性运行 Agent 时打开浏览器界面看着它操作。不要设成无头模式就丢后台了。亲眼盯着出了问题还能及时介入。6. 从“买票”到“万物”Agent 的能力边界与下一步想象买票这个场景只是 Agent 能力的冰山一角。当你理解了“看一眼屏幕想一下点一下”这个循环你会发现几乎任何在浏览器里能完成的操作理论上都可以交给 Agent 去做。6.1 哪些场景已经可以放心用从我目前测试过的方向看以下几类场景 Agent 的完成度和稳定性已经相当不错信息查询与汇总让它打开几个网页提取特定信息并整理成表格这类任务 Agents 做得很顺手。表单填写与资料提交只要页面逻辑不是特别反人类填入规范的测试数据问题不大。格式校验出错时它能读提示并重新填写。常规购物流程从搜索商品、加购物车、到结算页不做实际支付整体流程跑通率很高。日程与邮件辅助在网页端日历里创建日程或者根据已有邮件内容整理待办事项。这些场景有几个共同特征目标明确、步骤可验证、出错成本低。在这些领域Agent 的“翻车”基本都能通过重试或人工介入补救。6.2 哪些场景暂时还别抱太大期望反过来说以下几类场景我用下来体验很差建议暂时不要指望高实时性竞争类任务比如某些热门场次的抢购Agent 的决策链路太长从截图到决策再到执行动作需要数秒根本抢不过毫秒级的脚本。复杂验证码场景虽然 Agent 能理解图像语义但应对专门为拦截机器设计的高难度验证码它并没有比专用破解方案高明多少而且合规性也存疑。需要极高精度操作的任务比如在画布上精确圈选某个像素区域模型给出的坐标有时候会偏几个像素精细活还得靠专用工具。超长流程任务超过 100 个交互步骤的任务上下文消耗和错误累积会让成功率急速下降。6.3 我的判断与建议如果你问我未来是不是所有爬虫都要被 Agent 取代我的判断是短期不会但爬虫的形态会进化。传统爬虫会继续在高频、大规模、固定数据结构的数据采集领域存在因为它快、便宜、可控。但凡是需要“理解页面”的场景Agent 会越来越强。而且随着多模态模型能力的提升、上下文窗口的扩大、操作延迟的降低Agent 的适用边界会不断扩展。我个人的下一步计划是把手头一些“病入膏肓”的遗留爬虫项目逐步改造成“Agent 规则兜底”的混合架构。常规流程交给 Agent 临场发挥关键节点用规则校验结果出错时自动回退。既保留了 Agent 的适应能力又避免了它“自由发挥”过度。6.4 写在最后的个人体会从手搓爬虫到看见 Agent 自己操作浏览器我有一种很深的感受我们这行很多人花了大量时间去适应机器的规则——学习 HTML 结构、研究反爬策略、维护脆弱的选择器。而 Agent 的出现把方向彻底掉转了——机器开始学习理解我们的世界理解一个网页的视觉语义理解一个按钮意味着什么理解“买两张相邻的座位”这句话背后的意图。当然它现在还像一个刚入职的实习生会走错路、会误点弹窗、会钻牛角尖。但实习生的成长速度往往超出所有人的预期。也许再过一两年我们不再需要纠结爬虫怎么写只需要学会如何更清晰地表达目标就够了。我个人建议每一个搞自动化、数据采集、Web 工具开发的朋友都抽个下午亲手跑一次 Agent 操作浏览器的 demo。你不用急着上生产环境也不用担心它替代谁。只是亲眼看看“它自己完成了”这个过程你对未来几个月技术走向的判断可能就会完全不一样。最后分享一个操作小技巧调试 Agent 时记得把它的运行日志完整保存下来包括每一步截图。遇到问题回看日志比看任何文档都管用。很多我觉得“玄学”的 bug最后翻日志一看都是 Agent 在某一步理解错了页面状态导致的日志里每一步的截图就是最好的“破案现场”。
