最近在终端里写代码的流程又有了变化。以前是IDE里开一个对话面板，让AI帮我补全函数、解释报错，然后我手动复制粘贴代码。现在主流玩法变成了终端Agent，AI不再只是“回答问题的助手”，而是真的能自己跑测试、读文件、改代码、提交commit。opencode 就是这类工具里讨论度非常高的一个，它的定位介于 Claude Code 和 Codex CLI 之间，但又是开源、模型无关的，也就是说你今天用 Anthropic 的模型，明天想换 OpenAI 或者本地模型，都不需要换工具。这篇内容我打算把它从安装配置到真实项目里的使用经验完整过一遍，尤其会重点讲 Windows 下那些莫名其妙的报错、Skills 和 Memory 的坑，以及它跟其他终端 Agent 到底怎么选。
1. 先搞清楚：opencode 到底是什么，它解决了什么问题
1.1 从“对话式补全”到“能自己动代码的终端Agent”
如果你只用过 GitHub Copilot 或者 Cursor 这类 IDE 内置的 AI，刚上手 opencode 可能会有点不习惯。因为它不是给你逐行补全的，而是一个跑在终端里的 Agent，它的工作方式是：你给它一个任务描述，它会自己分析项目结构、读取相关文件、决定改哪些地方、执行命令、看测试结果，然后带着上下文继续做下一轮，直到任务完成。
这个差异很关键。以前我们用 AI 编程，本质上还是“人主导、AI 辅助”：代码还是你自己写，AI 只是帮你补全、帮你查资料。而 opencode 这类工具是“AI 主导、人审查”：你告诉它目标，它负责把活干完，你在旁边看 diff、提意见、指挥方向。它不再是一个增强编辑器体验的插件，而是一个团队成员。
我第一次用 opencode 的时候，让它去修一个仓库里的测试失败。它做的第一件事不是直接改测试断言，而是先把相关源码文件打开看了一遍，然后用rg搜索所有可能影响这个测试的函数调用链，改完代码之后自己跑了一遍测试，发现还有两个用例挂了，又接着修，最后把所有用例跑绿了才停下来。这个体验完全是另一个量级。
1.2 为什么我把它选成主力工具，而不是继续用那些 IDE 内置助手
选项很多，但 opencode 有几个点让我觉得值得换过去。
它是模型无关的。这是最核心的一点。大多数终端 Agent 工具会绑定自家模型，但 opencode 背后接的是标准化接口，你可以配置 Anthropic、OpenAI、Gemini、本地 Ollama，甚至是一些兼容 OpenAI 格式的服务商。这意味着它不会被单一模型厂商锁死。今天 Claude 便宜好用就切 Claude，明天 Gemini 能白嫖就切 Gemini，配置改一下就行，不用换工具。
它是开源的。代码在 GitHub 上，有问题可以提 issue，也可以自己改。遇到行为不符合预期，我能直接翻源码去确认它在做什么，不管是对隐私的顾虑还是对功能的掌控感，这都让我更安心。
TUI 交互做得很好。虽然听起来只是“终端界面”，但实际体验差异大。opencode 的终端界面支持会话管理、文件引用、diff 查看、多 Agent 切换，不是那种简陋的一问一答。如果你用过类似工具，应该明白终端 UI 好坏直接决定日常舒不舒服。
1.3 opencode 项目身份与开源背景
顺便说一句，很多人在搜索“opencode 是哪家的公司”。它不是一个商业公司的闭源产品，而是一个开源项目，由 SST 团队发起并维护，整个项目面向开发者社区。所以你不存在“被某个厂商绑定”的问题，也不需要担心某个公司哪天政策变了就把功能砍掉。社区里很多增强玩法，比如 Skills、自定义命令、IDE 插件，都是围绕它的开放生态长出来的。
2. 安装与环境配置：从零跑到第一次对话
2.1 前置要求与安装命令
安装 opencode 之前，最基础的前提是 Node.js 版本在 18 以上。它本身是跨平台的，Windows、macOS、Linux 都能跑。
最常见的安装方式是用 npm 全局安装：
npm install -g opencode-ai装完之后，在终端里输入opencode --version，能输出版本号就说明装好了。macOS 上如果你用的是 Homebrew，也可以这样装：
brew install sst/tap/opencode还有一种是直接用安装脚本，适合不想装 Node.js 的环境：
curl -fsSL https://opencode.ai/install | bash这里必须提醒一下：curl 管道给 bash 这种方式，有安全风险，我一般只在临时容器里用，自己日常机器上还是建议走 npm 或者 brew，这样升级和卸载都更规范。
2.2 Windows 用户最常踩的“找不到命令”坑
热词里有一条很典型：“opencode : 无法将‘opencode’项识别为 cmdlet、函数、脚本文件或可运行程序的名”。这是 Windows + PowerShell 环境下最常见的安装失败表现。
这个报错的本质，并不是 opencode 没装上，而是 PowerShell 找不到 npm 全局安装目录下的可执行文件。npm 的全局 bin 路径没有加到系统 PATH 里时，你在任意目录执行opencode，shell 就会报这个错。
排查链路是这样的：
- 先确认 Node.js 是否安装成功，执行
node -v，如果提示找不到 node，那就是 Node.js 本身都没装好，去官网装 LTS 版本再重来。 - 装了 Node.js 但仍报错，执行
npm config get prefix，会输出一个全局路径，比如C:\Users\你的用户名\AppData\Roaming\npm。 - 看这个路径是否在系统环境变量 PATH 里。打开“系统属性 -> 环境变量”，检查 Path。如果没有，把上面那个路径追加进去，然后重新打开 PowerShell，再执行
opencode --version。
这个问题之所以高发，是因为很多安装教程默认 mac/Linux 环境，直接一句话带过了 PATH 配置，Windows 用户照抄就卡住了。装完之后你会发现，不只是 opencode，以后所有 npm 全局安装的命令行工具都能正常用了。所以这个坑一次填平，长期受益。
2.3 模型接入配置：opencode auth login 与 opencode.json
装好之后，第一次运行需要接入一个模型。opencode 的设计很直接，你可以用 auth login 的方式把 API Key 存到系统钥匙串里，也可以直接在配置文件里写好。
先看最常用的命令方式：
opencode auth login执行之后会有一个交互式界面，让你选择 provider，然后粘贴 API Key。登录成功之后它会自动把凭证存好，后续不用重复输入。
但我个人更推荐用配置文件集中管理，尤其是当你有多套模型、多个工作场景，希望在项目间切换时。配置文件路径在：
- macOS / Linux：
~/.config/opencode/opencode.json - Windows：
%USERPROFILE%\.config\opencode\opencode.json
一个最简配置长这样：
{ "$schema": "https://opencode.ai/config.json", "provider": { "default": "anthropic" }, "model": "claude-sonnet-4-20250514" }如果你有多个 provider，可以这样写：
{ "$schema": "https://opencode.ai/config.json", "provider": { "default": "anthropic", "openai": {}, "gemini": {} }, "model": "claude-sonnet-4-20250514" }其中provider下面的每个 key 对应一个模型服务商，value 里可以继续写模型的额外参数，比如自定义 base URL、temperature、max tokens 等。如果你用的是本地或者内网部署的模型服务，只要它是 OpenAI 兼容的格式，就可以通过自定义 provider 方式接进来。
这里有个小经验：接入成本最低的方式是先走opencode auth login确认凭证有效，然后再折腾配置文件。如果你一上来就手动写配置，容易把 base URL 或者模型名写错，到时候报错反而分辨不清是 Key 问题还是配置问题。先用最简单的方式跑通一次，确认工具本身没问题，再去定制，排查问题的半径会小很多。
3. 实战上手：TUI操作、Skills与Memory怎么用
3.1 主界面操作与高频快捷键
opencode 启动后的默认界面是 TUI，输入opencode就进入。不同版本的界面细节可能会改，但核心交互逻辑是稳定的。
一进来就是一个输入框，你可以直接打字描述任务。比如“帮我看看 src/utils/format.ts 里的函数为什么在 UTC 时间下格式化结果是错的”。Agent 会自己读文件、定位代码、分析逻辑，然后给出修改方案或者直接动手改。
常用的操作命令包括：
/model：切换当前会话使用的模型，这个很实用，比如同一个任务先用便宜的模型跑一遍，遇到卡壳再切换更强的模型。/new：新建一个会话，清空上下文。/refer或者直接输入@文件名：显式引用某个文件，让 Agent 优先去读它。/help：查看当前版本支持的全部命令。
另外一个比较重要的交互是“Agent 模式”切换，快捷键通常是 Shift+Tab。在 Agent 模式下，它可以执行命令、读写文件，具备完整行动能力；还有一个更保守的模式，只让它回答问题、给方案，不直接动代码。对不熟悉的项目，我建议先开保守模式，让它给方案，确认之后再切回 Agent 模式执行。
TUI 里查看 diff 是日常高频操作。Agent 改完代码后，你可以用快捷键逐行看改动，确认哪些是你要的，哪些是它自作主张改的。很多时候问题不是 AI 不干活，而是它太勤快，顺手把格式、变量命名、注释全改了。所以“先 diff 后提交”这个习惯，跟我自己写代码一样严格要求，不能省。
3.2 Skills：让 Agent 按你的套路做事的正确姿势
Skills 是 opencode 里一个特别值得仔细琢磨的机制，跟上文提到的 Claude 的 Agent Skills 类似。它的作用，简单说就是：给 Agent 一套“标准作业流程”。
举个例子。我团队里有固定的代码提交规范：commit message 必须带任务编号前缀，格式是TASK-123: 一句话说明。我不想每次对话里都重复叮嘱，于是写了一个 skill，名为commit-message，描述是“当用户要求提交代码或生成 commit 时，按团队规范生成”。
在 opencode 里的落地方式，是在 skills 目录下建文件夹，里面放一个 SKILL.md 文件。路径是：
~/.config/opencode/skills/commit-message/SKILL.mdSKILL.md 的内容结构如下：
--- name: commit-message description: 用户要求生成 commit message 时使用该技能，按团队规范格式输出。 --- # Commit Message 规范 1. 标题格式：TASK-编号: 简要描述，不做名词堆砌。 2. 正文要点： - 说明为什么改，而不是机械列出改了哪些文件 - 一行不超过 80 字符 3. 禁止： - 添加 Co-Authored-By - 写无意义的 change、update、fix关键在于description字段。opencode 会根据描述来判断什么时候调用这个 skill。描述写得越具体，触发越准确。比如你写“生成 commit 时使用”，它就只在提交代码时触发；如果你写“任何代码审查时也参考”，它就会扩大触发范围。这个字段相当于 skill 的“门卫”。
我自己用过一段时间之后的体会是：每个 skill 的内容一定要聚焦，一个 skill 只解决一件事。不要试图写一个包含所有规范的大杂烩，那样 Agent 反而分不清该在什么时候用。我现在项目里大概维护了 6 个 skill，对应测试要求、代码风格、commit 规范、前端组件设计约定等，每个都是短小精悍的指令，效果比我之前写一大段 system prompt 好太多。
3.3 Memory 与 AGENTS.md：跨会话记住项目的关键
如果你希望 Agent 不只是“每次重新认识项目”，就得用好 Memory 和 AGENTS.md 这两个东西。
AGENTS.md 是项目说明书。你可以在项目根目录放一个 AGENTS.md，写清楚目录结构、技术栈、常用脚本、注意事项。opencode 会把它作为项目上下文读取，相当于你给 Agent 的入职手册。新开会话时，它不需要从头摸索，直接按照 AGENTS.md 里的指引去理解项目。
我建议一开始先用/init命令自动生成一个初版 AGENTS.md，它会扫描项目结构、识别技术栈、列出主要命令，生成之后你再手动补充那些只有你知道的隐性知识，比如“这个模块的缓存逻辑很绕，修改前必须看 tests/cache_test.go”、“部署前必须先跑npm run typecheck”。这些信息写进去之后，Agent 每次开工前就看得到，不会一遍遍踩同一个坑。
Memory 则是跨会话积累的项目笔记。opencode 会把会话中产生的关键信息和你的反馈记录到项目对应的 memory 文件里。比如，我跟 Agent 说过“不要改 src/api 下的文件，那边是另一组负责的”，下次新会话里它就能记住这个约束。你可以在会话里输入/memory查看当前项目已经积累了哪些记忆，也可以直接在对应的 memory 文件里手工补充。
我踩过的坑是：Memory 虽然自动记录，但它是“吸收”式的，不会自动判断哪些是临时指令、哪些是长期约束。所以你不能指望它自动管理好一切。我现在的做法是，每完成一个阶段性任务，主动打开 memory 文件清理一遍，把临时性的、只对某次任务有效的内容删掉，只保留那些下一次还会用到的规则和决策背景。
3.4 opencode go：代码库语义搜索
如果说上面的 Skills 和 Memory 是“让 Agent 更懂规矩”，那opencode go解决的是“让 Agent 更懂代码库”。
它是一个独立的子命令，能力是对代码库做语义索引和搜索。传统工具搜索代码一般是靠字符串匹配，你搜一个函数名，能搜到定义处和引用处。但opencode go能做的是更接近自然语言的方式：你描述“负责用户登录后刷新 token 的逻辑在哪里”，它基于索引和语义理解返回相关文件、符号、文档的定位。
对于接手一个历史项目，或者进入一个完全没看过的代码仓库，这个功能的价值就出来了。我一般先把整个仓库跑一遍索引，然后直接问类似“session 续期逻辑在哪”，省掉了大量人工翻代码的时间。
使用上也很简单，在项目目录里执行：
opencode go index之后就可以用：
opencode go search "刷新用户token的逻辑"来定位代码位置。它索引出来的符号位置可以直接和 TUI 会话联动，我在对话里让它改某个逻辑时，可以直接引用 go 搜索到的结果，减少 Agent 自己翻文件的盲目性。
4. 编辑器集成：VSCode、JetBrains 与桌面版
4.1 VSCode插件：终端与编辑器来回切换的体验优化
纯终端里用 opencode 是完整的，但很多场景下你还是离不开编辑器，尤其是需要精确看上下文、手动修改 Agent 改得不完美的地方时。opencode 官方有 VSCode 插件，插件 ID 是opencode.opencode，直接在扩展市场里搜 opencode 就能找到。
这个插件解决的核心问题是“切换成本”。装完之后，你可以直接在编辑器里打开 opencode 的面板，相当于嵌入了一个 TUI 视图，不用再切到独立终端窗口。插件还跟编辑器诊断信息联动，比如当前打开文件有 lint 报错，Agent 能直接感知到，你让它修 bug 的时候它不需要再额外跑一遍 lint 才知道哪里有问题。
我实际使用中最顺手的一个场景是：编辑器里打开一个文件，选中一段代码，右键发送给 opencode，让它针对这段代码提出问题。然后再把它的回答带回编辑器里实施。这种“编辑器写、终端想”的切换方式，比我之前完全在终端里操作要顺手得多，尤其是在改前端页面样式、或者需要频繁肉眼观察输出的场景下。
4.2 JetBrains 系列插件与桌面版
如果你主力是 IntelliJ IDEA、PyCharm 这类 JetBrains 系的 IDE，opencode 也有对应的插件，可以在插件市场搜索 opencode 安装。功能方向和 VSCode 插件类似，主要也是把 TUI 嵌入 IDE 面板，以及打通项目上下文。
JetBrains 系里我注意到更多人在意 Maven、Gradle 这类构建工具的项目配置。热词里也有“opencode mvn 配置”，其实 opencode 本身并不依赖 Maven，但它可以通过上下文读取项目的pom.xml或者build.gradle，从而理解依赖和构建命令。如果你希望 Agent 能自己跑mvn test来验证改动，建议在 AGENTS.md 里明确写清楚构建命令，比如：
## 构建与测试 - 编译：mvn -DskipTests package - 跑全量测试：mvn test - 只跑某个模块：mvn test -pl modules/xxx桌面版则是另一种形态，它本质上是 TUI 的图形封装，用本地服务加桌面壳的方式提供了窗口化界面。对于不习惯终端操作的人来说，桌面版的上手门槛更低，界面也更直观。但如果你已经习惯了终端工作流，桌面版并没有带来更多额外能力，我个人还是更常用 TUI。
4.3 关于 superpowers 等第三方增强配置的接入方式与红线
社区里流传着接入 superpowers 这个第三方增强配置的做法，它本质上是一套预置的增强方案，比如额外的系统指令、技能集合、行为约束模板。接入的方式一般是通过 Skills 或者自定义指令目录，把它作为 opencode 的扩展加载。
我的态度是：增强配置可以接，但一定要先读懂它做了什么再上项目。很多人顺手一个安装命令复制粘贴，根本不知道那几十个 skill 文件里具体写了什么指令。有些第三方 skill 会改掉 Agent 的输出格式、命令执行策略、甚至和安全相关的行为，比如允许自动执行某些高风险命令。
我踩过一次坑：装了一个社区 skill 集合，里面的某个 skill 要求 Agent 在修复测试时优先“通过修改测试来让测试通过”，而不是“修复源码”，我当时没仔细看，结果 Agent 在一个修复任务里直接改了几个测试断言，让它“变绿”了。好在有 diff 审查，我及时发现回滚了，但这件事让我立下两个规矩：
- 第三方增强必须逐文件审查，至少浏览每个 SKILL.md 的 name 和 description，明确它会在什么场景触发。
- 接入后先在小仓库里跑一次试运行，观察 Agent 的行为有没有异常，再决定是否用于正式项目。
5. 模型选型与 Agent 横向对比
5.1 免费模型与收费模型的搭配方案
opencode 的模型无关设计让我可以自由搭配不同模型。日常使用里，我基本是免费模型和收费模型混着用的。
不花钱的路线有几种：一是 Gemini 系列目前有免费档额度，虽然频控严格，但适合写写脚本、改改配置、解释报错这类轻量任务；二是通过 Groq 这类托管服务跑开源模型，速度快，也能覆盖一部分日常需求；三是本地起 Ollama，接上 qwen、llama 这类自托管模型，好处是完全私有、无频控，坏处是硬件门槛高，代码理解能力跟顶级商用模型有差距。
收费路线的主力就是 Claude 系列和 GPT 系列。就写代码这个场景，我个人的主观体验是 Claude 系列的代码理解和长上下文能力更突出，尤其是处理那种跨文件、需要综合判断的 bug 修复任务；GPT 系列在某些工具调用和结构化的任务上也很稳。至于 Gemini 的付费档，我在多模态场景下会用，比如让它看 UI 截图来设计页面。
建议的搭配方案是：
| 任务类型 | 建议模型 | 说明 |
|---|---|---|
| 简单脚本、格式化、解释报错 | 免费档模型 | 成本低，跑得快 |
| 模块级代码编写、数据库迁移 | 主流商用模型 | 质量和稳定性优先 |
| 跨文件重构、复杂 bug 修复 | 顶级商用模型 | 需要强上下文理解和推理 |
| 看的见图片/UI 的任务 | 多模态模型 | 视觉理解能力必要 |
5.2 opencode、Codex、Claude Code、Pi：谁更顺手的判断依据
现在终端 Agent 的选项越来越多，Codex CLI、Claude Code、opencode，还有社区里的 Pi 这类轻量 Agent，经常被拿来对比。我个人的判断标准不是“谁更强”，而是“你在什么约束下工作”。
如果你深度绑定某一家的模型，比如你已经有 Claude 的 API Key、并且在 Claude 生态里有长期积累，Claude Code 很自然。如果你主要在 OpenAI 生态里，Codex CLI 也顺理成章。但如果你跟我一样，不想被任何一家模型绑死，希望同一个工具能在不同模型间自由切换，那 opencode 的优势就很明显：它是模型无关的。
Claude Code 的优势在于跟 Anthropic 模型的深度适配，很多行为是专门为 Claude 调优的，特定任务上开箱即用的效果很好。Codex CLI 则是 OpenAI 的实验田，能第一时间体验到新模型在 Agent 场景下的表现。opencode 的优势则在于开放性和可定制性，它允许你配任意模型，还能通过配置和 Skills 把工具调成你想要的样子。社区活跃度也是一个因素，opencode 的迭代速度非常快，隔一阵子就多出几个新功能。
Pi 这种轻量 Agent 我也试过，定位更偏“快速问答 + 小任务执行”，没有 opencode 这么完整的会话管理和项目上下文机制。它的优点是轻、启动快，但面对需要持续多轮、跨文件操作的重活，用起来就没有 opencode 从容。
给你一个直接的选型建议：如果你只打算在一两个项目里试试终端 Agent，不介意绑定模型，哪个模型用着顺手就选哪个官方工具；如果你想把它变成长期主力，而且希望自主控制模型切换和项目级配置，选 opencode 会更划算。
6. 真实项目里的排错经验与工作流建议
6.1 “无法识别opencode”的完整排查链路
前面提到过 Windows 下的常见报错，我再把它完整展开一下，方便照着排查。
报错原文是：
opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名。 请检查名称的拼写，如果包括路径，请确保路径正确，然后再试一次。这个错误的排查顺序，我建议严格按照从简到繁来：
node -v和npm -v，确认 Node.js 环境还在、版本不是太老。我见过有人电脑上有新旧两个 Node 版本，全局包装到了老版本路径下面，但 shell 用的是新版本。npm ls -g opencode-ai --depth=0，确认包确实装上去了。如果这里提示没有装，重新执行安装命令。npm config get prefix，拿到全局 bin 目录。npm 在 Windows 下默认把全局 bin 放在%APPDATA%\npm。- 去系统环境变量 PATH 里检查这个目录是否存在。没有就加上。
- 重新打开一个全新的终端窗口再试。必须强调新窗口，因为终端的 PATH 是在启动时加载的，旧窗口里不会自动刷新。
我曾经看到一个同事在这个问题上卡了很久，最后发现是安装的时候用了 sudo，全局包被装到了/usr/local/lib/node_modules下，但当前用户的可执行路径解析不到那里去。Windows 上类似的坑就是权限安装路径不一致。如果以上步骤都试了还不行，卸载重装的时候注意不要混用不同的安装方式，比如不要一个环境里同时用过 npm 和安装脚本，容易造成路径错乱。
6.2 “unexpected server error”的定位过程
终端里常见的另一个报错是：
opencode error: unexpected server error. check server logs这种报错的字面意思是“模型服务端返回了意外错误”，实际原因五花八门。我经历过几种情况：
第一种是配置了不存在的模型名。比如你在配置文件里把 model 写成了claude-sonnet-4-20250514，但你的 API 账号实际没有访问这个模型版本的权限，服务端就会返回错误。解决方法是用/model命令看看当前 key 能访问哪些模型，或者在服务商的平台页确认可用模型列表。
第二种是 API Key 权限不足或额度耗尽。很多时候你设置了账单上限，额度用完再请求就会得到 4xx/5xx 错误。这类的特征是：前几天还好好的，突然就报错了。排查方法是去模型服务商的账单页面看一下使用量。
第三种是网络链路不稳定。这里的坑在于，你访问海外模型服务时，网络质量直接决定请求成功率和延迟。我遇到过的问题是：同一个 Key 在某些网络环境下稳定，换个网络就觉得“今天模型变笨了”，其实不是模型变了，是请求重试太频繁导致上下文丢失。这里我不展开讲具体网络方案，只提醒一点：如果你频繁遇到连接超时、unexpected error 这类问题，先确认你对模型服务端的访问是否稳定顺畅。
排查这种报错，标准动作是看日志。opencode 的日志目录在系统数据目录下，Windows 一般在%USERPROFILE%\.local\share\opencode\log，macOS 在~/Library/Application Support/opencode/log附近。你可以在 TUI 里用/doctor或者直接看日志文件，找到具体的 HTTP 状态码和错误体，再去对应服务商查含义。不要停留在“报错了”这个层面，把日志里的关键错误信息拉出来，问题基本就清楚了一半。
6.3 我在几个真实项目里的工作流模板
最后分享一套我现在比较稳定的工作流，它就是从一个真实项目里打磨出来的。
第一步是“初始化项目认知”。新接一个项目，我先在根目录执行opencode go index建索引，然后运行/init生成 AGENTS.md 初版，再手动往里补充只有我知道的知识。这个过程是 Agent 和项目建立默契的基础，省了这一步，后面每次对话它都要重新摸索，效率差很多。
第二步是“先方案后实施”。接任务时，我要求 Agent 先把方案描述清楚，我再决定是否执行。方式很简单，直接在对话里说：“先别改代码，给我一个修复方案，列出涉及的文件、改动点、风险，确认后再动手。”这个习惯尤其适合不熟悉的项目，能避免它一头扎进去把代码改乱。
第三步是“一次只做一件事”。我会把大任务拆成小任务，逐个对话完成。比如“先修登录接口的 500 错误”，修完、测试过了、我审完 diff，再开新会话做“优化错误提示文案”。拆开之后，每个会话的上下文都很干净，Agent 不容易自我混乱，出了问题也容易定位是哪个任务引发的。
第四步是“持续沉淀”。任务完成后，我会把过程中确定的规则写进 AGENTS.md，把踩过的坑记到 memory 文件，把可复用的流程做成 skill。这套体系一旦运转起来，后面的项目会越来越顺，因为 Agent 对项目的理解会随着时间不断加深，而不是每次从零开始。
我在实际项目中还发现一个小技巧：让 Agent 在完成大任务后，主动生成一份简短的改动说明，包括它改了什么、为什么改、哪些地方它做了取舍。这份说明我会直接作为代码评审的参考材料。它不仅能帮你快速审查 Agent 的改动，也能倒逼 Agent 更认真梳理自己的思路，减少胡改乱改的概率。
最后想说的是，opencode 这类工具每个版本迭代都很快，你今天看到的某个命令可能下个月就换了形态。我建议你装好之后先把/help完整过一遍，在自己的小项目里多试几次，慢慢调教出适合自己团队的工作流，比照搬任何人的配置都可靠。
