> 原始 Markdown 孪生体（构建期从源 Markdown 生成）。渲染页：https://docs.gatellm.io/zh-CN/usecases/model-enhancement · 文档索引：https://docs.gatellm.io/zh-CN/llms.txt


# 增强模型能力

模型各有能力短板：有的不识别图片，有的执行阶段性价比不够，有的在单一视角下审查代码容易漏判。短板触发时上游往往直接 400 拒收、客户端整段对话卡死；或者默认模型又贵又不够强、单模型产出可信度有限。网关可以在**不改客户端、不换接入模型名**的前提下，用请求体规则（Request Payload Rules）、变换脚本与多模型编排把流量改投给更合适的模型（组合），把短板「补」掉。

## 场景与对策

| 场景 | 症状 / 目标 | 对策 |
|------|------------|------|
| 模型无法识别图片 | 带图请求被上游 400 拒收 | `switch-route` 规则检测图片，改投多模态模型（场景一） |
| 只想消除报错、不在乎图片内容 | 同上 | `filter-content-types` 剥掉图片块，原模型照常服务。见 [把含图片的请求路由到视觉模型](/zh-CN/howto/route-image-requests-to-vision-model.md) 的「备选方案」 |
| 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 场景规则挂哪、验证步骤，见 [把含图片的请求路由到视觉模型](/zh-CN/howto/route-image-requests-to-vision-model.md)。只想消除报错、不在乎图片内容时，用该页「备选方案」的 `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 模式切换模型](/zh-CN/howto/script-switch-model-by-plan-mode.md)。

## 场景三：多模型共识的 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 做多模型代码审查](/zh-CN/howto/github-code-review.md)。

## 常见问题

**Q：switch-route 会不会拖慢请求？**
不会。它在协议翻译前按结构判定，不读二进制内容字节，大请求体仍走磁盘暂存，不占内存。

**Q：规则挂在负载均衡器（LB）上可以吗？**
规则要挂在客户端请求实际命中的那条**模型**配置上。客户端模型名是 LB 时，挂在 LB 背后的节点模型上——LB 解析出的节点会带着自己的请求体规则执行。

**Q：改投后账单怎么算？**
按目标模型计价（场景一是多模态目标模型，场景二是 `EXEC_MODEL`，场景三按各审查模型分别计价、网关统一汇总），统计与账单里体现为目标模型的用量。见 [定价与计费](/zh-CN/howto/setup-pricing-and-billing.md)。

**Q：场景二退出 plan 模式后没切走 / 脚本看起来没生效？**
多半是判定写成了「是否包含标记」（进入标记永久留在历史里，会永远误判为 plan 态），或脚本挂在了 after 槽，或脚本 OOM 被静默兜底。逐项排查见 [用脚本按 Claude Code plan 模式切换模型](/zh-CN/howto/script-switch-model-by-plan-mode.md) 的常见问题。

**Q：场景三每个 PR 都审，评论会刷屏吗？**
不会。每轮审查开始前，action 会把该 PR 上历史 Claude 评论自动折叠为 OUTDATED，PR 时间线里只留最新一轮的展开评论；超大 PR（超 `max_lines`）默认直接跳过。详见 [用 GitHub Actions 做多模型代码审查](/zh-CN/howto/github-code-review.md)。

**下一步**：[降低调用成本](/zh-CN/usecases/cost-reduction.md) 看降本；[请求改写与路由：怎么选](/zh-CN/practices/routing-and-transform.md) 看选型边界；[上游与模型字段](/zh-CN/reference/upstreams-models-fields.md) 看 `request_payload` 全部模式。