AWS上线AgentCore网页搜索API：LangGraph并行构建依赖监控代理

摘要：AWS 正式推出 Amazon Bedrock AgentCore Web Search API，通过一次调用向智能体返回带有标题、URL、发布日期和相关摘录的网页结果，并直接使用现有 AWS 凭证完成 SigV4 签名。官方以 LangGraph 构建每日依赖监控示例，并行研究 npm、PyPI 与容器基础镜像，将时间窗口、来源黑名单和搜索预算保留在代码层，再对引用来源、包名、CVE 编号和发布日期进行确定性校验。测试中三条分支用时 36 秒，相比串行执行 99 秒显著提速。方案可部署于 AgentCore Runtime，也可经 Gateway 统一实施管理员来源策略，但安全结论仍需结合权威漏洞源与人工复核。

---

核心更新

AWS 已正式提供 Amazon Bedrock AgentCore Web Search API。智能体通过单次 API 调用即可获得当前网页结果，每条结果包含页面标题、URL、发布日期和与查询相关的摘录。调用沿用应用现有的 AWS 凭证并通过 SigV4 签名，无需单独保存或轮换第三方搜索引擎密钥。

这项能力可直接接入 LangChain、LangGraph 与 Deep Agents，也可通过 AgentCore Gateway 向 MCP 客户端开放。AWS 官方示例采用 LangGraph 构建每日依赖监控器，同时检查 npm、PyPI 和容器基础镜像中的安全公告、版本发布及供应链变化。

架构：让模型负责生成，让代码负责约束

示例将职责拆成两层：模型决定搜索词并生成结构化发现；时间窗口、域名黑名单、搜索预算、证据校验和去重则由确定性代码控制。

每个生态对应一条 LangGraph 分支：

1. fan_out 使用 LangGraph 的 Send API 为 npm、PyPI 和容器镜像分别创建研究节点。
2. 分支调用 Amazon Bedrock 中的 Anthropic Claude，并附带由 create_web_search_toolkit 创建的搜索工具。
3. 工具为每次请求附加 published_after 与 exclude_domains，并通过 max_searches=4 限制调用次数。
4. model_filters=False 使模型只能看到查询参数，无法修改日期边界、来源黑名单或搜索预算。
5. 分支结束后，代码验证引用与证据是否匹配，再合并结果。
6. keep_new 使用 LangGraph Store 查询已报告项目，避免每日任务重复推送同一公告。

这种设计并未消除模型幻觉，而是把模型输出降级为待验证候选。真正决定哪些内容进入报告的是代码规则。

证据校验：验证引用存在，不等于验证漏洞结论

每条发现必须依次通过四项检查：引用 URL 必须出现在该分支的搜索结果中；来源标题或正文必须以完整词形式提到目标包；CVE 或公告编号必须出现在来源文本中；来源发布日期必须落在监控窗口内。缺少发布日期的页面按窗口外处理。

这套机制能够拦截无来源 URL、虚构编号和过期材料，但不能证明以下信息：

• 严重性等级是否准确；
• 漏洞是否已在野利用；
• 受影响版本范围是否完整；
• 修复建议是否适用于当前依赖树；
• 网页索引日期是否等同于问题首次披露日期。

因此，官方明确建议生产安全流程继续对接权威漏洞数据库，并由安全人员复核后再执行升级、隔离或发布操作。网页搜索适合发现线索，不应成为唯一事实源。

并行化收益与工程代价

在官方测试中，三条研究分支共发起 12 次搜索并返回 80 个来源。证据检查剔除了两条发现：一条来源未提及目标包，另一条 CVE 编号未出现在来源正文中。最终四条发现通过检查，其中两条因持久化存储已存在而被去重。

并行执行的墙钟时间为 36 秒，串行执行为 99 秒，缩短约 64%。不过，这组数字只反映示例任务，不能直接等同于线性加速比。LangGraph 的并行仍受模型并发配额、Web Search 区域配额、账户级请求速率和分支长度影响；默认每区域每账户为每秒 10 个搜索请求，且同一账户下的所有智能体共享配额。

并行化主要降低端到端等待时间，但不会消除总搜索次数、模型 Token 消耗和索引费用。若某条分支需要更多轮搜索，其最坏延迟仍可能主导整个任务。生产系统应同时设置每分支预算、总运行预算、超时和失败降级策略。

部署：从笔记本到 Runtime 与 Gateway

本地验证阶段可使用 Notebook，但 Runtime 会话中的 InMemoryStore 是临时的，无法满足长期每日任务。官方建议将状态迁移到支持精确键查询的持久化存储，例如 langgraph-checkpoint-aws 提供的 DynamoDBStore。

部署到 AgentCore Runtime 时，可选择两类计算资源：

• MicroVM：每个会话使用独立 MicroVM，适合强会话隔离；
• Runtime Instances：运行在账户内的 AWS 托管 EC2 实例上，适合多日会话、GPU 工作负载或多个智能体共享实例。

AgentCore Runtime 的搜索调用由执行角色签名，因此 IAM 权限应保持最小化。示例只要求 bedrock-agentcore:InvokeWebSearch 作用于 web-search.v1 工具资源。

对于需要跨团队统一治理的平台，AgentCore Gateway 可以承载 Web Search Tool，并以管理员策略锁定域名黑名单。Gateway 路径需要两个权限：Gateway 服务角色具备 InvokeWebSearch，调用 Gateway 的客户端身份具备 InvokeGateway。若不同团队需要不同来源策略，应为每个团队创建独立 Web Search Target，而不是依赖模型自行遵守提示词。

开发者落地建议

1. 先定义不可变策略：在工具创建层固定日期窗口、域名白名单或黑名单、总搜索次数及并发上限，不要只写进系统提示词。
2. 分离模型输出与证据对象：利用 return_sources=True 同时保留供模型阅读的结果和供图节点校验的 Artifact。
3. 采用持久化去重：开发环境可用 InMemoryStore，定时生产任务应使用 DynamoDB 等持久化存储，并以稳定指纹而非自然语言标题作为键。
4. 增加权威数据交叉验证：将 CVE、OSV、NVD 或供应商公告接入确定性子图，网页搜索只负责发现候选事件。
5. 控制搜索与模型预算：同时限制每分支次数、总 Token、总运行时间和账户级配额，避免并行任务触发限流。
6. 建立人工闸门：对严重性判定、依赖受影响范围和修复操作设置审批，不允许智能体仅凭网页摘录自动变更生产基础设施。
7. 审计引用与输出：所有面向用户的结论必须保留来源链接，并记录原始搜索结果、校验结果和最终报告之间的可追溯关系。

能力边界

该 API 的主要工程价值不是让模型获得一个任意浏览网页的入口，而是把搜索封装进已有的 AWS 身份、权限和智能体工具体系：应用无需维护额外搜索密钥，平台团队能够集中施加来源策略，LangGraph 则负责并行编排与状态管理。

但搜索质量仍受 AWS 运营的网页索引覆盖度、更新时效和抽取质量影响。官方测试证明了并行调度、来源约束和确定性过滤的可行性，并没有建立漏洞识别准确率、误报率或漏报率基准。涉及软件供应链安全的生产系统仍应以权威漏洞源为事实基线，把 AgentCore Web Search 定位为早期发现与信息聚合层。

---

消息来源：AWS Machine Learning Blog (2026-11-10)

—— 完 ——

主题标签： #AWS 关注 #AgentCore 关注 #LangGraph 关注 #Web Search 关注 #供应链安全 关注