AgentCore 推出免建资源的网页搜索接口

给 AI 应用补充最新信息，不一定要先搭一套 Agent 工具网关。AWS 这次把 Amazon Bedrock AgentCore 的网页搜索能力开放成独立 API：业务代码用现有 AWS 身份签名，就能直接拿到搜索结果和文本摘录，无须先创建 Gateway 或搜索目标。

它解决的是接入层的问题：已有后端、自写 Agent 循环或数据流水线，可以少经过一层基础设施。但接入变简单，不代表搜索质量、来源可信度和统一管控都自动解决。对程序员来说，更值得看的是这条边界。

一次搜索调用，为什么不必先经过 Gateway

过去使用 AgentCore Web Search，需要创建 AgentCore Gateway、添加搜索目标，再通过模型上下文协议（MCP）客户端调用。对于维护多个 Agent 的平台团队，这套路径有价值：统一工具入口，集中处理入站和出站认证、语义工具选择，以及可选的 MCP 会话。

但已有 API 层的应用，可能只想拿一组网页结果。为了搜索再接入网关，会增加配置和调用链路。

新的入口是 bedrock-agentcore 数据平面的 InvokeWebSearch。AWS SDK 或 AWS CLI 使用现有凭证，以 AWS Signature Version 4（SigV4）签名请求；调用方需要 bedrock-agentcore:InvokeWebSearch 权限。原文示例授权的资源是 arn:aws:bedrock-agentcore:us-west-2:aws:tool/web-search.v1。

这里的「无须创建资源」，指直接调用搜索 API 前不用创建 Gateway，并不是免配置权限。

运行在 AWS Lambda、Amazon ECS、Amazon EC2、Amazon EKS 上时，可以通过执行角色获取凭证。搜索查询由 Amazon 运营的索引处理，原文明确表示不会转发给第三方搜索引擎；它与 Alexa+、Kiro、Quick 等产品使用同一套搜索基础设施。

API 和 Gateway 搜索的是同一个索引，选择的重点是调用方式与治理方式。

AWS 仍推荐大多数 Agent 工作负载使用 Gateway。独立 API 更适合自定义编排、LangChain 或 LlamaIndex 集成，以及事实核查、内容补充、监控等非 Agent 流程。重试、缓存和错误处理也可以由业务代码自行掌握。

搜索结果能直接给模型，但字段和过滤条件要看清

下面的 Boto3 示例，把搜索范围限制在两个技术站点，并设置发布时间下限：

import boto3

client = boto3.client("bedrock-agentcore", region_name="us-west-2")

response = client.invoke_web_search(
    webSearchId="web-search.v1",
    searchQuery="multi-region EKS cluster deployment best practices",
    maxResults=10,
    filters={
        "domainFilter": {"include": ["aws.amazon.com", "kubernetes.io"]},
        "publishedDateFilter": {"publishedAfter": "2026-01-01T00:00:00Z"},
    },
)

for result in response["results"]:
    print(result.get("publishedAt"), result.get("title"), result.get("url"))

要看最后一行的 .get()：每条结果都有文本摘录 text，但 title、url、publishedAt 只有索引掌握时才返回。若业务要求每个结论都附来源，调用成功之后仍需检查 URL 是否存在。

原文给出了一条真实调用结果，发布时间为 2026-09-25T15:52:00Z。这能说明返回结构，但不能证明整体搜索质量或覆盖率。

几个参数限制会直接影响集成：

• searchQuery 最长 200 个字符，不能把整段聊天记录直接当查询。
• maxResults 支持 1–25，省略时最多返回 25 条；控制台初始值则是 10。
• domainFilter 的 include、exclude 列表各最多 100 个域名，根域名也匹配子域名。
• publishedAfter、publishedBefore 使用 RFC 3339 UTC 时间，例如 2026-01-01T00:00:00Z，两个边界都包含在范围内。

原文把示例描述成搜索 2026 年发布的页面，但代码只设置了下限，没有设置 publishedBefore。如果复用于严格的年度检索，就应补齐上限。发布时间还可能缺失，日期过滤也不能替代对页面内容是否过时的检查。

只想验证能否调通，可以在 AWS CloudShell 使用控制台会话凭证执行：

aws bedrock-agentcore invoke-web-search \
    --web-search-id web-search.v1 \
    --search-query "latest EKS features" \
    --max-results 5

要注意 --web-search-id web-search.v1，它指定的是 AWS 托管搜索工具。本地使用 Python 时，需要 Boto3 1.43.127 或更高版本；CloudShell 同样要求调用身份具备搜索权限。

框架接入也已提供：langchain-aws 1.9.3 起支持 create_web_search_toolkit，AgentCore Python SDK 1.26.0 起提供相关支持，其中 WebSearchClient 会返回解析过日期的结果。原文 LangChain 示例使用 create_agent、init_chat_model，模型标识为 bedrock_converse:us.anthropic.claude-sonnet-5。

工具还可以固定模型不能修改的排除域名、日期下限和搜索预算。原文提到的依赖监控示例通过 LangGraph 并行研究三个包生态，并在报告前核查来源，但没有给出核查准确率。

企业控制能复用，统一搜索规则却不会凭空出现

直连 API 只支持 IAM 授权，Gateway 还可以通过 JSON Web Token（JWT）授权。更关键的区别在过滤规则：Gateway 管理员可以在目标上设置统一域名列表，调用 Agent 看不到这些规则；API 则由每次请求携带过滤条件。

因此，团队如果要求所有查询遵守同一来源策略，就要在可信的工具封装或服务层固定规则。不能只在提示词里要求模型遵守。

两条路径的字段也不同：API 使用 searchQuery、publishedAfter、publishedBefore，Gateway 的 MCP 工具使用 query、from、to。迁移时不能直接照搬参数对象。

审计同样有边界。CloudTrail 将 InvokeWebSearch 记录为数据事件，默认不会启用，需要为 AWS::BedrockAgentCore::WebSearch 添加事件选择器。事件记录搜索工具和 maxResults，不记录查询文本或过滤条件。它能提供调用审计，却不能单靠这些日志还原搜索内容。

私有子网可以通过 AWS PrivateLink 接入。需要为 com.amazonaws.<Region>.bedrock-agentcore 创建接口 VPC 端点并开启私有 DNS；例如 bedrock-agentcore.us-west-2.amazonaws.com 会解析到端点私有 IP，业务代码无须修改 endpoint URL。安全组必须允许调用资源访问 HTTPS 443。

端点策略可以限制调用身份，IAM 中的 aws:SourceVpce 条件可以进一步要求必须经过指定端点。不过同一端点还承载 Runtime、Memory、Identity、Browser、Code Interpreter 等数据平面 API，设置策略时要考虑这些调用。接口端点另按标准 PrivateLink 价格计费。

按原文口径，搜索费用为每 1,000 次查询 7 美元，直连没有 Gateway 费用；默认配额是每账户、每区域每秒 10 次请求，可以申请提高。可用区域包括美国北弗吉尼亚、俄亥俄、俄勒冈、欧洲爱尔兰、亚太东京和悉尼。

我的判断

我认可它把「获取网页证据」从 Agent 基础设施中拆出来。已有 AWS 后端的团队，可以继续使用熟悉的身份、部署和权限体系，接入搜索的路径更短。

但这是一篇产品发布说明，不是搜索评测。作者没有提供相关性、延迟、中文覆盖、索引更新速度，也没有与其他搜索 API 做对照。「同一套基础设施」能解释服务来源，不能直接证明更适合国内程序员查技术资料。

与 Gateway 相比，直连减少了一层接入，也把更多规则维护交给应用。多个 Agent 共用严格策略时，集中管理仍有吸引力；只有一个现成服务需要搜索时，直连接入通常更容易理解和维护。这是架构取舍，原文没有量化收益。

搜索返回的是候选证据，模型生成的结论仍需要核查。

文本摘录便于放入上下文窗口，但原文没有承诺它足够覆盖完整论证。处理版本兼容、配置限制等问题时，仍应检查来源页面和适用条件。查询留在 AWS，也不等于检索到的网页内容天然可信。

能拿来做什么

• 已有 AWS 上的 Node 或全栈服务，可以先用官方 SDK 接入独立搜索调用，在服务端保留 IAM 凭证，并检查结果字段，再决定哪些摘录进入模型上下文。
• 做技术资料助手时，可以把 aws.amazon.com、kubernetes.io 这样的来源范围固定在工具层，同时设置合理日期条件，减少模型临时选择来源的不确定性。
• 做依赖动态监控时，可以参考原文流程，把搜索发现与来源核查分开，核查后再生成报告，并保留可追溯的来源信息。
• 已有多个 Agent 共用工具的平台，应先比较统一域名规则、JWT 接入和集中认证需求，再决定使用 API 还是 Gateway，同时核算查询量与 PrivateLink 成本。