把 Codex 变成全栈网页抓取器用 Web MCP 获得实时网络访问

AI 编码助手能在几秒内搭建 API 脚手架、生成前端组件并编写测试。但模型只能针对它已经知道的内容，或你粘贴进上下文的内容进行推理，而一旦你要集成一个陌生的 API、面对昨天刚变更过的文档，或是在一个快速演进的平台上进行构建，这种方式就会失效。

让 Codex 集成一个新服务，它会自信地生成客户端、接好认证并设置好环境变量。一切看起来都没问题，直到你对照官方文档核对：某个必填参数漏掉了，某个端点被重命名了，认证现在还需要一个额外的请求头。这些问题在运行之前都不明显，因为生成的代码看上去依然合情合理。

通常的解决办法是打断你的心流：在另一个标签页打开文档，翻遍 GitHub 找到最新的 README，把相关章节粘贴进对话，再不断要求重新生成，直到一切都对得上。真正的摩擦不在于写代码，而在于在调研与实现之间来回奔波。

Crawlbase Codex Plugin 消除了这种割裂。它以 Crawlbase Web MCP Server 为后盾，通过自然语言赋予 Codex 对网络的实时访问能力：抓取 HTML、提取干净的 Markdown、捕获截图，并可选择将页面持久化到 Crawlbase Cloud Storage，这一切都无需离开你的编辑器。一个配套仓库提供了本文所用的提示词、示例文件和项目结构。在开始之前先克隆它：

git clone https://github.com/ScraperHub/turn-codex-into-a-full-stack-web-scraper.git
cd turn-codex-into-a-full-stack-web-scraper

读到最后，你将已经安装好插件、用冒烟测试验证过它、直接从 GitHub 拉取实时文档，并让 Codex 依据这份文档构建出一个最小的全栈抓取器。更有价值的是，你将拥有一套工作流，它几乎适用于任何对准确、最新信息有要求的 AI 辅助任务。

为什么 AI 辅助开发需要实时网络数据

模型擅长针对给定的上下文进行推理。它们的弱点不是编程，而是训练之后发生变化的信息。文档在不断演进：SDK 会新增参数，API 会弃用端点，认证要求会发生变化，而发布说明里携带的实现细节往往从来不会出现在教程中。

没有实时网络访问，这个循环就是手动的：让 Codex 集成一个 API，得到大体正确的代码，对照当前文档进行比较，把差异粘贴回对话，再重新生成。有了这个插件，Codex 自己就能闭合这个循环。

Codex 不再靠人工去收集文档，而是在写下第一行代码之前就检索到当前版本。

Crawlbase Codex Plugin 是什么

OpenAI Codex plugins 生态让你可以用可复用的技能、应用集成和 MCP 服务器来扩展 Codex。Crawlbase Codex Plugin 把 Crawlbase Web MCP Server 打包成一个插件，通过自然语言暴露出生产级的抓取能力。安装之后，你就可以让 Codex：

• 抓取一个网页并返回 HTML。
• 从一篇文章中提取干净的 Markdown。
• 捕获整页截图。
• 抓取由 JavaScript 渲染的站点。
• 将抓取到的页面存储到 Crawlbase Cloud Storage，之后无需再次抓取即可取回。

在底层，插件会启动 npx -y @crawlbase/mcp，通过环境变量传入你的 Crawlbase 凭据，并与 Crawlbase 的抓取基础设施通信。上方的主图勾勒出了完整的路径：你的提示词发给 Codex，Codex 调用插件，插件驱动 Web MCP Server，而 Crawlbase 在幕后处理渲染、重试、代理轮换、反爬和存储。从你的视角看，这一切都是通过提示词完成的。

你将构建什么

目标不只是抓取某一个站点，而是构建一套可重复的工程工作流，把实时文档与 AI 辅助开发结合起来。在接下来的五个步骤里，你将安装插件、用冒烟测试验证它、从 GitHub 获取最新的 Web MCP 文档、用这份文档生成一个最小的全栈抓取器，并了解截图和 Cloud Storage 在更大的工作流中处于什么位置。

第 1 步：安装插件

把插件克隆到 Codex 的插件目录中：

git clone https://github.com/crawlbase/crawlbase-codex-plugin ~/.codex/plugins/crawlbase-mcp

导出你的 Crawlbase API 令牌（如果你还没有账户，请先注册 Crawlbase）。配套仓库包含一个 .env.example，列出了它所需的变量：

export CRAWLBASE_TOKEN=your_token_here
export CRAWLBASE_JS_TOKEN=your_js_token_here

重启 Codex。之后插件会显示为 Crawlbase Web Scraper，暴露出诸如 crawl、crawl_markdown、crawl_screenshot 以及各项 Cloud Storage 操作之类的工具。随附的 .mcp.json 会启动 npx -y @crawlbase/mcp 并从环境中读取你的凭据，因此没有任何密钥存在于插件本身之中，这让它在共享的、纳入版本控制的环境里也能保持安全。

第 2 步：用冒烟测试验证

在生成应用代码之前，先确认整条流水线可以正常工作。把 prompts/00-smoke-test.txt 粘贴进 Codex，或者直接询问：

Get the markdown content of https://example.com

这个请求刻意几乎什么都不做。如果一切都接好了，Codex 会调用 crawl_markdown，返回干净的 Markdown（标题、各级小标题、正文），而不是原始 HTML。这就验证了完整的执行路径：从你的提示词，经过 Codex、插件和 Web MCP Server，一直到 Crawling API。这条路径是本教程其余部分的主干：你描述想要的结果，服务器就把实时的网络内容喂进 Codex 的上下文。如果失败了，请检查 CRAWLBASE_TOKEN 是否已导出，并在安装插件之后重启 Codex。

第 3 步：在写代码之前获取最新文档

与其让 Codex 凭记忆来集成 Crawlbase，不如先把 GitHub 上的当前文档交给它。把 prompts/01-fetch-api-readme.txt 粘贴进 Codex；它会从原始的 GitHub URL 检索 Web MCP 的 README，涵盖环境变量、各个 MCP 工具、store=true、Cloud Storage 的检索方式，以及与令牌相关的存储行为。

训练数据会过时。直接从 GitHub 拉取 README，意味着 Codex 所依据的正是今天 main 分支上的那份文档。如果 README 很大，可以用 store=true 抓取它，之后再用 storage_get 配合 as=markdown 把它取回（参见 Cloud Storage 文档）。

第 4 步：生成全栈抓取器

在上下文中已经有了当前文档，就用 prompts/02-build-full-stack-scraper.txt 让 Codex 生成这个应用。该提示词要求三个层次：

现在 Codex 已经有了你的需求、你的项目上下文和最新的文档，因此它是对照当前的 API 参考来生成的，而不是历史训练数据。用 books.toscrape.com 或另一个公开的练习站点来测试这个应用。如果因为站点依赖 JavaScript 而导致返回的 Markdown 为空，就按照你在第 3 步检索到的文档，改用 CRAWLBASE_JS_TOKEN 重试。

第 5 步：用实时网络数据进行迭代

打开 prompts/03-iterate-with-live-data.txt。它汇集了多种工作流：比较 Markdown 输出、捕获截图、用 store=true 存储文档，以及重试由 JavaScript 渲染的页面。到了这一步，调研、实现和调试全都存在于同一次 Codex 对话之中，而不再散落在各个标签页里。

用 Cloud Storage 持久化抓取结果

许多抓取工作流并不会在一次请求之后就结束。你可能需要回访文档、比较页面发生了怎样的变化，或者在不再次访问目标站点的前提下重新处理同一次抓取。在任意一次抓取上设置 store: true，Crawlbase 就不会把页面内联返回，而是把底层的 HTML 保存在 Cloud Storage 中，并返回诸如 rid、stored_at、storage_url 和 token_type 之类的元数据。你可以用以下工具来管理已存储的内容：

• storage_get 和 storage_bulk_get
• storage_list 和 storage_count
• storage_delete 和 storage_bulk_delete

有一个细节值得了解：无论你调用的是 crawl、crawl_markdown 还是 crawl_screenshot，被存储下来的产物始终是底层的 HTML。当你以 Markdown 形式取回一个已存储的页面时，Crawlbase 会在检索时从那份 HTML 现场生成它。截图不会保存在 Cloud Storage 中；它们会通过一个临时的截图 URL 单独返回。

理解存储分区

Cloud Storage 会按抓取时所用的 API 令牌，对抓取到的页面进行分区。用 CRAWLBASE_TOKEN 获取的页面，与用 CRAWLBASE_JS_TOKEN 获取的页面处于不同的存储仓，因为标准抓取和由 JavaScript 渲染的抓取运行在不同的基础设施上。

每一次成功的抓取响应都包含一个 token_type 字段（normal 或 js），告诉你文档被存储在了哪里。在之后的存储操作中复用这个值：如果某个页面是用 JavaScript 令牌抓取的，就把 use_js_token: true 传给 storage_get、storage_list 或 storage_bulk_get。一个 "Not found" 响应通常并不意味着文档不见了；它意味着你查询的是错误的分区。查看原始抓取的 token_type，通常就足以找到正确的存储仓。

工程最佳实践

上面的工作流非常适合做原型；而有几项实践能让它在项目成长时依然稳固。

• 在生成集成代码之前先获取当前文档。API 和 SDK 演进得很快，把今天的文档交给模型，能大幅减少已弃用的端点、错误的参数和过时的认证流程。
• 把凭据保存在环境变量中。提交一个 .env.example，让别人知道需要哪些变量，但绝不要提交真实的令牌。
• 存储大型抓取结果，而不是把它们内联进来。对于大型文档页面或数据集，store: true 能让对话保持聚焦，并让你在之后再取回内容。
• 把生成的代码当作生产代码来对待。校验状态码、设置合理的超时，并抛出有意义的错误。无论是否借助 AI，健壮的错误处理才是让一个应用可靠的关键。

随着项目从原型阶段成长起来，并发、重试、监控和基础设施可靠性也开始变得重要；我们关于扩展网页抓取项目的指南涵盖了这些生产层面的考量。

结论

AI 编码助手在能够针对当前信息而非历史训练数据进行推理时，才会发挥出最佳状态。把 Crawlbase Codex Plugin 与 Crawlbase Web MCP Server 搭配起来，就赋予了 Codex 对实时网络内容的直接访问能力：它可以检索文档、提取干净的 Markdown、捕获截图，并依据可获得的最新信息构建应用，全都在一次对话之内。

常见问题

Crawlbase Codex Plugin 是什么？

它是一个面向 OpenAI Codex 的扩展，把 Crawlbase Web MCP Server 集成进你的开发工作流。安装之后，Codex 就能通过自然语言提示词来抓取网页、提取干净的 Markdown、捕获截图，并管理 Crawlbase Cloud Storage。你不必自己编写抓取基础设施，而是让 Codex 去检索实时的网络内容，并把它用作代码生成的上下文。

为什么要用 Web MCP Server，而不是让 Codex 生成一个抓取器？

Codex 擅长生成抓取代码，但除非你提供，否则它无法访问实时的站点或文档。这个插件通过 Crawlbase 的基础设施赋予 Codex 实时网络访问能力，因此它能拉取最新的 API 文档、抓取站点、渲染 JavaScript 页面，并依据当前信息（而非可能已经过时的训练数据）来生成代码。

我可以把这个插件用于高度依赖 JavaScript 的网站吗？

可以。它同时支持静态页面和由 JavaScript 渲染的页面。在配置了 CRAWLBASE_JS_TOKEN 之后，Codex 会使用 Crawlbase 的 JavaScript 渲染来抓取动态站点、在脚本运行之后提取内容，并捕获渲染后的截图。

为什么在存储一个页面之后 storage_get 还会返回 "Not found"？

用 CRAWLBASE_TOKEN 抓取的页面，与用 CRAWLBASE_JS_TOKEN 抓取的页面是分开存储的。如果某个页面是用 JavaScript 令牌抓取的，就把 use_js_token: true 传给存储工具。大多数 "Not found" 响应只是意味着你查询的是错误的存储分区，而不是页面不见了。

NZ

Neil Zamora

高级架构师 · Crawlbase

Crawlbase 高级架构师，专注大规模爬取背后的系统：代理轮换、反机器人韧性，以及隐藏这些复杂性的 API。

IK

Ian Kalvin

技术支持工程师 · Crawlbase

Crawlbase 技术支持工程师，从生产环境抓取与代理配置中真正出问题的第一线写作。