一个金融服务的智能体，不该拿一篇没经过审核的博客来回答客户的问题。一个查“当前有没有货”的产品助手，也不该把三年前的价格和库存数据当真。这两句都是常识，可恰恰是绝大多数 AI Agent 落地时最难跨过的一道坎。它要不要联网，能上什么网，能用多“新”的信息，到底谁说了算。
8月19日，亚马逊在官方科技博客抛出了自己的答案。AWS 宣布，Amazon Bedrock AgentCore 的 Web Search 工具在 1.2.0 版本里正式支持运行时域名过滤与发布时间过滤。开发者可以在每一次 API 调用中，单独指定这次搜索允许访问哪些域名、排除哪些域名，以及结果必须落在哪个发布时间窗口内。这些约束全部在服务端强制执行，不需要任何外部编排脚本，也不存在客户端的过滤循环。叠加此前就有的管理员级域名策略，整套体系被做成了一个“管理员兜底、逐次细化”的分层过滤模型。
同一次发布，还把 Web Search 的可用区域扩展到了欧洲（爱尔兰都柏林，eu-west-1）和亚太（东京，ap-northeast-1）。对一个讲究数据就近和本地合规的欧洲企业而言，这意味着查询再也不用跨越大西洋绕一圈。从6月17日纽约峰会上官宣 Web Search on AgentCore 正式可用，到如今给这副联网能力装上能逐次收紧的信息阀门，AWS 只用了两个月。
为什么“能联网”突然不够了
时间拨回两个多月。6月17日的 AWS 纽约峰会上，这段能力第一次正式走到台前。当时的卖点是让 Agent 用实时网页知识给答案兜底，背后是一套 Amazon 自营的网页索引，横跨数以百亿计的文档，另有内置知识图谱和语义片段抽取。查询全程待在 AWS 内部，不会被路由去第三方搜索引擎，实现数据零出口。
这套“零出口加自建索引”的架构，解决的是企业最敏感的那个问题。用户的查询，究竟去了哪里。这个问题，很多团队是坐进合规评审会议室，才第一次掂出它的分量。一旦引入第三方搜索 API，就得做供应商安全评审，管对方的密钥、配额、限流，还要收拾各家搜索返回格式不统一带来的解析烂摊子，最后还得担心查询会落在哪个国家、数据如何留存。每一件单拎出来都是一个完整的工程，凑到一块，就是让无数 Agent 项目卡在演示阶段过不去的泥潭。
可“能联网”只是第一道门。门打开之后，更刺眼的问题浮出水面，这只手伸向全网，会不会乱抓。
治理的天平，压在“逐次调用”上
没有哪家公司愿意自己的金融 Agent 顺手引用一个无人维护的博客。可难就难在，Agent 的每一次调用，场景都可能不一样。同样是联网搜索，有的查询该全库放行，有的查询必须锁死在自家几个可信域名里。若用一刀切的组织级策略去管，要么管得太死，把能力废掉，要么放得太松，让不可信来源长驱直入。
这正是组织级治理和个体灵活之间那道永恒的张力。企业想要的，是无论何时何地都有底线兜底；而工程师想要的，是每个具体场景都能微调。这两个诉求放在 Agent 身上，几乎天然打架。亚马逊这次推出的双层过滤模型，就是冲着弥合这道裂缝去的。
管理员在配置 connector 资源时，先在 target 层设好域名白名单和黑名单。这份名单对调用方的 Agent 不可见，却对每一笔流过 target 的请求都生效，这是组织的底线。在这条底线之上，开发者可在每次 tools/call 调用里，额外塞进 include 或 exclude 的域名列表，以及发布时间区间，把这一笔请求的范围动态收窄。
这里的核心只有一条铁律。运行时过滤只能收窄，绝不能拓宽管理员划定的范围。无论调用方如何试探，企业的策略底线都纹丝不动。从前 exclude 黑名单只能放 20 个域名，1.2.0 起 include 和 exclude 各自最多能容纳 100 个，还支持根域名直接覆盖子域名。白名单从无到有，黑名单从 20 扩到 100，逐次调用越来越细，治理的颗粒度肉眼可见地在变密。
为什么这两道闸缺一不可？因为单纯靠管理员静态配置，会漏掉大量“查一次、过一个场景”的临时性约束。比如一个市场分析 Agent，大多数时候可以放行全网，但遇到财报季，就得临时把范围收窄到几家指定上市公司的官网和合规披露渠道。这种约束如果都要提前配进 target 层，管理员就得维护一张越来越臃肿、越来越难维护的清单。把收窄的权限下放到每次调用，既保住了底线，又免去了管理员疲于奔命。
时效这道闸，比想象中更值钱
域名过滤解决的是“信不信得过”的问题，发布时间过滤解决的则是“新不新”的问题。这两者常常被混为一谈，其实是两种完全不同的风险。
域名管的是来源可信度。一家机构该引用权威信源，不该引用野鸡博客，这是合规和安全的基本盘。发布时间管的却是时效性，价格、库存、政策、股价，这些信息的新鲜度直接决定 Agent 给出的答案是“接地气”还是“胡说八道”。一个产品信息 Agent，如果拿三年前的定价和库存去回答用户今天的咨询，用户一查就穿帮，信任瞬间归零。AWS 这次给出的 publishedDateFilter，正是用 ISO-8601 的 UTC 时间窗，把答案锁在用户真正关心的那个当下。
这两道闸放在一起，才真正把“联网取证”从玄学变成了可审计的能力。服务端强制执行意味着，无论 Agent 的模型怎么推理、怎么“编”，最终落到答案里的依据都过了一遍过滤。这比单纯指望模型自律可靠得多。
一道看不见的审计线
比过滤本身更值得关注的，是它背后的可观测性设计。域名白名单和黑名单由管理员层配置、运行时不可见，这意味着每一笔请求的合规边界在架构层面就是确定的。而 include 和 exclude 列表随请求传入，服务端一并执行、一并记录，请求日志里天然就带着过滤条件的上下文。这对审计和合规而言，意味着一条完整的证据链。谁在什么时间、什么场景下，让 Agent 访问了哪些来源，全都可以追溯。
在金融、医疗、法律这些强监管行业，这种可审计的联网取证能力，往往比 Agent 本身的推理能力更先过合规评审。AWS 把过滤条件设计成随请求零成本带入，而不是在 Agent 外部另起一套日志系统，这里面藏着对 Agent 生产化落地场景的深刻理解。
自建索引，才是这盘棋真正的底牌
如果把第三方搜索 API 的过滤参数原样透传一遍，这次发布挑不出毛病，但也谈不上想象力。真正值得琢磨的，是这一切都长在 Amazon 自营的网页索引上。
多数给 Agent 加联网能力的方案，本质是给第三方搜索引擎套一层壳。AWS 不是。它自己建、自己运营这套索引，自己维护知识图谱，自己做语义片段抽取，让模型拿到的是一段段“更浓、更省 token”的上下文，而不是一坨笨重的原始 HTML。到了 1.2.0，过滤、时效、区域入口，全都长在同一副自建骨架上。这也正是它敢说“服务端强制执行、无需外部编排”的底气。
底气也写进了定价。Web Search 按查询计费，每 1000 次 7 美元，折算下来一次联网取证不过 0.007 美元。对一个跑起来的 Agent，这个成本几乎可忽略，前提是背后这套索引和治理体系足够可靠。而自建索引带来的另一个隐性红利，是它把数据主权攥在了自己手里。对大企业和强监管行业来说，查询不落到第三方搜索引擎手里，本身就是一道绕不开的合规加分项。
竞争格局，信息门禁正在变成标配
盯着“让 Agent 联网”这块蛋糕的绝非只有亚马逊。谷歌在 Gemini API 与 Vertex AI 里放了 Grounding with Google Search，让模型对接自家实时搜索并返回可验证来源；OpenAI 则靠 ChatGPT Search 占据了消费者侧的流量。但这些玩家手里的搜索，多半和自家模型生态绑得很紧，更像一种顺带的插件。
AWS 踩中的是不同的位置。它把联网搜索当成一种可治理的基础设施来卖，不给模型限定垂类，不把 Agent 架构锁死在某一框架，而是把“能上什么网、用多新的数据”这个治理开关，彻底交到开发者手里。八月初，AWS 更进一步，把同一个 Web Search 工具直接下沉到 Bedrock 模型推理层，让 OpenAI 的 GPT-5.4、5.5、5.6 等模型也能通过 Responses API 原生调用，无需先搭建一整套 Agent 基础设施。这套“从 Agent 层到模型层一路打通”的打法，摆明了想把联网搜索做成云上的一块通用底座。
说到底，AI Agent 联网取证这件事，正从“能不能”的技术议题，滑向“敢不敢”的治理议题。谁的开关更细、谁的底线更硬、谁的区域入口更近，谁就在从实验走向生产的那场竞赛里多一分胜算。而信息门禁，正在成为每个认真对待 Agent 的人都绕不过去的标配。
让智能体会联网，只解决了一半问题。真正让企业敢放手把它放进生产系统的，是那扇既能放行、又能在关键时刻死死咬住不放的信息门禁。亚马逊赌的，就是把这扇门做成 Agent 时代绕不开的水电煤。
快报