LiteLLM + Amazon Bedrock AgentCore WebSearch 为 Agent 构建托管联网搜索（扩展篇）
内容提要
本文介绍如何通过 LiteLLM MCP 网关接入 Amazon Bedrock AgentCore WebSearch，为模型和 Agent 提供托管联网搜索。相比自部署 SearXNG 方案，该方案支持 OpenAI 格式的服务端搜索循环、流式输出和原生结构化引用，搜索源免运维，且适用于任意 OpenAI 兼容模型。Claude Code 等客户端可通过 /mcp 端点以 Bearer 认证接入，SigV4 由网关代签。
延伸解读
从自部署到托管：搜索源运维负担的转移
上篇方案需自维护 SearXNG，虽无 API 费用但需承担部署、更新与可用性责任。本篇改用 Amazon Bedrock AgentCore WebSearch，搜索源由 AWS 托管，与 IAM 权限和计费体系一体化，免去运维。代价是按查询计费，成本随调用量线性增长。对成本极度敏感且愿意自维护的团队，上篇方案仍成立；需要免运维与托管集成的场景，本篇更合适。
结构化引用如何改变客户端集成方式
上篇的引用依赖提示词工程，模型在正文中生成编号，客户端难以可靠解析。本篇响应在 provider_specific_fields 中原生携带 mcp_tool_calls 与 mcp_call_results，包含每次搜索的查询词及每条结果的标题、URL、发布时间和摘要。客户端可据此直接构建引用 UI，无需解析模型正文。提示词内嵌引用的方式仍兼容，可叠加使用。
Agent 客户端接入：为何需要网关代签 SigV4
AgentCore Gateway 入站认证为 AWS SigV4，而 Claude Code 等 MCP 客户端通常只支持静态 header，无法完成逐请求签名。LiteLLM 将管理的 MCP servers 聚合为对外 /mcp 端点，认证转换为 Bearer key，SigV4 由网关代签，AWS 凭证不出服务端。客户端只需注册该端点即可获得搜索工具，由其自身工具循环驱动调用，解决了 Agent 直连 AgentCore 的认证痛点。
两条路线并非互斥：按场景选择
上篇方案在成本敏感、愿意自维护 SearXNG 的场景依然可用；本篇在需要托管搜索、结构化引用、流式输出与 Agent 生态接入时更优。两者可共存，且本篇支持任意 OpenAI 兼容模型，包括自托管 sglang/vLLM 私有模型，与 Bedrock 托管模型可在同一配置中共存。选择时应权衡运维投入、计费模式与客户端形态。
Q&A
LiteLLM + Amazon Bedrock AgentCore WebSearch 方案相比自部署 SearXNG 方案有哪些改进？
该方案在五个方面改进了上篇方案：1) 原生结构化引用，响应中携带每次搜索的查询词与结果明细（URL/标题/发布时间）；2) 支持流式（SSE）输出；3) 主路径为 /chat/completions，OpenAI SDK 可直接使用；4) 适用于任意 OpenAI 兼容模型（含自托管 sglang/vLLM 私有模型）；5) 搜索源为 AWS 托管，免运维，与 IAM 权限/计费体系一体化。
如何配置 LiteLLM 以接入 Amazon Bedrock AgentCore WebSearch？
在 LiteLLM 的 config.yaml 中，添加 mcp_servers 配置：agentcore_search 的 url 为 AgentCore Gateway 的 MCP 端点，transport 设为 http，auth_type 设为 aws_sigv4，aws_region_name 指定区域（如 us-east-1），aws_service_name 默认为 bedrock-agentcore。同时配置 model_list 指向任意 OpenAI 兼容后端，并设置 general_settings 中的 master_key。启动 LiteLLM 容器时挂载 config.yaml 和 .env 文件（包含 AWS 凭证和上游 API 密钥）。
如何让 Claude Code 通过 LiteLLM 使用 AgentCore WebSearch 作为搜索工具？
首先将 LiteLLM 作为模型后端：设置环境变量 ANTHROPIC_BASE_URL 为 LiteLLM 地址，ANTHROPIC_API_KEY 为 LiteLLM 密钥，ANTHROPIC_MODEL 为模型名。然后添加 MCP 搜索工具：运行 claude mcp add --transport http websearch http://<gateway-host>:4000/mcp --header "Authorization: Bearer <litellm-key>"。Claude Code 即获得 web-search-tool___WebSearch 工具，由其自身循环驱动调用，SigV4 签名由网关代签，AWS 凭证不出服务端。
LiteLLM 网关如何实现服务端自动执行搜索并返回最终答案？
在 /chat/completions 请求中携带 tools 参数，包含 {"type":"mcp", "server_url":"litellm_proxy", "require_approval":"never"}。LiteLLM 收到模型返回的 tool_calls 后，自动以 SigV4 调用 AgentCore 搜索，将结果回喂模型，循环直至模型产出终答。客户端一次请求即可得到完整回答。不带 type:"mcp" 工具的请求则为普通透传。
该方案如何提供结构化引用？
响应的 provider_specific_fields 中原生携带完整搜索轨迹，包括 mcp_tool_calls（每次搜索的查询词和参数）和 mcp_call_results（每条结果的标题、URL、发布时间、摘要）。客户端可据此构建引用 UI，无需解析模型正文。提示词内嵌引用的方式仍然兼容，可叠加使用。
该方案对模型和部署环境有什么要求？
模型方面：任意 OpenAI 兼容后端均可，包括 Bedrock 经 LiteLLM 或自托管 sglang/vLLM 私有模型。部署方面：LiteLLM 可运行在任意能访问 AgentCore 区域端点的环境，需使用包含 MCP 网关和 aws_sigv4 认证支持的 Docker 镜像（如 ghcr.io/berriai/litellm:main-stable）。AgentCore Gateway 和 WebSearch 目前在海外区域提供（如 us-east-1）。
