对于很多展会议程，多Tab网页，n8n基本束手无策，靠Apify或Bright Data这类三方工具都不一定能搞定。刚才用OpenClaw的Playwright Skill直接跑通了，浏览器自动点Tab、自动滚动、全程无需外部服务。对比下来差距真的很明显。让你的OpenClaw打通Playwright，几乎可以爬任何网页。
以前在通信行业工作的时候，每年MWC前后有一件固定的苦差事：把巴展 mwcbarcelona.com/agenda 上的完整议程扒下来。
听起来不难。但你真去试试就知道了。
那个页面是典型的单页应用，PRE、MON、TUE、WED、THU 五个日期Tab，点一个加载一个，每个Tab里还有懒加载，得滚到底部数据才出来。直接 web_fetch 抓到的 HTML 基本是空的——所有 session 数据都是 JavaScript 异步请求回来的，根本不在初始 HTML 里。
找 Apify 或 Bright Data，还要看有没有现成的 MWC 专属 actor 或脚本——没有的话，要么自己写，要么接受拿不到数据这个现实。
今年我换了个思路，用 OpenClaw 的 Playwright Skill 来搞。结果……省事很多。
n8n遇到动态网页，能怎么办？
先说清楚 n8n 的现状，别让人觉得我在黑它。
n8n 是我一直在用、也在教的工具，它的强项是流程编排——把 webhook、数据库、API、通知渠道这些东西串起来，逻辑清晰，可视化调试很顺手。
但爬复杂网页这件事，n8n 没有原生能力处理 JavaScript 渲染页面。HTTP Request 节点只能拿到服务器返回的原始 HTML，碰到 MWC 这种 SPA，内容根本不在里面。
解法只有两条路：
路线一：接入 Apify 或 Bright Data 这类专业爬虫服务。它们的优势是有现成的 actor 库，很多主流网站有专属抓取方案。缺点也明显——你得为每个目标网站找对应方案，万一没有，还是要回到"自己写脚本"这条路。而且这两个平台都要花钱，按量计费，跑一次 MWC 全量议程大概要消耗多少额度，算起来并不轻松。
路线二：自己在 n8n 里搭 Code 节点，调 Puppeteer 或 Playwright。可以，但你得真的会写代码，还要自己维护脚本，页面结构一变就得重新调试。
两条路都有门槛。对大多数人来说，能走通的概率并不高。
OpenClaw怎么做的——Playwright Skill，AI自己写脚本
OpenClaw 这边的逻辑不一样。
它的底层是 Playwright，支持真实浏览器操作：点击、滚动、等待 JS 渲染，全都能做。关键是，它不需要你提前准备脚本——你用自然语言描述需求，它自己生成、调试、迭代代码，一套流程跑完。
我告诉它：帮我创建一个 smart-browser 技能，用持久化 Chrome Profile，抓 MWC 议程，等 JS 渲染完之后提取所有 session 数据，保存成 Markdown。
Skill 跑起来之后，浏览器被以无头的方式调用，MWC 议程页面被正确的爬取下来，文字信息还别存到了本地的目录
抓取完成后，可以继续让 OpenClaw 整理数据：
请把抓到的数据整理成结构化的报告：
然后我问了一个关键问题：3月3日、3月4日的日程在另外几个 Tab 里，这个 Skill 能处理吗？
它不是说"我试试"，而是直接给出了改造计划：定位日期按钮 → 模拟点击 → 等待刷新 → 循环抓取 → 按日期分文件存储。
跑完之后，每天的议程都存成了独立的 Markdown 文件。
真正的差距在哪里
用 Apify 或 Bright Data，你是在调用别人已经写好的脚本。如果有就能用，如果没有就凉了。
用 OpenClaw + Playwright，你是在让 AI 实时分析页面结构、实时写脚本、实时调试。没有"有没有现成方案"这个问题，因为它就是在当场帮你生成那个方案。
当然 OpenClaw 也不是万能的。碰到反爬机制强的网站（比如某些需要复杂验证的平台），它也需要多轮调试甚至翻车。
但对于 MWC 这类公开信息型的大型活动网站，它的表现已经完全够用了，而且你不需要懂 Playwright，不需要会 Python，只需要会说话。
n8n 我还是会用、也会继续教——它在流程自动化这条线上有 OpenClaw 没有的优势。但爬复杂动态网页这件事，至少目前来看，是 OpenClaw 更顺手。
