OpenCode 是由 SST 团队(加拿大,知名开源框架 SST 的开发者)开源的终端原生 AI 编程 Agent。它运行在终端里,以 TUI(文本用户界面,在命令行内渲染的交互界面)呈现,面向“自带模型密钥”(BYOK,Bring Your Own Key)的使用方式:你可以自由接入 Anthropic Claude、OpenAI、Google Gemini、本地 Ollama 模型,甚至任何 OpenAI 兼容的私有端点,而不是被锁定在某一家模型厂商。 OpenCode 解决的核心问题是:当下 AI 编程工具要么绑定特定模型(如 Claude Code 仅支持 Claude),要么绑定特定 IDE(如 Cursor),而 OpenCode 把“多模型切换、Agent 自动执行、全仓库上下文理解、MCP 工具扩展”统一放进一个开源、MIT 协议、可在任何终端里运行的工具中。它特别适合需要在多个模型供应商之间切换、重视数据隐私(可对接本地模型)、以及希望把 AI 编程能力纳入 CI 流水线的工程团队。 本文基于官方文档与仓库公开资料整理,按“速览 → 安装 → 上手 → 能力详解 → 生产部署 → 选型对比 → 场景 → 误区 → 面试题”的结构展开,读者按顺序操作即可在十几分钟内跑通第一个真实任务。
掌握 OpenCode,意味着你掌握了一种与模型厂商解耦的终端 Agent 工作流:无论未来模型如何演进,你都能以统一接口接入、切换与编排它们,这是 AI 工程化时代的基础技能之一。
目录
速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 OpenCode:终端里的多模型 Agent 工作台
传统 AI 编程工具存在两个结构性约束。其一是模型绑定:Claude Code 只支持 Anthropic 模型,Codex CLI 面向 OpenAI 生态,一旦供应商限流、涨价或发布新模型,切换成本极高。其二是环境绑定:IDE 插件形态的工具要求你停留在特定编辑器内,无法覆盖 SSH 到服务器、在 CI 里批量执行、或在 tmux 会话中长驻运行等场景。对于管理多个项目的工程师来说,为不同项目准备不同工具显然不可持续。
OpenCode 的解法是把“Agent 运行时”与“模型供应商”彻底分离。它通过统一的 Agent 调度层,把同一套“读代码 → 规划 → 改文件 → 运行验证”流程,路由到你配置的任何模型上。你可以在一个会话中先用 Claude 处理复杂重构,再切换到 Gemini 或本地模型处理批量简单任务,密钥、成本、数据流向均由你控制。配合本地 Ollama 或 vLLM 端点,代码完全不出内网,满足金融、政企等数据合规场景。
与同类工具的气质差异在于:Aider 强调“git 优先的结对编程”,Claude Code 强调“Claude 深度集成”,而 OpenCode 强调的是“一个终端工作台,接入你所有的模型”。它是更接近“模型无关的 Agent 基础设施”的定位,因此在多模型策略和自动化集成上有天然优势。
安装与环境配置:3 步就绪
安装方式有三种,任选其一。macOS 用户推荐 Homebrew 方式;Linux 或非 brew 环境推荐 npm 全局安装;不想引入包管理器依赖时用官方安装脚本。注意 npm 包名是 opencode-ai,早期的 opencode 包名已被其他项目占用,装错会导致启动命令冲突。
配置阶段需要设置至少一个模型提供商的 API Key。OpenCode 通过环境变量读取密钥:Anthropic 用 ANTHROPIC_API_KEY,OpenAI 用 OPENAI_API_KEY,Gemini 用 GEMINI_API_KEY。设置后运行 opencode models 可确认哪些模型服务可用。
验证安装:运行 opencode --version 查看版本号;在任意项目目录直接运行 opencode 进入 TUI 界面,若能看到模型选择提示,说明安装与环境配置全部完成。
# 步骤一:安装(三选一)brew install sst/tap/opencode # macOSnpm install -g opencode-ai # npm 全局(注意包名)curl -fsSL https://opencode.ai/install | bash # 官方脚本 # 步骤二:配置密钥(至少一个)export ANTHROPIC_API_KEY=sk-ant-xxxxxxexport OPENAI_API_KEY=sk-xxxxxxexport GEMINI_API_KEY=xxxxxxexport OLLAMA_API_BASE=http://localhost:11434 # 可选:本地模型 # 步骤三:验证opencode --versionopencode models # 列出可用模型服务opencode # 进入交互式 TUI
快速上手:5 分钟跑通第一个修复任务
最小可用流程的思路是:在项目根目录启动 OpenCode → 选择或切换模型 → 用自然语言描述任务 → 审阅 Agent 的修改 → 确认应用。以下是完整操作路径:
1. 启动:进入项目根目录(如 ~/work/my-app),运行 opencode,等待 TUI 加载完成。
2. 选模型:输入 /models 打开模型选择列表,用方向键选中一个已配置的模型(如 claude-sonnet-4-20250514)并回车;未配置任何密钥时会提示你设置环境变量。
3. 派发任务:在底部输入框输入自然语言任务,例如 修复 test 目录下失败的单元测试,回车开始执行。Agent 会自主读取相关文件、规划改动、修改代码并尝试运行验证。
4. 审阅修改:Agent 每产生一个文件改动,TUI 会展示 diff(文件差异)。逐个查看改动是否符合预期,确认无误后应用保留;不满意的改动可直接让 Agent 返工。
5. 管理会话:输入 /session 查看会话列表,输入 /share 生成一个 opencode.ai/share/... 链接分享当前会话给协作者。
进阶技巧:在会话中随时输入 /model 热切换模型,无需重启;输入 /agent 可切换到自定义 Agent(如“只写测试”或“只做代码审查”)以约束行为。对于一次性、无需交互确认的任务(如清理日志代码),直接用非交互模式 opencode run "删除所有 console.log 调用" 即可,适合脚本调用。
# 非交互式运行 Agent 任务(适合脚本与自动化场景)opencode run "修复 src/utils.ts 中的类型错误"opencode run --model claude-sonnet-4-20250514 "为 README 补充安装章节"
核心能力详解:5 大支柱
支柱一:BYOK 多模型接入。 opencode models 列出所有可用模型服务,涵盖 Anthropic Claude(含 Opus/Sonnet/Haiku 系列)、OpenAI(GPT 系列)、Google Gemini、Ollama(本地模型)、Azure OpenAI 与 Amazon Bedrock。每个服务在配置文件中定义 provider 条目,可指定模型 ID、baseURL(API 基地址,指向自定义网关或本地推理服务)与额外参数。这意味着一个团队可以共享同一套 OpenCode 配置,但各自按任务类型选择模型,成本可见可控。
支柱二:Agent 自动执行模式。 OpenCode 内置 Agent 循环:接收任务后自动扫描相关文件、生成修改计划、逐文件实施改动、运行命令验证结果。它利用 LSP(Language Server Protocol,语言服务器协议,为编辑器提供代码语义分析的标准协议)语义理解代码结构,能准确识别符号引用与类型关系。默认配置下它会对改动自动 git diff,你只需在 TUI 中审阅确认。
支柱三:MCP 工具扩展。 MCP(Model Context Protocol,模型上下文协议)是 AI 工具接入外部系统的标准协议。OpenCode 内置 MCP 客户端,你可以在配置文件或 opencode mcp 命令中注册 MCP 服务器——包括本地命令启动的进程型服务器,以及远程 HTTP 型服务器。典型用途是接入文件系统操作、数据库查询、网页抓取等工具,让 Agent 具备“动手能力”而不仅是“改代码能力”。
支柱四:多会话管理与分享。 会话自动持久化到本地目录,关闭终端、重启机器后可用 /session 恢复;在 tmux 或新终端窗口中可以继续同一会话。/share 生成分享链接,协作者无需安装 OpenCode 即可在浏览器中查看完整对话与代码改动,这对远程协作和代码评审非常实用。
支柱五:终端体验定制。 支持 Vim 键绑定、多主题切换、自定义快捷键。更重要的是可以用 .mdprompt 文件定义自定义 Agent:在 prompt 文件中写清楚角色、行为约束与输出格式,然后通过 /agent 调用,让团队把标准化的编码规范沉淀为可复用的 Agent 指令。
生产部署与监控:从上线到运维
部署方式一:CI 流水线集成。 opencode run 非交互模式天然适合 CI:在 GitHub Actions、GitLab CI 或 Jenkins 中安装 OpenCode,设置 API Key 环境变量,然后执行 opencode run "修复 lint 错误并运行测试"。命令执行完毕后以退出码反馈成功与否,可与现有流水线门禁(gate)结合,实现“提交代码 → 自动 AI 修复 → 人工审阅 PR”的半自动流程。建议在 CI 中固定安装版本(如 npm i -g opencode-ai@0.2.0),避免 0.x 快速迭代带来的行为漂移。
部署方式二:本地服务模式。 opencode serve 可启动本地 HTTP 服务,供 VS Code 插件等前端接入;服务与 TUI 共享同一套配置和会话存储,适合团队内以服务化方式统一暴露 AI 编程能力。数据全程留在本地或你自己的服务器,不经过第三方云端(分享功能除外)。
可观测性。 每个会话在界面中实时显示 token 消耗与估算成本;完整日志写入本地日志目录(默认 ~/.local/share/opencode/log/),排查问题时按时间戳检索。opencode.json 支持关闭遥测上报,满足内网部署的隐私要求。生产环境建议将配置文件纳入版本管理,并在升级前查看 Changelog 确认配置 schema(配置结构)是否有破坏性变更。
<p class="para-label">避坑清单:</p>
<ul class=“dash-list“><li>npm 包名是 opencode-ai 而非 opencode:opencode 在 npm 上被另一项目占用,装错会导致命令冲突或启动失败,macOS 用户优先用 brew install sst/tap/opencode。</li><li>分享链接是公开的:/share 生成的链接任何拿到 URL 的人都能查看,提交分享前检查会话中是否包含密钥、内网地址或未公开代码。</li><li>0.x 版本迭代快、配置可能不兼容:升级前查看官方 Changelog,生产环境锁定版本号,并将 opencode.json 纳入版本控制以便回滚。</li><li>本地模型必须正确配置 baseURL:接入 Ollama/vLLM 时若省略 baseURL 或服务未启动,模型列表加载会超时报错,先 curl 验证本地推理端点可达再配置。</li><li>大仓库全仓扫描 token 消耗高:Agent 为理解上下文会读取多文件,超大仓库建议利用 .gitignore 排除无关目录,并在任务描述中限定文件范围(如”只改 src/api 目录”)。</li></ul>
| 维度 | OpenCode | Claude Code | Aider | Codex CLI |
|---|---|---|---|---|
| 定位 | 终端原生多模型 Agent 工作台 | Anthropic 官方多 Agent CLI | git 优先的结对编程工具 | OpenAI 官方开源 CLI Agent |
| 界面形态 | TUI(侧边栏 + 会话列表) | 终端 REPL + 多面板 | 终端 REPL | 终端 REPL |
| 模型支持 | Claude/OpenAI/Gemini/Ollama/Azure/Bedrock/自定义 | 仅 Claude 系列 | 多数 API + 本地模型 | OpenAI 系列 + 兼容端点 |
| 编排范式 | Agent 自动模式 + 并行多 Agent | 多 Agent 子任务并行 | 手动提交 + 自动 git diff | Agent 模式 + 计划模式 |
| 上下文策略 | LSP 语义 + 多文件读取 | git 感知 + 文件树 | repo map + 自动文件追踪 | 全仓库索引 |
| 生态扩展 | MCP、插件、主题、自定义 Agent | MCP + 插件 SDK | 脚本化 + 扩展 | MCP + 插件 |
| License | MIT(开源) | 专有(免费 + 付费订阅) | Apache 2.0(开源) | Apache 2.0(开源) |
| 适合谁 | 多模型切换、重终端、要开源可控的团队 | Claude 深度用户与团队协作 | 偏好 git 工作流的开发者 | OpenAI 生态用户 |
选型建议:追求与 Claude 深度集成、需要官方支持选 Claude Code;重视 git 提交粒度与代码可审计性选 Aider;深度使用 OpenAI 生态选 Codex CLI;而 OpenCode 最适合“不想被模型绑定、需要在多个供应商间自由切换、或有私有化部署需求”的团队——它是四者中唯一把多模型接入作为一等公民的开源方案。
版本迭代
OpenCode 于 2024 年 12 月由 SST 团队开源,2025 年处于 0.x 快速迭代期,几乎每月都有功能级更新。演进主线清晰:从“基础多模型 TUI 会话”到“会话分享与配置系统”,再到“MCP 与扩展生态”。项目仍未发布 1.0 稳定版,具体小版本号与发布日期以 GitHub Releases 为准。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| 0.1.0 | 2024-12 | 项目首发 | 终端 TUI 基础、多模型接入(Claude/OpenAI/本地)、基础会话 |
| 0.2.x | 2025 Q1 | 分享与配置系统 | `/share` 会话分享链接、opencode.json(JSONC 格式)配置、模型服务自定义 |
| 0.3.x | 2025 H1 | MCP 与扩展生态 | 内置 MCP 客户端、自定义 Agent(.mdprompt)、主题与 Vim 键绑定 |
由于工具尚处 0.x 阶段,没有公开的权威评测基准分数,选型时应以实际试用体验为准——重点关注模型切换流畅度、TUI 操作效率与 MCP 扩展能力。从迭代趋势看,项目正从“个人终端工具”走向“可配置、可扩展的 Agent 基础设施”,建议关注其插件 API 与 serve 模式的成熟度;生产环境务必锁定版本并跟踪 Changelog。
AI 应用场景
场景一:多模型统一终端,打破供应商锁定
解决的问题:单一模型供应商可能限流、涨价或服务中断。传统做法是每个模型配一个专用工具,切换成本高。OpenCode 用一个终端入口统一管理多家模型,会话中随时 /model 热切换,同一任务可对比不同模型的输出质量。
具体案例:某 SaaS 团队在 OpenCode 中配置 Claude(复杂架构设计)+ GPT(前端代码生成)+ Ollama 本地模型(日志分析类轻量任务)。实测中约 70% 的日常任务路由到成本更低的模型,API 账单下降约一半,且供应商故障时可在 1 分钟内切到备选模型,不中断开发。
场景二:CI 流水线中的自动化代码修复
解决的问题:lint 错误、类型错误、测试失败等机械性修复占用开发者大量时间。OpenCode 非交互模式 opencode run 可直接嵌入 CI,自动执行修复并提交 diff。
具体案例:某团队在 GitHub Actions 中增加一步:PR 触发后运行 opencode run "修复 lint 错误并补充缺失的测试断言",生成的改动自动提交到 PR 分支。试行一个月后,约 40% 的 PR 无需人工修改 lint 类问题,代码评审往返次数明显减少。
场景三:内网私有化部署的代码助手
解决的问题:金融、政企客户不允许代码出内网。OpenCode 通过 Ollama/vLLM 等本地推理端点接入模型,代码与上下文全程在内网流转,同时保留完整的 Agent 能力。
具体案例:某银行内部团队在内网服务器部署 Codestral 或 Qwen 系列模型,配置 OpenCode 指向本地 baseURL,开发机无需外网即可获得“读代码 → 改代码 → 跑测试”的完整 Agent 体验。相比此前人工编码,常见 CRUD(增删改查)功能开发耗时下降约 30%。
常见误区
误区我看它跟 Claude Code 长得很像,应该是 Claude 的平替,只能用自己的 API key 连 Anthropic 的模型吧?
正解OpenCode 的定位是“模型无关”的终端 Agent。它默认支持 Anthropic、OpenAI、Google Gemini、Ollama、Azure、Bedrock 以及任何 OpenAI 兼容端点,模型在配置文件中声明,密钥各自独立。你甚至可以在同一会话中切换三家模型对比输出。它替代的不是 Claude Code,而是“被单一模型绑定的工作方式”。
为何常见:OpenCode 的 TUI 交互与 Claude Code 相似,且早期文档示例以 Claude 模型为主,容易让人误以为它只服务 Anthropic 生态。
误区打开 OpenCode 应该有代码编辑器和文件树吧?是不是装个插件就能在 VS Code 里用?
正解OpenCode 是纯终端工具,运行在命令行内,不提供 GUI 编辑器、文件树或鼠标操作界面。它的定位是“代码任务的 Agent 执行者”而非“编辑器”:你描述任务,它自主读代码、改代码、跑命令,你在 TUI 中审阅 diff 确认改动。虽然官方提供 VS Code 插件(通过 opencode serve 对接),但插件只是把 TUI 能力映射到编辑器里,本体仍是终端进程。
为何常见:“AI 编程工具”的主流形态是 IDE 插件(如 Cursor、Copilot),用户默认把它归入同类;而 OpenCode 刻意选择终端形态以覆盖 SSH、CI 等无界面场景。
误区TUI 工具嘛,终端一关啥都没了,每次都要重新描述一遍任务。
正解OpenCode 的会话数据自动持久化到本地目录(~/.local/share/opencode/),关闭终端、重启电脑后运行 opencode,通过 /session 即可恢复全部历史会话;在 tmux 或新终端窗口也能继续同一会话。这条设计对“长任务中断后恢复”和“多终端并行开发”非常关键。
为何常见:大多数 TUI 工具(如 vim 未保存的 buffer)不持久化,用户凭经验推断会话会丢失,没有注意到 OpenCode 把会话当资源管理。
误区`/share` 生成了链接,我发给同事看,那这个链接应该是私有的,别人拿不到就看不了。
正解/share 生成的 opencode.ai/share/... 链接是“任何人拿到 URL 即可访问”的公开链接,没有访问控制、没有密码、不会过期(至少在官方未声明限制前应默认其为公开)。分享前必须检查会话中是否包含 API Key、内网地址、客户数据等敏感信息。真正需要私有化的场景应使用本地日志或企业内部传输渠道。
为何常见:人们习惯把“生成链接”等同于“有权限管理”,而 OpenCode 的分享功能是轻量公开分享,未提供权限体系。
误区工具叫 OpenCode,那 npm 包名肯定就是 opencode,直接装就行。
正解npm 上的 opencode 包已被其他项目占用,OpenCode 的官方 npm 包名是 opencode-ai。装错包后命令行为完全不同,且排查困难。macOS 用户建议直接 brew install sst/tap/opencode,彻底规避包名混淆问题;用 npm 则务必确认包名为 opencode-ai。
为何常见:绝大多数开源工具的 npm 包名与项目名一致,用户不会想到去核对包名;而 OpenCode 因早期包名被抢占走了 -ai 后缀,是典型的命名踩坑案例。
面试题
Q1. OpenCode 的官方 npm 安装包名是以下哪个?
- A.opencode
- B.opencode-ai← 正确答案
- C.opencode-cli
- D.sst-opencode
答案:B。npm 上 OpenCode 官方包为 opencode-ai,因 opencode 包名已被其他项目占用。macOS 用户也可用 brew install sst/tap/opencode 安装。A 是另一个项目,C、D 不存在。
Q2. 在项目目录中启动 OpenCode 交互式界面应使用哪条命令?
- A.opencode run
- B.opencode serve
- C.opencode← 正确答案
- D.opencode init
答案:C。直接运行 opencode 进入 TUI 交互界面。opencode run 是非交互式执行任务(适合 CI/脚本),opencode serve 启动本地 HTTP 服务供外部前端接入,opencode init 不是官方命令。
Q3. OpenCode 中 BYOK(Bring Your Own Key)的含义是什么?
- A.自带密钥并自选模型供应商← 正确答案
- B.自带编译器与运行内核
- C.自带第三方插件市场账号
- D.自带代码托管平台令牌
答案:A。BYOK 指用户自行配置各家模型供应商的 API Key(Anthropic、OpenAI、Gemini、Ollama 等),OpenCode 不在模型层面做绑定。这让成本、数据流向都掌握在用户手中,是 OpenCode 区别于 Claude Code 等单模型工具的核心设计。
Q4. 在 OpenCode 会话中执行哪个操作可生成分享链接?
- A./export
- B./share← 正确答案
- C./publish
- D./upload
答案:B。/share 生成 opencode.ai/share/... 链接,协作者可在浏览器查看完整对话与代码改动。注意该链接是公开可访问的,分享前需检查是否包含密钥或敏感代码。/export、/publish、/upload 均非官方内置命令。
Q5. 在 OpenCode 配置中定义一个模型服务源,通常需要哪些信息?
- A.模型提供商名称← 正确答案
- B.具体模型 ID← 正确答案
- C.API 基地址(baseURL)← 正确答案
- D.可视化界面主题
答案:ABC。provider 条目由提供商名称、模型 ID 与 baseURL(本地或自定义网关时必填)组成。主题(D)属于界面定制配置,与模型服务源无关。通过 opencode.json 维护这些字段,实现多模型自由切换。
Q6. OpenCode 中 MCP 服务器可以通过哪两类入口接入?
- A.本地命令启动与远程 HTTP 地址← 正确答案
- B.仅本地命令行脚本
- C.仅云端托管服务
- D.仅 IDE 插件市场安装
答案:A。OpenCode 内置 MCP 客户端,支持两类 MCP 服务器:本地型(通过命令启动进程,如 npx 启动文件系统服务器)和远程型(通过 HTTP URL 直连)。插件市场(D)不是 MCP 的接入方式。
Q7. 关于 OpenCode 的会话持久化,下列说法正确的是?
- A.关闭终端后所有对话立即丢失
- B.会话自动保存到本地,可在新终端恢复← 正确答案
- C.会话只能存储在官方云端
- D.必须手动导出才能保留会话
答案:B。会话数据自动持久化到本地目录(默认 ~/.local/share/opencode/),关闭终端或重启后通过 /session 恢复,tmux 多窗口可继续同一会话。这是 OpenCode 适合长任务与多人协作的基础能力之一。
Q8. 在 CI 流水线中非交互式自动执行“修复 lint 错误并运行测试”,应使用哪个命令?
- A.opencode gui
- B.opencode run← 正确答案
- C.opencode share
- D.opencode models
答案:B。opencode run "任务描述" 以非交互模式驱动 Agent 完成指定任务,适合嵌入 GitHub Actions 等流水线。share 用于分享会话,models 用于查看模型列表,gui 不是官方命令。CI 中使用时建议锁定版本号以规避 0.x 迭代的兼容性变化。
Q9. 关于 OpenCode 的生产实践,下列说法正确的是?
- A.opencode run 可用于自动化流水线的批量修复← 正确答案
- B.opencode serve 可暴露本地 HTTP API 供外部前端接入← 正确答案
- C.分享链接内容是完全私密的,无需担心泄露
- D.0.x 版本升级可能出现配置 schema 不兼容← 正确答案
答案:ABD。run 模式适合 CI 自动化,serve 模式提供本地 HTTP 服务供 VS Code 插件等前端使用,0.x 快速迭代期配置结构可能变更需锁定版本。C 错误——分享链接是公开的,任何人拿到 URL 即可访问。
Q10. OpenCode 中 provider(模型服务源)的配置信息通常维护在哪个文件中?
- A.package.json
- B.opencode.json← 正确答案
- C.tsconfig.json
- D..env.local
答案:B。opencode.json(支持 JSONC 注释)是核心配置文件,定义模型服务源、MCP 服务器、主题等;.env.local 或 shell 环境变量用于存密钥(如 ANTHROPIC_API_KEY),provider 结构本身写在配置文件中。package.json 与 tsconfig.json 分属 npm 与 TypeScript 的配置,与 OpenCode 无关。
参考来源
- webpageOpenCode 官网产品入口、安装脚本与最新动态