前言
之前有个需求要爬取某BOSS直聘的岗位信息， 我在Cursor 里让 Agent 去执行，它兴冲冲写出一堆 CSS 选择器，跑通了。过了一段时间，官方页面改了一个 class，整段 pipeline 直接归零，无力回天。
公开数据明明在那，网站就是不让程序稳定拿，平台一改 DOM，你的 scraper 就废。如果你也在搭 Agent 工作流，我建议搞个稳定的解决方案去爬取数据。想先验证 Agent 爬虫能不能稳定跑？先用一个公开商品页创建 Collector，再测试 run 和 heal，不需要先搭完整的代理池和浏览器基础设施。
开始免费测试：每月 5,000 次免费额度，无需绑定信用卡 。
一、Agent 会写爬虫，但为什么总上不了生产？
经常用Claude Code的玩家，你有没有发现， 其实它能力上限，很大程度是被终端里装什么工具决定。工具链弱，Agent 就会写慢、写脆、写一堆 workaround。
我过去踩过的坑，基本就四类：
- 选择器能跑，稳态不能跑：首版 OK，DOM 小改就全废。
- JS 页面拿到空壳 ：Agent 以为抓到了，其实是
。 - 代理/验证码链路缺失：一个站点 403，整条任务链中断。
- 跨会话不可复用：A 同学调通的逻辑，B 同学新会话又从零"猜"。这种重复劳动最折磨人，纯纯浪费时间。
还遇到了一个很频繁的问题，演示环境能跑，生产环境一上量就崩。CAPTCHA 弹出来、IP 被限流、页面 A/B 两套 DOM 随机切换------Agent 写的脚本根本扛不住这些脏活。
之前我们用 Playwright 就想着稳了，但是指纹、403、CAPTCHA 这些问题还照样会出现。
如果搭一套浏览器池 + 代理池 + 自愈逻辑程序，对小团队来说成本也不低。其实我想说不是 Agent 不够聪明，而是让它干了不该它扛的基础设施活。
二、我的分工：Agent 编排，Bright Data 采集
Bright Data 是一个面向 Web 数据采集的基础设施平台；本文重点使用其中的 CLI、采集器和 MCP 能力，把数据采集能力接入 Agent 工作流。
我现在固定两层：
- Agent ：字段定义、清洗规则、失败重试、业务校验。
- Bright Data CLI ：Agent 负责业务逻辑编排，Bright Data 负责数据采集基础设施。通过 Bright Data CLI，Agent 可以调用采集器、运行任务，并在页面变化后执行 heal，从而减少手写选择器和维护底层反爬基础设施的工作。
Bright Data CLI 支持 scraper heal，核心点是：修复时保留同一个 Collector ID，不用每次改版就重建资产。这层分工带来的变化很直观，以前 PR 里全是"补丁式 selector"；现在更多在评审"字段语义是否满足业务"。采集场景也要做职责分层------Agent 不该同时当"业务开发者 + 反爬工程师 + 运维"。
立即免费开始：每月 5,000 次免费额度，无需绑定信用卡。
三、三步跑通：登录 → 创建采集器 → 反复调用
Collector 是 Bright Data 里的「采集任务 ID」：你用一句话说清要抓哪些字段，平台生成一条固定采集逻辑，并分配 c_ 开头的编号（如 c_abc123）。之后 Agent 每次抓取只需传这个 ID，不用重写选择器------这就是「可复用」的意思。
1）安装与登录
npm install -g @brightdata/cli验证brightdata/cli是否安装成功
bdata --version
bdata login
官方文档写明：scraper create / scraper run / scraper heal 都可以在 Claude Code、Cursor、Codex 的内嵌终端直接跑，也支持 npx 免全局。
2）用自然语言创建采集器
示例商品：Apple iPad Air（第 5 代，64GB，Wi-Fi，粉色），ASIN B09V3KXJPB。
bdata scraper create https://www.amazon.com/dp/B09V3KXJPB \
"提取商品标题、现价、原价、评分、评论数、ASIN，输出 JSON" --country us
返回的 Collector ID 形如 c_mswxhw7c11mykts3oo
这个 ID 就是团队资产，不是一次性的脚本文件。
查看https://brightdata.com/cp/scrapers地址，可以看到在My scrapers菜单中看到新生成的记录
3）运行 + 输出 JSON
scraper run 默认就是 JSON 结构，建议加 --pretty 格式化，并用 -o 落盘：
bdata scraper run c_mswxhw7c11mykts3oo https://www.amazon.com/dp/B09V3KXJPB \
--pretty -o result.json可以看到当前目录生成了result.json文件
输出示例（字段以实际 Collector 为准）：
[
{
"product_title": "Apple iPad Air (5th Generation): with M1 chip, 10.9-inch Liquid Retina Display, 64GB, Wi-Fi 6, 12MP front/12MP Back Camera, Touch ID, All-Day Battery Life -- Pink",
"current_price": {
"value": 652.77,
"currency": "USD",
"symbol": "$"
},
"rating": 4.8,
"review_count": 13469,
"asin": "B09V3KXJPB",
"input": {
"url": "https://www.amazon.com/dp/B09V3KXJPB"
}
}
]如果还没建好 Collector、只想先拿结构化商品字段，可以直接用 pipelines（默认就是 JSON）：
bdata pipelines amazon_product https://www.amazon.com/dp/B09V3KXJPB \
--pretty -o product.jsonbdata scrape -f json 返回的是 HTTP 响应包装（status_code + headers + body），不是业务字段 JSON。要结构化商品数据，用 scraper run 或 pipelines amazon_product。
4）接入 MCP：会话里直接调 Collector
如果你已经在用 MCP 工具栈，可以执行：
brightdata add mcp
这会把 Bright Data 能力挂到 Agent 可调用的工具里。CLI 负责"稳定调用"，MCP 负责"减少手写封装"。以前 Agent 每抓一次都要我提醒命令格式；现在有 registry + MCP 后，会话里直接说"跑 amazon_ipad_air Collector 并校验字段完整性"就行。
跑完以后，我会让 Agent 做一层轻量 QA------字段是否齐全、数值是否合理、空值比例是否异常。
如果你已经完成 Collector 创建，下一步就是把它接进自己的 Agent 工作流。先跑一个真实公开页面，验证字段准确率、改版恢复能力和输出稳定性，再决定是否扩大流量。
四、把 Collector ID 写进 Agent 记忆层
这是我后来觉得最值的一步。
把 ID 和规则写进：
-
.cursor/rules
-
{
"collector_registry": {
"amazon_ipad_air": "c_mpohus372o5tmid1jk",
"product_detail_cn": "c_abc123xyz"
},
"agent_rules": [
"主流程只允许调用 registry 内 Collector",
"失败先 heal，再决定是否重建",
"仅采集公开可访问页面，禁止登录态抓取"
]
}
五、对比：三种方式，谁更适合 2026 的 Agent 工程化
| 路线 | 首次搭建 | 抗改版 | 输出形态 | 运维成本 | 适用 |
|---|---|---|---|---|---|
| Agent 手写爬虫脚本 | 中 | 低 | 页面片段/非结构化文本 | 高 | 一次性实验 |
| 自建 Agent + 自购代理 | 慢 | 中 | 可结构化但维护重 | 很高 | 有专职爬虫团队 |
| Agent + Bright Data CLI | 快 | 高（heal 原地修复） | 结构化 JSON | 低到中 | 多团队协作、持续迭代 |
在实际的体验过程中，我觉得Agent 把业务流程编排得再顺，在数据采集时挂掉，下游照样全停。页面改个 class、站点返回 403、验证码突然弹出来------这些都不是改 prompt 能解决的。
所以我认为技术选型时更看重两件事：抗改版 和可运营。
不是 demo 今天能跑就行，而是目标站改版后，不用再去耗费人力去修选择器。否则每个 Agent 项目最后都会变成长期维护工程，人力都耗在补洞上，主线功能反而推不动。
六、我踩过的三个误区
误区 1：让 Agent 直接读 HTML 再"理解字段"
输出不稳定。
误区 2：一失败就重建抓取
这最耗时间。官方 heal 流程的设计就是"原地修复、ID 不变"。能 heal 就先 heal。
误区 3：把采集失败当模型问题
模型再强，输入是空壳也白搭。先稳采集，再调 prompt，ROI 高一个量级。
七、合规与信任：能抓 ≠ 可以乱抓
生产环境必须把合规写进流程，不是写进 PPT。在抓取数据时应该遵循以下原则：
- 只采公开可访问数据，不绕过登录、不抓受限个人信息。
- 数据处理遵循 GDPR、CCPA 等法规，项目侧做最小化采集和留存。
- 优先选有公开安全背书的平台能力。
平台资质只是基础，不等于你的业务自动合规。你还需要自己的告知机制、数据用途说明和法务审查流程。Bright Data 对外也强调服务 20,000+ 客户，并面向公开网页数据采集场景。
FAQ
1）只会 Cursor，不会写复杂爬虫，能上手吗？
能。内嵌终端跑 login + scraper create，Agent 围绕 Collector ID 写业务逻辑即可。
2）为什么 Collector ID 必须写进规则文件？
这是跨会话复用的关键。没有 registry，Agent 每次都会临时手写选择器，稳定性很差。
3）heal 适合什么场景？
当页面发生 selector 漂移、DOM 小幅改版或字段突然变为空时，可以优先尝试 heal，而不是直接删除并重新创建 Collector。
4）能和 MCP 结合吗？
可以。执行 brightdata add mcp 后，Agent 工具栈里会有标准化采集能力（来源：Bright Data CLI commands 文档）。
5）免费额度够先做验证吗？
通常够验证关键链路（准确率、稳定性、恢复能力）。正式流量再评估成本。
总结
2026 年用 Agent做爬虫，拼的不是"会不会写选择器"，而是"采集能力能不能被团队长期运营"。如果你还在让 Claude Code 裸跑浏览器，得到的往往是会动的 Demo。
要上生产，就让它站在可靠底座上，我的技术方案很简：Bright Data CLI 跑通 → 固化 Collector ID → Agent 专注编排。也许这不是唯一解，但我目前解决了我们很大的问题，至少不会再被第三方"页面改一个 class"这种问题卡住流程。
准备把 Agent 爬虫从 Demo 推到生产环境？先从一个公开数据采集任务开始：创建 Collector、运行一次、测试 heal，再把 Collector ID 固化到 Agent 的规则文件中。
立即免费开始 ：每月 5,000 次免费额度，无需绑定信用卡。