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 工程化时代的基础技能之一。

目录
  1. 为什么需要 OpenCode:终端里的多模型 Agent 工作台
  2. 安装与环境配置:3 步就绪
  3. 快速上手:5 分钟跑通第一个修复任务
  4. 核心能力详解:5 大支柱
  5. 生产部署与监控:从上线到运维
  6. 版本迭代
  7. AI 应用场景
  8. 常见误区
  9. 面试题
  10. 参考来源
工具类型
终端原生 AI 编程 Agent(开源 CLI/TUI)
开发商
SST(加拿大·多伦多)
开源协议
MIT(可商用)
主要语言
TypeScript / Node.js
当前版本
0.x 快速迭代(2025 年持续发版)
安装方式
`npm i -g opencode-ai` / `brew install sst/tap/opencode` / curl 脚本
官方文档
上手难度
★★☆☆☆(低)
适合人群
CLI 用户、AI 应用工程师、多模型切换团队、私有化部署需求方
同类工具
Claude Code · Aider · Codex CLI
托管服务
无

速览卡是工具类内容的固定首屏模块: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 界面,若能看到模型选择提示,说明安装与环境配置全部完成。

bash15 行
# 步骤一:安装(三选一)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 调用" 即可,适合脚本调用。

bash3 行
# 非交互式运行 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>

维度OpenCodeClaude CodeAiderCodex CLI
定位终端原生多模型 Agent 工作台Anthropic 官方多 Agent CLIgit 优先的结对编程工具OpenAI 官方开源 CLI Agent
界面形态TUI(侧边栏 + 会话列表)终端 REPL + 多面板终端 REPL终端 REPL
模型支持Claude/OpenAI/Gemini/Ollama/Azure/Bedrock/自定义仅 Claude 系列多数 API + 本地模型OpenAI 系列 + 兼容端点
编排范式Agent 自动模式 + 并行多 Agent多 Agent 子任务并行手动提交 + 自动 git diffAgent 模式 + 计划模式
上下文策略LSP 语义 + 多文件读取git 感知 + 文件树repo map + 自动文件追踪全仓库索引
生态扩展MCP、插件、主题、自定义 AgentMCP + 插件 SDK脚本化 + 扩展MCP + 插件
LicenseMIT(开源)专有(免费 + 付费订阅)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.02024-12项目首发终端 TUI 基础、多模型接入(Claude/OpenAI/本地)、基础会话
0.2.x2025 Q1分享与配置系统`/share` 会话分享链接、opencode.json(JSONC 格式)配置、模型服务自定义
0.3.x2025 H1MCP 与扩展生态内置 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 安装包名是以下哪个?

单选题 · easy

  • 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 交互式界面应使用哪条命令?

单选题 · easy

  • 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)的含义是什么?

单选题 · easy

  • A.自带密钥并自选模型供应商← 正确答案
  • B.自带编译器与运行内核
  • C.自带第三方插件市场账号
  • D.自带代码托管平台令牌

答案:A。BYOK 指用户自行配置各家模型供应商的 API Key(Anthropic、OpenAI、Gemini、Ollama 等),OpenCode 不在模型层面做绑定。这让成本、数据流向都掌握在用户手中,是 OpenCode 区别于 Claude Code 等单模型工具的核心设计。

Q4. 在 OpenCode 会话中执行哪个操作可生成分享链接?

单选题 · mid

  • A./export
  • B./share← 正确答案
  • C./publish
  • D./upload

答案:B。/share 生成 opencode.ai/share/... 链接,协作者可在浏览器查看完整对话与代码改动。注意该链接是公开可访问的,分享前需检查是否包含密钥或敏感代码。/export、/publish、/upload 均非官方内置命令。

Q5. 在 OpenCode 配置中定义一个模型服务源,通常需要哪些信息?

多选题 · mid

  • A.模型提供商名称← 正确答案
  • B.具体模型 ID← 正确答案
  • C.API 基地址(baseURL)← 正确答案
  • D.可视化界面主题

答案:ABC。provider 条目由提供商名称、模型 ID 与 baseURL(本地或自定义网关时必填)组成。主题(D)属于界面定制配置,与模型服务源无关。通过 opencode.json 维护这些字段,实现多模型自由切换。

Q6. OpenCode 中 MCP 服务器可以通过哪两类入口接入?

单选题 · mid

  • A.本地命令启动与远程 HTTP 地址← 正确答案
  • B.仅本地命令行脚本
  • C.仅云端托管服务
  • D.仅 IDE 插件市场安装

答案:A。OpenCode 内置 MCP 客户端,支持两类 MCP 服务器:本地型(通过命令启动进程,如 npx 启动文件系统服务器)和远程型(通过 HTTP URL 直连)。插件市场(D)不是 MCP 的接入方式。

Q7. 关于 OpenCode 的会话持久化,下列说法正确的是?

单选题 · mid

  • A.关闭终端后所有对话立即丢失
  • B.会话自动保存到本地,可在新终端恢复← 正确答案
  • C.会话只能存储在官方云端
  • D.必须手动导出才能保留会话

答案:B。会话数据自动持久化到本地目录(默认 ~/.local/share/opencode/),关闭终端或重启后通过 /session 恢复,tmux 多窗口可继续同一会话。这是 OpenCode 适合长任务与多人协作的基础能力之一。

Q8. 在 CI 流水线中非交互式自动执行“修复 lint 错误并运行测试”,应使用哪个命令?

单选题 · hard

  • 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 的生产实践,下列说法正确的是?

多选题 · hard

  • 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(模型服务源)的配置信息通常维护在哪个文件中?

单选题 · extreme

  • 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 无关。

参考来源