Higress项目中AWS Bedrock模型调用问题的技术解析

问题背景

在Higress项目中，用户尝试通过AI-proxy功能调用AWS Bedrock服务时遇到了模型响应内容为空的问题。具体表现为：当使用ARN格式的模型标识符（如"arn:aws:bedrock:us-west-2:xxxxxxxxxxxxxxxxxx"）调用Claude Sonnet 3.7模型时，虽然API返回了200状态码，但响应体中的content字段为空。

问题现象分析

用户最初提交的请求体格式如下：

{
  "model": "arn:aws:bedrock:us-west-2:xxxxxxxxxxxxxxxxxx",
  "messages": [{
      "role": "user",
      "content": "今天是2024年07月29日。用json输出最近三天的日期，包含字段： today, next_day, day_after_tomorrow."
    }]
}

返回的响应体为：

{
  "id":"d6afdf1c-bc70-4a21-9d02-448f9bcef24a",
  "choices":[{
    "index":0,
    "message":{
      "content":""
    }
  }],
  "created":1747205050,
  "model":"arn:aws:bedrock:us-west-2:xxxxxxxxxxxxxxxxxx",
  "object":"chat.completion",
  "usage":{}
}

技术排查过程

1. 初步验证

首先需要确认的是，相同的AK/SK通过AWS官方SDK（boto3）可以正常调用Bedrock服务，这排除了IAM权限问题的可能性。

2. 模型标识符分析

AWS Bedrock支持两种模型标识方式：

• 基础模型标识符：如"anthropic.claude-3-7-sonnet-20250219-v1:0"
• 应用推断配置ARN：如"arn:aws:bedrock:us-west-2:xxxxxxxxxxxxxxxxxx"

3. URL编码问题

深入分析发现，问题的核心在于模型ARN中的特殊字符处理。AWS Bedrock API要求URL中的保留字符必须按照RFC 3986规范进行转义。特别是ARN中的冒号(:)必须编码为%3A。

4. 解决方案

最终解决方案包含两个关键步骤：

1. 在传入model参数前，先对ARN进行URL编码，将"arn:aws:bedrock:us-west-2:xxxxxxxxxxxxxxxxxx"转换为"arn%3Aaws%3Abedrock%3Aus-west-2%3Axxxxxxxxxxxxxxxxxx"
2. 在Higress的bedrock.go文件中的urlEncode函数中，增加对百分号(%)的二次编码处理，将其转换为%25

技术原理

URL编码规范

根据RFC 3986，URL中的保留字符包括：

• 通用保留字符：:/?#[]@
• 子组件保留字符：!$&'()*+,;=

在AWS Bedrock API调用中，模型标识符作为URL路径的一部分，其中的冒号(:)必须进行编码，否则会导致API端点无法正确解析请求。

双重编码问题

当对已编码的字符串进行二次编码时，其中的百分号(%)本身也需要编码。这就是为什么需要在urlEncode函数中增加对%转%25的处理逻辑。

最佳实践建议

1. 模型标识符处理：

   • 对于基础模型标识符，可以直接使用
   • 对于ARN格式的模型标识符，必须进行URL编码

2. 错误排查步骤：

   • 首先验证IAM权限是否配置正确
   • 检查模型标识符格式是否符合AWS文档要求
   • 启用调试日志，分析请求处理流程
   • 对比官方SDK和Higress实现的差异

3. 代码实现建议：

   • 在Higress的Bedrock插件中增加模型标识符的自动编码逻辑
   • 提供更明确的错误提示信息，帮助用户快速定位问题

总结

通过这个案例，我们了解到在集成AWS Bedrock服务时，正确处理URL编码是确保API调用成功的关键因素之一。特别是当使用ARN格式的模型标识符时，必须严格遵守RFC 3986规范对保留字符进行编码。Higress项目可以通过增强错误处理和自动编码逻辑来提升用户体验，减少类似问题的发生。