在OpenCode里配置AI打工仔：Flash跑腿，GLM动脑，账单砍七成
你每个月在AI调用上花多少钱？我之前没算过，直到有一天心血来潮翻了翻OpenCode的账单，直接愣住。GLM 5.2跑了那么多调用，可仔细一看，大部分活儿根本不需要它出马——列文件清单、检查JSON格式、跑测试看结果。
这些杂活儿让那个便宜又快的DeepSeek Flash干就行了，何必每次都把贵巴巴的GLM请出来。后来我在OpenCode里调了调配置，让Flash当主力干杂活，GLM退居二线当军师只负责动脑子。
账单瞬间砍了一大截，活儿干得反而更顺溜了。OpenCode本身支持多Agent协作，这套配置就是把这个特性用到了极致。
OpenCode配置文件照着这个抄
OpenCode的配置文件叫opencode.jsonc，放哪儿都行，取决于你想让这套配置管多大范围。我一般把基础配置放全局，然后每个项目单独微调。
~/.config/opencode/opencode.jsonc # 全局配置，所有项目都生效
~/.opencode/opencode.jsonc # 项目级配置，只影响当前项目
.opencode/opencode.jsonc # 仓库级配置，可以提交给团队共用
把下面这段粘进去就行：
json
{
"$schema": "https://opencode.ai/config.json",
"default_agent": "deepseek-flash",
"agent": {
"deepseek-flash": {
"description": "Primary agent. Fast, cheap orchestration for routine engineering work.",
"mode": "primary",
"model": "opencode-go/deepseek-v4-flash",
"steps": 30
},
"glm-advisor": {
"description": "Strategic advisor for second opinions, plan critique, and architecture tradeoffs.",
"mode": "subagent",
"hidden": true,
"model": "opencode-go/glm-5.2",
"steps": 15,
"temperature": 0.3,
"permission": {
"read": "allow",
"glob": "allow",
"grep": "allow",
"list": "allow",
"webfetch": "allow",
"edit": "deny",
"write": "deny",
"bash": "deny",
"task": "deny",
"question": "allow",
"todowrite": "deny"
}
}
},
"provider": {
"opencode-go": {
"apiKey": "{env:OPENROUTER_API_KEY}"
}
}
}
default_agent那行写了deepseek-flash，意思就是OpenCode每次新建会话都默认用Flash来接活。GLM那边设成了subagent模式，还藏起来了（hidden:true），平时不露面，只有被专门调用的时候才跳出来。provider那块配的是OpenRouter的API Key，OpenCode通过OpenRouter来调用这些模型。
OpenCode里Flash负责所有不用动脑子的活儿
Flash这货最大的优势就是便宜。在OpenCode里通过opencode-go这个provider调用，每百万输入token只花0.14美元。你平时让AI列个目录、读个文件、查个报错信息，消耗的token也就一两千。一次调用花0.0003美元，基本等于不要钱。而且OpenCode调用它的响应速度极快，问啥秒回，从不让你干等着。
OpenCode里每个Agent都有个steps参数，控制它能连续执行多少步操作。Flash我设了30步，处理大部分日常任务绰绰有余。比如让它把项目里所有JSON文件找出来整理成清单，或者跑一遍所有测试然后把结果汇总，这些多步骤操作它都能一口气干完。
GLM在OpenCode里就金贵多了。每百万输入token要1.4美元，是Flash的十倍。而且这家伙思考特别慢，你要是把推理强度开到最大，在OpenCode里调用一次能让你等60到120秒。你想想，我就是想看看项目里有哪些文件，结果OpenCode卡那儿两分钟才吐结果，这谁受得了。关键是列文件这种事儿，Flash给出的结果跟GLM没区别，何必花十倍的钱等十倍的时间。
所以在OpenCode里，所有机械的、重复的、步骤明确的活儿统统扔给Flash。它便宜、它快、它记性好（100万token上下文窗口整个项目代码都能记住），天生就是干杂活的料。
OpenCode里GLM只动嘴不动手
GLM在OpenCode里的角色是subagent，也就是子代理。它只负责分析问题、评估方案、指出漏洞，绝不直接动手。这个设计在OpenCode里通过permission字段来实现。
你看配置里permission那块，read、glob、grep、list、webfetch全设成allow，它能在你的项目里看文件、搜代码、读网页。但edit、write、bash、task全是deny，改不了代码、写不了文件、跑不了命令、也调用不了其他子代理。这就等于它长了眼睛和嘴巴但没长手，所有建议都通过OpenCode的任务传递机制送回给Flash，由Flash决定怎么执行。
temperature我设成0.3，这个值控制回答的随机性，越低越保守越不容易胡说八道。对于顾问角色来说，宁可保守也不能瞎编。steps只给了15步，比Flash少一半。因为GLM就是做分析的，把问题想清楚、把建议写明白就完事了，不需要执行一堆操作。
GLM在OpenCode里的工作流程是这样的：你给Flash布置任务，Flash评估后觉得需要动脑子，就通过OpenCode的task工具把问题甩给glm-advisor。GLM收到问题开始思考，输出结构化的建议，然后OpenCode把建议传回给Flash的上下文。Flash拿到建议后继续跟你在同一个会话里对话。你全程感觉不到切换，但后台其实已经完成了一次昂贵的思考外包。
给OpenCode里的军师立个规矩
在OpenCode里，你还可以给每个Agent挂专用的prompt文件。在项目根目录的.opencode/prompts/文件夹里新建一个glm-advisor.md，把下面这段粘进去：
markdown
You are a sharp, honest senior advisor. All context is inline in the prompt below.
Never reference files, external sources, or prior conversations.
Structure every response in three sections:
1. CONCLUSION -- your direct answer or recommendation in 1-3 sentences.
2. REASONING -- the key factors, evidence, or logic behind your conclusion.
3. WATCH OUT -- caveats, failure modes, or what may have been missed.
Be direct. If the question has no good answer, say so and explain why.
Do not hedge unnecessarily. Calibrate confidence honestly.
然后在配置文件里glm-advisor那个block下面加上一行："prompt": "{file:.opencode/prompts/glm-advisor.md}"。这样OpenCode每次调用GLM的时候，都会先把这个提示词塞进去，强制它按三个部分回答：先说结论，再说推理过程，最后提醒风险。
这个提示词还给它下了个死命令——别参考外部文件，别翻历史对话，所有信息都在当前问题里。这个设计是为了防止GLM在OpenCode里自己瞎联想，它只能老老实实分析你刚甩给它的那堆上下文。如果问题本身无解它也得直说，别和稀泥。这样一来你在OpenCode里看到GLM的输出，一眼就能判断它靠不靠谱。
OpenCode里的实际干活流程
在OpenCode里跑起来是这样的。你打开一个会话，default_agent是Flash，所以第一个接话的就是它。你给它布置任务，它先评估这个活儿是不是需要动脑子。
如果就是机械活儿——比如把项目里所有JS文件按大小排序，或者把测试输出里的报错提取出来分类——Flash在OpenCode里自己就干了，整个会话里GLM连眼皮都没抬一下。
但如果你问的是需要判断力的问题——比如"我这个数据库表结构在OpenCode的workflow里有什么坑"、"这俩框架选哪个更合适"、"这段异常处理的逻辑有没有遗漏"——Flash会通过OpenCode的task工具启动glm-advisor子代理，把问题连同整个会话上下文一起扔过去。然后GLM开始思考，一两分钟后给出三明治结构的建议（结论-推理-风险），传回给Flash的上下文。Flash拿到建议后可能会继续追问你更多信息，也可能会直接按照建议执行后续操作，整个过程都在同一个OpenCode会话里无缝完成。
啥时候该让OpenCode喊军师出来
怎么判断一个任务要不要在OpenCode里触发GLM？几条经验供你参考。
有标准答案的活儿全让Flash自己干。比如改日期格式、查找所有包含某个函数的文件、按模板生成配置、把日志按时间排序。这些事有明确的正确和错误之分，Flash干完你一眼就知道对不对，出不了大差错。
没有标准答案的活儿就得让Flash在OpenCode里调GLM了。比如评估两个技术方案各自的风险收益、判断一个设计是不是过度工程了、预测某个改动可能带来的连锁反应。这些问题要考虑好几个因素，不同因素之间还可能冲突，结论全靠经验和判断力，这正是GLM的用武之地。
还有一种情况：你觉得Flash给的答案不太对劲，但又说不上来哪儿不对。这时候让Flash在OpenCode里喊GLM出来当裁判最合适。GLM用更高一档的推理能力重新审视同样的问题，往往能揪出Flash忽略的细节或者逻辑漏洞。
有个小技巧：把OpenCode会话里的GLM当成高级版橡皮鸭。你不需要它真干什么，就是把问题完整描述给它，然后看它怎么拆解。有时候它的建议并不完美，但光是看推理过程，你自己就能找到解决方案了。
改完配置OpenCode的调用差别有多大
改配置之前，我的OpenCode里所有会话默认都用GLM。列个文件？GLM来。查个报错？GLM来。格式化输出？还是GLM来。每次调用都收钱，简单任务单个不贵但架不住量大，月底一看全被杂活儿吃掉了。
改完之后，OpenCode的默认Agent换成了Flash，绝大多数日常操作都在Flash这边完成了。只有碰到真正的难题才动用GLM的配额。带来的变化是：OpenCode整体响应变快了，大部分请求秒回，不用等那个漫长的思考过程。同时GLM的配额从OpenRouter那边省下来不少，可以集中用在真正需要它的地方。
有几个坑得提前知道
这套OpenCode配置虽然好用，有几个点得留意。
Flash和GLM在OpenCode里都支持100万token上下文，这个不是区分因素。别觉得Flash便宜就记性差，它一样能记住你整个代码库。
GLM在OpenCode里如果推理强度开到最大，每次思考60到120秒。如果你需要同步等它输出，那每次都得干等。建议把需要GLM分析的问题攒一批，在OpenCode会话里统一问。
权限配置里GLM只读不写，这个在OpenCode里很安全。但要注意它的读取范围。如果项目里有密钥密码之类的敏感信息，最好在OpenCode的工作区配置里排除掉。GLM虽然不能改东西，但信息泄露的风险还是要防。
GLM的输出是先传回给Flash的上下文再展示给你。如果GLM的建议特别长，Flash的上下文会被占掉一部分。建议在prompt文件里要求GLM回答尽量精炼，控制在合理长度。
算笔OpenCode的调用账
咱们算一笔具体的账。假设在OpenCode里一个月有1000次调用，每次平均消耗2000个输入token和500个输出token。
全用GLM的话：输入成本1.4美元每百万token乘以200万token等于2.8美元，输出成本按4.2美元每百万token算乘以50万token等于2.1美元，加起来一个月差不多5美元。
换成Flash加GLM的组合呢：750次简单调用走Flash，每次1500输入token加300输出token。Flash的输入输出同价都是0.14美元每百万，成本是0.14乘以1.125百万加上0.14乘以0.225百万，总共约0.19美元。剩下250次复杂调用走GLM，成本是1.4乘以0.5百万加上4.2乘以0.125百万，约1.225美元。总成本不到1.5美元。
同样在OpenCode里干活，成本从5美元降到1.5美元，省了七成。而且这还是往宽里算的，实际很多复杂调用的token消耗没这么多。
这套OpenCode配置背后的玩法
这套配置本质上是在OpenCode的多Agent框架里做计算资源的精细化调度。OpenCode本身就支持primary agent加subagent的协作模式，这个配置只是把不同模型塞进了不同角色里。
Flash干执行的活儿，GLM干思考的活儿，各司其职。OpenCode的task工具负责在它们之间传递任务和结果，用户面对的始终是同一个会话界面，底层的模型切换完全透明。
放到团队里看也很有意思。Flash就像初级工程师在OpenCode里干活，负责日常杂务和明确指令。GLM是高级架构师，只在关键决策时被拉进会话。初级工程师干95%的活儿，高级工程师只负责那5%需要判断力的部分。这才是OpenCode多Agent协作的正确打开方式。