进化:Oh My OpenAgent 配置迭代实录
上一篇讲了初始配置的搭建过程,这篇记录跑了两周之后的调整:从单供应商扩展到四层模型池、补了降级链路、踩了 GLM-4.5-air 只分析不写代码的坑。
文档包含:降级策略设计、免费模型池完整清单和分析、并发控制配置、GLM-4.5-air 替换方案的决策过程。
上一篇文章写完初始配置,跑了两周,该修的都修出来了。
从单模型到多供应商
初始配置有个问题:几乎所有 Agent 都绑在智谱 GLM 系列上,免费模型只打了几个酱油位。跑起来发现两个事——
第一,GLM-4.7-flash 和 GLM-4.5-flash 已经下线了,配置里写的白写。第二,有些 GLM 模型连通性不稳定,glm-4.7-flashx、glm-5v-turbo 直接超时连不上。一旦主模型挂了,没有靠谱的降级链路,整个 Agent 就卡死。
解决思路很简单:把模型池撑大。智谱 GLM 当主力,NVIDIA 的付费模型当备选,OpenRouter 的免费模型兜底。
现在的模型来源变成四层:
| 层 | 供应商 | 用途 |
|---|---|---|
| 1 | zhipuai-coding-plan | GLM 全系列,核心任务 |
| 2 | nvidia | 多品牌托管(Qwen、Nemotron、Devstral、DeepSeek) |
| 3 | openrouter | 只用免费模型(free 后缀) |
| 4 | opencode 内置 | 免费保底 |
降级链路:API 挂了怎么办
这是初始配置里完全缺失的。加了 runtime_fallback 配置:
| |
每个 Agent 和 Category 都配了 fallback_models 数组。主模型 400/429/503/529 错误时,自动按顺序往下切。典型的链路:
| |
实际触发过几次,主要是 429(智谱限流)。降级到 NVIDIA 的 Qwen3-Coder 之后体感上基本无感,编码质量没有断崖。
GLM-4.5-air 的坑:会分析但不动手
这是跑了两周后发现的最有意思的问题。
GLM-4.5-air 在初始配置里负责三类活:quick(小改动)、unspecified-low(低复杂度杂活)、writing(文档写作)。定位是性价比模型——快、便宜、够用。
但实际用下来发现一个固定模式:让它改代码,它会很认真地分析该改哪里、为什么要改、改了之后的影响——然后就不改了。每次都是"建议你修改 XXX"而不是直接给出修改后的代码。
重复出现太多次,不是偶发问题。
分析了一下配置,glm-4.5-air 出现在 10 个位置,其中 5 个需要写代码:
| 位置 | 角色 | 要写代码? |
|---|---|---|
sisyphus compaction | 上下文压缩 | 不用 |
atlas fallback | Todo 管理 | 不用 |
librarian fallback | 搜索文档 | 不用 |
explore fallback | 搜代码 | 不用 |
writing 主模型 | 写文档 | 不用(写文字不写代码) |
quick 主模型 | 单文件修改 | 要 |
unspecified-low 主模型 | 简单任务 | 要 |
sisyphus-junior fallback | 任务执行 | 要 |
deep fallback | 研究+实现 | 要 |
unspecified-high fallback | 复杂任务 | 要 |
策略很清楚:不需要写代码的 5 个位置保留不动,需要写代码的 5 个位置全部换掉。
免费模型池
要换就得选替代品。opencode models 跑出来当前可用的免费模型一共 29 个(25 个 OpenRouter + 4 个 OpenCode 内置)。全部列出来分析一遍。
OpenRouter 免费模型(25 个)
编码主力
| 模型 | 架构 | 编码能力 | 上下文 | 工具调用 | 备注 |
|---|---|---|---|---|---|
| gemma-4-31b-it | Dense 31B | HumanEval+ 88.4%, LiveCodeBench 80.0% | 256K | 原生支持 | 免费池里编码最强的,BFCL 92.25% |
| llama-3.3-70b-instruct | Dense 70B | HumanEval 88.4% | 128K | 原生支持 | 大模型,编码和推理都扎实 |
| gemma-4-26b-a4b-it | MoE 26B (4B 激活) | LiveCodeBench 77.1% | 256K | 原生支持 | 4B 激活意味着快,编码质量接近 31B |
| gemma-3-12b-it | Dense 12B | HumanEval 85.4% | 128K | 不确定 | 编码分数不错,MATH 83.8%,但工具调用没有官方文档 |
| nemotron-3-nano-30b-a3b | MoE 30B (3B 激活) | HumanEval 78%, SWE-Bench 38.8% | 1M | 原生支持 | 1M 上下文是杀手锏,工具调用 BFCL 53.8% |
Gemma 4 26B 是 MoE 架构,26B 总参数但只有 4B 激活——推理速度接近 4B 模型但编码质量接近 30B 级别。拿来干 quick 的活(改个变量名、修个 import)刚好。31B 的 Dense 版本编码更强(HumanEval+ 88.4%),但慢一些。
推理专用
| 模型 | 架构 | 推理能力 | 上下文 | 备注 |
|---|---|---|---|---|
| gpt-oss-120b | MoE 120B | AIME 2025 92.1% | 128K | OpenAI 开源,推理极强但编码一般(HumanEval 73%) |
| gpt-oss-20b | MoE 20B (3.6B 激活) | AIME 2025 92.1% | 128K | 小体量但推理能力跟 120B 一样强 |
| nemotron-3-super-120b-a12b | MoE 120B (12B 激活) | 强推理 | 256K | 编码和推理平衡 |
| nemotron-3-nano-omni-30b-a3b-reasoning | MoE 31B (3B 激活) | LiveCodeBench 63.2% | 256K | nano-30b 的多模态+推理变体,加了视觉/音频 |
GPT-OSS 系列的 AIME 分数很夸张,92.1% 跟不少闭源模型持平。但编码是短板(HumanEval 73%),适合推理场景而不是编码场景。
多模态
| 模型 | 架构 | 能力 | 上下文 | 备注 |
|---|---|---|---|---|
| nemotron-nano-12b-v2-vl | Dense 12B | 视觉(图片理解) | — | 免费池里唯一能看图的,multimodal-looker 在用 |
| gemma-3n-e4b-it | MatFormer ~4B | 视觉 | 32K | 太小,工具调用不成熟 |
| gemma-3n-e2b-it | MatFormer ~2B | 视觉 | 32K | 更小,基本不可用于编码 |
视觉模型选择很有限。nemotron-nano-12b-v2-vl 是免费池里唯一能看图且工具调用靠谱的。Gemma 3n 系列虽然带视觉但太小(2-4B 有效参数),LiveCodeBench 只有 25.7%。
中等体量
| 模型 | 架构 | 编码能力 | 上下文 | 备注 |
|---|---|---|---|---|
| gemma-3-27b-it | Dense 27B | LiveCodeBench 29.7% | 128K | 比老版 Gemma-2 27B 好很多,但跟 Gemma 4 系列比差距大 |
| nemotron-nano-9b-v2 | Dense 9B | 轻量编码 | — | 轻量但能干活,适合 fallback |
| glm-4.5-air | Dense (?) | 分析强,编码弱 | — | 只分析不写代码的模型,写作和搜索够用 |
| minimax-m2.5 | — | 通用 | — | MiniMax 出品,通用能力不错 |
太小不适合编码
| 模型 | 参数 | 备注 |
|---|---|---|
| gemma-3-4b-it | 4B | 编码能力弱 |
| llama-3.2-3b-instruct | 3B | 太小 |
| lfm-2.5-1.2b-instruct | 1.2B | AIME25 14%,基本不能编码 |
| lfm-2.5-1.2b-thinking | 1.2B | 同上,加了推理也没用 |
| laguna-m.1 | — | Poolside 出品,能力未知 |
| laguna-xs.2 | — | 同上 |
| dolphin-mistral-24b-venice-edition | 24B | Venice 定制版,无 censor 但工具调用不明确 |
| hermes-3-llama-3.1-405b | 405B | 参数大但无工具调用,Agent 场景不可用 |
| trinity-large-preview | — | 端点不稳定 |
OpenCode 内置免费模型(4 个)
| 模型 | 备注 |
|---|---|
| big-pickle | 通用,最后兜底用 |
| hy3-preview-free | 腾讯混元,中文场景不错 |
| minimax-m2.5-free | MiniMax 出品,通用 |
| nematron-3-super-free | NVIDIA Nemotron 3 Super,推理和编码平衡 |
OpenCode 内置模型没有公开的 benchmark 数据,但从实际使用看做 fallback 保底够了。big-pickle 是最常用的兜底——什么 Agent 都能跑,虽然质量一般但不会挂。
最终的替换方案
| |
附带效果:quick 和 unspecified-low 从付费模型切到免费模型,小任务不花钱了。
保留 glm-4.5-air 的位置不动——上下文压缩、文档搜索、代码搜索、Todo 管理、文档写作,这些都是只读或者纯文字输出,“只分析不动手"反而挺合适。
并发控制
初始配置里没做并发限制,多个 Agent 同时跑的时候容易撞上供应商的限流。这次按模型大小和供应商限制配了并发数:
- GLM-5.1(旗舰,慢):3 并发
- GLM-5-turbo / GLM-4.7(中端):5-8 并发
- NVIDIA 大模型(480B、253B):2-3 并发
- OpenRouter 免费:3-8 并发(按模型大小分)
- OpenCode 内置免费:10-20 并发
实际跑起来基本不撞限流了。之前偶尔出现的 429 错误在加了降级链路之后也变成无感切换。
当前完整配置
改完之后的配置结构(只列免费模型和 OpenCode 内置模型相关的链路):
| |
踩坑总结
模型能用 ≠ 模型适合。GLM-4.5-air 的编码能力没问题,但它就是不输出代码改动,只输出分析。这种行为差异靠 benchmark 跑不出来,得上手用才知道。
免费模型池变化快。两周前没有的模型现在有了,之前有的现在下线了。opencode models 定期跑一次看看有什么新东西。
降级链路不是锦上添花,是必需品。没有 fallback 的时候,一次 429 就能把整个 Agent 卡住。加了之后,主模型限流切到备选,体感上基本无感。
并发限制要跟供应商对齐。大模型的并发限额本来就低(2-3),不配的话多个 Agent 同时跑会触发限流,然后降级,然后备选模型也限流,雪崩。
下一阶段想试试把 NVIDIA 的新模型(DeepSeek-v4、Llama-4 Maverick)放到 fallback 链路里测试。也打算跑一轮连通性测试,把 OpenRouter 免费模型池里能用的都筛一遍,看看有没有比 Gemma 4 26B 更好的选择给 quick 用。