让 OpenClaw 打开一个公开网页，这件事已经没什么门槛了——接上浏览器能力就能做，具体配置见 OpenClaw 怎么接浏览器。但真实需求往往更进一步：数据在登录之后才看得到。后台报表、行业平台的会员数据、自己的订单和账单、供应商门户里的价格表，全都在登录墙里面。
这时候问题就从「怎么抓」变成了三个更具体的难题：登录态怎么存、验证码怎么办、频率怎么控。这篇按这个顺序讲，最后一段专门说边界——因为这一类活，做错方式比做不成更危险。
第零步：先判断这件事该不该用抓取做
动手前先过三个问题，能省掉后面一大堆麻烦：
（1）有没有官方接口？有 API 就用 API。接口的字段是稳定的、有文档的、有调用配额的，而页面结构随时会改。很多看起来「只能爬」的数据，其实平台自己提供了导出或开放接口，只是藏得深。
（2）数据是不是你自己的？自己账号里的订单、账单、报表，抓下来做归档和汇总，性质清楚。抓别人的、抓会员内容再转手，性质完全不同。这条线要先画清。
（3）服务条款和 robots 怎么说？看一眼不费时间，但它决定了你后面所有动作的正当性。明确禁止的，就别做；没说的，按「克制」处理。
三个问题都过得去，再往下走。
一、登录态怎么存：三条路，选稳定的那条
登录态（Cookie、会话令牌）是这件事的核心资产。三种常见做法：
（1）让 Agent 每次自己走一遍登录流程。最直觉，也最不稳。登录页随时会改版，多因素验证会随时弹出来，而且每次登录都会在对方系统里留一条「新设备登录」记录——频繁出现本身就会触发风控。除非是一次性任务，否则不建议。
（2）用浏览器会话文件保存登录态，一次登录多次复用。这是最实用的做法：你手动在一个独立浏览器环境里登录一次，把这个环境的会话状态存成一个文件，之后 OpenClaw 每次抓取时加载它。优点很明显——登录这件事交给人做，抓取这件事交给机器做，中间的分界线非常清晰，验证码、短信、扫码全部落在人这一侧。
（3）用带有效期的访问令牌调接口。如果对方平台有令牌机制，优先选这条。令牌的权限范围更明确，过期机制天然帮你控制风险。
会话文件本身就是密钥，必须按密钥对待。三件事：文件权限收紧到只有运行账号能读；不进版本库、不进日志；设置有效期，到期重新登录生成。凭证管理的一整套做法可以参考 AI Agent 凭证轮换怎么做，另外 密钥出口绑定 这块也值得看一眼。
还有一条容易被忽略的：用一个专用账号，不要用私人主账号。专用账号的权限可以被限制得刚好够用（比如只读），出了事影响面小，而且被风控时不影响你自己正常使用。
二、验证码怎么办：交给人，不要交给流程
验证码分三类，处理方式完全不同：
（1）图形验证码。让人工过。第一次登录时人已经在那儿了，顺手点一下，然后会话文件就被复用了。不要为了「全自动」去接识别服务——识别成功率不稳定，而且这类做法在很多平台的服务条款里是明确禁止的。
（2）短信验证码。同样交给人工。如果确实需要自动化，思路不是「破解短信」，而是让短信进一个专用号码或专用邮箱，由 OpenClaw 从那里读出来再回填。这条链路的搭建方式，和 OpenClaw 怎么收发邮件 里讲的收信处理是同一套。
（3）扫码登录。人扫一次，然后复用会话。这是最省事也最合规的一种。
核心原则一句话：验证码是平台用来确认「操作者是人」的机制，你的流程里就应该真的有人在。把它绕过去，短期省了事，长期要么被风控封掉，要么承担不该承担的风险。
三、频率与增量：不越界的三个约束
这一节是决定这件事能不能长期做下去的关键。
（1）并发压到最低。默认单个并发、串行抓取。这不是保守，是因为并发对目标站点的压力是乘法级的，也是最容易被识别为异常流量的特征。你的任务是获取数据，不是压测别人的服务器。
（2）加间隔，并且让间隔不规律。固定每 100 毫秒一次，这是机器最典型的特征。给它一个区间内的随机间隔，对数据准确性没有任何影响，但礼貌得多。
（3）做增量，别重复抓。这一条同时省钱、省时间、降低风险。做法是维护一张「已抓取清单」，记录 URL 和内容指纹（比如正文的哈希），每次只抓新增或指纹变化的页面。这方面的思路和 OpenClaw 怎么定时盯网页变化 完全一致——那篇讲的是「盯变化」，这篇讲的是「在登录态下盯变化」。
如果你每天要抓的页面上千，更要先想清楚：真的需要每天全量抓一遍吗？大部分场景真正变化的内容不到百分之几。把增量做好，抓取量能降一个量级，风控风险也跟着降。
四、抓下来的内容怎么处理：落盘、去重、入库
抓取只是中间步骤，产出物的质量决定这一步有没有价值。三条建议：
（1）落成结构化字段，不要存原始 HTML 就完事。至少保留：来源标题、发布时间、正文、来源 URL、抓取时间、所属账号。多存一个抓取时间的意义在于，将来你能知道「这个结论是基于什么时候的数据」。
（2）保留原文快照，同时存一份文本版。快照用于事后核对和留证，文本版用于检索和喂给模型。只留文本版，将来出现争议就没有依据。
（3）去重按指纹，不按标题。同一个内容改了标题重新发布的情况太常见了。按正文指纹判重，比按标题靠谱得多。
如果这批数据最终要进知识库供问答使用，入库、切片、引用溯源那一整套可以用 OpenClaw 搭企业内部知识库 里讲的流程；如果只是归档整理，OpenClaw 整理本地文件 里的命名与映射表做法可以直接搬过来。
五、执行侧：四件必须做的事
（1）先试运行。让它只打印计划访问的 URL 和动作，不真的抓。重点确认：要抓的页面清单对不对、有没有误抓到不该抓的路径。
（2）先抓十条。人工看一遍内容是否完整（有没有抓到登录提示页、有没有抓到空壳页面）。这一步能挡住绝大多数「登录态其实已经失效」的问题。
（3）留日志，但日志里不要有凭证。记录访问了什么、结果如何、耗时多少，但会话文件的内容、令牌、Cookie 值都不该出现在日志里。审计字段怎么设计，参考 AI Agent 审计查询字段怎么设计。
（4）给会话失效设计一个明确出口。登录态过期是一定会发生的。要做的是「检测到跳转到登录页 → 停止抓取 → 通知人重新登录」，而不是「反复重试把账号刷进风控名单」。失败之后怎么升级、怎么转人工，规则参考 AI Agent 失败升级规则怎么定。
六、边界：三种情况必须停下来
（1）平台明确禁止自动化访问。条款里写了，就别做。这条没有讨论空间。
（2）数据涉及他人隐私，且你无法说明用途和保存期限。「先抓下来再说」是最危险的做法。用途说不清的，就不该抓。
（3）需要靠绕过技术手段才能拿到。需要破解验证码、需要伪造身份、需要突破访问控制的，本质已经越过了正常使用的边界。这类需求应该回到第零步：找官方渠道谈，而不是找技术方案绕。
顺带说一句：如果 OpenClaw 是在一个隔离环境里跑这类任务，整体的隔离设计可以参考 AI Agent 沙箱是什么——把「跑抓取的环境」和「你自己的机器」分开，是最省心的一道保险。
优缺点说清楚
好处：把重复的手工查询变成一次配置；数据能自动归档、自动对比，不再靠人截图；登录态复用之后，日常运行几乎不需要人介入。
代价：页面改版会导致抓取失败，需要维护选择器；会话会过期，需要有人按时重新登录；被风控的风险始终存在，所以限速和增量不是可选项而是必需品。最重要的一点——它比公开页面抓取的合规要求高一个等级，能不做就别做，能做 API 就别爬页面。
适合人群
适合：需要定期归档自己账号内数据（订单、账单、报表、后台指标）的个人和团队；需要监测供应商或合作方门户信息变化的岗位；有内部系统、但短期拿不到接口，需要先做过渡方案的场景。不适合：公开数据本来就能直接抓的（那就用更简单的公开抓取）；需要绕过验证或访问控制才能拿到的；数据涉及大量他人隐私而用途又说不清的。
总结
OpenClaw 抓登录后的页面，一条主线：先判断该不该抓（有 API 用 API、数据性质清楚、条款允许）；登录态优先用「人工登录一次 + 会话文件复用」，并当密钥管理、用专用只读账号；验证码一律交给人，自动化的方向是「让短信进专用信箱」而不是「绕过识别」；执行上压并发、加随机间隔、做增量抓取；产出上结构化落盘、按指纹去重、留原文快照；运行上试运行、抽样验、留日志不含凭证、给会话失效设计明确出口。一句心法：这类活的专业度不体现在「能抓到」，而体现在「知道什么不该抓、抓多少才合适、什么时候该停下来问人」。
