我把 AI 编程助手改造成了一支「数字工程团队」—

我把 AI 编程助手改造成了一支「数字工程团队」—— OpenCode 配置全解

一台电脑，十几个 AI 代理，三家公司的大模型，外加一个长期记忆和一双能查数据库的「手」。这篇文章带你逐层拆解我的 OpenCode 配置，看看开源 AI 编程助手到底能玩出什么花。

写在前面：为什么要折腾？

你大概也遇到过这种情况：让 AI 写个小函数，它分分钟搞定；可一旦让它「重构这个模块」「排查这个线上 bug」「顺带把测试补上」，它就开始丢三落四、前后矛盾、改了东墙塌西墙。

根本原因不是模型不够聪明，而是你把它当成了一个无所不能的全能选手。现实里没有哪个工程师能同时把架构设计、代码实现、安全审计、文档撰写都做到顶尖——AI 也一样。

于是我开始琢磨：能不能不只用一个 AI，而是搭一支 AI 工程团队？有人负责拆活，有人负责查资料，有人负责写代码，有人负责挑刺？

答案是能。工具就是 OpenCode，方法是多模型 + 多代理编排。下面是我完整配置的逐层拆解。

一、OpenCode 是个什么东西？

一句话：OpenCode 是一个开源的、跑在终端里的 AI 编程助手。

如果用过 Claude Code 或 Cursor，你对它的形态不会陌生——你在终端里跟 AI 对话，它能读你的代码、改文件、跑命令。但 OpenCode 有几个关键不同：

特性	OpenCode	Claude Code	Cursor
开源	✅ 完全开源	❌	❌
运行形态	终端 TUI	终端	独立 IDE
模型选择	任意，随便换	绑定 Claude	内置几家
插件生态	npm 插件 + MCP	有限	插件市场
多代理编排	靠插件实现	原生有限	无

对我最重要的是「模型随便换」这一点。这意味着我可以同时用智谱的 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	glm-5.1	主代理。接需求、拆活、调度全场，是我日常对话的「我」
sisyphus-junior	glm-4.5-air	初级执行员。干单文件的简单改动，便宜快
explore	MiMo v2.5	探索员。在代码库里做大规模搜索，靠 100 万窗口吃下整个项目
librarian	deepseek-chat	图书管理员。查外部文档、开源仓库、官方 API 说明
oracle	deepseek-reasoner	神谕师。最贵的推理模型，只留给最难架构题和 debug 2 次失败的硬骨头
metis	deepseek-chat	计划顾问。复杂任务动手前先做需求分析、找歧义
momus	deepseek-chat	评审官。专门挑计划的毛病，查漏补缺
prometheus	deepseek-chat	规划师。把大任务拆成可执行的工作分解
multimodal-looker	glm-4.6v	多模态观察员。带「眼睛」的代理，能看图、看 PDF、看截图（注意那个 `v`）
atlas	MiMo v2.5	通用辅助代理

这里的设计精髓是「让合适的模型干合适的活」：

搜索类重活（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	MiMo v2.5	改个 typo、单文件小改动
unspecified-low	MiMo v2.5	不归类但轻量的杂活
unspecified-high	glm-4.6	不归类但有难度的杂活
deep	deepseek-chat	需要自主研究 + 端到端实现的硬任务
ultrabrain	deepseek-reasoner	真正烧脑的逻辑题、算法、架构决策
visual-engineering	glm-4.6	前端 / UI / 样式 / 动画
artistry	deepseek-chat	需要跳出常规思路的创意解法
writing	glm-4.5-air	文档、技术写作（不需要最强模型）

看出来了吗？这是一张「任务难度 → 模型成本」的精准映射表。写文档用 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 给了我这套底座，而具体的模型搭配和代理分工，则是每个团队、每个项目都可以自定义的部分。希望这篇拆解能给你一些启发，去搭一支属于你自己的「数字工程团队」。