被低估的智能体编排插件 oh-my-opencode-slim

一直以来，我的开发工具以Qoder、Trae国际版这两款国产IDE为主，辅以智谱的Coding-Plan。因为开发强度不高所以一直够用。但是最近发生的几件事促使我寻求更多的开发选择。

首先，是智谱旧版无周限套餐强制停止续费，其次是Qoder涨价。这两件事网上的讨论有很多，我就不具体赘述了，这些事情的发生共同指向了一件事 — 与传统软件开发边际成本递减不同，AI时代下的Token正在因为用户增多及使用方式的进化（比如各种“虾”）而变得越来越昂贵。作为普通的个人开发者，寻求多渠道互补的平替资源几乎成了必选项。

也就是在这个背景下我开始关注OpenCode这款开源的Claude Code平替，至于为什么不直接去用Claude Code，自己也说不清，可能对我来说开源的东西总比商业化产品优先级要高一些。

不管你用Claude Code还是CodeX，Cursor还是Qoder或Trae，除了为产品背后的模型买单之外，更多的是为了这些产品不断迭代进化的智能体编排能力付费。OpenCode作为一款开源的Claude Code平替，也有自己生态的智能体编排插件。我最早关注的是oh-my-openagent（原oh-my-opencode），并且安装学习使用了一小段时间，不过最终放弃了。至于理由嘛，一个字 穷 😭。

oh-my-openagent的编排能力的确很强，但同时也是一个Token吞金兽，虽然不了解这款插件背后具体的上下文细节，但毋庸置疑的一点是，这家伙一定在上下文里塞了太多东西了。对于一些关键任务或者项目脚手架的搭架，我一般采用opus这类顶级模型实施，而使用oh-my-openagent，一个简单的md文档review就可以轻松消耗掉10美金以上的额度，这种消耗显然是我承受不起的。就在我要放弃这个OpenCode的时候，无意中在Github上发现了一个slim版的oh-my-openagent，也就是本文标题中的 oh-my-opencode-slim

什么是 oh-my-opencode-slim

官方Github上的about是这样写的: Slimmed, cleaned and fine-tuned oh-my-opencode fork, consumes much less tokens，这简直太契合我的痛点了，烧不起Token！

同oh-my-openagent一样，oh-my-opencode-slim 也内置了一个智能体团队。通过配置文件为不同的智能体角色分配不同的底座模型，让合适的模型做合适的事，最终通过一个总调度智能体完成复杂的系统工程构建。而且最重要的一点，没有上下文爆炸，保护你的钱包！

oh-my-opencode-slim 的内置智能体

oh-my-opencode-slim内置了8个智能体，其分别扮演的角色如下表：

从上述智能体的官方推荐配置模型能看出官方给这些智能体的定位:

• Orchestrator, Oracle: 毫无疑问是整个工作流实施质量的决定者，模型配置拉满，哪个推理强用哪个
• Explorer, Librarian: 负责枯燥的代码及外部知识的检索工作，速度与效率优先于推理能力
• Council: 这是一个特殊的智能体，事实上从配置上，它不是单一模型，而是需要配置多个模型，由一个主Council模型驱动多个子Council模型，就一个问题各自发表推理结论，最终由主Council模型进行互相印证及决策采用。官方文档中提到，一般情况下，Orchestrator不会主动调用Council，多用于用户就某个问题需要头脑风暴时手动调用
• Designer: 前端设计智能体，配置前端输出设计感强的模型，官方推荐gemini-3.1-pro-preview，这与AI圈认同Gemini模型的前端能力是一致的
• Fixer: 上述智能体都是搞管理的，现在苦逼的打工狗来了，大多数迭代问题都属于Fixer范畴，由这个智能体负责实施。官方的建议模型配置是 openai/gpt-5.4-mini，这点上我不太认同，我觉得这个智能体最终交付的质量对推理能力的要求同样重要，我自己配置的是GLM5.1这类头部编码模型
• Observer: 这个智能体是官方的可选智能体，并不在常规的工作流编排中出现，只有在你的工作流涉及到多模态的时候才会被调用，所以这个智能体的模型配置必须是支持多模态的

配置文件

oh-my-opencode-slim的配置文件在 ~/.config/opencode/oh-my-opencode-slim.json 。官方默认的配置文件长这样:

{
  "$schema": "https://unpkg.com/oh-my-opencode-slim@latest/oh-my-opencode-slim.schema.json",
  "preset": "openai",
  "presets": {
    "openai": {
      "orchestrator": {
        "model": "openai/gpt-5.5",
        "skills": [
          "*"
        ],
        "mcps": [
          "*",
          "!context7"
        ]
      },
      "oracle": {
        "model": "openai/gpt-5.5",
        "variant": "high",
        "skills": [
          "simplify"
        ],
        "mcps": []
      },
      "librarian": {
        "model": "openai/gpt-5.4-mini",
        "variant": "low",
        "skills": [],
        "mcps": [
          "websearch",
          "context7",
          "grep_app"
        ]
      },
      "explorer": {
        "model": "openai/gpt-5.4-mini",
        "variant": "low",
        "skills": [],
        "mcps": []
      },
      "designer": {
        "model": "openai/gpt-5.4-mini",
        "variant": "medium",
        "skills": [
          "agent-browser"
        ],
        "mcps": []
      },
      "fixer": {
        "model": "openai/gpt-5.4-mini",
        "variant": "low",
        "skills": [],
        "mcps": []
      }
    }
  }
}

配置文件中的preset属性是配置方案的名称，对应着presets属性中成员键名，官方默认配置的键名是openai。在具体的preset模型配置中可以看到，每一个智能体都有model、variant、mcps、skills几个子属性，分别对应着: 模型配置、模型变体、智能体可调用的MCP工具列表、智能体可调用的Skills列表。

上面提到的Council智能体配置格式不同于其他智能体，官方建议配置如下:

{
  "preset": "openai",
  "presets": {
    "openai": {
      "council": { "model": "openai/gpt-5.5" }
    }
  },
  "council": {
    "presets": {
      "default": {
        "alpha": { "model": "openai/gpt-5.4-mini" },
        "beta": { "model": "google/gemini-3-pro" },
        "gamma": { "model": "openai/gpt-5.3-codex" }
      }
    }
  }
}

需要注意的一点是，Council的配置出现在两个地方，presets中的是Council的决策智能体，与presets平级 的council属性，配置的是头脑风暴成员的子模型。

推荐的模型配置

如果你只有一个国内的Coding Plan，其实是不适合用这类智能体编排插件的，因为这种智能体编排工具需要并行运行干活，而对于基础版的Coding Plan来说，厂商在API端就给你的并发调用数量限制了，一般也就1,2个并发，也就是说，虽然你的oh-my-opencode-slim智能体在安排并行任务，但实际上内部却只能顺序执行，因为API端会产生堵塞。

解决这个问题也不难，其实就是多找些API用就是了。OpenCode官方的Go订阅套餐其实就很合适，支持的模型详见 传送门 。最关键的是，可以真正的并行调用而不会产生阻塞问题。

我因为目前还在订阅Qoder和GLM，所以暂时还没有订阅这个Go，但是从官方介绍和社区反馈看，Go订阅的性价比还是挺高的，开源全家桶，官方更新也很勤快，能第一时间跟上新发布的模型。我目前采用的模型配置方案是: deepseek v4 pro / flash , GLM5.1 / GLM5-Turbo / GLM4.7 ，配置文件如下:

{
  "$schema": "https://unpkg.com/oh-my-opencode-slim@latest/oh-my-opencode-slim.schema.json",
  "preset": "cheap",
  "presets": {
    "cheap": {
      "orchestrator": {
        "model": "zhipuai-coding-plan/glm-5.1",
        "skills": [
          "*"
        ],
        "mcps": [
          "*",
          "!context7"
        ]
      },
      "oracle": {
        "model": "deepseek/deepseek-v4-pro",
        "variant": "xhigh",
        "skills": [
          "simplify"
        ],
        "mcps": []
      },
      "librarian": {
        "model": "zhipuai-coding-plan/glm-5-turbo",
        "skills": [],
        "mcps": [
          "websearch",
          "context7",
          "grep_app"
        ]
      },
      "explorer": {
        "model": "deepseek/deepseek-v4-flash",
        "variant": "xhigh",
        "skills": [],
        "mcps": []
      },
      "designer": {
        "model": "deepseek/deepseek-v4-pro",
        "variant": "xhigh",
        "skills": [
          "agent-browser"
        ],
        "mcps": []
      },
      "fixer": {
        "model": "deepseek/deepseek-v4-pro",
        "variant": "xhigh",
        "skills": [],
        "mcps": []
      },
      "council": {
        "model": "deepseek/deepseek-v4-pro",
        "variant": "xhigh",
        "skills": [],
        "mcps": []
      }
    }
  },
  "council": {
    "presets": {
      "default": {
        "alpha": { "model": "zhipuai-coding-plan/glm-4.7" },
        "beta": { "model": "deepseek/deepseek-v4-flash" },
        "gamma": { "model": "deepseek/deepseek-v4-pro" }
      }
    }
  }
}

没错，配置名字就是“cheap”😄。这个配置里有几个注意的地方:

• 所有的deepseek v4模型，都是使用xhigh这个变体，在deepseek的官方文档中，为了兼容Anthropic协议，low、medium 会映射为deepseek v4 的high, xhigh 会映射为deepseek的 max 。传送门
• council配置中，glm-4.7 / deepseek-v4-flash / deepseek-v4-pro 这几个坐一桌实际上是不合理的，如果后面订阅了GO，这里应该配置能力接近的模型才比较好，比如 Qwen3.6 Plus / Kimi K2.6 / MiMo-V2.5-Pro 之类的配置
• model字段的配置需要查，这个信息你可以在bash/powershell中运行 opencode models --refresh，控制台会列出你目前所有可以配置的模型完整字符串

切换模型配置与使用

做好配置文件后，进入OpenCode CLI，输入 /preset xxxx ,切换到xxxx模型配置上，以刚才的示例来讲，就是cheap（为了上面那个json不至于太长，我删了官方的openai配置，如果你保留的话，这里需要命令切换到xxxx上去）。

接下来就是使用了，oh-my-opencode-slim暴露在对话框中的智能体只有两个，Orchestrator和Council。有什么开发需求，主要和Orchestrator对话，如果你需要头脑风暴，按Tab切换成Council就好。

总结

寻寻觅觅很久，目前 OpenCode + oh-my-opencode-slim 是我认为最舒服的组合，编排能力能打，且Token消耗相对克制很多，如果你用过oh-my-openagent，这点是能够有明显体感的，为什么说这个插件被低估了呢，因为目前Github的Stars还只有3.5K，但这个插件的实际价值与上限我认为远比目前Stars所处的水平要高。

写了这么多，其实还有一个我想讲讲的插件是OpenSpec，搭配起 oh-my-opencode-slim 简直不要太舒坦，不过这又是另一个故事，以后有时间再写吧。