要点
- 2026 年 11 月 10 日，Amazon 在 AWS Machine Learning 博客发表《Build a daily dependency watcher with LangGraph and Amazon Bedrock AgentCore web search》，作者是 Sundar Raghavan 和 Omar Abdelwahab。文章宣布，Amazon Bedrock AgentCore 中的 Web Search API 现已可用。
- AWS 称，每条查询都由 Amazon 自己运营的网页索引提供，不会被送到第三方搜索引擎。调用使用应用已有的 AWS 凭证签名，不必再保存搜索 API 密钥。所需权限是对 AWS 自有资源执行 bedrock-agentcore:InvokeWebSearch。
- 每条结果包含页面标题、URL、发布日期和一段摘录。请求可以纳入或排除域名，也可以按日期范围限制结果。langchain-aws 工具包可以为工具附上日期下限、屏蔽名单、搜索预算，并把返回的来源作为数据保留，还可以让模型看不到这些过滤条件。
- 在作者的测试里，三个研究分支并行运行，共做 12 次搜索，得到 80 条来源，墙钟时间 36 秒结束，三个分支耗时相加则是 99 秒。证据检查去掉了两条发现。四条发现通过检查，存储里已记录过其中两条，因此报告只列出两条新发现。
- 这四项检查确认的是：引用的 URL 来自该分支自己的搜索，来源中出现了该软件包名称，发现里的 CVE 或公告编号出现在正文中，以及带日期的页面落在监视窗口内。它们不能确认严重程度、是否被利用、受影响版本或建议操作，而且索引标注为“本周”的页面，描述的也可能是更早的事件。
2026 年 11 月 10 日，Amazon 在 AWS Machine Learning 博客中介绍了一个用 LangGraph 和 Amazon Bedrock AgentCore 的 Web Search API 构建的每日依赖监视。文章由 Sundar Raghavan 和 Omar Abdelwahab 署名，并称该 API 现已可用。可核对的主张，并不是智能体终于能搜索实时网页。它是：AgentCore 把搜索查询和来源策略留在 AWS 边界之内，并且放在模型无法放宽的代码里，因此真正在出售的产品，是对搜索的治理。结果新不新，并不是这件事的全部。
[1]AgentCore 实际交付了什么
这篇文章描述的是一个供智能体和应用程序使用的第一方搜索 API。调用方用自己已有的 AWS 凭证签名请求，包括在 AWS Lambda、Amazon Elastic Container Service 或 Amazon Bedrock AgentCore runtime 上的执行角色。AWS 称，每条查询都由 Amazon 自己运营的网页索引提供，查询本身不会被送到第三方搜索引擎。这是一项关于查询文本去向的产品主张，而它之所以重要，是因为这些查询常常会暴露内部工作。
每条结果包含页面标题、URL、发布日期，以及与查询相关的摘录。请求可以纳入或排除域名，也可以把结果限制在某个发布日期范围内。同一套搜索还通过 AgentCore Gateway 提供，管理员可以在那里把一条来源策略应用到每一个智能体和 Model Context Protocol 客户端。文中的笔记本使用美国东部，北弗吉尼亚区域，也就是 us-east-1，作者把读者指向支持的区域列表，而不是在我们读到的正文里宣称全球覆盖。
对 LangChain 开发者来说，LangChain 的 AWS 集成里的 AgentCore 网页搜索工具现在会调用这一 API。文章为演示给出了最低版本：boto3 1.43.127 或更高，AgentCore 的 Python SDK 1.26.0 或更高，以及 langchain-aws 1.9.3 或更高。文章还写到，默认情况下，一个账户在每个区域每秒最多可以发送 10 个请求，该账户中的所有智能体共享这一配额。
[1]依赖监视，以及作者自己的测试
文中的实例是安全团队的晨间监视。它先拿到监视名单和时间窗口，再为 npm、PyPI 和容器基础镜像各拆出一个研究分支。LangGraph 让三个分支并行运行。每个分支内部，Amazon Bedrock 上的 Anthropic Claude 模型决定搜什么，并在最后返回结构化发现。该分支的搜索工具会给每次查询加上日期窗口和屏蔽名单，签名请求，并在 4 次搜索后停止。分支结束后，图会只保留通过证据检查的发现，去掉已经报告过的条目，并生成一份带出处的表格。
在作者的这次运行中，三个分支共做了 12 次搜索，得到 80 条来源。它们的墙钟时间是 36 秒，三个分支耗时相加则是 99 秒。证据检查去掉了两条发现：一条的来源没有点名该软件包，另一条的 CVE 编号没有出现在其来源中。没有来源来自被屏蔽的域名。四条发现通过了检查。存储里已从更早的测试运行中记录过其中两条，因此报告列出了两条新发现。第二次用相同输入再跑，分支会再次搜索，保留两条发现，但报告里没有新内容，因为两条都已在存储中。
这些耗时和计数是一次供应商演示，而不是第三方基准测试。它们表明，在作者自己的笔记本上，这张图可以运行、过滤并记住结果。它们并不能说明该 API 在另一支团队的来源下会怎样表现，或在共享的每秒 10 次请求上限下会怎样表现。
[1]哪些规则留在代码里，而不交给模型
这项设计的主张，集中在文章的一句话里。模型决定搜什么，并撰写发现。无论模型做什么都必须成立的规则，全部留在代码里：日期窗口、屏蔽名单、搜索预算，以及对每条发现的检查。在作者展示的工具包设置中，日期下限和被排除的域名由工具自行附上。把 model_filters 设为 false 后，模型只能看到一个查询参数。文章写到，模型可以收紧这些约束，但不能取消它们。每个分支有自己的工具包，因此搜索预算不会合并成模型可以一次性花光的共享计数器。
证据检查同样是代码。分支返回之前，会用该分支自己的搜索结果做四项测试。被引用的 URL 必须来自这些搜索之一。来源的标题或正文必须以完整单词点名该软件包。发现里的任何 CVE 或公告编号都必须出现在这段文字中。来源的发布日期必须落在监视窗口内，缺日期则视为窗外。分支合并后，存储会记录已经报告过的内容，这样每日任务不应再把同一条公告送上来。
在 AgentCore Gateway 上，同一个想法被再向外移了一层。屏蔽名单可以作为管理员策略放在网关目标上，对智能体隐藏，智能体无法取消它。文章写到，这条路径需要两个主体上的两项权限：网关的服务角色需要调用网页搜索的权限，智能体需要调用网关的权限。
[1]这些检查不能确认什么
作者把缺口写得很清楚。这四项检查能抓住没有依据的 URL、未点名软件包的来源、编造的编号，以及窗外或没有日期的来源。它们不能确认严重程度、是否已被利用、受影响版本，或建议采取的操作。它们也不能证明一个问题是何时首次被披露的。索引标注为本周的页面，描述的也可能是更早的事件。文章写到，在生产环境的安全流程里，发现仍应对照权威漏洞源核验，而且在有人据此行动之前，应有人审看该发现。
正是在这个限度上，“带出处的网页搜索”不能替代一套漏洞处理流程。这个 API 可以把查询留在边界内，并把策略留在模型够不着的地方。就现有证据而言，它并不能告诉团队，一条发现是不是新的、是不是可被利用的，或分级是否正确。
这是一篇 AWS 产品博客。36 秒和 99 秒、12 次搜索和 80 条来源，都是作者自己的测试。价格只通过指向 Amazon Bedrock AgentCore 定价来提及，示例中一次监视最多 12 次搜索。我们没有独立调用该 API，也没有重跑这个笔记本。
[1]更公允的读法
更公允的读法是：已经在 AWS 上构建智能体的团队，有理由希望搜索不要离开自己的云账户，也不要依赖一把需要轮换的第三方密钥。把日期窗口、屏蔽名单和预算放进代码，是这些规则该在的位置，因为一个能改写自己来源策略的模型，并不能构成策略。这些证据检查虽然有限，却是一种具体办法，让引文仍然对应搜索真正返回的内容。
同样公允的是，这仍然是围绕一个新 AWS API 的操作指南。结果有多新、Amazon 自营索引起盖了什么、摘录质量如何，文章里都没有独立测量。对已经信任另一家搜索提供方的团队来说，这里的新信息，可能少于那些一直被密钥管理、数据驻留规则，或一再无视屏蔽名单的模型挡住的团队。
[1]谁该在意，接下来看什么
已经在 AWS 上运行智能体、而今天仍把搜索查询送到外部引擎的安全和平台团队应当关心。希望过滤条件无法被模型关掉的 LangChain 和 LangGraph 开发者应当关心，希望通过网关用一条来源策略覆盖许多智能体的管理员也应当关心。
未来六个月里，真正的检验是：团队是否把该 API 当成默认搜索路径；在许多智能体同时搜索时，共享的区域配额是否会成为实际限制；以及生产环境中的监视，在证据检查之后是否仍需要人工审看，正如作者已经建议的那样。还有第二项检验：AWS 是否会公布关于索引起盖和摘录质量的可核对材料，而这篇文章并没有提供。
[1]收束
就这篇文章中的证据而言，AgentCore 网页搜索是一种办法，把查询文本和来源策略留在 AWS 内部和代码之中，再按搜索实际返回的内容核对引文。它不是一套完整的漏洞处理流程，36 秒的演示也不能代替那套流程。未来六个月里要看的主张是：这些写在代码里的规则，以及留在边界内的查询路径，是否会成为 AWS 托管智能体的默认做法，同时对严重程度和新颖性的人工审看仍然留在流程里。
[1]