好的，我们开始吧。很高兴见到大家。我是Johan Raju，我在Bright Data担任解决方案架构师。我在这家公司已经工作了大约六年，一直从事数据收集和网页抓取方面的工作。我们最初作为一家代理基础设施公司起步，拥有全球最大的住宅IP网络，随后转型为数据收集平台。如今，我们是世界上最大的网页数据采集平台，每月采集的数据量达到PB级别，仅次于Google。这里简要介绍一下我们的发展历程以及我们是如何走到今天的。
接下来我将涵盖两个主题。首先，我要讲述如何利用实时网络数据构建AI智能体（Agent）。我会讨论人们在处理AI智能体时通常使用的工具，与基于预索引数据的RAG模型相比有哪些优势。我还会分享我们在行业中观察到的变化，以及未来可能出现的趋势和运行这些智能体所需具备的条件。
最后，我将进行一个动手实践环节，大家可以跟随我一起操作。我会展示一个产品情报智能体，它将以亚马逊上的某款商品为例，获取Reddit上的用户情感反馈，然后提供分析建议：你是否应该购买该产品？答案是“是”或“否”。
在网页抓取领域工作多年，我注意到一个现象：当我们思考构建爬虫或收集数据时，究竟需要付出什么努力？在我早期接触的客户中，刚开始起步时通常关注的是目标网站以及想要抓取的具体内容。人们往往从低数据量开始，这构成了传统的网页抓取架构。
假设我是一名电商用户，想要收集电商数据。我的主要目标可能是亚马逊和沃尔玛，因为那里有大量商品，我可以获取价格情报、评论数据以及大多数商品的通用信息。那么，网页抓取在什么时候会变得具有挑战性呢？这是我目前在与客户合作时观察到的行业变化。
起初，我们只关注亚马逊和沃尔玛等少数几个网站；但现在，我们需要Shoppee、独立的Shopify商店、Etsy以及其他众多站点。如果我们退一步看，为了围绕目标网站构建爬虫，开发人员通常需要3到5天的时间来开发。这不仅仅是编写代码，还包括质量保证（QA）、在开发环境中运行、测试以及整个端到端管道的搭建。
如果我们考虑10个网站，可能还需要一些时间；但如果要扩展到100个甚至1000个站点，事情就开始变得复杂了。在人工智能介入之前，开发人员必须手动理解网站结构，确定选择器（selectors）的位置，判断是否可以通过API定位这些数据点，并基于这些知识构建爬虫。我曾与许多从事抓取工作超过10年、负责管理和维护这些爬虫的人共事过。
然而，当涉及到规模化扩展时，问题就出现了：你不仅要添加新的目标网站来扩大抓取范围，还需要管理已有的爬虫系统。假设亚马逊明天进行了页面改版，另外两个网站也做了调整，而你正在管理1000个站点。这就需要对工程资源投入更多精力，花费大量时间去弄清楚：具体发生了什么变更？如何抵消这些影响并修复问题？
此外，还需要评估这是否影响了客户体验、服务等级协议（SLA）以及数据质量。在过去，要扩展资源以管理上千个站点是一个瓶颈，往往需要两倍甚至四倍的工程师。但在人工智能时代，这种情况不再必要，因为我们可以利用智能体（Agents）。智能体能够自主发现网站并为其构建爬虫，这比依靠开发团队和工程师要容易得多。
这里有一个电商网站选择器定位的经典案例。在这个例子中，我们仅针对价格和标题进行抓取。如果明天价格的选择器发生了变化怎么办？这将导致你的服务出现停机时间，因为如果你负责抓取该网站却无法获取价格数据，可能会影响后续的产品分析等整个管道流程。
通常这需要团队介入修复，并回填丢失的数据。但现在借助AI智能体，这些过程可以实现自动化处理。在构建爬虫时，必须认识到一个事实：每个网站都是独一无二的。例如，亚马逊和沃尔玛虽然都有价格、标题和描述等信息，但它们的页面布局截然不同。因此，每个网站都需要构建独特的爬虫。
比这更重要的是，每个网站都致力于保护其数据资产。为了确保竞争对手无法获得相同的产品情报或保持数据安全，这些站点通常会实施各种反机器人机制（anti-bot）和验证码技术，以阻止爬虫和机器人收集数据。
我见过各种各样的封锁手段。有些基础网站通过数据中心IP即可访问；而另一些受Cloudflare、Okami等保护的平台，则要求必须使用住宅IP地址。你需要模拟真实的浏览器行为，表现得像一个真实用户。如果你在页面上点击过快、滚动速度异常，或者屏蔽了图片加载等，都可能触发反机器人机制。
正如我之前提到的，在AI智能体成熟之前，工程能力一直是扩展的瓶颈。当时构建爬虫需要开发人员对网站结构有深入的理解。由于许多网站的布局差异巨大，它们会尽力确保数据的安全性……
收集这些数据需要付出极大的努力，且必须具备深厚的领域专业知识才能获取。这是一张传统爬取架构的示意图。简而言之，左侧是触发抓取的动作主体。有些人喜欢使用调度器、定时任务等工具，希望每日或每周自动获取数据，这会直接启动作业并进入下一层。也有人通过特定的配置和URL来触发，原理相同，请求会直接发送到代理层。
代理的主要作用是隐藏身份以避免被检测。可用的代理类型多样，包括静态IP（如数据中心或ISP IP），以及来自笔记本电脑、平板和电视的轮换住宅IP。后者因绑定真实设备，对网站而言更具真实性，从而更容易获得访问权限。此外，还有内置反机器人能力的工具，例如Bright Data提供的Web Unlocker或Browser API（浏览器自动化部分），它们能自动管理请求是否被拦截、是否需要重试以及IP选择是否正确。
接下来的层是对数据进行解析并验证其真实性，这是获取数据后的关键步骤。例如，需要确认是否90%的情况下都能成功获取价格信息，并验证数据的准确性。是否需要审查数据或评分？必须考虑如何确保通过管道传输的数据能通过验证规则进行准确检查。随后进入后处理阶段，包括数据去重、丰富化和批量预处理等。
数据处理完成后，需将其交付至云存储或内部系统。在此过程中，要确保不重复提供记录或不干净的数据。通常采用“奖章架构”，数据从青铜层经过白银层最终进入数据库。如果流程中任何环节失败，往往需要从头开始整个处理过程。
这正是我之前提到的问题：如果反机器人层出现故障，或者选择器发生变化，就必须重启整个流程。有时甚至需要回填数据，这可能导致错过服务等级协议（SLA）等后果。接下来我将专门讨论人工智能的应用。在座有多少人正在使用像ChatGPT这样的AI大脑？
有多少人在输入查询时看到过“思考中”、“寻找答案”或“搜索网页”的提示？这表明AI在决定如何处理查询。当它需要实时寻找答案而无法仅依赖预训练数据时，就会进入异步路径（RAG）。例如查询“去旧金山旅行的最佳时间”，AI可能基于预训练数据回答夏季是最佳时机。
但如果查询变为“今年去旧金山旅行的最佳时间”，AI就必须实时访问网络，判断用户是否在询问特定事件或活动。它需要做出决策以提供实时的旅行建议。这是AI提供的两种不同输出路径之一。另外，响应有时会被缓存。例如纽约的天气查询，由于一天内变化不大且多人询问，可以缓存结果以节省Token费用和网络搜索成本。
获取情报主要有同步和异步两条路径，各自适用于不同场景。同步路径用于实时网络搜索，而异步路径则依赖预训练数据。两者需要不同的设置方案。我们提供工具（将在下一页介绍），利用Bright Data的技术让AI或代理能够顺利访问网络并收集数据，而不会被拦截。
我注意到许多网站通过robots.txt文件屏蔽了Claudebot和GPTbot等爬虫程序。因此，当这些AI引擎试图从特定网站获取数据时，可能会因被屏蔽而无法访问。这正是我们的优势所在：我们能够解锁网络资源。无论用户使用的是爬虫、智能代理还是ChatGPT，我们的工具都能确保其顺利访问网络并抓取数据。
在这方面我们已深耕多年。接下来我要介绍的是网页模型上下文协议（MCP）。它通常与Claude Code、LangChain等工具集成。你可以将其想象为一个需要对话的“大脑”，该大脑连接到我们的MCP端点，即我们库中控制的60多个API。例如搜索引擎（如Google）等工具即可通过此协议接入。
结果，将网页抓取为 Markdown 文件以及作为 HTML 进行抓取。现在，如果我想针对特定网站，比如亚马逊、Reddit、LinkedIn、Instagram，这些也都包含在内。实际上，举个例子，两周前我和一个人合作过，他试图利用 MCP 构建一个社交媒体监听工具。他说的一个用例是：“嘿，这是我的名字，我想去网络上收集我所有的社交媒体个人资料，并告诉我有多少粉丝。”
所以他的做法是在 Claude Code 中使用它。首先通过搜索引擎调用我们的 MCP，找到了他在 Instagram、TikTok、LinkedIn 上的页面结果并返回，然后向我们的数据管道发出 API 请求，最后带回关于你有多少粉丝的结果并提供上下文。这就是你知道它能做什么的力量，以及 MCP 能解锁多少网络内容。此外，这也适用于浏览器自动化。
比如创建一些你需要使用浏览器的东西，像点击、滚动，或者像在 DoorDash 上自动化下单，又或者在旅游网站上尝试找出购买机票的最佳时间、预订航班等。像这样的事情对它来说非常有优势。接下来我要展示一段关于 MCP 如何工作的视频，让我把它调出来。
所以在左侧你可以看到这是使用 Bright Data 的 MCP 设置在 Claude 上抓取的结果，而在右侧是没有使用 Bright Data 的 MCP 设置。你可以看到被询问的是相同的提示词，即“使用浏览器获取这个页面的内容”，这是一个 Glassdoor 的 URL。在左侧可以看到，有了 Bright Data 作为 MCP，它实际上访问了 Glassdoor 并获取了结果；但在右侧，它被阻止进入 Glassdoor。
这是一个完美的例子，你知道像 Glassdoor 这样的网站在数据收集层面是非常受保护的站点。这也是为什么将 MCP 与 Claude、GPT 或任何你想在其上运行的智能体配对时具有优势的一个很好的例子。
好的，现在我要讲一个用例示例。与 AI 公司合作时，这些是我接触过的客户例子，他们以任何形式使用 Bright Data。比如训练模型、微调以丰富他们的模型或提供 AI 智能体实时访问权限，就像我们提到的那样，或者增强 RAG（检索增强生成）。在这个例子中，我将专门讨论职位数据。
假设有人来找我并说：“嘿，听着，我需要职位数据，我想用职位数据训练一个模型，比如简历匹配。”我们需要知道的是，当你考虑职位数据时，它不像其他形式的数据收集那样，我可以拉取数据然后就不管了或训练模型。你需要关于职位的持续更新：哪些公司在发布什么，有多少可用职位，薪资是多少，地点在哪里等等。
因此，数据实际上是结构化的并具有一致的输出非常重要。实际性能也非常关键，因为如果你正在构建一个模型来分析工作模式或就业市场的任何情况，你需要数据持续流入。你还需要它非常可靠，因为如果出现问题或有停机时间，这实际上会影响你想要运行的整个管道及其时间表。
而且这不仅关乎从当天开始获取职位数据，有些人需要过去的职位数据，比如过去几个月或几年的。因此覆盖所有这些非常重要，因为如果你想构建一个大局观——在这个例子中是关于职位的：我如何在我的模型上训练以找到该职位的最佳匹配？你需要了解趋势是如何变化的。
你知道，软件工程师的薪资可能随着时间的推移而增加，你需要理解需求是什么，当前的报价是多少。你可以围绕这些构建你的模型。所以这是一个用例示例，比如用于简历匹配的 AI 智能体，这正是我们在这里讨论的内容。因此，你需要实时访问以实际进行数据抓取并能够同时训练这个模型。
好的，接下来我将在这里介绍一个动手练习。我有一个 Google Notebook（笔记本）。如果你们中的任何人正在跟随操作，运行此脚本需要两样东西：一个是 Bright Data API 令牌，另一个是 Gemini API 密钥。我在 Google Drive（云端硬盘）上有设置两者的说明列表。
本质上，我已经为你准备好了所有运行环境。所以我会简要谈谈我们要做什么。首先我们调用 Bright Data 的 API 端点来收集亚马逊数据，从亚马逊获取响应。然后调用 Reddit 本身的 API，捕获原始的 Reddit 数据响应，并对此执行 AI 分析。
在我运行之前，我想展示我们从每个 API 获得的确切数据。对于亚马逊，我们获取的是产品级别的数据。所以我选了一个 Stanley Quencher 杯子作为例子，本质上我们有该产品的所有数据：价格、图片、URL 等。我会在它运行后再次展示这一点，我的屏幕有点小，所以可能无法显示全部内容。
我们还有一个 Reddit API，我将在构建的这个脚本中做的是对该特定的 Stanley Quencher 杯子运行关键词搜索。我将输出那些讨论是否应该购买此产品、它是否值得、人们对此有何看法的帖子。所以，让我们现场运行这个脚本。
好的，我们的密钥已经加载好了。
好，我们得到了返回的亚马逊数据。你可以看到它有价格、评分、其他卖家正在销售它以及来自产品本身的所有实际数据，如功能等。现在，我们将触发对 Stanley Quencher 杯子的 Reddit 搜索，只是为了获取关于产品本身的评论。
在这个运行过程中，我将展示一些我之前讲过的内容：模型上下文协议（MCP）服务器。我们有不同的层级，我知道我谈到了浏览器自动化和搜索引擎，但我们也涵盖电子商务、社交媒体、金融情报、研究、商业智能等方面。这些都可以插入到 MCP 中。
Endpoint，你知道的，App Store 的数据还在持续更新和扩展。目前我们提供了超过60种工具供 AI Agent（智能体）使用。有些人其实更喜欢自己编写爬虫，但我们提供的方案允许你的 AI 代理自主选择要使用的工具。这样一来，流程会更加精简高效，也更容易上手操作。
在演示进行期间，如果大家有任何问题都可以提出来。刚才有人问：为什么你们能够抓取简历级别的数据，而普通的机器人却做不到？这其中的优势何在？Bright Data 之所以能做到这一点，是因为我们拥有全球最大的代理基础设施网络。
当你谈论抓取数据时，可能只是几天的页面爬取量。比如以 Glassdoor 为例，起初或许能正常运行，但过不了多久，网站就会察觉到异常：比如检测到对方使用的是数据中心 IP 地址访问页面，且页面上没有任何实际的用户交互行为。
此时，网站就会开始部署层层反机器人防护机制。正是在这种情况下，像我们 Bright Data 这样的公司才能发挥作用。因为你需要做的不仅仅是拥有爬虫或机器人，还需要思考如何绕过网站设置的 CAPTCHA 等保护措施。
关键在于要能够持续、稳定地规避封锁，而不触发拦截机制。我们在这方面已经深耕多年，并拥有专门针对反机器人逻辑的工具。我们会根据每个网站的情况调整策略，并在大规模应用中保持一致性。
不过，对于那些刚开始尝试自行爬取数据并内部管理的公司来说，必须意识到这也需要投入大量的工程时间和人力资源。因为要弄清楚网站究竟做了哪些更改以应对爬虫，往往比单纯管理爬虫本身还要耗费更多时间。
好了，看起来数据已经返回了。我可以给大家展示一下。系统成功捕获了一些关于该 Tumblr 帖子本身的 Reddit 评论。可以看到，人们对该帖子的评价不一：有人认为这很尴尬，也有人对此非常着迷。
接着系统给出了实际的购买建议反馈。数据显示该产品有不错的折扣，亚马逊上的评论绝大多数是正面的，但也夹杂着少数混合观点。由于需求量大而库存低，系统基于从数据中获取的信息进行了分析。
此外，还对该 Tumblr 帖子及其评论数量进行了一些其他维度的分析。系统实际上拆解了我们 API 返回的所有数据点，并给出了明确的决策建议：是否应该购买？还是不应该买？
这只是一个示例，展示了如何从 Amazon 获取数据，然后在 Reddit 上运行分析并做出决策。但这不仅仅局限于电商领域，它可以应用于任何用例场景。只要我们的工具能够让你访问页面并获取数据即可。
接下来，逻辑构建和管道搭建以及规模化扩展就取决于你了。因为我们最擅长的事情就是提供大规模的数据支持。
好了，我想我们可以结束了。如果大家在之后还有问题，我随时可以解答；或者大家也可以前往 Bright Data 的展位交流。感谢各位的时间。
[音乐]