AWS Bedrock AgentCore Web Search 新增域名与日期过滤
AWS 为 AgentCore Web Search 工具新增运行时域名与发布日期过滤能力,并扩展都柏林、东京两个新区域…
亚马逊云科技近日宣布在 Amazon Bedrock AgentCore 的 Web Search 工具中引入运行时域名过滤与发布日期过滤能力,并将其作为 web-search 连接器 1.2.0 版本的一部分同步上线。该功能允许开发者在每次 API 调用时动态指定可访问的域名范围与结果的时间窗口,并由服务端强制执行,无需额外的外部编排。结合既有的管理员级域名策略,组织可以构建一个分层过滤模型,在保证企业合规底线的同时,为单次 API 调用保留按需动态收窄作用域的灵活性。
与此同时,本次发布还将 Web Search 的可用区扩展至 eu-west-1(都柏林)和 ap-northeast-1(东京)两个新的 AWS 区域。欧洲与亚太地区的客户现在可以从更靠近其工作负载的区域端点调用 Web Search,降低延迟,并满足部分监管客户对数据驻留位置的要求。AgentCore 采用零出站架构,搜索查询始终留在 AWS 网络内部。
新增的运行时过滤能力
1.2.0 版本在 Web Search 工具的 filters 对象中引入了两个新能力:
- 运行时域名过滤:通过 include(白名单)或 exclude(黑名单)列表控制每次 tools/call 调用时可被检索的域名来源。两个列表各自最多支持 100 个域名,独立计数。
- 发布日期过滤:通过 ISO-8601 UTC 时间区间限定结果仅来自指定时间范围内发布的内容,起止日期均为闭区间。
这两个过滤器均为可选参数,缺省时与既有行为一致,即所有已索引内容均可被检索。
为什么要做运行时过滤
现实中的智能体负载往往需要比组织级策略更细粒度的控制。AWS 在博客中给出了几个典型场景:合规类智能体在分析监管动态时应只检索 .gov 类域名与已批准发布方;市场情报类智能体在总结「本周财报电话会」时不应返回上一季度的高排名结果;多租户平台需要在同一接口下为不同客户提供差异化的域名策略;客服类智能体在回答「最新版本改了什么」时只能返回最近 7 天内发布的文档。
运行时过滤正是将这类控制能力下沉到每一次 API 调用中,从而补足管理员级策略难以覆盖的动态需求。
分层过滤模型:管理员级 + 运行时
本次设计中的一个关键原则是:运行时过滤器只能在管理员级策略设定的范围内收窄作用域,而不能扩大它。这一约束确保企业合规策略始终被强制执行,无论运行时调用方请求什么。管理员级域名列表在连接器资源创建阶段设定。
在合并逻辑上:
- 域名白名单(include):最终生效的白名单是管理员级与运行时列表的交集。例如管理员允许 [a.com, b.com, c.com],运行时调用包含 [b.com, c.com, d.com],则最终只检索 b.com 和 c.com,d.com 因不在管理员列表内而被静默丢弃。
- 域名黑名单(exclude):最终生效的黑名单是管理员级与运行时列表的并集。例如管理员屏蔽 [x.com],运行时调用排除 [y.com],则两个域名均被屏蔽。
整个请求生命周期在服务端完成:智能体通过 tools/call 发出 query 与 filters,Gateway 将运行时过滤器与管理员级策略合并,对网络索引执行过滤检索,对原始结果强制合规校验,最终仅返回通过校验的结果供智能体引用。过程中不涉及客户端过滤循环、不做后处理,也不需要额外往返。
区域扩展与零出站架构
新增的 eu-west-1 与 ap-northeast-1 两个区域,使欧洲与亚太客户可在本地调用 Web Search,进一步降低跨大西洋流量带来的延迟。由于 AgentCore 采用零出站架构,搜索查询不会离开 AWS 网络,这也为有数据驻留合规需求的客户提供了本地化的『接地』路径,使其无需将流量跨区路由即可构建有据可查的智能体。
