Claude Desktop Web Search 获得当前答案，但 AWS 掌控访问路径

10 月 2 日，Claude Desktop web search 新增了一条由 AWS 控制的访问路径，在无需通过独立搜索 API 发送查询的情况下弥补了知识缺口。AWS 发布了一套参考架构，将 Amazon Bedrock 上的 Claude Desktop 连接至 Amazon Bedrock AgentCore 中托管的 Web Search 工具。模型可检索当前信息，而企业仍可将身份验证、授权和搜索基础设施保留在既有的 AWS 环境内。

这种组合之所以重要，是因为 Bedrock 上的 Claude Desktop 并不会自动继承 Anthropic 消费者服务提供的全部功能。如果没有接入搜索工具，其回答仍受到底层模型训练截止日期以及用户提供上下文的限制。因此，涉及最新文档、不断变化的产品细节或当前事件的问题，可能得到过时的回答。

更深层的竞争并非 Claude 与另一款聊天机器人之间的较量，而是由 AWS 管理、绑定身份的搜索路径，与接入外部搜索 API 或自定义检索服务这一常见做法之间的对比。AWS 省去了若干集成工作，但同时也引入了多阶段身份链，并带来了网络边界、权限、日志记录和运营归属等重要问题。

Claude Desktop Web Search 现已具备 AWS 托管路径

AWS 将网页访问从外部附加功能转变为可由 Claude Desktop 通过 MCP 发现的托管 AgentCore 目标。

AWS 将这套参考架构作为技术演练发布，而非发布新的 Claude 模型版本。其核心变化在于架构层面。Claude Desktop 可连接至 AgentCore Gateway，后者将 AWS Web Search 作为 Model Context Protocol 工具公开。

MCP 是一种开放协议，让 AI 应用能够通过标准接口发现并调用外部工具。在这一设置中，网关会向 Claude Desktop 提供工具列表。当提示依赖模型尚不具备的信息时，Claude 便可请求搜索。

该搜索服务并非针对用户自行管理的第三方 API 的薄封装。AWS 表示，它依托一个由 Amazon 运营、覆盖数百亿份文档的索引。该托管服务会返回标题、URL、摘要和发布日期，并提取适合模型上下文窗口的段落。

AWS 还称，该索引会持续更新，新增或变更的内容可在数分钟内得到反映。对于时间敏感的问题，这一说法十分重要；不过，搜索新鲜度仍会因页面、爬取可访问性和发布者行为而异。经常更新的公开文档，与隐藏在复杂脚本背后的冷门页面，面临的检索挑战并不相同。

更广泛的Web Search 文档介绍了托管索引之外的域名控制和日期筛选功能。目标管理员可排除指定域名。较新的连接器版本还支持域名纳入规则，以及请求级别的发布日期范围限制。

这些控制措施为搜索建立了一层策略界面，而不只是通往开放网络的路径。组织可以将助手限制在获批的文档域名内，或排除不符合内部信任要求的来源。它们也可将请求收窄至某一明确时间段内发布的材料。

演练指出，这一特定集成目前支持三个 AWS 区域：美国东部（北弗吉尼亚）、欧洲（爱尔兰）和亚太地区（东京）。企业在将这些地点视为长期限制前，应核实当前可用性。AWS 服务覆盖范围可能会独立于较早的教程而扩展。

实际结果很直接。Claude Desktop 可超越静态模型知识，无需开发者自行构建爬虫、规范化搜索结果，或管理另一家搜索服务商的凭据。这并不意味着每一条返回事实都正确，而是为模型提供了一种受治理的机制来寻找更新的证据。

知识截止日期本质上是治理问题

缺失的能力不只是搜索。企业需要在不创建另一条失管数据路径的前提下获取当前信息。

当用户询问近期软件发布、更新后的云文档、新法规或不断变化的运营状况时，模型知识截止日期的问题便会显现。模型可以基于提供的材料进行推理，但除非应用为其提供合适工具，否则无法检索缺失的事实。

面向消费者的 AI 产品通常会用一个搜索按钮掩盖这种区别。企业部署则不能如此。安全团队需要知道哪项服务接收查询、凭据存放在哪里、由哪位用户发起请求，以及什么权限支配了这项操作。

这使 Claude Desktop web search 成为一项身份和基础设施决策。团队可以接入外部搜索服务、运营自有检索层，或在其云环境内使用托管服务。每种选择都会改变所涉及的供应商、凭据、日志和故障点数量。

AWS 正在将 AgentCore Gateway 定位为控制点。网关是一种中介层，在应用身份验证和目标访问规则的同时，向 AI 客户端提供工具。它让 Claude Desktop 可以调用搜索，而无需在桌面端配置中放置搜索 API 密钥。

网关还将面向客户端的身份流程，与用于调用托管目标的权限分离开来。Claude Desktop 向网关提供与用户关联的令牌；随后，网关通过拥有所需权限的 AWS 服务角色调用 Web Search。

这一划分减少了后端凭据的直接暴露，也为管理员提供了检查访问和应用策略的位置。不过，它并不会自动判断每个查询是否恰当，也不会决定每位用户是否都应获得相同的搜索能力。

这一设计适合已依赖 AWS IAM Identity Center 管理员工访问的组织。它们可以将应用分配给获批准的用户或群组，而不是新建独立身份目录。既有的离职管理和访问审查流程也可随之覆盖搜索连接。

这正是该架构带来的主要压力。使用外部搜索 API 的团队需要证明增加一个凭据存储和一个用户查询处理方的合理性。运营自定义检索栈的团队则需证明其工程和监控负担的合理性。AWS 提供了一条整合这些问题的路径，但仅适用于愿意接受其云边界和部署模式的组织。

这种转变也会影响知识工作流。搜索提供当前的公开信息，而诸如知识融合之类的系统可将公开发现与用户保留的内部上下文连接起来。关键区别在于：检索组织外部发生了什么变化，与回忆组织已知内容，是两回事。

AgentCore 以身份链替代 API 密钥

其核心机制以可追踪的用户认证、令牌签发、网关验证和 AWS 授权搜索流程，取代松散的共享凭据。

该流程始于 AWS IAM Identity Center，它通过组织的单点登录流程对员工进行身份验证。在已发布的设计中，Identity Center 充当 SAML 身份提供商。SAML 是一种用于在身份提供商与应用之间传递认证断言的标准。

Amazon Cognito 位于 SAML 登录与 AgentCore Gateway 之间。Cognito 对 Identity Center 用户进行联合身份认证，完成 OAuth 2.0 授权码流程，并签发 JSON Web Token。JWT 是一种包含可由接收服务验证声明的已签名令牌。

Claude Desktop 通过已配置的客户端 ID 和客户端密钥启动授权流程。回调会返回至端口 53280 上的 localhost 地址。用户登录后，Claude Desktop 将收到访问网关所需的令牌。

AgentCore Gateway 会在每一次请求中验证该令牌。它会检查配置的 OpenID Connect 发现信息和允许的客户端标识符，然后才接受调用。AWS 的入站授权指南还支持受众、作用域和必需的自定义声明，以实现更细粒度的验证。

这种细粒度控制非常重要。有效的组织身份并不必然意味着拥有使用所有 AI 工具的权限。管理员可根据身份设计，通过已分配群组、客户端限制、作用域或声明来收窄访问范围。

认证完成后，网关会通过 MCP 公开托管的 Web Search 连接器。Claude Desktop 使用该协议的 tools/list 操作发现可用工具。当 Claude 判断某个提示需要当前信息时，便会通过网关调用该工具。

该演练为网关的执行角色配置了调用 AWS Web Search 资源的权限。这属于出站授权，即网关在验证入站用户请求后，再向目标进行身份验证。用户不会获得底层 AWS 角色凭据。

AWS 在其网关概念中记录了其他多种授权模式，包括基于 IAM 的入站访问和卸载式授权。Claude Desktop 模式使用自定义 JWT 授权，因为桌面客户端需要兼容 OAuth 的用户流程，而不是直接进行 AWS 请求签名。

其结果比将共享搜索密钥放入配置文件更具结构性。每个请求都从经过认证的客户端进入，并抵达由 AWS 角色授权的目标。组织可在不重新设计整个接口的情况下调整任一端。

但这种结构也引入了更多组件。Identity Center 必须包含正确的用户和群组；其 SAML 应用必须正确映射属性。Cognito 需要用户池、身份提供商、应用客户端、域名、回调地址和 OAuth 配置。AgentCore 则需要网关、授权器、角色、策略和连接器目标。

这条链中的任何配置错误，都可能在用户看来表现为笼统的搜索故障。过期令牌、错误受众、不匹配的回调、无效客户端、缺少网关权限或目标不可用，都可能中断同一项可见操作。

这正是为什么在 AWS 模式中，安全的 Claude 网页搜索并非一个勾选框即可启用的功能。其价值来自明确的控制，而明确控制也带来运营工作。企业以维护这些边界之间身份关系的成本，换取了更清晰的边界。

托管搜索对定制检索栈形成压力

AgentCore 最有力的论点并不是 Amazon 发明了网页搜索，而是托管 MCP 端点能够一次性消除多个集成层。

传统实现通常从外部搜索 API 开始。开发者需要配置凭据、构建封装器、定义工具架构、解析响应、筛选有用段落，并将结果提供给 AI 客户端。他们还必须管理配额、错误、遥测数据以及供应商特定的响应格式。

自定义索引会带来更多责任。团队需要处理爬取、存储、排序、时效性检查、内容提取，以及对抗恶意页面。他们还必须决定如何遵守网站限制，以及如何移除过时或低质量的文档。

AgentCore 将其中大量工作整合为一个托管目标。AWS 负责运营索引和检索服务。Gateway 通过 MCP 提供该目标，而服务角色负责处理对外访问。Claude Desktop 提供客户端体验，并在需要时调用工具。

这种安排对三类替代方案形成压力。

首先，第三方搜索 API 必须在覆盖范围、排序质量、专业内容和可移植性方面展开竞争。它们更简单的部署方式仍然具有吸引力，尤其是对 AWS 生态之外的团队而言。然而，引入额外供应商也意味着新增一层数据处理关系和一个凭据边界。

其次，自托管搜索系统必须证明，其可定制性足以弥补维护成本。专用语料库、私有数据源或领域特定的排序模型，都可能使自定义检索变得值得。对于通用公共网络查询而言，重新构建标准化基础设施的理由则较弱。

第三，AI 应用内置的原生搜索功能必须满足企业治理要求。一个便捷、面向消费者的搜索开关，无法回答组织身份、区域选择、访问分配或云级审计能力等问题。

Anthropic 的连接器指南补充了一个重要的网络细节。远程 MCP 连接源自 Anthropic 的云基础设施，而非用户的电脑。因此，远程服务器需要接受来自相关 Anthropic 网络范围的流量。

这一细节使“整个交互都保留在一个私有网络内”之类的简单说法变得复杂。AWS 搜索目标和索引可以留在 AWS 基础设施内，但客户端到网关的连接仍会从 Anthropic 服务跨越至 AWS 端点。企业在描述 AWS 边界时，必须精确定义所指的是哪一段。

本地 MCP 服务器的运作方式不同，因为 Claude Desktop 会从本地机器访问它们。但本地进程无法提供 AWS 所描述的那种集中管理的远程网关。选择取决于部署覆盖范围、集中控制和网络暴露，而非一种放之四海皆准的安全排名。

对于已经采用 AWS 身份和运营体系的组织，AgentCore 的优势最为明显。它们可以复用账户结构、角色、监控实践和管理归属。采用其他身份平台的公司仍可使用这一模式，因为 AWS 表示 Cognito 可与兼容 SAML 或 OIDC 的提供商联合。

对于规模较小的团队，同样的架构可能显得过于复杂。用户池、联合桥接、应用客户端、网关角色和网络策略，会在第一次搜索成功前就带来额外负担。托管搜索服务消除了检索基础设施，但并未消除企业身份架构。

这正是竞争分界线。AgentCore 更适合重视策略一致性胜过最短部署时间的组织。在可移植性和快速部署比统一 AWS 控制平面更重要的场景中，外部 API 和更简单的连接器仍有空间。

安全的 Claude Web Search 仍需要威胁模型

JWT 验证和 AWS 托管检索降低了部分风险，但它们并不能让网页内容变得可信，也无法消除管理层面的失效模式。

第一个不确定性涉及“所有查询都留在 AWS 边界内”这一表述。AWS 表示，搜索流量会保留在其基础设施中，并且不需要第三方搜索密钥。这在搜索层面确实显著降低了供应商暴露。

然而，Claude Desktop 仍是发起客户端。对于远程 MCP 连接器，Anthropic 表示其云基础设施会连接到远程服务器。安全审查人员应绘制完整请求路径，包括 Claude 服务、公共网关端点、AWS Region、Web Search 目标、日志系统和返回内容。

第二个不确定性是令牌设计。AgentCore 会验证 JWT，但保护效果取决于所配置的声明。过于宽泛的客户端注册或薄弱的组分配，可能授予超出预期的访问权限。有效令牌证明的是身份和声明集被接受，而非每个请求本身都合理。

AWS 文档指出，部分 JWT 声明可能会出现在 CloudTrail 记录中。它建议避免在 subject 字段中包含个人身份信息，并建议使用不透明标识符。这一警告值得关注，因为当身份声明包含不必要的个人数据时，可审计性可能演变为隐私问题。

第三个不确定性是授权深度。该演练将用户或群组分配给 Identity Center 应用，并将网关限制为允许的客户端。企业可能还需要针对部门、数据分类、批准域名或敏感查询类别增加控制。

域名允许列表可以降低接触不可信来源的风险，但无法保证事实准确性。获批网站同样可能发布过时、被篡改或错误的信息。搜索结果应作为模型推理的证据，而非不容质疑的事实。

提示注入带来了另一项担忧。检索到的页面可能包含意图影响 AI 代理的文本，包括与用户目标冲突的指令。语义提取能够移除部分无关页面材料，但无法确保每一段提取内容都安全。

风险取决于 Claude 在搜索后能够执行什么操作。只读研究助手的影响范围，比能够发送消息、修改记录或调用管理工具的代理更窄。组织应评估组合工具权限，而不是孤立地批准 Web Search。

工具批准对话框提供了一项用户层面的保障。AWS 的演练展示了 Claude 如何呈现拟议查询，并提供拒绝、仅允许一次或在当前任务中允许的选项。这种可见性可以帮助用户发现意外搜索。

批准并不是完整的策略系统。用户可能在未意识到风险的情况下批准有害请求，而频繁提示也可能导致习惯性接受。集中限制、有限范围和谨慎的工具组合仍然必不可少。

第四个不确定性是可观测性。团队需要知道是否能够还原：哪个用户发起了搜索、哪个查询到达目标、返回了哪些结果，以及哪些响应采用了这些结果。他们还需要制定保留策略，避免收集超出必要范围的敏感材料。

第五个不确定性是可用性。用户体验依赖于 Identity Center、Cognito、AgentCore Gateway、Web Search、Claude 的连接器服务和区域连接性。任一组件故障，都可能导致用户失去当前信息访问能力，而基础模型仍会基于较旧知识继续作答。

这带来一种微妙的产品风险。用户未必总能区分基于最新搜索结果的回答，与未成功搜索时生成的回答。界面和运营监控应让工具故障可见，而非悄然降级为过时响应。

因此，AWS 的架构是安全性的起点，而不是一套完成的威胁模型。它减少了凭据蔓延，并将搜索目标纳入 AWS 控制范围。组织仍必须定义数据边界、访问规则、日志实践、故障行为，以及针对恶意检索内容的保护措施。

三个信号将揭示该架构能否站得住脚

下一项考验是运营层面的采用情况，而不是演示能否返回一个当前答案。

第一个信号是企业如何将授权范围收窄到基础应用分配之外。强健的部署将采用限定范围的客户端、受限声明、审慎分配的群组和有限的网关权限。薄弱的部署则会将任何已认证员工都视为同样有权使用相同搜索能力。

如果 AWS 发布更多围绕群组声明、最小权限角色和查询级策略的生产模式，托管路径将更容易得到辩护。如果客户必须独立设计这些控制措施，定制化安全工作仍将是采用过程的重要部分。

第二个信号是 AWS 和 Anthropic 如何澄清端到端网络边界。搜索索引、结果处理和目标调用可以保留在 AWS 内，但远程 MCP 请求始于 Anthropic 云。企业买家将需要关于端点、允许的网络范围、区域行为、遥测数据和内容处理方式的精确文档。

更清晰的边界文档将强化 AWS 关于该模式避免不必要第三方搜索暴露的主张。模糊的表述则会削弱这一主张，尤其是对必须记录每个处理方和网络跳转的受监管买家而言。

第三个信号是真实工作负载下的检索质量。覆盖数百亿文档的索引听起来范围广泛，但用户将根据时效性、相关性、引用质量、延迟和一致性作出判断。当团队搜索文档、法规、产品更新或快速变化的新闻时，域名过滤和发布日期控制必须以可预测的方式运行。

这一信号将决定托管搜索是取代外部供应商，还是仅仅加入其中。企业常会保留多条检索路径：当某项服务在通用查询中表现良好，却在专业来源上表现不佳时尤其如此。

该架构还将面临可用性考验。管理员必须完成联合、令牌、网关、角色和连接器配置。用户必须进行身份验证并理解工具批准机制。支持团队必须跨多个服务诊断故障，而不能让每起事件都演变为云身份调查。

对开发者而言，眼前价值在于由托管索引支持的标准 MCP 接口。对企业买家而言，价值在于将身份和搜索控制整合到 AWS 中。对知识工作者而言，价值在于能从同一 Claude Desktop 界面更简单地访问当前公共信息。

这些好处都不能免除验证重要答案的必要。搜索依据改善了获取最新证据的能力，但不会把网络变成可信数据库。用户应检查引用来源、比较相互冲突的说法，并认识到结果何时依赖于不断变化的页面。

决定性问题在于，一个组织是否足够需要当前答案，以至于愿意负责任地运营这条身份链。已经使用 Bedrock 和 IAM Identity Center 的团队，有充分理由测试 Claude Desktop 网页搜索。在接入影响更高的工具之前，他们应从狭窄的用户群体、有限权限、明确域名、可观测故障和只读工作流开始。