智谱 Coding Plan × Oh My OpenCode：多模型编排配置实战

发表于： 2026-04-05 分类于： AI/开发工具

字数： 2226 阅读：≈ 5分钟浏览：

为什么折腾这个

用 AI 写代码这事儿，单模型和多人模型的差距越来越大。一个模型再强，也干不过一组各司其职的模型并行推进。

Oh My OpenCode （下文简称 OmO）是 OpenCode 生态里的多模型编排插件，11 个 Agent 各有分工，48 个 Hook 贯穿整个生命周期。智谱的 Coding Plan 则提供了 GLM 全系列的模型访问。两者搭配起来，就能按角色分配不同的模型——编码强的干编码，推理强的干推理，免费的干杂活。

这篇文章记录我的完整配置过程。

GLM 模型家族

智谱 Coding Plan 目前可用的编程相关模型：

模型	干什么用的
GLM-5	开源旗舰，744B MoE，200K 上下文，SWE-bench 77.8%
GLM-5-turbo	闭源，在 GLM-5 基础上专门给 Agent 工作流做了优化，工具调用错误率从 2-6% 降到 0.67%，速度快了约 36%
GLM-5.1	后训练优化的版本，编码得分从 35.4 涨到 45.3（+28%），相当于 Claude Opus 4.6 的 94.6%
GLM-4.7	推理质量扎实，`max` 变体支持扩展思考
GLM-4.7-flash	速度优先的 4.7 变体
GLM-5v-turbo	多模态，能看图

这三个 “5 系” 容易搞混，关系是这样的：

1
2
3
GLM-5          ← 开源基座，啥都能干，但偶尔抽风
  ├── 5-turbo  ← 给 Agent 优化：快、稳、工具调用靠谱
  └── 5.1      ← 给编码强化：代码质量涨了 28%

选型看需求就行：要编码选 5.1，要稳定跑 Agent 选 5-turbo，要推理选 4.7，要看图选 5v-turbo，要快选 4.7-flash。

OmO 的 Agent 体系

OmO 的思路很直接：每个 Agent 用自己的系统提示词、工具权限和模型。不是一刀切。

Agents

Agent	干什么	需要什么样的模型
Sisyphus	主编排，任务分解和调度	最强编码
Prometheus	规划，需求澄清和计划制定	长链稳定，工具调用靠谱
Oracle	架构顾问，只读分析	深度推理
Librarian	文档和 API 检索	理解能力
Explore	代码库搜索	快
Metis	预规划咨询，找盲点	深度推理
Momus	计划评审	深度推理
Atlas	Todo 管理	轻量就行
Multimodal-Looker	截图、PDF 分析	得能看图
Sisyphus-Junior	具体实现	看任务类型路由

Category	什么时候用
`visual-engineering`	前端 UI、CSS
`ultrabrain`	难搞的逻辑、架构决策
`deep`	自主研究 + 端到端实现
`artistry`	创意方案
`quick`	小改动
`unspecified-low`	低复杂度杂活
`unspecified-high`	高复杂度杂活
`writing`	文档写作

配置文件

折腾完的 oh-my-openagent.json：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
{
  "$schema": "https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/dev/assets/oh-my-opencode.schema.json",
  "agents": {
    "sisyphus": {
      "model": "zhipuai-coding-plan/glm-5.1"
    },
    "oracle": {
      "model": "zhipuai-coding-plan/glm-4.7"
    },
    "librarian": {
      "model": "zhipuai-coding-plan/glm-4.7"
    },
    "explore": {
      "model": "opencode/qwen3.6-plus-free"
    },
    "multimodal-looker": {
      "model": "zhipuai-coding-plan/glm-5v-turbo"
    },
    "prometheus": {
      "model": "zhipuai-coding-plan/glm-5-turbo"
    },
    "metis": {
      "model": "zhipuai-coding-plan/glm-4.7",
      "variant": "max"
    },
    "momus": {
      "model": "zhipuai-coding-plan/glm-4.7",
      "variant": "max"
    },
    "atlas": {
      "model": "opencode/minimax-m2.5-free"
    },
    "sisyphus-junior": {
      "model": "opencode/gpt-5-nano"
    }
  },
  "categories": {
    "visual-engineering": {
      "model": "zhipuai-coding-plan/glm-5v-turbo"
    },
    "ultrabrain": {
      "model": "zhipuai-coding-plan/glm-4.7",
      "variant": "max"
    },
    "deep": {
      "model": "opencode/nemotron-3-super-free"
    },
    "artistry": {
      "model": "zhipuai-coding-plan/glm-5.1"
    },
    "quick": {
      "model": "opencode/gpt-5-nano"
    },
    "unspecified-low": {
      "model": "opencode/gpt-5-nano"
    },
    "unspecified-high": {
      "model": "opencode/minimax-m2.5-free"
    },
    "writing": {
      "model": "zhipuai-coding-plan/glm-4.7-flash"
    }
  }
}

为什么这么配

Sisyphus → GLM-5.1

主编排者是一切的入口，编码能力不能妥协。GLM-5.1 编码得分 45.3，比 GLM-5 的 35.4 涨了 28%，差距很明显。

Prometheus → GLM-5-turbo

规划器的活儿是长链任务分解，核心是工具调用得稳。GLM-5 偶尔会陷入思维循环死锁，GLM-5-turbo 专门解决了这个问题，工具调用错误率从 2-6% 降到 0.67%。做规划最怕的就是 Agent 跑着跑着卡死了。

Oracle / Librarian → GLM-4.7

Oracle 是只读架构顾问，Librarian 搜文档查 API。这两个位置需要理解能力而不是编码能力，GLM-4.7 够用。

Metis / Momus → GLM-4.7 (max)

预规划咨询和计划评审都需要深度推理。variant: "max" 开启扩展思考模式，让模型想得更深一些。

Explore → Qwen3.6 Plus (免费)

代码搜索是高频操作，一天能跑几十次，用免费模型就行。Qwen3.6 理解代码的能力不错。

Atlas → Minimax M2.5 (免费)

Todo 管理，没什么好说的，免费就行。

Multimodal-Looker → GLM-5v-turbo

唯一需要看图的 Agent，没得选。

Sisyphus-Junior → GPT-5-nano (免费)

它自己不做决策，按 Category 路由到具体模型，基础模型轻量即可。

前缀的事

配置里有三种前缀：

zai-coding-plan/* — 智谱 Coding Plan 订阅提供的
zhipuai-coding-plan/* — 智谱直连 API
opencode/* — OpenCode 平台免费模型

底层模型是一样的，区别在计费方式。Coding Plan 有配额但单价低，直连 API 没限制但按 token 算。高频的 Agent 我尽量用了免费模型，核心任务走 Coding Plan。

实际跑起来

日常编码输个 ultrawork，Sisyphus（5.1）接管，分解任务后并行派出 Explore（Qwen 搜代码）和 Librarian（4.7 查文档），汇总完交给 Junior 实现。5.1 在日常重构和 Bug 修复上跟 Opus 的体感差距不大，中英文混合的代码库里没啥问题。

复杂规划用 /start-work 触发 Prometheus（5-turbo）。它会先问你几个问题确认需求边界，然后出结构化的计划。之前用 GLM-5 跑规划偶尔会思维循环卡死，换 5-turbo 之后没再出现过。

架构评审不用手动触发——遇到困难决策或者连续两次修复失败，Sisyphus 会自动去问 Oracle（4.7）。Oracle 只读不改代码，给分析和建议。4.7 在模块划分和接口设计上的推理深度够用。

多模态场景里，Multimodal-Looker（5v-turbo）负责认截图和 PDF。配合 visual-engineering category，前端任务可以直接对着设计稿生成代码。

几个要注意的

GLM-5.1 的 94.6% Opus 对标分数是 Z.ai 自己测的，第三方验证还在做。不过 GLM-5 基座的 SWE-bench 77.8% 已经被外部验证过了，所以这个数字不算离谱。

GLM-5-turbo 是闭源的，不像 GLM-5 走 MIT 协议。Z.ai 说后续会把改进融入开源版本。

Coding Plan 有请求配额，高频使用的话核心任务走订阅，杂活走免费模型就行。

思路总结

核心就一句话：按角色选模型。

写代码的用 5.1
跑 Agent 流程的用 5-turbo
做推理评审的用 4.7 (max)
看图的用 5v-turbo
打杂的用免费模型

不是每个角色都需要最强模型，匹配对了就行。

蓝宝石的傻话