Higress项目中AI代理与请求拦截插件的协同问题分析与解决方案

在微服务架构中，API网关作为流量入口，其插件系统的协同工作能力至关重要。本文以Higress项目中的AI代理插件（ai-proxy）与请求拦截插件（request-block）的交互问题为例，深入分析问题本质并提供解决方案。

问题现象

当同时启用AI代理插件和请求拦截插件时，系统出现以下异常行为：

1. 拦截返回403状态码时，响应符合预期
2. 拦截返回200状态码时，响应内容被AI代理插件修改
3. 部分情况下会出现连接异常终止

技术背景

Higress的插件系统基于Wasm技术实现，具有以下特点：

• 插件执行分为不同阶段（如AUTHZ阶段）
• 每个插件可以设置优先级数值
• 插件可以处理请求和响应的各个生命周期

问题根因分析

通过深入分析，发现问题产生于以下技术细节：

1. 插件执行顺序问题
   请求拦截插件配置在AUTHZ阶段（优先级320），而AI代理插件默认优先级为100。虽然数值上请求拦截更高，但阶段不同导致实际执行顺序不符合预期。

2. 响应处理机制缺陷
   AI代理插件会对所有经过的响应进行协议转换，即使该响应是由其他插件生成的拦截响应。当拦截返回200状态码时，AI代理会错误地尝试将其转换为通义千问协议格式。

3. 状态码处理不完善
   系统未正确区分"直接响应"（如拦截响应）和"上游响应"，导致插件处理逻辑混乱。

解决方案

基于以上分析，提出以下改进方案：

1. 插件执行顺序优化
   调整插件配置，确保请求拦截插件在更早的阶段执行，避免响应被后续插件误处理。

2. 响应来源判断机制
   在AI代理插件中增加响应来源判断逻辑：

codeDetails, _ := proxywasm.GetProperty([]string{"response", "code_details"})
if codeDetails != "via_upstream" {
    // 跳过协议转换处理
}

3. 状态码处理策略

• 对于非200状态码的拦截响应，保持原有处理逻辑
• 对于200状态码的拦截响应，添加特殊标记避免后续处理

实施建议

在实际部署时，建议：

1. 明确各插件的执行阶段和优先级
2. 对拦截响应使用非200状态码（如403）
3. 如需返回200状态码，确保响应内容符合AI代理预期的协议格式
4. 定期检查插件配置，避免冲突

总结

Higress作为高性能API网关，其插件系统的协同工作需要开发者深入理解各插件的执行机制。通过本次问题分析，我们不仅解决了特定场景下的插件冲突问题，也为类似场景下的插件开发提供了最佳实践参考。未来在插件设计中，应当更加注重状态管理和执行顺序的控制，以确保系统的稳定性和可预测性。