# AWS 介绍通过 AgentCore Gateway 为 Claude Desktop 接入网页搜索

- Source: MechNext — https://mechnext.eu/zh/article/28-aws-details-web-search-for-claude-desktop-through-agentcore-gateway
- Published: 2026-10-03
- Updated: 2026-10-03
- Category: Industry News
- Language: zh (Markdown in other languages: ?lang=en, ?lang=de, ?lang=sk, ?lang=pl, ?lang=ru)

> AWS 于 2026 年 10 月 2 日发布操作说明，介绍 Claude Desktop 如何经 AgentCore Gateway 使用 Web Search，以及身份验证、令牌和连接器的配置。

2026 年 10 月 2 日，AWS 发布了一篇介绍如何为 Claude Desktop 接入 Web Search 的文章。文章采用 Amazon Bedrock AgentCore Gateway 作为连接路径，并将 Web Search 描述为由亚马逊网页索引支持、可与 MCP 兼容的托管能力。本文所述的组件分工、配置步骤和可用区域，均依据这篇 AWS 文章。阅读这些内容时，可以把它视为 AWS 给出的一套具体配置流程：从分配访问权限，到完成身份验证，再到让桌面应用发现和使用搜索工具，各步骤在文章中都有对应的位置。

### Claude Desktop 如何连接搜索能力

在 AWS 描述的安排中，Claude Desktop 通过 AgentCore Gateway 连接 Web Search。Gateway 是桌面应用与搜索能力之间的连接环节，也是文章所述令牌验证发生的位置。文章没有只给出一个桌面应用中的开关，而是同时介绍身份服务、网关和连接器的配置。因此，理解这条路径，需要分别看清谁负责验证用户身份、谁负责签发令牌，以及谁在请求到来时检查令牌。把这些职责区分开，有助于按照文章给出的顺序阅读操作步骤，也有助于理解为什么连接器设置要与前面的身份配置一起考虑。

AWS 文章将 IAM Identity Center 用于用户身份验证，将 Cognito 用于签发 JWT，并称 AgentCore Gateway 会在每一次请求中验证这些令牌。这里的三个环节承担不同任务：用户身份验证说明发起访问的是谁；签发令牌为后续请求提供文章所述的凭据；网关验证则发生在请求进入网关时。文章把它们放在同一条访问路径中说明。读者在查看设置时，可以沿着这条路径逐项对应，而不必把 IAM Identity Center、Cognito 和 Gateway 当成名称相近、作用却未加区分的配置项。

### 文章描述的联合身份验证流程

该操作说明使用 Cognito 联合身份验证层，并描述了 OAuth 2.0 授权码许可流程，以及通过 IAM Identity Center 进行的 SAML 身份验证。两种表述指向这套流程中的不同部分：文章用 SAML 说明与 IAM Identity Center 相关的身份验证，用授权码流程说明联合身份验证路径。随后，Cognito 在文章所述配置中签发令牌，供 AgentCore Gateway 验证。对于只想弄清组件关系的读者，这一顺序比单独记住各个缩写更有用，因为它把登录、令牌与网关请求串成了同一个操作过程。

在具体设置方面，AWS 首先要求建立 Cognito 用户池，使其成为 AgentCore Gateway 的 OIDC 令牌签发方。这一步明确了网关将从哪里获得需要验证的令牌。文章随后要求在 IAM Identity Center 中建立 SAML 应用，使该应用与 Cognito 联合，并为用户或群组分配 Web Search 的访问权限。这里的权限分配也是明确的操作步骤。仅从文章的结构看，建立用户池、建立联合身份验证应用，以及给用户或群组分配访问权限，分别回答令牌来源、登录衔接和访问对象这几个问题。

### 网关与入站授权

完成上述身份相关设置后，文章创建一个包含 Web Search 的 AgentCore Gateway，并将入站授权设为基于 JWT 的方式。AWS 对这一环节的描述与前面 Cognito 签发令牌的步骤相互衔接：Cognito 是文章中的令牌签发方，Gateway 是文章中的令牌验证方。读者核对配置时，可以分别查找这两个角色，而不是把签发和验证合并为同一个动作。文章还说明，Gateway 对每一次请求中的令牌进行验证；这是 AWS 对其所述流程的表述，本文不将其延伸为对其他部署或配置的结论。

这套安排也说明了为什么文章把 Web Search、JWT 入站授权和身份服务放在同一篇操作说明中。Web Search 是要在 Claude Desktop 中使用的能力；Gateway 提供文章所述的连接和令牌验证位置；IAM Identity Center 与 Cognito 则参与用户身份验证及令牌签发。每一项配置都对应访问路径中的一个环节。按文章的先后顺序阅读，可以从访问对象与令牌来源逐步走到网关，而不需要假定桌面应用本身完成了所有身份相关工作。

### Claude Desktop 连接器与工具发现

在 Claude Desktop 一侧，AWS 给出的连接器配置使用 Streamable HTTP、Gateway 资源 URL，以及 Cognito 应用客户端的 ID 和密钥。这些是文章明确列出的配置项。资源 URL 将连接器指向已创建的网关，应用客户端信息与前面描述的 Cognito 设置相对应。阅读这一段时，应把它看作先前身份和网关步骤的延续：文章先说明访问路径中的各个组件，再说明桌面应用如何使用这些已配置的组件。连接器设置本身并不是文章中身份配置的全部内容。

AWS 表示，Claude Desktop 会通过一次 MCP tools/list 调用发现 WebSearchTool。这个描述涉及工具在客户端被发现的阶段，与实际执行工具的阶段可以分别阅读。文章还说明，执行工具时会出现批准对话框，其中列出 Deny、Allow for this task 和 Allow once 三个选项。对照文章中的操作流程，读者可以先关注 WebSearchTool 是否作为工具被发现，再关注执行时出现的选择。把这两个阶段分开理解，能够更准确地对应文章对工具列表调用和执行批准界面的各自描述。

文章列出这些批准选项，是其 Claude Desktop 使用流程的一部分。它让读者看到，在工具被列出之后，应用还有一个与执行有关的选择步骤。本文只依据 AWS 提供的选项名称描述该界面，不从选项推导额外的运行规则。与此类似，tools/list 这一细节说明文章如何描述工具发现，但不能单凭该调用推断其他客户端或其他连接方式也会采用完全相同的过程。就这篇操作说明而言，工具发现、执行批准和网关令牌验证分别位于不同环节。

### 文章列出的区域及阅读范围

关于可用范围，AWS 在文章中列出 AgentCore Web Search 所在的三个 AWS 区域：US East (N. Virginia)、Europe (Ireland) 和 Asia Pacific (Tokyo)。这是一份来自该文章的区域清单，说明 AWS 在文中列出的可用地点。它不提供其他区域的可用性结论。若读者要按文章理解完整步骤，区域清单应与身份配置、网关创建和连接器设置一起阅读，因为它同样限定了这篇操作说明陈述的范围。

把所有步骤放在一起，AWS 所述路径是：为用户或群组分配 Web Search 访问权限；通过与 Cognito 联合的 IAM Identity Center SAML 应用完成身份验证；由 Cognito 签发 JWT；由配置了 Web Search 和 JWT 入站授权的 AgentCore Gateway 验证请求中的令牌；最后在 Claude Desktop 中通过所述连接器发现并使用 WebSearchTool。这是对 AWS 操作说明中各项事实的顺序整理，目的是帮助读者看清组件之间的关系。每个组件的角色都来自文章所给出的流程，而不是对部署结果的独立验证。

这篇文章提供的是一套具体的接入说明，因此阅读重点可以放在各设置之间如何衔接：用户或群组的访问分配决定谁被纳入文章所述的访问安排；联合身份验证与 Cognito 用户池对应登录和令牌来源；Gateway 的 JWT 入站授权对应令牌检查；Claude Desktop 的连接器设置和 MCP 工具发现对应应用中的使用步骤。区域清单则表明 AWS 在文中给出的地理范围。上述配置、界面选项及区域名称均可在 [AWS 原文](https://aws.amazon.com/blogs/machine-learning/add-secure-web-search-to-claude-desktop-with-amazon-bedrock-agentcore)中查阅。