前言
你把"帮我写个 Walmart 商品采集脚本"交给 Codex,它多半能在几分钟内给你一份看上去不错的 Python 代码。请求、选择器、重试、CSV 导出,一样不少。但把它直接跑在 Walmart 搜索页上,得到的往往不是商品列表,而是访问拦截或人机验证页。这个文件只证明程序能运行,不能证明采到的数据可用。
同时还会出现很多问题。这是不是目标页面?价格是不是当前价格?少了评分和评论数后,Agent 会不会把空值补成一段很真的话?
本文会用 Bright Data CLI 获取公开网页的原始结果,再由 Codex 完成验收和导出。
想直接复现这个流程,可以先通过 Bright Data 的免费入口 获取一个公开网页,再让 Codex 做字段验收和结构化输出。
什么是 Agent 原生数据采集?
Agent 原生数据采集,会把网页访问、数据提取、数据验证和结果交付拆成不同步骤。AI Agent 根据任务调用合适的数据访问工具,随后检查结果是否真的能进入业务流程。
这篇文章里的分工很明确。Bright Data CLI 负责访问 Walmart 的公开页面并返回原始结果。Codex 负责抽取字段、核对数据、标记异常、生成 JSON、CSV 和运营可读的 HTML 报告。
Codex 的脚本,先卡在获取页面这一步
我们团队需要每周查看 Walmart 上无线耳机的公开竞品情况,运营同事需要一张表,里面有商品名、价格、评分、评论数、商品链接和采集时间。
普通的 requests 或 Playwright 脚本先碰到的是访问限制。页面即使返回 200,也可能只是验证码页,商品列表并没有出现在响应里。即使某次拿到了 HTML,动态内容、地区差异和页面改版也可能让选择器读到空值或旧字段。
| 运行时看起来没问题 | 业务真正需要的结果 |
|---|---|
| HTTP 200 或脚本没有报错 | 确认拿到的是目标搜索页,不是验证页 |
| 写出了 Markdown 或 CSV | 至少有约定数量的有效商品 |
| 选择器找到了某段文本 | 标题、价格、来源 URL 等必填字段完整 |
| Codex 给出汇总结论 | 每条记录可回查,异常会被标记 |
数据验收 Contract
采集成功不能只看 HTTP 状态码。对 Agent 工作流而言,一份结果至少要满足下面几条规则:
- 目标页面正确,不能把验证页或营销页当成商品列表
- 商品标题、价格、评分、评论数等核心字段存在
- 每条商品保留可回查的来源 URL
- 重复记录已经处理,异常记录进入
needs_review - 字段缺失时保留空值和异常原因,不能让模型自行补全
一张验证页也能返回 HTML。一条跳转后的营销文案也能被模型读得头头是道。等它被放进周报、看板甚至自动决策里,才发现数据不对,代价就不只是改两行 selector 了。

把网页访问、数据验收和交付拆开
我经过调研,决定把获取 Walmart 商品数据并出表的工作拆开。
Bright Data CLI 是一个命令行数据访问工具。它让开发者在终端或 Agent 工作流中调用 Bright Data 的网页数据访问能力,无需把代理、页面访问和处理逻辑全部写进业务代码。
Codex 不再尝试和访问限制较劲,它只读原始结果、检查字段、整理数据,再把同一份结果导出成运营能直接使用的文件。
获取原始页面结果的环节,由 Bright Data CLI 负责。
| 环节 | 负责的工具 | 交付物 |
|---|---|---|
| 获取 Walmart 搜索页 | Bright Data CLI | 原始页面结果 |
| 识别商品字段 | Codex | 结构化商品记录 |
| 检查缺失和异常 | Codex | needs_review 清单 |
| 生成交付文件 | Codex | JSON、CSV 和 HTML 报告 |
这样拆分的价值很直接。网页访问基础设施从业务代码里分离出来,Codex 可以专注于数据提取、验证和交付。流程中的问题也更容易定位:是页面没有拿到,还是字段没有通过验收。
第一步:在 Codex 中调用 Bright Data CLI 获取原始页面
目标是获取Walmart 的公开搜索结果页,整理"wireless headphones"的有效商品记录。
以下命令用于演示通过 Bright Data CLI 获取公开 Walmart 页面结果。实际使用前,请确认目标网站规则、授权范围和适用法律。
我要获取数据的URL:
text
https://www.walmart.com/search?q=wireless%20headphones

在 Codex 客户端的项目对话里,把下面这段任务发给它:
text
检查当前环境是否安装过Bright Data CLI,使用命令查看:brightdata --version 。
如果没有安装则在当前项目环境中安装 Bright Data CLI。使用命令:npm install -g @brightdata/cli 。
如果没有登录,请提示我完成 Bright Data 登录;登录完成后再继续。
访问 [https://www.walmart.com/search?q=wireless%20headphones](https://www.walmart.com/search?q=wireless%20headphones) 使用美国地区。
把结果保存为 walmart-headphones.md。完成后告诉我文件路径和本次命令的状态,不要根据页面内容自行生成商品信息。

Codex 会在当前项目环境中调用 Bright Data CLI。首次运行时,CLI 会要求完成账号认证;这一步需要你按界面提示登录。认证完成后,Codex 运行的底层命令相当于:
bash
brightdata scrape "https://www.walmart.com/search?q=wireless%20headphones" \
--country us \
-o walmart-headphones.md
bdata 也可以作为 brightdata 的短别名。命令把访问 Walmart 页面交给 Bright Data CLI,并将结果保存为 walmart-headphones.md。我这是第二次访问,3 秒内就获取到了结果。

先跑一个真实页面
如果你已经在使用 Codex,可以先让 Bright Data 提供网页数据访问,再让 Agent 提取字段、验证结果并导出文件。这样不必先搭一整套网页访问基础设施,也能验证这条 Agent 原生数据采集流程是否适合自己的项目。
开始免费试用 Bright Data,当前官方免费方案页面列出了每月 5,000 次页面加载且无需绑定信用卡。具体额度与适用产品以注册页面为准。
第二步:让 Codex 做验收、整理和导出
有了 walmart-headphones.md,Codex 才开始做自己擅长的工作。它读取文件中的商品信息,抽取标题、价格、评分、评论数和商品链接,统一字段格式,再检查哪些记录能进表、哪些记录需要人工确认。
把下面这段任务交给 Codex:
text
读取 walmart-headphones.md,整理 Walmart 无线耳机商品。
每条记录提取 title、price、rating、review_count、source_url 和 collected_at。
按 source_url 去重,保留全部合格记录。
页面不是目标商品列表、标题是 Suggested 等非商品名称、字段缺失或无法回查来源的记录,
标记为 needs_review,不要根据上下文补造价格、评分或评论数。
将合格记录导出为 walmart-headphones.json 和 walmart-headphones.csv;
再生成 walmart-headphones-report.html,供运营查看商品数量、价格区间、异常记录和来源链接。
HTML是面向运营的轻量报告 ,适合直接打开查看:顶部放本次采集时间、有效记录数和待复核数;中间放商品表;底部列出被拒绝的记录及原因。每一行都保留来源链接,运营看到异常价格时能回到页面核对,不必再找开发同事要原始文件。JSON 方便给下一步程序或 Agent 使用,CSV 方便筛选和导入表格软件,HTML可以让所有人都能看懂数据。

再看一下导出的部分json数据:
json
{
"title": "Nothing Headphone (1) Hybrid Active Noise Cancelling Headphones, Wireless Over-Ear Headphones with 6 Mics, 80Hrs Playtime, Hi-Res Audio, KEF-Tuned, Spatial Sound, Comfort Fit & Fast Charging White",
"price": 219,
"rating": 4.1,
"review_count": 10,
"source_url": "https://www.walmart.com/ip/Nothing-headphone-1-White/16568151805",
"collected_at": "2026-08-19T07:13:28.824Z"
}
导出的csv文件也都没有问题: 
当任务每周都要跑,有三种接入方式
方式一:在当前对话里直接调用 CLI
单次验证、临时查一个关键词,直接让 Codex 调用 Bright Data CLI 最省事。把 URL、国家、需要的字段和导出格式写进提示词,运行后先看原始 Markdown 和 HTML 报告。这个阶段只解决一件事:数据能否按预期拿到,字段是否够用。但是如果频率更高一些,每天、每时都要获取对比的话,会有些麻烦。
方式二:把已验证的流程设成 Codex 定时任务
竞品表通常不是看一次就结束。每周一上午更新一次,运营才有持续可比的数据。Codex 客户端左侧的"已安排"页面可以新建任务,选择项目、模型、重复频率、执行时间和通知方式。这里可设为"每周一 09:00,所有运行都通知";如果业务需要更高频率,改为每天或每个工作日即可。
定时任务会在新对话里执行,不能依赖这次聊天已经说过的话。因此提示词要把数据源、操作步骤、异常规则和输出位置一次写全。下面这段可直接用于创建每周任务:
text
每周执行一次 Walmart 无线耳机竞品采集,并在当前项目中保存结果。
目标页面:
https://www.walmart.com/search?q=wireless%20headphones
采集地区:美国。
1. 先检查 Bright Data CLI 是否可用且已登录。未安装或登录失效时,不要改用 requests、Playwright 或其他抓取方式;停止后在本次结果中说明原因。
2. 使用 Bright Data CLI 获取目标页面。以当天日期创建目录 data/walmart/YYYY-MM-DD/,将原始结果保存为 walmart-headphones.md。
3. 读取原始结果,提取 title、price、rating、review_count、source_url 和 collected_at。title 为 Suggested、Best seller 等分组标签的记录无效;价格、评分、评论数、来源链接或采集时间缺失时标记为 needs_review。按 source_url 去重,不要根据上下文补造任何字段。
4. 将全部合格记录导出为 walmart-headphones.json 和 walmart-headphones.csv;生成 walmart-headphones-report.html。HTML 报告需要显示采集时间、合格记录数、待复核数、价格区间、商品表、来源链接和异常原因。
5. 保留原始 Markdown、JSON、CSV、HTML 和待复核记录。不要删除之前日期目录中的文件,不要修改项目里的无关文件。
6. 在任务结果中只汇报本次目录、合格记录数、待复核数、价格区间,以及是否需要人工处理登录或数据异常。

collection-contract.json 放在什么时候用
如果只有这一条定时任务,上面的完整提示词已经包含了全部规则。把 collection-contract.json 单独放进项目目录,并不会让定时任务自动读取它;定时任务默认只执行自己保存的提示词。
当同一份 Walmart 数据既要手动跑 CLI,也要由定时任务执行,后续还要交给 MCP 继续筛选时,再把筛选标准单独保存成 collection-contract.json。同时在定时任务提示词或 AGENTS.md 中写明"处理数据前先读取 collection-contract.json"。它保存的是数据规则,不是 Bright Data CLI 的配置:
json
{
"task": "walmart-wireless-headphones-monitoring",
"input_file": "walmart-headphones.md",
"selection": {
"deduplicate_by": "source_url"
},
"field_rules": {
"title": {
"minimum_length": 15,
"reject_values": ["Suggested", "Best seller"]
},
"price": { "minimum": 0.01, "currency": "USD" },
"rating": { "minimum": 0, "maximum": 5 },
"review_count": { "minimum": 0 },
"source_url": { "host": "www.walmart.com", "path_prefix": "/ip/" }
},
"on_failure": "needs_review",
"outputs": ["json", "csv", "html"]
}
方式三:用 MCP 处理多步探索任务
当任务从一个固定 URL 变成"先找无线耳机新品,再比较不同品牌和价格区间,最后挑出值得跟踪的商品"时,MCP 更合适。它可以让 Codex 在同一任务里完成搜索、浏览、筛选和后续处理。固定页面的周期采集仍用 CLI 或定时任务;MCP 负责范围会变化、需要逐步判断的研究任务。额度与适用产品应以 Bright Data 当前方案页面 为准。
| 任务形态 | 推荐方式 | 适合的频率 |
|---|---|---|
| 临时核验一个固定页面 | CLI + 当前对话 | 一次性 |
| 每周更新同一张竞品表 | CLI + Codex 定时任务 | 每周或每天 |
| 多页面搜索、比较和筛选 | MCP | 按需或定期 |
FAQ
已经会 Playwright,还需要 Bright Data CLI 吗?
要看问题卡在哪。复杂交互、登录后的自有系统测试,Playwright 仍然合适。若目标是公开网页的数据访问与后续 Agent 处理,CLI 能把访问层从业务代码里拆出去。它们可以配合,不必互相取代。
CLI、定时任务和 MCP 应该怎么选?
临时核验固定 URL,用 CLI。每周或每天重复跑同一份流程,用 CLI 加 Codex 定时任务,并把完整提示词放进任务。需要先搜索、再浏览、再判断的多步任务,用 MCP。Skills 或 AGENTS.md 适合补充项目长期规则,但不会替代页面获取和定时执行。
Codex 生成 HTML 报告时,原始文件还要保留吗?
要。HTML 只适合查看和汇报,不能替代原始结果。保留 walmart-headphones.md、JSON 和 CSV,才能回查一条价格来自哪个页面、某条记录为什么被标记为 needs_review。
可以采集公开网页,就能随意使用数据吗?
不能。公开可访问不等于没有使用边界。采集前仍要核对目标网站规则、业务授权和适用法律;不要处理登录后、私有或受限内容。
先跑一个真实的 Web Scraping 工作流
让 Codex 写出采集代码并不难。真正需要验证的是,网页结果能否稳定进入业务流程。
一条更可靠的 Agent 原生数据采集流程,让 Bright Data 负责网页数据访问,让 Codex 负责数据提取、验收、异常标记和最终交付。页面返回验证页、字段缺失或数据异常时,流程会把它们拦在 needs_review,而不会继续把它们当成正常结果处理。
如果你想复现本文的 Walmart 示例,可以从 Bright Data 的免费入口 开始,获取一个真实的公开网页结果,再让 Codex 按文中的 needs_review 规则完成数据验收。