opencode实战指南：模型无关的AI编程Agent安装配置与进阶玩法

1. 为什么我在一堆AI编程Agent里选了opencode

过去半年，AI编程Agent的更新速度真的快到离谱。Claude Code刚火起来的时候，所有人都说终端编程要起飞；接着Codex开源，又有人说OpenAI要通吃；中间还冒出pi、Gemini CLI这些新面孔。我基本每个都试过一遍，最后实际留下来长期用的，反而是opencode。理由说起来很简单：它不绑定任何一家模型厂商，你想用Claude、GPT、Gemini、DeepSeek还是其他兼容服务，改一行配置就行。市面上大部分同类工具是"套在某个固定模型上"的思路，opencode走的是"我是调度中枢，模型随便换"的路子。这个差异，用久了才知道有多重要。

opencode是SST团队开源的一个终端AI编程Agent，GitHub上叫sst/opencode，本质上是一个跑在终端里的编程助手。它能读你项目里的代码，能自己执行Shell命令，能多文件批量改代码，还能通过会话管理整个开发任务。把它想成"一个坐在你终端里、能自己动手写代码和跑命令的实习生"就行，你负责下指令和验收，它负责执行。我从它1.x版本一路用到2.0，最大的感受是：它不是玩具，是能真正干活的工具。

1.1 opencode到底解决什么问题

先理清一个容易混淆的点：opencode这种Agent和GitHub Copilot、Cursor这类AI编程助手不是一回事。Copilot是"补全器"，你写半行，它帮你接后半行；Cursor是"编辑器里的助手"，你在IDE里圈一段代码，它帮你改。opencode则完全是另外的玩法，它以"任务"为单位工作。你给它一个目标，它会自己列出计划、读代码、改代码、跑测试、看报错，再改，直到完成任务或遇到无法决定的事才停下来问你。

我举个例子。接手一个老项目时，我让它把某个模块里的TODO和FIXME全部列出来并分类，它自己遍历了目录结构，找到了几十处标记，还顺带分析出哪些是废弃代码、哪些是待实现功能。这种活儿放到Copilot里根本没法干，因为补全器没有"任务意识"；放到Cursor里也得你手动找文件、圈代码。而opencode这种终端Agent天生就适合干跨文件的脏活累活。

它解决的另一类痛点是"上下文断裂"。以前用AI助手，经常是IDE里复制一段代码，切到ChatGPT粘贴，得到答案再切回来。opencode直接把项目路径、终端输出、会话历史都串到一起，你和它的每一轮对话都建立在真实项目状态之上，不用反复解释背景。这个体验一旦习惯了，就再也回不去了。

1.2 和其他Agent的差异：能自由换模型这件事有多重要

同类工具里我单独拎opencode出来说，主要是三个差异点。

先说模型无关。Claude Code深度绑定Claude，Codex绑定OpenAI的模型，Gemini CLI绑定Gemini，pi这种新工具虽然灵活但生态还不够。opencode的模型层是可插拔的，config里指定provider和model就行。这意味着你今天用Claude写推理密集的架构代码，明天觉得DeepSeek更便宜可以切过去跑体力活，后天模型服务商出故障了还能整个换掉。省钱是一方面，更重要的是不被人拿捏，模型A涨价了、限流了、效果变差了，换B几乎零成本。这个自由度，是我最看重的一点。

第二个差异是开源和社区生态。opencode本身开源，社区贡献了一堆Skills、配置模板、插件，你遇到问题能直接翻源码，不用对一个黑盒干瞪眼。它的人气过去一年涨得很快，新功能层出不穷，很多想法都是用户提出来、社区实现的。

第三个差异是编辑器集成覆盖很全。官方有VSCode插件、JetBrains系列插件，还有独立的Desktop客户端，后面我会单独讲怎么用。

当然它也有不太行的地方。它毕竟是终端优先的设计，刚上手时配置有一定门槛，没有图形界面，很多操作要靠命令和JSON文件完成。网上搜"opencode"相关的问题，一大半是安装、配置、报错相关的，这也正常，灵活的工具必然要付出学习成本。

这篇文章我会把从安装到进阶的完整路线走一遍，重点写我实际踩过的坑，以及那些文档里不会写的经验。

2. 从零装好opencode：安装路线和Windows常见报错

opencode的安装方式有好几种，不同系统选不同路线会省很多事。我在Windows和macOS上都装过，Linux服务器上也跑过，下面按优先级来说。

2.1 一条命令安装

macOS上最省事的是Homebrew：

brew install sst/tap/opencode

装完直接执行opencode --version就能看到版本号。macOS用户要注意一下，如果之前系统没装过Xcode Command Line Tools，Homebrew会先自动装，等的时间比较久，属于正常现象。

Linux和Windows（如果有WSL）可以用官方提供的一键脚本：

curl -fsSL https://opencode.ai/install | bash

这条命令会把二进制装到~/.opencode/bin或者系统PATH下的目录，取决于脚本版本。装完最好打开一个新的终端窗口再执行opencode，因为PATH的变更不会自动同步到已开着的shell里。我第一次装完直接在当前终端敲命令，死活提示找不到，其实就是这个原因。

如果你机器上有Node.js，也可以走npm：

npm install -g opencode-ai

npm包名带不带后缀以官方文档为准，我记得是opencode-ai，因为opencode这个短名字在npm上早被别的包占了。用npm装的好处是能顺便拿到CLI的更新，缺点是有时候全局node_modules的PATH会被Node版本管理器改乱，反而出问题。

提示：如果你同时装了多个Node版本（nvm、fnm这类工具），npm全局包会装到当前激活版本的目录。切换到另一个Node版本后opencode命令又会消失，这不是安装失败，是PATH没有指向新版本的全局目录。

2.2 Windows用户最大的痛：无法将“opencode”项识别为 cmdlet

这个报错在Windows上出现频率极高，网上一搜一大片：

opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。请检查名称的拼写，如果存在路径则确保路径正确，然后再试一次。

第一次遇到这个错误的人，第一反应往往是"opencode没装好"。实际大多数情况是三个原因之一。

一是npm全局目录不在PATH里。用npm prefix -g看一下全局目录，如果输出类似C:\Users\你的用户名\AppData\Roaming\npm，那就手动把这个目录加到系统环境变量PATH。Windows设置里搜"环境变量"就能找到，加进去之后记得开新终端。

二是安装过程本身失败了。npm源慢、网络不稳定都可能导致装上了一个残缺的包，或者根本没装上。一个很笨但有效的办法是：重装一遍，看到npm输出最后的added xxx packages才算成功。

三是装完之后没有开新终端。npm安装成功了，但当前PowerShell窗口还是旧的PATH环境，直接执行当然找不到。打开新的PowerShell或Windows Terminal再试。

如果你用的是Windows自带的PowerShell，还有一个常见情况是执行策略限制导致npm的.ps1脚本被拦。如果报错文字里带着Set-ExecutionPolicy或者禁止运行脚本，可以在管理员PowerShell里执行：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

这是给当前用户放行本地脚本，不会影响系统安全性，比设置Unrestricted合理得多。

2.3 不想依赖包管理器：直接下载CLI二进制

还有一种方式适合不想装Node、也不方便用Homebrew和脚本的环境：去GitHub的Releases页面下载对应平台的预编译压缩包。Windows下下载带windows字样的压缩包，解压后里面是一个opencode.exe，把它放到一个固定的目录，比如D:\tools\opencode，然后把这个目录加进PATH。macOS就下载darwin的包，Linux下载linux的包，解压后丢到/usr/local/bin或~/.local/bin。

这个方式最可控，更新版本时下载新的替换旧文件就行，但缺点是要手动处理PATH和版本管理。我自己的做法是：主力开发机用Homebrew或npm，方便升级；CI服务器和临时环境用官方脚本来装，最大化减少依赖。如果你经常在Linux服务器上改配置，注意opencode的配置文件是JSON格式，改完要保证语法正确，不然Agent可能直接启动失败。

2.4 验证安装：跑通第一次对话

装好之后先别忙着配复杂的东西，直接执行：

opencode

正常情况下它会启动一个终端界面，第一次运行会问要不要登录模型服务商，或者直接进到可选模型的界面。选一个你常用的模型，随便问一句"你好，告诉我当前目录下有哪些文件"，如果它能正确回答，说明基本链路已经通了。

这里要注意，opencode的模型服务需要你提前准备好API密钥。它支持通过opencode auth login交互式登录，也可以手动配置API key。后者我会在下一节详细讲。

3. 模型接入与配置：从免费模型到go订阅和CC Switch的搭配玩法

安装只是开始，真正决定使用体验的是模型配置。opencode最大的卖点是模型无关，但这个优势要发挥出来，得先把配置体系搞清楚。

3.1 opencode的配置体系：全局配置和项目配置

opencode的配置分散在两个层面。第一层是全局配置，通常在~/.config/opencode/目录下，里面有两个关键文件：config.json和auth.json。auth.json存的是各个模型服务商的密钥，敏感度高，建议设置好文件权限；config.json存的是模型列表、默认模型、provider参数这些。不同版本文件名可能略有差异，最靠谱的确认方式是在opencode里运行/config命令，它会直接告诉你当前加载的配置文件路径。

第二层是项目级配置。你可以在项目根目录放一个opencode.json，里面写只对这个项目生效的配置项，比如项目专用的模型规则、系统提示词、文件忽略列表。这层配置和全局配置是合并的，项目配置优先级更高。很多团队会把项目级配置提交到Git仓库，让所有成员拿到一致的Agent行为。改配置的时候注意，JSON文件不允许写注释，我从其他工具转过来时习惯性写了//注释，结果解析失败，这个坑很典型。

改完任何一层配置，建议完全退出opencode再重新启动。虽然部分版本支持热加载，但JSON写错、字段没生效的情况，重启一次能避免很多玄学问题。

3.2 模型选型：主力模型、轻量模型和特殊任务模型

配置里最核心的就是provider和model。我的习惯是配两个以上的模型，按任务类型切换：

• 主力模型，用来干复杂推理、重构、设计类任务。Claude系列或者GPT系列都行，看你对风格的偏好。
• 轻量模型，用来做格式化、补文档、解释某段代码这类低难度任务。这类模型响应快、便宜，大批量跑不心疼。
• 特殊模型，比如某些服务商独有的大上下文模型，用来处理超大项目文件分析。

网上常说的"opencode go订阅模型选择""go套餐"，本质上属于第三方模型聚合服务。这类服务把多家模型API聚合到一起，买一个订阅套餐，就能在一个入口用上多种模型，不用分别注册各家服务商、分别充值。好处是方便，一个key搞定所有；潜在问题是稳定性完全取决于聚合服务的运营水平，你选的时候要多看口碑，别贪便宜。我一般只把它当备用渠道，主力请求还是走各家的官方API。至于具体哪家套餐划算，我不做推荐，这类服务变动太快，今天评测便宜的下个月可能就跑路了，自己用少量金额测试再决定。

在opencode里接入这类服务的方式和接官方API一样，就是新增一个provider，把baseURL指向聚合服务的接口地址，填入套餐提供的key。baseURL和provider名称一定要和服务商给的文档对得上，写错的话通常报401或者404，很难排查。

3.3 免费模型到底能不能用

免费模型这个话题，几乎每个opencode新手都会问。我的结论是：能用，而且适合入门练手，但不建议拿来干正经活儿。

免费模型的限制主要有三方面。一是响应速度普遍慢，尤其到下午和晚上的高峰时段，一个简单请求可能要等几十秒；二是上下文窗口和请求次数通常被限制得很死，稍微长一点的任务做到一半就可能被断掉；三是免费模型的服务稳定性没有保障，我之前遇到过连续几次请求都失败，半天后才发现是配额被用完了，而服务商并不会主动通知你。

如果你是第一次用opencode，想熟悉它的交互方式和功能，拿免费模型跑一跑完全没问题。但如果你真的要拿它去改生产环境代码、接手项目，我强烈建议至少用一个付费的官方API模型，哪怕是最便宜档位的，也别在模型这里过度省钱。一个错误的重构浪费的时间，早就超过API那点费用了。

3.4 用CC Switch管理多个模型渠道的密钥

模型多了之后，新的痛点出现了：密钥混在一起，想切换服务商时要改配置、填key、重启，来回操作很烦。热词里反复出现"ccswitch配置opencode"，其实就是拿CC Switch这类工具来管密钥。

CC Switch本质上是一个API密钥管理工具，支持多种AI服务商，可以一键切换当前生效的密钥配置。你可以把OpenAI的key、Claude的key、聚合订阅的key都维护在CC Switch里，测试哪家好用就切到哪家，而不必反复手改opencode的配置文件。注意，CC Switch只管密钥和渠道切换，它本身不是一个模型服务商，你还需要先把对应服务的key配置好，它才能帮你切。

配置时容易踩的坑是provider命名不一致。CC Switch里假设某个服务商的配置名是openai，而opencode里要求填openai-compatible，两者对不上就报认证失败。你打开opencode的配置文件，确认里面provider实际的id，再回到CC Switch里把对应配置改成一致的。

另外还有一个叫做oh-my-claudecode的社区配置管理项目，它更多是把Claude Code生态里的配置模板、自定义命令迁移到opencode上，让老Claude Code用户更快上手。如果你的配置是从Claude Code搬过来的，可以关注一下这类项目。

4. 编辑器集成：VSCode插件、JetBrains IDEA插件和Desktop端

很多人的使用习惯是"离不开IDE"，你让他们切到终端里敲命令，心理门槛很高。opencode官方也出了插件和桌面端，把Agent能力塞回编辑器界面里。

4.1 VSCode插件：在编辑器里直接开Agent面板

VSCode插件安装很简单，直接在扩展市场搜opencode，装完它会在侧边栏多出一个图标。点击展开后，你可以看到和终端版几乎一样的会话面板，选中代码后右键，菜单里会有发送给opencode的入口。

我的实际用法是：选中一段有疑问的代码，右键选择opencode，然后在弹出的对话框里输入"解释这段代码的作用和潜在问题"，它会把答案显示在下方的面板里；或者先告诉它全局目标，再选中相关代码，让它在这个上下文里执行修改。比起纯终端，这种模式省去了来回粘贴代码的步骤，对习惯鼠标操作的开发者更友好。

但要提醒一句：VSCode插件本质上是给终端版套了一层外壳，它调用的是本地的opencode可执行文件，Agent的核心能力不是在插件里重新实现的。如果你在插件里遇到某个功能不好用，大概率终端版也一样，这时候去查opencode本身的日志，比折腾插件配置更有效。

4.2 JetBrains IDEA插件：重度项目的正确姿势

IDEA的插件在热词里也被频繁搜索，说明用JetBrains家的开发者也不少。IDEA插件和VSCode插件的思路类似，但有一个优点：它能直接利用IDE已经建立的项目索引和LSP信息，对Java、Go、Kotlin这类大型项目，Agent对项目的理解会比VSCode那边更充分。

初次安装后，需要在插件设置里指定opencode可执行文件的路径，如果opencode已经加入了PATH，插件能自动识别。没用过的话建议手动填一下完整路径，避免PATH解析问题导致插件报"找不到opencode"。

实际使用时，我更喜欢在IDEA里用opencode做跨文件重构。比如重构一个接口，改接口定义、实现类、调用方、单元测试，这些文件分散在不同目录，人工一个个跳转很累。IDEA里选中接口名，让opencode先分析引用关系，再执行重构，效率明显提高。不过这里也有个教训：IDEA项目里如果存在大量自动生成的代码（比如protobuf生成类），Agent扫文件时容易被这些垃圾文件干扰，建议在项目级opencode.json里配好忽略目录，把build、dist、generated这些目录排除掉。

4.3 opencode Desktop适合哪些人

Desktop客户端我自己的使用频率不高，但它的定位很清晰：给完全不想碰终端的人准备。它是一个图形界面，左边是会话历史，中间是对话区，右边可以实时看文件改动diff。启动项目、选择模型、查看执行过程都在图形界面里完成，体验比终端友好很多。

如果你是从Cursor这类编辑器切换过来的，Desktop是一个不错的过渡方案；如果你本身就很习惯终端操作，Desktop的优势其实不大，因为终端版的信息密度更高、操作更快。不管用哪种前端，底层的Agent和配置是同一套，不存在"Desktop端功能更多"这种说法。

5. 进阶玩法：Skills、LSP和Playwright

装好、配好、跑起来，这只是opencode的及格线。真正让Agent从"能用"变成"好用"的，是下面这几个进阶能力。它们的共同特点是：让Agent更懂你的项目，更懂你的工作流程。

5.1 Skills：给Agent写一份操作手册

Skills是opencode支持的一种扩展机制，英文直译是"技能"。它的作用相当于给Agent一本操作手册：你告诉它在什么场景下应该怎么做。比如你的项目有严格的代码规范，你可以在skill里写"所有新代码必须通过lint才能提交"；或者对某个复杂模块，写清楚它的架构约定，Agent看到相关任务时就会自动参考。

一个标准的skill是一个markdown文件，放在项目的.opencode/skills/目录下。文件里写清楚技能的触发条件和操作步骤。我举个实际例子，团队里经常有人忘记写规范的commit message，我写了一个"commit message"技能：内容描述了触发时机（用户要求提交代码时）、检查规则（看本次改动的文件列表）、生成建议格式（type(scope): subject）。之后每次让opencode帮忙提交，它都会按这个规范来。

写Skills的注意事项：描述要具体，别写"负责提高代码质量"这种空话，要写成可执行的指令；触发条件用词要明确，"当用户要求提交代码时"比"当需要提交时"更容易命中；还有，skill不用写太长，Agent的上下文窗口是有限的，塞太多废话反而稀释了真正的规则。

5.2 LSP接入：让Agent拥有编辑器级别的代码理解

热词里有"opencode 如何使用lsp"，问的人多是因为它对Agent的帮助是质变级别的。LSP（Language Server Protocol）本来是给编辑器提供代码分析的一套协议，opencode可以接入LSP服务，让Agent直接查询符号定义、查找所有引用、获取类型信息、读取诊断错误。

这带来一个很实际的变化：以前Agent分析代码，靠的是纯文本扫描，它对"这个变量到底指向哪个函数"这样的问题理解很弱。接入LSP后，Agent可以像IDE一样精确跳转到某个符号的定义，知道一个函数在哪些地方被调用，改签名时能列出所有影响点。这种能力在处理大型项目时非常有用。

配置方法并不复杂，在opencode的配置里添加lsp相关字段，指定语言服务器的启动命令。比如对Python项目，你可以配置基于Pyright的language server；对TypeScript，可以配置typescript-language-server。具体命令名称和格式，以你安装的语言服务器为准。

我的避坑经验是：不要一口气给所有文件类型都配上LSP。每启动一个LSP服务都要占系统资源，项目大、文件多的时候，开启太多服务会让Agent的响应变得很慢。先给最核心的语言配上，比如主开发语言和配置文件类型，跑顺了再逐步加。

5.3 用Playwright让Agent自己复现并定位前端Bug

这个玩法是我最近用得很爽的一个，热词里也在搜"opencode playwright 怎么测试前端bug"。它的核心思路：让opencode调用Playwright，启动浏览器，自动操作页面，复现你描述的前端问题，然后把console报错、接口返回、DOM状态反馈给Agent，由Agent进一步定位问题根源。

我讲一次真实经历。有个项目里用户反馈"表单填写完失焦后数据丢了"。复现步骤繁琐，人工点要好几步。我在opencode里写了一个"前端bug复现"的skill，里面定义了标准流程：先启动开发服务器，然后打开指定页面，按描述点击、输入、失焦，截图，把结果返回给Agent。那一次它自动打开了页面、填入了测试数据、触发失焦，然后捕获到一个反序列化的异常信息，定位到了是某个字段类型解析的问题。整个过程我只负责最后验收它改的代码。

这个能力的价值在于，它把"人肉复现bug"这个最耗时、最枯燥的环节自动化了。但也要注意，Playwright的浏览器环境和真实用户环境有差异，有些依赖真实设备身份才能复现的问题，它不一定能覆盖到。它适合的是逻辑性、交互性bug，对纯视觉细节、特殊机型问题帮助有限。

5.4 接手开发项目：让opencode当你的引导员

热词里"opencode接手开发项目"被搜得很多，这其实是Agent工具一个被低估的场景。你接手一个完全陌生的老项目，第一件事往往是搞清楚项目结构、入口、构建方式、依赖关系。传统做法是自己在IDE里翻，或者问同事；现在这些"读代码"的活完全可以交给opencode。

我的建议是按"先宏观后微观"的节奏来。第一轮，让opencode从项目根目录开始，生成一份项目结构总览，注明每个目录的职责；第二轮，让它定位入口文件和核心流程；第三轮，挑一个真实的功能链路，让它把调用关系捋清楚。每轮对话建议开在新的session里，避免前面分析的噪声干扰后面的任务。

接手老项目还有个非常值钱的地方：让opencode帮忙检查废弃代码和危险逻辑。曾经有一个项目，Config文件里塞了一个用不到的数据库连接池，年久失修，一启动就报错。就是靠opencode全局搜索引用后反馈的"这个连接池只在启动时初始化、从未被任何业务代码调用"。这种结论，人工排查可能要耗一下午，Agent几分钟给出来了。不过它给出的结论务必人工二次确认，Agent的分析有时候是对的，有时候是错的，只有你想清楚原理后，才会真正获得对这个项目的认知。

6. 高频报错排查：两个典型错误与一套配置避坑清单

用opencode这类工具，报错是常态，尤其是在配置模型阶段。热词里被反复搜索的两个错误，我一个个拆。

6.1 "this model is not available in your country"怎么办

这个报错的字面意思是"你所在区域无法使用该模型"。我第一次遇到时也很懵，明明是同一个API key，为什么有些模型能用、有些不能用？

结合我后来多次排查的经验，这个提示通常不是opencode本身的问题，而是模型服务商对模型的开放范围有限制。可能是你当前的API账户所属区域不在该模型的服务范围内，也可能是该模型还没对你所在地区开放，还有可能是模型名称填错了，实际映射到了另一个有限制的模型。

我的排查顺序是这样的：首先检查模型名称是否和服务商文档里写的一模一样，包括大小写和连字符；其次去服务商的控制台或官方状态页，确认这个模型是否对当前的key类型开放；然后换一个同时代的替代模型，比如文档里标注了对其他区域开放的同系列版本；最后如果还不行，就考虑换一家服务商提供相同能力的模型。opencode本身是模型无关的，换个渠道往往是最快的解法。

需要特别提醒别做的事：遇到这类限制，不要尝试去绕过服务商的区域限制。一方面是这么做违反服务商的使用条款，另一方面就算你强行连上，稳定性、数据安全都不可控。正确的处理方式永远是确认授权范围，或者换一个合法可用的模型。这类问题大概率是暂时的，服务商开放范围是动态调整的，过段时间再检查一次，说不定就解决了。

6.2 "unexpected server error. check server logs"

这个错误在运行opencode时也经常出现。完整报错通常长这样：

opencode error: unexpected server error. check server logs.

它的含义很宽泛：Agent在调用后端的某个服务时，后端返回了一个非预期的异常。我把最常见的几个原因列出来。

第一，认证问题。API key过期、没权限、额度用完了，有时候不会直接报401，而是包一层"server error"抛出来。先检查auth配置，换一个确定可用的key试试。

第二，模型服务商网关抽风。第三方聚合服务的稳定性参差不齐，高峰期经常返回这种模糊错误。可以看服务商的状态页，或者等几分钟重试。

第三，检查opencode自身日志。你可以用opencode --log或者查看日志文件目录（通常在~/.local/share/opencode/log/或%USERPROFILE%\.local\share\opencode\log\），日志里会有真正的错误原因。日志这东西平时没人看，但排查问题时它是第一个要看的东西。

第四，本地环境问题。磁盘满了、内存不够、临时目录不可写，都可能触发这种错误。我遇到过一次是/tmp目录权限被改坏了，opencode写临时会话文件失败，报的就是这种不具体的错误。

排查顺序建议是：先看日志，再验密钥，再重启，最后检查本地环境。按这个链路走，90%的情况能定位到问题。

6.3 一套配置层面的避坑清单

最后总结几条配置层面的通用避坑经验，都是我实际踩过的：

• 修改JSON配置时注意JSON格式，opencode的配置文件不允许写注释，很多人从其他工具转过来习惯在配置里写//注释，一写就解析失败。想加注释，看下这个版本的opencode是否支持jsonc格式，不支持就老老实实只写JSON。
• API key不要直接明文写进config.json，更不要提交到Git仓库。推荐用opencode auth login或环境变量的方式注入，密钥泄露这种事，一次就能让你后悔。
• 项目根目录的opencode.json会覆盖全局配置，但两者不是互斥关系。遇到"明明改了配置却不生效"的问题，先想想是不是有项目级配置把你覆盖了。
• 不要把模型名写在很老的习惯里。opencode和各家模型提供商都在快速迭代，旧的模型可能下架、改名，配置里用到的模型ID如果经常报错，去官网文档确认它是不是已经过期。
• 改了配置不生效时，先重启opencode，再去查文档。虽然热重载功能在一些版本里开了，但配置文件路径、字段名这些变化，重启永远是最快最有效的验证手段。

说实话，opencode这类工具现在还在快速变化期，今天写的配置方式，过几个月可能就有新语法。但它的核心思路是不会变的：一个模型无关、可编程、能自主干活的终端Agent。我从开始用到现在，最大的体会是它逼着我重新整理了项目——配置、规范、文档越清晰的项目，Agent干活越靠谱。反过来，代码一团糟、没有测试、文档全无的项目，换再强的模型也无济于事。工具是放大器，它放大的是你本来就有的人。这句话放到opencode身上，再合适不过。