Article · AI translation
AI 智能体越来越多地处理依赖当天变化的工作，例如安全公告、产品发布、价格和法规。模型的训练数据无法回答这些问题，因此智能体需要网页搜索。在生产环境中，团队还需要可引用的结果，并能控制哪些来源可以采用。他们希望搜索查询留在自己的云环境中，因为这些查询往往会暴露内部工作。Amazon Bedrock AgentCore 中的 Web Search API 现已推出。它通过单次 API 调用，为智能体和应用程序提供最新的网页结果，并使用它们已经在用的 AWS 凭证签名。AWS 从 Amazon 运营的网页索引中处理每一条查询，不会将查询发送给第三方搜索引擎。每条结果都包含页面标题、URL、发布日期以及与查询相关的摘录。请求可以包含或排除指定域名，并将结果限定在某个发布日期范围内。在 AWS Lambda、Amazon Elastic Container Service（Amazon ECS）或 Amazon Bedrock AgentCore Runtime 上，智能体使用其执行角色调用该 API。无需存储或轮换搜索 API 密钥。Amazon Bedrock AgentCore 上的 Web Search 也可通过 AgentCore Gateway 使用；Gateway 是 Amazon Bedrock AgentCore 的一项功能。在那里，一项管理员来源策略可覆盖每个智能体和模型上下文协议（MCP）客户端。对于 LangChain 开发者，LangChain 的 AWS 集成中的 AgentCore 网页搜索工具现在会调用 Web Search API。一次函数调用即可为智能体提供最新且附有引用的搜索结果。该工具还可以保存模型无法更改的规则，例如日期窗口、来源屏蔽列表和搜索预算。它以数据形式返回结果，供代码检查。它适用于 LangChain 智能体、运行这些智能体的编排框架 LangGraph，以及增加了子智能体、虚拟文件系统和上下文压缩功能的 Deep Agents。在本文中，你将基于 Web Search API，将安全团队的每日依赖项监测构建为一个 LangGraph 图。每天早上，监测任务都会检查是否有新情况影响团队发布时使用的开源软件包和容器基础镜像。它会并行研究 3 类软件包生态系统，同时由代码将日期窗口、屏蔽列表和搜索预算置于模型控制之外。它会根据每条发现所引用的来源核查该发现，并记住已经报告过的内容。随后，你将在 AgentCore Runtime 上运行监测任务，并通过 AgentCore Gateway 向各团队提供该任务。在我们的测试中，3 个分支在 36 秒内完成，而依次运行需要 99 秒。解决方案概览：模型决定搜索什么并撰写发现。无论模型如何操作都必须遵守的每项规则都保留在代码中：日期窗口、屏蔽列表、搜索预算，以及对每条发现的检查。图 1 展示了从笔记本运行监测任务时，这些部分如何协同工作。图 1：从笔记本运行、使用 LangGraph 和 Web Search API 的每日依赖项监测。编号步骤如下：一次运行会以监测清单和监测时间窗口启动图。fan_out 为每类生态系统启动一个研究分支：npm、PyPI 和容器基础镜像。LangGraph 并行运行这 3 个分支。在每个分支内，智能体调用 Amazon Bedrock 中的 Anthropic Claude 模型。模型决定搜索什么，并在最后生成结构化的发现。分支的搜索工具会将日期窗口和屏蔽列表添加到每条查询中。它使用以 AWS 签名版本 4（SigV4）签名的请求调用 Web Search API。步骤 3 和步骤 4 会重复进行，每个分支最多搜索 4 次，所有分支同时执行。每个分支只保留其来源能够支持且处于时间窗口内的发现。3 个分支全部完成后，LangGraph 合并它们的发现并运行一次 keep_new。keep_new 检查 LangGraph 存储并记录新发现，确保不会重复报告。report 为安全团队构建附有引用的新发现表格。前提条件：开始之前，你需要：一个 AWS 账户，并在提供 Web Search API 的 AWS 区域中操作。示例使用美国东部（弗吉尼亚北部）区域（us-east-1）。其他区域请参阅“支持的 AWS 区域”。Python 3.10 或更高版本。用于运行笔记本的身份的 AWS 凭证，凭证来自环境变量或 AWS 命令行界面（AWS CLI）配置文件。该身份需要步骤 1 中的 AWS Identity and Access Management（IAM）权限，并能够访问 Amazon Bedrock 中的 Anthropic Claude 模型。还需要以下 Python 软件包：boto3 1.43.127 或更高版本、AgentCore Python SDK（bedrock-agentcore）1.26.0 或更高版本，以及 langchain-aws 1.9.3 或更高版本。使用以下 pip 命令安装：pip install -U "boto3>=1.43.127" "bedrock-agentcore>=1.26.0" "langchain-aws[tools]>=1.9.3" langchain langgraph。Web Search 和模型调用按使用量计费。详情请参阅 Amazon Bedrock AgentCore 定价。监测任务每次运行最多执行 12 次搜索。完整代码位于此笔记本中。笔记本会运行每个单元，包括设置部分。以下步骤介绍与搜索有关的关键部分。步骤 1：授予权限。首先，授予运行身份执行搜索的权限。Web Search API 需要对 AWS 拥有的一项资源执行一项 IAM 操作，因此每个账户中的策略语句都相同。（完整设置方法请参阅“授予调用 API 的权限”。）这使用的权限与网关服务角色执行网页搜索所需的权限相同：{ "Effect": "Allow", "Action": "bedrock-agentcore:InvokeWebSearch", "Resource": "arn:aws:bedrock-agentcore:us-east-1:aws:tool/web-search.v1" }。步骤 2：构建具有固定规则的搜索工具。现在构建每个研究分支使用的搜索工具。监测任务不能让模型选择日期窗口、可信来源或搜索次数。图还需要以数据形式获取返回的来源，以便稍后根据来源检查发现。langchain-aws 软件包中的网页搜索工具包通过以下选项满足这些要求：toolkit, tools = create_web_search_toolkit( region="us-east-1", exclude_domains=BLOCKLIST, published_after=window_start.strftime("%Y-%m-%dT%H:%M:%SZ"), model_filters=False, max_searches=4, return_sources=True, )。如果不提供 gateway 参数，该工具会调用 Web Search API。每次搜索都带有屏蔽列表和发布日期下限，模型自身提供的参数只能进一步收紧这些限制。设置 model_filters=False 后，模型只能看到查询参数。工具在 4 次搜索后停止，并以两种形式返回结果：供模型使用的文本，以及供图使用的工件。每个分支都创建自己的工具包，因此各分支可以并行搜索。你也可以将相同的工具提供给 Deep Agents 子智能体。步骤 3：定义发现的数据结构。有了搜索工具后，定义每个分支返回的内容。每个分支都是使用 Pydantic 数据结构作为响应格式的 create_agent 智能体，因此返回的是发现，而不是散文。每条发现包含软件包、一行标题，以及来源提供时的 CVE 或公告 ID。它还包含来源所述的严重程度、来源是否称其已被利用、建议采取的措施和来源 URL。笔记本中提供了完整的数据结构和提示词。步骤 4：构建图及其证据检查。现在组装图。fan_out 使用 LangGraph 中的 Send API 为每类生态系统发送一个分支，使分支并行运行。在分支返回之前，代码对每条发现执行 4 项检查。这些检查将发现与该分支自身搜索返回的内容进行比较：引用的 URL 曾由该分支的某次搜索返回。来源的标题或正文以完整单词形式提及该软件包。发现中的任何 CVE 或公告 ID 都出现在该文本中。来源的发布日期位于监测时间窗口内。工件中的每个日期都已解析，缺失日期视为处于窗口之外。所有分支完成后，keep_new 将通过检查的发现与 LangGraph 存储进行比较，然后 report 构建表格。这些检查可以发现不受支持的 URL、未提及软件包的来源、编造的 ID，以及时间窗口之外的来源。它们不会确认严重程度、利用状态、受影响版本或建议采取的措施，也无法证明某个问题最初披露的时间：索引标为本周发布的页面可能描述的是更早发生的事件。对于生产环境中的安全工作流程，应对照权威漏洞信息源核实发现。在任何人据此采取行动之前，应由专人审查发现。步骤 5：运行监测任务。现在可以用 7 天的时间窗口运行监测任务。在我们的运行中，3 个分支执行了 12 次搜索，返回了 80 个来源。它们的实际运行时间为 36 秒，而各分支运行时间相加为 99 秒。证据检查剔除了 2 条发现：一条的来源未提及软件包，另一条的 CVE ID 未出现在其来源中。没有任何来源来自被屏蔽的域名。4 条发现通过检查，keep_new 报告了其中 2 条。此前的测试运行已报告过另外 2 条，因此存储阻止了它们再次被报告。图 2 展示了 LangGraph Studio 中的这次运行；LangGraph Studio 是 LangGraph 的可视化调试器。报告的每一行都链接到其来源；Web Search 可接受使用条款要求，向用户展示的任何输出都必须提供此类来源链接。图 2：LangGraph Studio 中一次依赖项监测任务的运行。右侧的 3 条研究记录对应 3 个生态系统分支，LangGraph 并行运行了它们。报告仅列出通过证据检查且此前未报告过的发现，每条发现都链接到其来源。步骤 6：再次运行监测任务，只查看新发现。最后，第二次运行监测任务，看看存储如何发挥作用。计划任务每天运行，团队不应重复看到同一份公告。在我们的第二次运行中，各分支再次搜索并保留了 2 条发现，而存储显示这 2 条此前都已报告。因此，报告中没有新内容，如图 3 所示。图 3：使用相同输入进行第二次运行。分支再次搜索，但 keep_new 发现每条结果都已在 LangGraph 存储中，因此报告没有新内容。对于计划任务，应将 InMemoryStore 替换为支持精确键查找的持久化存储，例如 langgraph-checkpoint-aws 中的 DynamoDBStore。向现有 LangChain 或 Deep Agents 应用添加网页搜索：如果你已有 LangChain 智能体，只需进行少量更改即可添加网页搜索。部署前请检查以下事项：权限：将步骤 1 中的策略语句添加到应用当前使用的身份或执行角色中。无需创建其他内容。区域：工具包所在的区域必须提供 Web Search API，而且可以不同于模型或应用其他部分所在的区域。工具名称：该工具名为 web_search。如果智能体已有同名工具，例如其他搜索提供商的工具，请在添加前为该工具设置另一个名称。规则与预算：每个工具包都带有各自的筛选条件和搜索预算。对于需要不同规则或独立预算的每个智能体或分支，分别创建一个工具包。吞吐量：账户中的所有智能体共享其 Web Search 配额，因此并行分支的请求量会累加。默认情况下，一个账户在每个区域每秒可发送 10 个请求。详情请参阅 Amazon Bedrock AgentCore 配额。使用 Deep Agents 时，你通过 create_deep_agent 定义智能体，包括模型、工具、系统提示词和子智能体。将工具包的工具传入某个子智能体的工具列表。将规则设置为工具包选项，因为无论模型提出什么请求，工具都会在每次搜索中应用这些规则。要像步骤 4 那样根据来源检查发现，可在智能体输出上运行该检查，或将其作为中间件添加。在我们的测试中，一个 Deep Agents 协调智能体将任务委派给配备这些工具的研究子智能体，并在约 1 分钟内返回了附有引用的答案。在 AgentCore Runtime 上投入生产：当你准备好每天运行监测任务而不依赖笔记本时，可将其托管在 AgentCore Runtime 上。Runtime 无需重写，即可运行使用任何框架构建的智能体，包括 LangGraph。它通过相同的 API 提供 2 种计算类型。默认的 MicroVM 为每个会话提供独立的隔离 microVM，因此一次运行无法看到另一次运行的数据。Instances 在你自己的账户中由 AWS 管理的 Amazon Elastic Compute Cloud（Amazon EC2）实例上运行智能体。它们适用于持续多天的会话、GPU 工作负载，或共享同一个实例的多个智能体。有关各自的限制，请参阅“为智能体使用隔离会话”和“Runtime Instances 和容量提供程序”。笔记本旁边的 Runtime 示例将同一个图作为 Runtime 入口点。其策略向 Runtime 执行角色授予步骤 1 中的权限，没有授予更广泛的访问权限。其 README 说明了如何使用 AgentCore CLI 在任一种计算类型上创建、部署和调用该项目。图 4：托管在 AgentCore Runtime 上的同一个依赖项监测任务。步骤 2 至步骤 7 与图 1 相同，每次搜索均由 Runtime 执行角色签名。在步骤 1 中，调用方调用 Runtime，例如使用 agentcore invoke。在步骤 8 中，Runtime 返回报告。Runtime 会话状态是临时的，因此内存存储仅在会话期间存在。每日任务需要步骤 6 中的持久化存储，并按计划调用。使用 AgentCore Gateway 将监测任务扩展到多个团队：Web Search API 和 AgentCore Gateway 上的 Web Search Tool 搜索的是同一个索引，同一个图也适用于两者。根据由谁执行规则以及由谁调用搜索来选择：当你自己的应用调用搜索并执行自己的规则时，使用 Web Search API，如步骤 1 至步骤 6 所示。它只需要一项 IAM 权限。当平台团队向多个智能体或团队提供搜索，并希望 AWS 对每次搜索应用统一的管理员来源策略时，使用 AgentCore Gateway。该策略位于网关目标上，对智能体不可见，智能体也无法取消该策略。当 Claude 等 MCP 客户端需要搜索，或者你希望在同一个 MCP 端点后将网页搜索与其他工具一起提供时，使用 AgentCore Gateway。笔记本中的可选步骤 7 会通过网关运行监测任务。它创建一个网页搜索目标，并将屏蔽列表作为管理员策略附在该目标上，因此搜索客户端不再添加屏蔽列表。这条路径需要向 2 个不同主体授予 2 项 IAM 权限。网关的服务角色需要对网页搜索工具拥有 bedrock-agentcore:InvokeWebSearch 权限。智能体用于签名的凭证需要对网关拥有 bedrock-agentcore:InvokeGateway 权限。图 5 展示了流程。图 5：通过 AgentCore Gateway 运行的同一个依赖项监测任务。图与图 1 相同。在步骤 4 中，搜索工具通过 MCP 调用 AgentCore Gateway，并使用 SigV4 签名。在步骤 5 中，网页搜索目标应用管理员屏蔽列表并调用 AgentCore Web Search。要为每个团队提供自己的策略，可为每个团队添加一个网页搜索目标，每个目标使用自己的屏蔽列表。此演练笔记本展示了这一模式。有关这条路径的更多信息，请参阅 Web Search Tool。清理：步骤 1 至步骤 6 不会创建 AWS 资源。如果你仅为本文添加了步骤 1 中的权限，请从获授该权限的身份中将其移除。如果运行了步骤 7，请删除目标和网关，以避免持续产生费用。将 DELETE_GATEWAY = True 后，笔记本的最后一个单元会执行以下操作：target = gateway_client.get_gateway_target_by_name(GATEWAY_ID, "security-sources") gateway_client.delete_gateway_target_and_wait(gatewayIdentifier=GATEWAY_ID, targetId=target["targetId"]) gateway_client.delete_gateway_and_wait(gatewayIdentifier=GATEWAY_ID)。笔记本会保留网关的服务角色，以便其他网关使用。不再需要时，请在 IAM 控制台中删除该角色。如果你已部署到 Runtime，请在项目文件夹中运行 agentcore remove all，然后运行 agentcore deploy -y。结论：Amazon Bedrock AgentCore 中的 Web Search API 使用 LangChain 智能体现有的 AWS 凭证，为其提供最新且附有引用的网页结果。依赖项监测任务展示了如何超越单次工具调用。将模型不能更改的规则保留在代码中，并将返回的来源作为数据保存在模型上下文之外。检查能够检查的内容，并在用户看到的所有内容中保留引用。当更多团队需要同样的搜索能力时，AgentCore Gateway 会向所有团队应用统一的策略。要开始使用，请打开笔记本。参考资料请参阅 LangChain 文档中的 Amazon Bedrock AgentCore Web Search 集成页面，以及“使用 Amazon Bedrock AgentCore Web Search 搜索网页”。关于作者：Sundar Raghavan。Sundar 是 AWS Agentic AI Foundations 团队的高级解决方案架构师。他负责 Amazon Bedrock AgentCore 的开发者体验，主管 SDK 和 CLI，并推动框架与生态系统集成战略。他关注开发者如何在 AWS 上构建、部署和扩展生产环境中的 AI 智能体。他还通过 Strands Robots 将同样的智能体开发者体验带到物理 AI 领域。Omar Abdelwahab。Omar 是 Amazon Web Services（AWS）的技术产品营销经理，专注于包括 Agentic AI 和 Web Search 在内的 AI 产品。他拥有计算机科学博士学位，乐于在 AI、技术和市场推广战略的交汇领域工作，帮助客户构建创新应用。