夜雨聆风一台电脑，十几个 AI 代理，三家公司的大模型，外加一个长期记忆和一双能查数据库的「手」。这篇文章带你逐层拆解我的 OpenCode 配置，看看开源 AI 编程助手到底能玩出什么花。
写在前面：为什么要折腾？
你大概也遇到过这种情况：让 AI 写个小函数，它分分钟搞定；可一旦让它「重构这个模块」「排查这个线上 bug」「顺带把测试补上」，它就开始丢三落四、前后矛盾、改了东墙塌西墙。
根本原因不是模型不够聪明，而是你把它当成了一个无所不能的全能选手。现实里没有哪个工程师能同时把架构设计、代码实现、安全审计、文档撰写都做到顶尖——AI 也一样。
于是我开始琢磨：能不能不只用一个 AI，而是搭一支 AI 工程团队？有人负责拆活，有人负责查资料，有人负责写代码，有人负责挑刺？
答案是能。工具就是 OpenCode，方法是多模型 + 多代理编排。下面是我完整配置的逐层拆解。
一、OpenCode 是个什么东西？
一句话：OpenCode 是一个开源的、跑在终端里的 AI 编程助手。
如果用过 Claude Code 或 Cursor，你对它的形态不会陌生——你在终端里跟 AI 对话，它能读你的代码、改文件、跑命令。但 OpenCode 有几个关键不同：
| 任意，随便换 | |||
对我最重要的是「模型随便换」这一点。这意味着我可以同时用智谱的 GLM、DeepSeek、小米的 MiMo——谁擅长什么就让谁上，还能有效控制成本。
二、模型层：不把鸡蛋放一个篮子
先看我的「人才库」。在 OpenCode.json 里，我接了三个模型供应商：
{ "model": "zhipuai-coding-plan/glm-5.2", // 主力模型：日常对话 "small_model": "zhipuai-coding-plan/glm-4.5-air", // 小模型：轻量任务省 token "provider": { "zhipuai-coding-plan": { // 智谱 GLM 系列 "options": { "apiKey": "60ae****.****" } }, "deepseek": { // DeepSeek "models": { "deepseek-chat": { /* 通用对话 */ }, "deepseek-reasoner": { /* 推理增强 */ } }, "npm": "@ai-sdk/deepseek", "options": { "apiKey": "sk-****" } }, "mimo": { // 小米 MiMo "name": "MiMo", "npm": "@ai-sdk/openai-compatible", "options": { "apiKey": "tp-****", "baseURL": "https://token-plan-cn.xiaomimimo.com/v1" } } }}为什么要接三家？ 因为它们各有所长：
智谱 GLM 系列（glm-5.2 / 5.1 / 4.6 / 4.6v / 4.5-air）：我的主力，覆盖从重活到轻活、从纯文本到多模态识图的完整梯队，国内访问稳定。 DeepSeek（chat / reasoner）： reasoner是个带深度思考能力的推理模型，专门留给最硬的架构和调试难题。小米 MiMo（v2.5 / v2.5-pro）：上下文窗口高达 100 万 token，价格便宜，特别适合大段代码搜索、批量资料消化的场景。
这里有个关键设计：主模型 ≠ 全场都用主模型。日常对话我用 glm-5.2，但搜索代码这种「量大但不难」的活，我丢给 100 万窗口的 MiMo；最难啃的推理题，丢给 DeepSeek-reasoner。这就是后面「多代理」要解决的事。
三、插件层：四大插件各司其职
OpenCode 的插件装在两个地方：OpenCode.json 的 plugin 字段（核心能力），和 tui.json 的 plugin 字段（界面美化）。
// OpenCode.json —— 能力插件"plugin": [ "OpenCode-supermemory", // 长期记忆 "oh-my-openagent@latest" // 多代理编排（核心！）]// tui.json —— 界面美化插件"plugin": [ "oh-my-openagent/tui", // 编排代理的界面组件 "OpenCode-supermemory/tui", // 记忆系统的界面组件 "OpenCode-theme-pack", // 主题包 "nerd-icons", // 图标字体 "status-bar-plus" // 增强状态栏]逐个说说。
1. OhMyOpenCode（OMO）—— 整个体系的「大脑」
这是最核心的插件，没有它，后面所有的多代理编排都无从谈起。它的作用一句话概括：把单个 AI 对话，升级成一支分工明确的代理团队。
它做了三件事：
定义了一批角色化子代理（探索员、图书管理员、神谕师、计划顾问……每个有自己的人设和工具权限）； 定义了一套任务类别（quick / deep / ultrabrain……按难度自动选合适的模型）； 提供了一套编排逻辑（主代理怎么拆活、怎么并行派活、怎么收口验收）。
我现在跟你对话的这个「我」，就是 OMO 里的 Sisyphus（西西弗斯） 主代理——负责理解需求、分解任务、调度其他代理。这个名字取自希腊神话里每天推石头上山的那位，寓意「工程师就是日复一日推代码这块石头的人」。
2. OpenCode-supermemory —— 给 AI 装上「长期记忆」
默认情况下，AI 的记忆只存在于当前对话——关掉窗口就忘光。supermemory 给它加了一个跨会话的持久记忆层，能记住「这个项目的架构偏好」「上次踩过什么坑」「用户喜欢什么风格」。
3. 界面美化三件套
OpenCode-theme-pack：一套好看的配色主题，终端不刺眼。 nerd-icons：用 Nerd Font 图标点缀文件树和状态，一眼能区分文件类型。 status-bar-plus：增强底部状态栏，实时看到当前模型、token 用量、代理状态。
别小看美化——写代码是长时间盯着终端的活，看着舒服，效率真不一样。
四、MCP：让 AI 长出「手」
MCP（Model Context Protocol，模型上下文协议）是 Anthropic 提出的一个开放标准，通俗讲就是给 AI 装「手」的标准接口——让它能去操作数据库、调 API、读文档库。
我目前接了一个 MCP 服务：
"mcp": { "dbhub": { "type": "remote", "url": "http://www.iakuil.com:28080/mcp" // 远程数据库网关 }}dbhub 是一个数据库 MCP 服务，接上之后，AI（包括我自己和所有子代理）就能直接用自然语言查数据库——「帮我看看 sellers 表里最近一周新增的记录」「这两张表的关联关系是什么」，它会自动翻译成 SQL、执行、把结果带回来。
MCP 的妙处在于它是协议级的：任何一个遵循 MCP 标准的服务（GitHub、Slack、Notion、数据库、浏览器……）都能即插即用地接入，AI 不用为每个工具单独学一套 API。
五、子代理体系：这篇文章的重头戏
这是大家最关心的「子代理怎么配置的」。秘密全在 oh-my-openagent.json 这个文件里。它分两部分：agents（角色代理） 和 categories（任务类别）。
5.1 agents：10 个角色化代理
每个 agent 是一个「岗位」，有自己的人设、工具权限，还各自指定了用什么模型：
| sisyphus | ||
| sisyphus-junior | ||
| explore | ||
| librarian | ||
| oracle | ||
| metis | ||
| momus | ||
| prometheus | ||
| multimodal-looker | v） | |
| atlas |
这里的设计精髓是「让合适的模型干合适的活」：
搜索类重活（explore）→ 100 万窗口的 MiMo，不怕代码库大； 推理类硬活（oracle）→ DeepSeek-reasoner，专攻深度思考； 执行类轻活（sisyphus-junior）→ glm-4.5-air，又快又省； 主调度（sisyphus）→ glm-5.1，能力均衡。
配置写起来非常直白：
"agents": { "oracle": { "model": "deepseek/deepseek-reasoner" }, "explore": { "model": "mimo/mimo-v2.5" }, "librarian":{ "model": "deepseek/deepseek-chat" }, "sisyphus-junior": { "model": "zhipuai-coding-plan/glm-4.5-air" } // ... 其余同理}5.2 categories：8 个任务类别
除了固定角色，OOM 还有一套「任务类别」机制——当我派活时，按任务的难度和性质选一个 category，每个 category 绑定一个模型：
| quick | ||
| unspecified-low | ||
| unspecified-high | ||
| deep | ||
| ultrabrain | ||
| visual-engineering | ||
| artistry | ||
| writing |
看出来了吗？这是一张「任务难度 → 模型成本」的精准映射表。写文档用 glm-4.5-air 这种轻模型就够了，没必要动用 deepseek-reasoner 烧钱；反过来，真正的架构难题，就该上最贵的推理模型一次想清楚。
"categories": { "quick": { "model": "mimo/mimo-v2.5" }, "ultrabrain": { "model": "deepseek/deepseek-reasoner" }, "visual-engineering":{ "model": "zhipuai-coding-plan/glm-4.6" }, "writing": { "model": "zhipuai-coding-plan/glm-4.5-air" } // ... 其余同理}5.3 它们怎么协作？
举个真实例子。假设你说「帮我重构这个模块，并补上测试」，主代理 Sisyphus 的处理流程大致是：
你提需求 │ ▼Sisyphus(主代理, glm-5.1) 理解 + 拆解任务 │ ├──(并行) explore(MiMo) 扫描现有代码结构 ├──(并行) librarian(deepseek) 查相关最佳实践 │ ▼综合信息，必要时问 metis/deepseek 确认需求无歧义 │ ▼prometheus(deepseek) 出工作分解计划 │ ▼momus(deepseek) 评审计划挑毛病 │ ▼派活（可并行）： ├── visual-engineering(glm-4.6) 改 UI 部分 ├── deep(deepseek-chat) 改核心逻辑 └── quick(MiMo) 改配置文件 │ ▼Sisyphus 收口验收，遇硬骨头 → oracle(reasoner) │ ▼交付整条链路里，每个环节都是「最适合的那个模型」在干活，而且能并行的全部并行。这就是为什么它比「一个模型从头干到尾」强得多。
六、技能系统：可复用的工作流
除了按需派代理，OMO 还支持「技能（Skill）」——把一套成熟的工作流固化下来，触发关键词就自动加载。
我目前装了两个安全相关的技能：
security-research：团队模式安全审计。一次性派出 3 个漏洞猎手 + 2 个 PoC 工程师并行扫代码库，证明可利用性、归类根因、校准严重等级。 security-review：上面那个的别名快捷方式。
技能的好处是「一次沉淀，反复使用」。比如安全审计这种流程很重、步骤固定的活，写成技能后，一句话触发就是一整套专业流程跑起来，不用每次重新教 AI。
七、配置文件全景
最后把三个配置文件的关系画清楚，方便你照着搭：
~/.config/OpenCode/├── OpenCode.json ← 主配置：模型、供应商、核心插件、MCP├── oh-my-openagent.json ← OOM 配置：所有子代理 & 任务类别的模型分配├── tui.json ← 界面配置：主题、图标、状态栏等美化插件├── package.json ← 依赖声明（@OpenCode-ai/plugin SDK）└── package-lock.json~/.cache/OpenCode/├── skills/ ← 已安装的技能（security-research 等）└── packages/ ← 插件本体（oh-my-openagent、supermemory…）~/.local/share/OpenCode/└── OpenCode.db ← 会话历史、快照（SQLite）加载优先级：OpenCode.json 定全局模型和插件 → oh-my-openagent.json 按代理/类别覆盖模型分配 → 运行时主代理按需调度。
八、几点掏心窝的经验
折腾完这套配置，有几个体会分享给你：
多模型不是炫技，是省钱。90% 的活用轻模型就够，只在关键决策点用重型模型，成本能压下来一大截。
子代理的核心不是「多」，是「分工清晰」。每个代理必须有明确的边界——探索的不写代码，写代码的不做架构决策。边界模糊，编排就会乱。
并行是最大杠杆。以前一个 AI 串行干五件事，现在五个代理并行干，吞吐量直接乘以五。
记忆系统是长期收益。supermemory 记住的项目上下文，会随着使用越来越值钱——用一个月后，它对你代码库的理解会深得多。
界面美化值得投入。终端是你每天盯最久的窗口，花十分钟配好主题和图标，回报是整整一年的舒适。
结语
很多人把 AI 编程助手当成一个「更聪明的补全工具」。但在我看来，真正的玩法是把它当成一个可编排的系统——有记忆、有分工、有外部能力、有可沉淀的流程。
OpenCode + OhMyOpenCode 给了我这套底座，而具体的模型搭配和代理分工，则是每个团队、每个项目都可以自定义的部分。希望这篇拆解能给你一些启发，去搭一支属于你自己的「数字工程团队」。