详解用Bedrock AgentCore、OpenSearch Serverless和Lambda构建自动化网页洞察提取系统,可监控RSS并生成可搜索的AI摘要。
从数十个网站中提取洞察往往意味着手动逐一访问每个网站,这个过程很快就会让人不堪重负。设计团队需要追踪竞品动向,市场团队希望监控内容趋势,产品经理需要掌握市场情报。但如果靠人工完成,就意味着必须有人访问网站、复制内容、整理信息,才能开始真正的分析。基于规则的爬虫提供了一定的自动化能力,但它们与页面结构紧密耦合。网站重新设计或迁移到 JavaScript 渲染的前端,可能会在团队察觉之前就让整个流水线静默失效好几天。
Amazon Bedrock AgentCore 是一个用于大规模构建、连接和优化 Agent 的平台,支持任意框架或模型。本文中的解决方案使用了 Amazon Bedrock AgentCore 的 Browser 功能。这是一项完全托管的浏览器服务,能够可靠地渲染 JavaScript 密集型页面,因此当网站发生变化时,你的流水线更具韧性。
本文演示了如何使用 Amazon Bedrock AgentCore Browser、Amazon Bedrock(用于 AI 驱动分析)、Amazon OpenSearch Serverless(用于语义搜索)和 AWS Lambda(用于编排)来部署自动化洞察提取解决方案。你构建的系统可以监控 RSS 订阅源,使用 AgentCore 托管浏览器检索网页内容,通过 AI 提取洞察,并通过 Web 界面使所有内容可搜索。
该解决方案是为需要追踪行业趋势的设计和产品团队构建的,但其架构适用于更广泛的场景:
竞争情报:追踪竞品博客、产品公告和新闻稿。AI 可以识别新功能、定价变化或战略转向。
市场研究:监控行业新闻、分析报告和行业出版物。搜索与你的业务相关的新兴趋势或技术。
内容策展:聚合多个来源的内容,让 AI 识别与目标受众最相关的内容。
合规监控:关注监管网站和新闻来源中可能影响业务的变动。
阅读完本文后,你将了解事件驱动架构如何将内容收集与 AI 处理分离、Amazon Bedrock AgentCore 中的浏览器自动化如何处理 JavaScript 密集型页面,以及 Amazon OpenSearch Serverless 中的向量嵌入如何在收集的洞察中支持语义搜索。完整的实现可在 GitHub 仓库中找到。
如果你对这些服务还不熟悉,以下资源提供了基础背景:
该架构遵循事件驱动模式,将内容收集与处理分离。下图展示了这个端到端系统,按三个功能层组织。

图 1 — 自动化网页洞察提取系统的架构图
RSS 订阅源收集:Amazon EventBridge 计划每 15 分钟触发一次 AWS Lambda 函数,检查配置的 RSS 订阅源中是否有新文章,并与 Amazon Simple Storage Service(Amazon S3)中的数据进行去重。
基于浏览器的内容检索:对于每篇新文章,Lambda 函数通过 Amazon Bedrock AgentCore 打开一个浏览器会话,并使用 Playwright 通过 Chrome DevTools Protocol(CDP)连接。与标准 HTTP 请求不同,远程浏览器会渲染完整页面(包括 JavaScript 密集型内容),等待动态元素加载,截取屏幕截图,并下载图片。这一步是让后续流水线成为可能的关键:没有可靠的页面渲染,下游的 AI 提取将收到不完整或损坏的内容。产物以结构化格式上传到 Amazon S3。
事件驱动处理:Amazon S3 上传事件向 Amazon Simple Queue Service(Amazon SQS)队列发布消息,第二个 Lambda 函数从原始 HTML 中提取干净的文本。
AI 驱动的洞察提取:Amazon Bedrock 从清理后的内容生成摘要、识别主题和实体、提取可操作的洞察,并创建向量嵌入。
索引和语义搜索: enriched 的结果被索引到 Amazon OpenSearch Serverless,支持关键词和向量搜索。
用户和 API 访问:最终用户通过 Amazon Cognito 进行身份验证,并通过 Amazon Elastic Container Service(Amazon ECS)上的 React 前端访问(使用 AWS Fargate)。对于程序化访问,Amazon ECS 上的 Model Context Protocol(MCP)服务器(使用 Fargate)通过 Amazon CloudFront 向外暴露系统。MCP 是一个开放标准,让 AI 助手和工具能够通过统一接口连接外部数据源。
以下部分描述了解决方案的主要组件。
RSS 同步 Lambda 函数不仅获取订阅源。它解析每个 RSS 订阅源,过滤出在可配置时间窗口内发布的文章(默认 24 小时),并使用 URL 哈希作为 Amazon S3 中的唯一 ID 进行去重。对于新文章,该函数通过 Amazon Bedrock AgentCore 打开一个远程浏览器会话,并使用 Playwright 通过 CDP 连接。这不是在 Lambda 中运行的无头浏览器,而是一个托管浏览器服务:AgentCore 托管远程浏览器,Playwright 通过 WebSocket 连接控制它。浏览器渲染完整页面,等待 JavaScript 加载,并捕获完整的渲染输出。然后该函数从页面提取图像,下载图像,并以结构化格式将所有内容上传到 Amazon S3:
s3://bucket/
└── example.com/
└── abc123def456/ # URL hash
├── article.html # Full HTML
├── screenshot.png # Page screenshot
├── metadata.json # Article metadata
└── images/ # Captured images
├── image1.jpg
└── image2.jpg
metadata.json 文件包含原始 URL、标题、时间戳以及对下载资产的引用。当元数据文件上传到 Amazon S3 时,它会自动触发处理流水线。
这种分离意味着内容收集和 AI 处理可以独立扩展。如果你正在监控数十个 RSS 订阅源,收集 Lambda 函数会并发处理它们,而带有死信队列的 Amazon SQS 队列为处理失败提供自动重试。
洞察提取 Lambda 函数预处理 HTML 以减少 token 消耗,这一环节显著提高了 AI 生成输出的一致性。
当它从 Amazon SQS 收到消息时,它从 Amazon S3 拉取 HTML 并通过预处理步骤运行。大型 HTML 文件(超过 1 MB)使用 html-to-text 简化以避免 token 限制。较小的文件使用 Mozilla 的 Readability 库,它能更好地提取主要内容并识别主要图像。
清理后的内容随后通过可自定义的 prompt 发送到 Amazon Bedrock。你可以使用 Amazon Bedrock 支持的模型。关于各 AWS 区域的模型可用性,请参阅 Amazon Bedrock 中的 Supported models by AWS Region。Prompt 要求 AI 提取:
Lambda 函数还为语义搜索生成向量嵌入,这样即使精确词汇不匹配,你也能找到相关内容。该函数将所有内容写入 Amazon OpenSearch Serverless:原始内容、AI 提取的元数据以及嵌入向量。索引配置为同时支持关键词和向量搜索。像「有哪些新兴的设计趋势」这样的查询会返回相关内容,即使源内容中没有出现这些确切的词汇。
由于此流水线将第三方网页内容发送到基础模型并将 AI 生成的输出发布到你的团队,生产部署应在提取环节包含保障措施。Amazon Bedrock Guardrails 让你无需更改提取 prompt 即可应用这些控制:
内容过滤 在有害或不适当的内容进入你的可搜索索引之前,将其从抓取的网页中屏蔽。
拒绝的主题和词汇过滤 将提取的洞察保持在你的团队期望的范围内,这在源订阅源不受你控制时尤为重要。
上下文 grounding 检查 验证生成的摘要和洞察是否基于源文章,减少将幻觉性声明作为事实索引的风险。
由于流水线从外部网站摄取内容,请将抓取的文本视为不受信任的输入:Guardrails 充当原始网页内容与你的组织消费的洞察之间的控制点。
使用 Amazon Cognito 身份验证的 React 前端提供了一个搜索界面,团队可以在其中浏览和探索洞察。MCP 服务器提供了一个 API 层,用于与其他 AI 工具集成,通过 Amazon CloudFront 支持程序化搜索和检索。MCP 是一个开放标准,定义了 AI 助手如何发现和调用外部工具,因此组织中的其他 AI Agent 可以直接查询洞察数据库。处理组件在 Amazon Virtual Private Cloud(Amazon VPC)内运行,Amazon CloudWatch 提供可观测性,AWS Identity and Access Management(IAM)强制执行最小特权访问。
构建一个真实的洞察提取流水线不仅仅是将托管服务连接在一起。有几个架构决策对成本、可靠性和输出质量产生了巨大影响,值得明确指出。
AgentCore Browser 会话功能强大但成本高昂。在我们的测试中,每次通过 Amazon Bedrock AgentCore 的 Playwright 渲染需要 10–30 秒,成本显著高于普通 HTTP 请求。URL 哈希去重(在触发新的 AgentCore 会话之前检查 Amazon S3)对于在规模上控制成本至关重要。这种权衡是值得的:AgentCore 可靠地捕获那些会让标准爬虫失效的页面,这是整个流水线依赖的基础。
原始 HTML 是 LLM 的糟糕输入。在将其发送到 Amazon Bedrock 之前清理 HTML,以减少 token 消耗并提高 AI 提取输出的一致性。这个预处理步骤不是优化,而是可靠结果的先决条件。
语义搜索拓宽了你能找到的内容。关键词搜索「家具趋势」返回精确匹配,而向量搜索则可以找到概念上相关的内容,无论术语如何。对于竞争情报或市场研究,嵌入向量使搜索界面真正有用。
SQS 解耦是流水线可靠性的关键。没有它,处理失败意味着文章永远不会被分析。Amazon S3 和提取 Lambda 之间的 Amazon SQS 死信队列提供自动重试,这是一个小型架构更改但对可靠性有重大影响。
Amazon OpenSearch Serverless 有真实的成本下限。无论使用量如何,该服务都需要最低容量单位,这适用于具有一致查询量的生产工作负载。对于较低容量的部署,Amazon Relational Database Service(Amazon RDS)配合 pgvector 以更低的基准成本支持相同的向量搜索功能,值得作为起点考虑。参见 Amazon OpenSearch Serverless pricing details。
为避免持续产生费用,请删除你创建的资源。
cdk destroy(或在 AWS CloudFormation 控制台中删除堆栈)在本文中,你学习了如何构建一个自动化洞察提取解决方案,将手动网页监控转化为可搜索的、AI 增强的知识库。事件驱动架构将内容收集与处理分离,Amazon Bedrock AgentCore 处理 JavaScript 密集型网站,Amazon OpenSearch Serverless 与向量嵌入一起支持超越关键词匹配的语义搜索。
完整的源代码、部署指南和配置说明可在 GitHub 仓库中找到。