亚马逊AWS官方博客
·
用 LiteLLM WebSearch Interception 集成 AWS 托管的 Amazon Bedrock AgentCore Web Search 能力
内容提要
本文介绍了如何将LiteLLM的Web搜索后端从自建的SearXNG替换为AWS托管的Amazon Bedrock AgentCore Web Search。该方案无需修改客户端，利用LiteLLM的websearch拦截机制，自动执行搜索并返回结果。通过重写核心方法实现与AgentCore的集成，减轻了自维护搜索引擎的负担，并支持按查询计费。文中提供了详细的部署和验证步骤。
关键要点
-
LiteLLM的websearch拦截机制可以将搜索后端从自建的SearXNG替换为AWS托管的Amazon Bedrock AgentCore Web Search。
-
该方案无需修改客户端，自动执行搜索并返回结果，减轻了自维护搜索引擎的负担。
-
通过重写核心方法实现与AgentCore的集成，支持按查询计费。
-
实现方案是继承WebSearchInterceptionLogger并重写_execute_search方法，调用AgentCore的MCP端点。
-
AgentCore Web Search的优势包括免于维护搜索引擎、查询在AWS基础设施内服务、结果附带来源引用。
-
部署步骤包括创建Gateway、配置IAM角色、添加Web Search连接器等。
-
验证步骤包括链路验证和生产切换验证，确保搜索功能正常工作。
-
进阶用法允许将AgentCore Web Search暴露为MCP server，支持无AWS凭证的客户端调用。
延伸解读
集成的优势与局限
通过将LiteLLM的搜索后端替换为Amazon Bedrock AgentCore，用户可以享受AWS托管的搜索服务，免去自建搜索引擎的维护负担。然而，该方案仅支持us-east-1区域，并且查询结果的最大字符数限制为200，这可能影响某些应用场景的灵活性。
部署与验证的关键步骤
在部署过程中，确保LiteLLM的配置文件与自定义回调模块位于同一目录下，以避免导入错误。此外，验证链路时需注意IAM权限的设置，确保Pod的IRSA角色具备调用Gateway的权限，以避免403错误。
按查询计费的注意事项
使用AgentCore Web Search时，按查询计费的模式可能导致成本不可控。建议用户在配置MCP访问组时，限制仅特定的virtual key可调用该服务，以有效控制费用并避免不必要的支出。
延伸问答
如何将LiteLLM的搜索后端替换为Amazon Bedrock AgentCore Web Search？
可以通过LiteLLM的websearch拦截机制，将搜索后端从自建的SearXNG替换为AWS托管的Amazon Bedrock AgentCore Web Search，具体方法是继承WebSearchInterceptionLogger并重写_execute_search方法。
使用Amazon Bedrock AgentCore Web Search的优势是什么？
使用Amazon Bedrock AgentCore Web Search的优势包括免于维护搜索引擎、搜索查询在AWS基础设施内服务、结果附带来源引用以及按查询计费。
部署LiteLLM与Amazon Bedrock AgentCore的步骤有哪些？
部署步骤包括创建Gateway、配置IAM角色、添加Web Search连接器等，确保所有配置正确后进行验证。
如何验证LiteLLM与AgentCore的集成是否成功？
可以通过链路验证和生产切换验证，确保从客户端发送的请求能够正常返回搜索结果，并检查CloudWatch中的调用计数。
LiteLLM的websearch拦截机制是如何工作的？
LiteLLM的websearch拦截机制在客户端发送请求时拦截模型产生的web_search工具调用，代为执行搜索并将结果拼接回上下文，整个过程对客户端透明。
AgentCore Web Search的查询限制是什么？
AgentCore Web Search的查询限制为每次查询最多200字符，返回结果的数量maxResults取值为1到25，默认值为10。
