增强模型能力
模型各有能力短板：有的不识别图片，有的执行阶段性价比不够，有的在单一视角下审查代码容易漏判。短板触发时上游往往直接 400 拒收、客户端整段对话卡死；或者默认模型又贵又不够强、单模型产出可信度有限。网关可以在不改客户端、不换接入模型名的前提下，用请求体规则（Request Payload Rules）、变换脚本与多模型编排把流量改投给更合适的模型（组合），把短板「补」掉。
场景与对策
| 场景 | 症状 / 目标 | 对策 |
|---|---|---|
| 模型无法识别图片 | 带图请求被上游 400 拒收 | switch-route 规则检测图片，改投多模态模型（场景一） |
| 只想消除报错、不在乎图片内容 | 同上 | filter-content-types 剥掉图片块，原模型照常服务。见 把含图片的请求路由到视觉模型 的「备选方案」 |
| Claude Code 执行模型要更强/更便宜 | opusplan 默认执行阶段走 sonnet；或 opus 跑到底成本高 | before 槽脚本识别 plan 模式标记，执行阶段 useModel 切到 zenlayer/qwen3.8-max / kimi-k3（场景二） |
| PR 代码审查要更高正确率 | 单模型审查有盲区，误报漏报难消除 | GitHub Actions 多模型并行审查 + 共识汇总，经网关统一接入（场景三） |
场景一：无法识图的模型，带图请求切多模态模型
症状：文本模型（如 glm-5.2）收到带图请求被上游 400 拒收；coding agent 重放整段历史时，一旦历史里出现过图片，之后轮轮报错。
方案：给原文本模型挂一条 switch-route 请求体规则，在协议翻译前按客户端形状检测图片，命中即改投多模态模型（如 zenlayer/qwen3.8-max）；不含图的请求照常走原模型。判定只做结构检查、不读图片二进制，大请求体不整段进内存。
关键坑：图片在各客户端协议里的位置不同——Anthropic 客户端可能出现在两个深度（消息顶层内容块、tool_result 嵌套内容块，缺一不可），OpenAI、DashScope（input.messages.*.content.*.image）各有自己的路径。漏配任一客户端形状，带图请求照样打到文本模型继续 400。
完整条件路径表（含控制台截图）、JSON 形态、LB 场景规则挂哪、验证步骤，见 把含图片的请求路由到视觉模型。只想消除报错、不在乎图片内容时，用该页「备选方案」的 filter-content-types 剥图。
场景二：替换 Claude Code 的执行模型（agent 模式）
症状 / 目标：Claude Code 的 opusplan 模式 plan 阶段走强模型、agent（执行）阶段默认 sonnet。执行阶段是 token 大头——想让执行阶段更强或更便宜（切 zenlayer/qwen3.8-max / kimi-k3），或 opus 跑到底成本太高。
方案：Claude Code 会在对话里注入 plan 模式标记（进入 Plan mode is active、退出 Exited Plan Mode，都在 <system-reminder> 里）。在入口模型的 before 槽挂变换脚本，从末尾消息向前扫描取最后一次出现的标记判定状态：plan 态留在原模型，非 plan 态 context.useModel 切到执行模型。opus 跑到底的会话从不进 plan 模式、无标记，脚本兜底把全部请求切到执行模型。
关键坑：① 判定必须是「取末次标记」而非「是否包含标记」——进入标记永久留在历史里，包含式判断会永远误判为 plan 态；② 必须挂 before 槽（after 槽读不到客户端注入的标记位置，且 useModel 只能同协议）；③ EXEC_MODEL 必须是网关里真实存在的模型名（用完整名称，可能带上游前缀），否则切过去 404 model_not_found；④ 脚本 OOM 会按 log-and-continue 静默兜底，表现为「没切换」。
完整脚本、标记判定原理、为什么必须挂 before 槽（含控制台截图）、OOM 与 SCRIPT_MEMORY_LIMIT_MB、排障 FAQ，见 用脚本按 Claude Code plan 模式切换模型。
场景三：多模型共识的 PR 自动代码审查
症状 / 目标：单模型审查有视角盲区，误报漏报难消除。让 2–3 个模型并行独立审查同一个 PR，再合并去重、标注共识置信度，正确率明显更高。
方案：GitHub Actions 触发审查 job，经网关调用审查模型——ANTHROPIC_BASE_URL 指向网关，网关做协议互译。GitHub 的 claude-code-action 只说 Anthropic 协议，靠网关互通让 qwen3.8-max、kimi-k3 这类非 Anthropic 模型也能进审查队列；多模型并行审查后汇总去重、标注共识，发布一条 PR 评论。一把网关访问密钥统一承接所有审查流量，凭证集中、成本可计量。
为什么经网关（而非直连上游）：一把钥匙开多家的门——协议互译是多模型共识的前提，直连只能审 Anthropic 系模型；审查流量全过网关、成本可计量；专用密钥限流、吊销即停，失控时不影响业务流量。
完整 5 步配置（网关配审查模型、为 CI 签发专用密钥【含控制台截图】、GitHub Secrets/Variables、单/多模型 workflow 两种接法、验证与排障），见 用 GitHub Actions 做多模型代码审查。
常见问题
Q：switch-route 会不会拖慢请求？ 不会。它在协议翻译前按结构判定，不读二进制内容字节，大请求体仍走磁盘暂存，不占内存。
Q：规则挂在负载均衡器（LB）上可以吗？ 规则要挂在客户端请求实际命中的那条模型配置上。客户端模型名是 LB 时，挂在 LB 背后的节点模型上——LB 解析出的节点会带着自己的请求体规则执行。
Q：改投后账单怎么算？ 按目标模型计价（场景一是多模态目标模型，场景二是 EXEC_MODEL，场景三按各审查模型分别计价、网关统一汇总），统计与账单里体现为目标模型的用量。见 定价与计费。
Q：场景二退出 plan 模式后没切走 / 脚本看起来没生效？ 多半是判定写成了「是否包含标记」（进入标记永久留在历史里，会永远误判为 plan 态），或脚本挂在了 after 槽，或脚本 OOM 被静默兜底。逐项排查见 用脚本按 Claude Code plan 模式切换模型 的常见问题。
Q：场景三每个 PR 都审，评论会刷屏吗？ 不会。每轮审查开始前，action 会把该 PR 上历史 Claude 评论自动折叠为 OUTDATED，PR 时间线里只留最新一轮的展开评论；超大 PR（超 max_lines）默认直接跳过。详见 用 GitHub Actions 做多模型代码审查。
下一步：降低调用成本 看降本；请求改写与路由：怎么选 看选型边界；上游与模型字段 看 request_payload 全部模式。