这两年终端里的AI编程助手越来越卷，从Claude Code到Codex再到各种名字都记不全的开源项目，基本是每季度换一波主力。我大概在半年前开始重度使用opencode，最开始只是抱着“再试一个新工具”的心态，结果它到现在还留在我日常工作流里，成了接手陌生项目、跑前端bug复现、写跨模块改动时最顺手的一个agent。这篇就把我实际安装、配置、接入IDE、排查问题的过程完整写出来，包含踩过的坑和一些网上不太会写到的细节，想上手opencode的朋友照着做基本能少走弯路。
1. 先从整体认识opencode：它不是又一个套壳终端
1.1 它到底是谁家的孩子
很多人在搜“opencode是哪家公司的”。据我了解，opencode是由SST团队开源并维护的AI编程agent项目，这个团队之前做过Serverless开发工具，在开发者圈子里口碑一直不错。opencode从一开始就走的是开源路线，代码仓库直接公开，采用类似MIT的开源许可，这也是为什么你能看到社区里冒出各种发行版、插件、桌面封装和Go重写版本。
这个项目的定位非常明确：做一个跑在终端里的AI编程代理，而不是简单地把大模型聊天框搬进命令行。它跟“问你一句、回你一段代码”的辅助工具有本质区别，它的工作方式是：你给它一个目标（比如“修复这个登录页在Safari下的样式问题”），它会自己读取项目文件、搜索代码、调用工具、执行命令、看测试结果，然后反复迭代直到任务完成。用一句话概括，它像一个能自己动手写代码、跑测试、查日志的实习生，而你需要做的只是把需求讲清楚。
我自己的感受是，opencode最值得被当成主力agent的原因有三个：一是它对项目上下文的处理比较细腻，能区分全局配置和项目级配置，不会把A项目的偏好带到B项目里；二是它的工具调用能力扎实，从读文件、改文件到跑playwright测试、执行shell命令，覆盖面很广；三是它的交互设计适合真实开发场景，支持多session管理，开着好几个任务的上下文互不干扰，这对同时盯多个 bug 的人来说太重要了。
1.2 它解决的核心问题是什么
我们平时用AI写代码，最常见的一个挫败感是：AI没头没尾，你不给它足够上下文，它就只能瞎编；你给它一堆上下文，它又分不清主次。opencode解决的正是“上下文管理”这个核心问题。
它会在当前项目里维护一个可复用的上下文体系，包括会话历史、项目规则、用户自定义的skills、长期的memory记录。你在项目根目录放一个配置文件，它就能自动读取项目约定（比如代码风格、目录结构、测试命令），下次再开新会话，这些约定仍然生效，不用每次重复交代。对接到具体任务的时候，它可以自主决定先读哪几个文件、运行哪条测试命令，而不是每走一步都回来问你“接下来怎么办”。
另一个解决的实际痛点是“多工具链切换”。以前我要先开一个终端跑Claude Code，再开一个终端跑Codex，还要记得哪个项目用了哪个配置。opencode本身支持对接多家模型服务，再加上ccswitch这类配置管理工具之后，一台机器上配置多套模型供应商、按项目切换、按成本切换都变得很自然。这个后面我会专门展开讲。
1.3 一个关键词：Agent 工作流
如果你想用opencode，脑子里要先建立“Agent工作流”这个概念，否则很容易用错。
传统的人机交互是“你问我答”：我说一句，模型回一段，我再改一下prompt，它再回一段。Agent工作流不一样，它是“目标导向的自主循环”：我把最终目标告诉模型，它自己拆解计划、调用工具、执行动作、观察结果、调整策略，直到目标完成或确认无法完成。在opencode里，你经常会看到它自己跑起一条测试命令，看到失败后主动去改代码，然后再跑一次测试，整个过程你可以在旁边看日志，也可以随时打断纠正方向。
这个转变带来的好处是效率质变，但坏处是初次使用会有点不习惯，总想在每一步都干预它。我的建议是，给它一个足够清晰的目标和边界条件，第一次让它自己跑完整个循环，然后再看它的决策路径。你会发现大多数时候它比你想象中靠谱，但也确实需要你预留好足够安全的运行环境，比如别让它在生产仓库上随手执行破坏性命令。
2. 安装与起步：从零到跑通第一条命令
2.1 安装方式与版本说明
opencode目前有几个常见的安装渠道，我根据自己的使用经验把它们整理成了一张表：
| 安装方式 | 适合场景 | 注意事项 |
|---|---|---|
| npm全局安装 | 日常终端使用，最省事 | 需要Node.js环境，版本不低于18 |
| go install | 喜欢单二进制、部署简单 | 需要Go工具链，二进制名字可能是opencode |
| GitHub Release下载 | 不想装运行时，下载即用 | 注意选择对应操作系统和CPU架构 |
| 桌面客户端 | 习惯图形界面 | 本质上还是调CLI，适合轻度使用 |
我自己目前主力用的是npm安装的方式，原因很简单：升级方便，一条npm update -g opencode就完事，而且npm包装好了各种依赖，不用自己手动处理动态库问题。如果你在受限的内网环境，或者你是个“洁癖型”用户，就喜欢那种一个二进制文件到处拷的部署方式，那Go安装版会更合你胃口。
顺带提一句，opencode对Node版本是有底线的，我最早在一台老开发机上折腾了半天装不上，最后发现是Node版本停在16，换了Node 20之后一次通过。建议新装之前先node -v看一眼，别让版本问题浪费二十分钟。
2.2 我把 opencode 装成了"Go版"与"客户端版"
聊聊这个“Go版”是怎么回事。opencode官方主仓库早期以Node/TypeScript为主，但社区里一直有用Go重写的版本流出来，性能更好，内存占用更低，而且对那种“只装一个二进制、要拷到服务器上用”的场景非常友好。我在一台内存比较小的云主机上部署过Go版，跑一个中型Python项目，长期占用的内存确实比Node版低不少。
不过Go版有一个让我折腾了半天的点：配置文件路径和官方版不完全一致，它不会自动读取npm全局目录下的那份配置。如果你同时在用npm版和Go版，建议把配置文件单独放到~/.config/opencode/这个标准路径下，两边都能读到，不需要各写一份。而且Go版配合ccswitch这类工具会更顺手，因为ccswitch本来就是跨工具管理配置的，能同时给opencode、codex、claude code设置模型供应商，省得三个工具各搞一套环境变量。
“桌面版”也值得提一句。opencode桌面版本质上是把CLI包了一层图形界面，支持新建会话、查看任务日志、管理多个项目入口。我实际体验下来，它最大的价值不是替代终端，而是让不熟命令行的同事也能上手用opencode，相当于把agent能力做成了一个团队可见的“小工具”。重度用户还是建议回到终端或IDE插件里操作，因为桌面版的交互深度目前还追不上原生CLI。
2.3 "无法将 opencode 识别为 cmdlet"到底卡在哪
这个报错是Windows PowerShell下最常见的坑，描述通常是：
opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。看到这个不用慌，本质就一句话：系统找不到opencode这个可执行文件。原因是npm的全局包安装好了，但npm全局bin目录没有被加到当前用户的PATH环境变量里。
解决分三步：
- 先找到npm全局bin目录，执行
npm prefix -g，在Windows上通常会得到类似C:\Users\你的用户名\AppData\Roaming\npm的路径。 - 把这个路径加到系统PATH里，可以通过“系统属性 -> 环境变量 -> Path -> 编辑 -> 新建”添加。
- 重新打开PowerShell或终端，再执行
opencode --version验证。
如果是macOS或Linux，报错通常是command not found: opencode，检查方向一样：确认npm的global bin目录在不在PATH里。macOS上如果用的是新版Node，路径可能是/opt/homebrew/bin，Linux上则很可能是/usr/local/bin或/usr/bin。
另外还有一种隐蔽情况：你明明已经配置了PATH，但那个终端窗口是配置PATH之前就打开的。Windows上PowerShell对环境变量的读取是会话级别的，改完PATH必须新开窗口。我经常看到同事改完环境变量之后在旧终端里反复重试，这就属于纯纯的时间浪费了。
3. 配置与模型接入：让 opencode 真正干活的几个关键姿势
3.1 配置文件与环境变量
opencode启动之后会按顺序加载配置，优先级从高到低大概是：当前项目的配置文件 > 用户目录下的全局配置 > 环境变量。项目级配置我习惯放在项目根目录的opencode.json里，全局配置则放在~/.config/opencode/opencode.json。
一个最简配置长这样：
{ "$schema": "https://opencode.ai/config.json", "model": "gpt-5", "theme": "opencode", "autoupdate": false }如果你同时配置了多套模型供应商，还可以把不同场景拆成独立配置块，比如用codex命名一个OpenAI系模型的工作区，用general命名一个日常问答场景。opencode支持在会话里用斜杠命令快速切换当前使用的模型和配置块，这个比反复改环境变量或者重启进程高效太多。
环境变量这块，官方主推的是各模型服务商的标准key，比如Anthropic的ANTHROPIC_API_KEY、OpenAI的OPENAI_API_KEY，opencode会识别这些标准变量名，所以你在别的工具里已经在用的key，通常不用重复配置。需要注意的是一些自建或私有化部署的模型服务，它们的key变量名是自定义的，需要你映射到opencode能识别的字段上，否则会出现“配置看着是对的，但请求一直401”的问题。
3.2 模型接入：官方 API、本地模型与第三方兼容端点
很多人关心opencode能不能免费用，这个问题得拆开说。
最省心的路径是直接用云厂商的官方API，按token计费，没有“套餐”概念，用多少算多少。opencode官方支持的模型提供商包括常见的OpenAI、Anthropic、Google Gemini等，配置方式就是在环境变量里放好对应的key，然后会话里/models切换即可。官方API的稳定性和数据安全边界最明确，我建议在公司项目、涉及敏感代码的场景一律走这条路。
第二个选择是本地模型，比如通过Ollama或LM Studio跑一个本地模型，把opencode的baseURL指到http://localhost:11434/v1，模型名填你本地起的名字。这种方式的好处是零API费用、数据不出本机，适合处理一些不方便外发的代码片段；坏处是模型能力上限摆在那，写业务代码还凑合，做复杂的bug诊断和多文件重构就比较吃力，硬件要求也不低。
第三个是社区里很常见的“兼容端点”方式，也就是使用一些与OpenAI接口格式兼容的服务地址。这里我要特别提醒一句：接第三方不正规的免费端点风险很高，一是随时可能下线，根本不给缓冲期；二是你的代码片段会被第三方服务器拿去做什么完全不可控。我的原则是，本地开发练手可以玩一玩，但正经项目别用。
3.3 skills 与 memory：把 Agent 调教成"老员工"
opencode让人愿意长期使用的关键功能，其实是skills和memory，这两样搭配起来，能把一个“什么都不知道的新人”调教成“熟悉团队规范的老员工”。
skills可以理解为给agent预设好的行为说明书。你可以写一个前端修复的skill，内容规定：接手前端bug时，先读package.json了解技术栈，再跑一遍现有测试，定位到最小复现路径，修复后用playwright做一遍回归验证。这样一来，以后每次提到“用前端修复的方式来处理”，opencode就会自觉按照这套流程走。我日常会为常见任务写几个固定skill，比如“README更新”“接口联调”“数据库迁移”，长期下来省掉的prompt时间相当可观。
memory解决的则是跨会话的“记性”问题。opencode会把一些项目事实、用户偏好、历史结论写入memory，下次开新会话它能自动带上。比如我处理过一个老项目，里面某个接口总是返回多余的字段，我在之前的会话里确认过“这个字段前端没有依赖，不要动”，这条记忆会保留下来，避免下次它“自作主张”把字段清理掉。配置里可以单独指定memory的存放路径，团队协作时可以放在共享目录里实现记忆共享，不过要小心隐私信息被写进去。
安装社区skill也不难。网上有沉淀好的skills合集，比如“superpowers”这类打包好的能力集，里面包含了代码审查、重构、写测试等一系列现成技能。opencode提供了安装命令，装完之后在会话里用对应名字触发即可，基本上就是抄作业的快乐。
3.4 用 Playwright 让 Agent 自己验证前端 bug
opencode内置了对Playwright的调用能力，这意味着它不只是“写代码给你看”，而是能真的把浏览器跑起来，打开页面、点击、截图、抓控制台报错。这个能力在前端bug修复场景里简直是大杀器。
我常用的流程是这样：把bug描述发给opencode，它先定位相关组件代码，然后自己写一个Playwright脚本，把复现步骤串起来，比如“打开登录页 -> 输入错误密码 -> 点击登录 -> 断言出现错误提示”。脚本跑起来如果报错，它会根据报错信息回去改代码，改完再跑一次，直到通过。整个过程我只需要最后检查一遍代码改动合不合理，不需要自己手动复现bug，也不用反复截图给AI描述页面状态。
这里有一个很关键的实践经验：一定要让opencode先跑基线测试，确认“bug在修复前确实存在”。如果跳过这一步，agent很容易陷入“自己写测试、自己改代码、自己验证通过”的自嗨循环，最后改出来的东西可能根本没碰到真正的bug。我给opencode定了一条规则：修复任何前端bug之前，必须先提交一个能复现原问题的失败用例。这条规则让我用agent时的返工率下降了很多。
4. 把 opencode 塞进 IDE：VSCode 与 JetBrains 插件体验
4.1 VSCode 插件：省掉来回切窗口的心烦
如果你主力编辑器是VSCode，很推荐装opencode官方插件。装上之后，左侧侧边栏会多出一个opencode面板，你可以在不离开编辑器的情况下直接发起agent任务。
这个插件比终端好用的地方在于它能自动感知当前打开的代码。比如我正盯着一个报错文件，直接在侧边栏问“这个文件里xxx函数为什么老是超时”，它会把当前文件内容连同项目结构一起作为上下文，回答的命中率明显比在终端里从零描述要高。同时，插件会把agent生成的代码改动以diff形式展示出来，我可以直接在编辑器里review，合适就接受，不合适就丢弃，这个体验比终端里糊成一团的输出好太多了。
插件还有一个我很喜欢的功能：把会话里生成的代码片段一键插入光标位置。这省去了“从终端复制 -> 切换窗口 -> 粘贴”的繁琐过程。对于喜欢频繁用agent写小函数、补测试用例的人来说，这个交互非常顺滑。
4.2 JetBrains IDEA 插件：Java 项目里也别缺席
JetBrains系（IDEA、PyCharm、GoLand等）同样有opencode插件，我主要是在一个老Java项目里用。这个项目的构建体系特别复杂，Maven多模块、私有仓库、各种profile，之前用终端版opencode经常因为拿不到正确的classpath导致分析不准。
换成IDEA插件之后，情况明显改善。它会把IDE里当前打开的项目模块、运行配置、依赖信息同步给opencode，agent在理解“哪些类是当前模块的”“跑哪个配置能启动服务”这些问题时准确率高了不少。而且IDEA插件可以直接调用IDE内置的Run/Debug能力，opencode说“我跑一下这个测试”，它真的会在IDE里起一个测试任务，测试结果也能回传给agent做下一步判断。这个闭环在改Java代码时比纯终端舒服太多。
不过也要说句公道话，JetBrains插件目前的功能丰富度比VSCode版略少，一些高级配置项在图形界面上还没有暴露，还是得靠改配置文件。好在大部分配置是通用的，项目里那份opencode.json两边都能复用，不需要重复配置。
4.3 终端派和 IDE 派怎么共存
我见过不少人在“终端用opencode”还是“IDE插件用opencode”之间纠结，其实这两者完全可以共存，负责的任务类型不一样。
终端版适合批量任务和长任务，比如“把整个项目里所有过时的API调用统一替换掉”“给一个老模块补全单元测试”，这类任务不需要我实时盯着文件，我可以让agent在终端里慢慢跑，自己去做其他事。IDE插件版适合局部小改动和需要人审阅的任务，比如此时此刻正在改一个函数，顺手让agent分析一下有没有边界问题，这种高频轻量的交互更适合放在编辑器里。
需要注意的一个坑是：如果你同时开着终端版本和IDE插件版本操作同一个项目，它们默认使用的session是各自独立的，容易出现“终端里已经改过的东西，IDE插件不知道”的情况。我的习惯是团队开发时统一约定一个入口，避免两边各改各的最后冲突；个人项目则随意，偶尔交错也没事。
5. opencode 实战：从接手陌生项目到完成一次修复
5.1 第一步不是写代码，是先读仓库
接手一个陌生项目的痛苦，很多程序员都深有体会：不知道入口在哪、不知道测试怎么跑、不知道目录结构为什么这么拧巴。opencode把这些信息获取的过程自动化了。
我第一次用它接手一个陌生项目时，先做了一件事：在项目根目录打开会话，输入/init之类的初始化指令，让opencode把项目扫描一遍。它会把项目的技术栈、构建命令、测试命令、代码目录分布、环境变量要求等信息总结出来，并写进项目级别的配置文件。之后所有新会话都会自动带上这些信息，我不需要再重复回答“我们这是一个Java项目，用Maven构建，测试用JUnit”这种基础问题。
这一步的价值在接手老项目时尤其明显。老项目之所以难搞，不是因为代码复杂度有多高，而是因为“潜规则”太多了：有些目录是自动生成的不能手改、有些测试需要连外部依赖、有些模块之间靠硬编码路径耦合。opencode在读取仓库的同时也会尝试从历史会话和memory里提取这些潜规则，所以我每解决一个问题，项目配置里就多一条经验，这个项目对opencode来说就越“透明”。
5.2 一次完整的前端提 bug -> 修复 -> 验证闭环
我用一个真实场景来解释一下完整流程。同事提了个bug，说“首页搜索框在联想词出现后，点击空白区域不会收起联想框”，这个问题听起来简单，但涉及事件冒泡、点击区域判断、React状态管理好几层。
我直接把bug描述扔给opencode，它大概干了这么几件事：
- 先搜索了首页搜索框相关的组件文件，确认使用的是React。
- 找出现有的事件绑定代码，发现点击空白处时，事件处理逻辑里没有判断“联想框是否打开”，导致状态没有正确关闭。
- 修改代码，在外部点击事件里补上了对联想框状态的判断和重置。
- 用Playwright写了一个测试脚本：打开首页 -> 点击输入框 -> 输入关键词 -> 等待联想框出现 -> 点击页面空白处 -> 断言联想框隐藏。
- 运行脚本，第一次跑的时候发现联想框还是没消失，它打印了控制台日志，发现事件绑定的容器层级不对，又调整了一下监听器挂载位置。
- 再次运行测试，通过。
整个过程大概花了不到十分钟。如果是我自己来，光“复现bug -> 定位问题 -> 写测试验证”这一个闭环少说也要四十分钟。opencode在中间遇到的波折它自己就消化了，我只负责在最后review了一下diff，确认改动没有影响到其他交互，然后合入。
5.3 涉及 Maven / Java 项目时的一个细节
很多人问“opencode mvn配置”是怎么回事，我猜是在Java项目里使用opencode时遇到了Maven环境相关的问题。
普通场景下，opencode通过shell执行mvn test之类的命令，只要能找到mvn命令就行。但如果你在IDE插件里使用，或者agent需要用maven的某个特定profile才能拿到正确的依赖，那就需要在配置里显式指定。比如：
{ "commands": { "test": "mvn test -P dev" } }这样opencode再跑测试时，会使用你指定的Maven命令，而不是自己猜。还有一个常见坑是：某些Java项目依赖需要通过maven wrapper（也就是./mvnw）来执行，直接喊mvn会报“找不到命令”或者“依赖无法解析”。出现这种情况时，把commands里的命令改成./mvnw就行。这算是我在Java项目里踩得比较多的一个坑，写出来给你们避一避。
5.4 与 codex、claude code、pi 的横向对比
我常被问到“opencode、Codex、Claude Code、pi，到底哪个好用”，说实话这种问题没有标准答案，因为不同工具的侧重点完全不一样。我只能说说我的主观体验。
| 工具 | 优势 | 短板 | 适合场景 |
|---|---|---|---|
| opencode | 配置灵活、skills/memory生态好、IDE插件全 | 上手成本略高，需要自己调教 | 长期项目，重度agent用户 |
| Claude Code | 自然语言理解强、写码质量高 | 模型源相对单一，定制性弱 | 快速原型、文本生成类任务 |
| Codex | OpenAI系模型，工具链统一 | 在复杂项目上下文处理上不占优 | 熟悉OpenAI生态的用户 |
| pi | 交互轻量，新手友好 | 功能深度和扩展性一般 | 轻度试用、简单问答 |
我的实际分工是：opencode负责需要深度操作项目的脏活累活，比如跨文件重构、老项目接盘、自动改bug；Claude Code留在一些偏分析和写作的任务上，比如代码评审、技术方案设计；Codex反而是应急用的，比如快速写一个脚本、做一个一次性数据清洗。工具之间不是敌人，能配合好就是好工具。
6. 常见问题与排查技巧实录
6.1 命令找不到 / PATH 失效
这个问题前面已经详细讲过了，我在这里再补充一个非常隐蔽的情况：如果你是通过打包下载的opencode桌面版或IDE插件，插件内部可能在用它自己打包的opencode二进制，而不是你PATH里的那个。此时你在终端里升级了opencode，但插件里还是旧版本，行为不一致。
排查思路很简单：在IDE插件设置里找到opencode可执行文件的路径，看它指向的是哪个二进制。如果指向的是插件内置版本，把它改成你PATH里实际安装的那个路径，这样终端和IDE共用一套版本，省得出现“终端能跑、IDE报错”的灵异事件。
6.2 unexpected server error：服务端报错怎么查
报错信息Error: unexpected server error. check server logs是很多人的噩梦。它看着像是opencode自己崩了，实际上绝大部分情况是模型服务端返回错误，opencode只是把错误透传出来了。
排查方向按优先级排序：
- 检查API Key是否有效，有没有过期或者额度耗尽。
- 确认当前模型名是否真实存在，很多服务商改了模型名之后，配置里还是旧的。
- 检查自定义的baseURL是否能连通，可以单独用curl打一下接口看返回。
- 看opencode的日志，日志里通常会带出服务端返回的detail信息。
我的习惯是给opencode配置一个logs目录，出问题先翻一遍agent日志，再结合服务商的响应顺手排查，基本能定位80%的问题。如果日志里没有任何服务端返回细节，那就要回到网络连通性上看，但这里就涉及到具体环境了，得自己判断。
6.3 免费模型突然不可用 / 第三方端点下线
经常看到有人问“xx免费模型下线了吗”，说实话，第三方免费端点本身就不是一个可靠的服务形态，它的可用性取决于提供者的资源和心情，今天能用不代表明天还能用。
如果你遇到原本能用的模型突然报错，我的建议是：
- 第一，去项目的issue列表或社区看一下有没有公告，确认是不是大范围失效。
- 第二，如果只是个别请求失败，可能是限流，等几分钟再试。
- 第三，如果确认端点已经挂了，果断切换备用方案，平时就要准备好至少两套可用的模型配置，免得被突然断供打乱计划。
- 第四，也是最重要的一点：生产环境或重要项目，老老实实用官方API或自建服务，别把核心流程绑在免费的第三方端点上。
这不是说不能用免费资源，而是要有“随时可能掉线”的心理准备和组织预案。我吃过的亏是项目上头催得急，模型却限流，最后紧急换配置浪费了小半天。吃过一次亏以后，我现在任何项目都会预留备用模型配置。
6.4 ccswitch 这类工具怎么配合
ccswitch的定位是一个配置管理工具，它能统一管理codex、claude code、opencode等多个agent工具使用的模型供应商配置。名字里的“switch”就是切换的意思，你可以在不同的模型供应商配置之间一键切换，而不用手动改环境变量。
我用ccswitch配合opencode的场景主要有两个。
第一个是不同项目用不同模型。我有些项目用OpenAI系的模型，有些用Anthropic系，以前每个项目要单独写环境变量脚本，切来切去很累。ccswitch允许我按项目绑定模型配置，在项目目录下执行一条命令就能生效，opencode读取到的自动就是对的key和模型。
第二个是成本控制。有些轻量任务我不想走贵的模型，会用ccswitch切到一个性价比更低的配置，跑完再切回来。这个过程很快，基本不影响思路。
需要提醒的是，ccswitch本身是社区工具，功能迭代很快，界面和命令也可能变化。用的时候仔细看它的README，尽量选择官方推荐的配置文件格式，避免和opencode自己的配置体系冲突。
6.5 一些性能与体验上的细节
最后聊几个体验层面的细节，可能不致命，但很影响日常手感。
第一个是内存占用。Node版opencode在长期运行时内存会缓慢上涨，尤其是有大量文件监听和长会话的时候。我试过在内存16G的笔记本上同时开三个opencode会话，内存占用冲到3G以上，机器明显变卡。解决方案是及时关闭不用的会话，或者换Go版。实测Go版在同样的任务负载下内存占用能低一截。
第二个是终端输出过多的问题。opencode在执行任务时会输出大量中间过程，包括它read了哪些文件、执行了什么命令。如果是简单任务还没什么，复杂任务时终端会被刷屏，反而看不清楚关键结论。我习惯把日志等级调低，只保留关键节点和最终结果。
第三个是自动更新的策略。opencode默认在启动时会检查更新，但如果你经常用旧版本配置文件，新版可能引入不兼容变更。我一般会把autoupdate关掉，只在确定需要新功能时手动更新，这样可以避免“怎么配置没变，行为却变了”的困扰。
这个部分说完，我基本把opencode从安装到日常使用的全流程都过了一遍。最后再分享一个我个人的小习惯：我会在每个月月初花一点时间整理自己积累的skills和memory，把上个月踩的坑沉淀成新的配置规则。因为agent工具真正拉开差距的，从来不是模型本身有多强，而是你对它的调教深度。工具是通用的，使用工具的经验才是你自己的护城河。
