Feature Request: 为 Anthropic 请求增加可配置的 Header / Body 重写规则

[Brisbanehuang]

Feature Request: 为 Anthropic 请求增加可配置的 Header / Body 重写规则

背景

当前在接入部分 Anthropic 兼容上游时，会遇到这样一类兼容性问题：

• 某些上游要求请求必须携带特定的 anthropic-beta header 组合
• 某些上游对不同模型的 thinking 参数约束不同
• 部分客户端不会主动传递这些 header 或参数
• 当前网关虽然有 Beta 策略、自动透传、请求整流器，但它们更偏向：
  • 放行 / 过滤 / 拦截 beta token
  • 尽量保留原始请求
  • 在报错后做有限的自动修正重试

对于“按账号 / 按模型 / 按接口路径，在转发前主动覆写请求头和请求体字段”的场景，目前还缺少一个统一的配置入口。

典型需求

希望支持下面这类规则化能力：

1. 对某类 Anthropic 账号的请求，统一追加或覆盖特定请求头
2. 按模型匹配规则，强制覆写 thinking.type / thinking.budget_tokens
3. 对 /v1/messages 和 /v1/messages/count_tokens 分别设置不同规则
4. 对不同账号类型分别生效，例如：
   • 仅 API Key
   • 仅 OAuth
   • 仅 Bedrock
5. 在不改客户端的前提下，由网关完成上游兼容性适配

当前能力与缺口

现有能力可以覆盖一部分问题：

• 自动透传（仅替换认证）
• Beta 策略
• Thinking 签名整流
• Thinking Budget 整流

但仍存在以下缺口：

• Beta 策略 只能做 透传 / 过滤 / 拦截，不能直接“设置 header 值”
• 请求整流器 主要在收到上游错误后再重试，不是请求前按规则主动改写
• 不能按模型精细化配置默认 thinking 参数
• 不能像通用网关过滤器那样，对特定路径 / 特定账号类型统一做 header/body 覆写

建议新增能力

建议增加一个通用的“Anthropic 请求重写规则”能力，优先支持：

• Header 重写
  • set / append / remove
• Body 字段重写
  • set / merge / remove
• 匹配条件
  • 账号类型
  • 分组或账号
  • 接口路径
  • 模型模式匹配
• 生效顺序
  • 请求进入上游前执行
  • 在计费 / 并发 / 审计之前或之后的执行时机应明确

一个可行的数据结构示例

{
  "enabled": true,
  "rules": [
    {
      "name": "anthropic-default-beta-and-thinking",
      "scope": {
        "platform": "anthropic",
        "account_type": "apikey"
      },
      "match": {
        "paths": ["/v1/messages", "/v1/messages/count_tokens"],
        "models": ["claude-haiku-*"]
      },
      "headers": {
        "set": {
          "anthropic-beta": "context-1m-2025-08-07,interleaved-thinking-2025-05-14"
        }
      },
      "body": {
        "merge": {
          "thinking": {
            "type": "enabled",
            "budget_tokens": 1024
          }
        }
      }
    }
  ]
}

期望收益

• 减少为了兼容特殊上游而修改客户端
• 减少通过硬编码分支处理个别上游差异
• 降低用户通过反复试错定位 header / thinking 兼容问题的成本
• 让 Anthropic 兼容链路具备更强的可运营性和可扩展性

兼容性建议

• 默认关闭，避免影响现有行为
• 仅在命中规则时生效
• 应保留现有 Beta 策略 与 请求整流器
• 新规则层建议定位为“请求前改写”，整流器继续负责“错误后补救”

补充说明

这个需求并不是针对某一个特定上游，而是面向一类通用兼容场景：

• 上游对 anthropic-beta 有额外要求
• 上游对 thinking 参数有额外约束
• 客户端本身无法稳定传递这些差异化配置

如果网关能原生提供这类规则化能力，会明显降低接入和维护成本。