OpenCode 配置 API 中转站完整指南：3 步开启 Claude 原生与 OpenAI 兼容双模式

OpenCode 是 2026 年最受关注的开源 AI 编码 Agent 之一，主打"模型无关、终端优先"的设计哲学，让开发者既能跑 Claude，也能调用 GPT、Gemini、本地模型，甚至混搭使用。它和 Claude Code 一样跑在终端里，但走的是另一条路线——把 provider 抽象成可插拔的配置项，由用户自己决定底层模型。

许多读者问站长我一个非常具体的问题：从配置上看 OpenCode 似乎是用 OpenAI 兼容模式调用的，那么它是否支持 Anthropic 的原生格式？接入 APIYI 这类第三方中转站时怎么选才合适？

本文从英文官方文档与源码角度做了完整考证，先讲清楚 OpenCode 是什么、和 Claude Code 的关键差异，再手把手演示如何把它接到 API易 apiyi.com 中转站上，覆盖 OpenAI 兼容与 Anthropic 原生两种调用方式。读完即可立即上手配置。

OpenCode 项目介绍：开源 AI 编码代理的核心定位

OpenCode 由 sst 团队（也就是 SST/Serverless Stack 框架的作者）维护，仓库地址 github.com/sst/opencode，采用 MIT 开源许可。截至发稿时已积累 15 万以上 GitHub Star，社区贡献者超过 850 人，是当前最活跃的开源编码代理项目之一。它的目标用户非常明确：希望在终端里完成大部分编码任务、又不愿被单一模型供应商绑死的中高级开发者。

OpenCode 的架构设计与运行模式

OpenCode 采用客户端／服务器架构，把 agent 核心逻辑跑在本地服务进程里，TUI（终端 UI）只是众多前端之一。这意味着同一个 agent 实例可以同时被终端、桌面应用、IDE 插件甚至手机端访问，未来的多端协同空间很大。

它内置两种 agent 模式，通过 Tab 键即时切换：

build 模式：默认开放全部工具权限，可读、可写、可执行命令，适合实际开发任务。
plan 模式：只读模式，仅做代码分析、方案设计与建议，不会修改任何文件。

维度	OpenCode 设计要点	对开发者的价值
架构	客户端/服务器分离	多端协同、远程控制
模型层	抽象为可插拔 provider	自由切换 75+ 模型
交互层	TUI / 桌面 App / IDE 插件	不被界面绑定
权限层	build / plan 双模式	安全与效率兼顾
部署方式	本地优先，可对接远程	数据留在本地

🎯 配置建议：如果你希望在 OpenCode 中用上 Claude、GPT、Gemini、DeepSeek 等多家模型，又不想为每家都开一个账号、维护多套密钥，可以直接接入 API易 apiyi.com 中转站，用一把令牌覆盖主流模型。

OpenCode 的核心能力

它的能力边界比传统 IDE 插件大得多。在终端中输入自然语言，OpenCode 可以解读整个代码库、新增功能、修改既有逻辑、运行测试甚至跨文件重构。plan 模式则用于先行评审：让 agent 先输出实现思路，开发者确认后再切到 build 模式落地。

它还支持非交互模式 opencode run "your prompt"，可以直接拼到 shell 脚本里，用于 CI/CD、批量重构、定时任务等自动化场景。这个能力是 Claude Code 早期不具备的，也是 OpenCode 在工程化场景里被频繁选中的原因之一。

值得一提的是，OpenCode 默认会把模型清单从 models.dev 这个公共数据库拉取并匹配，因此即便上游 provider 推出了新模型，OpenCode 也能很快感知到。当你通过中转站接入时，本地保留的模型映射可以与 APIYI 后台的模型清单保持一致，避免出现"配置里写了模型 ID，但实际请求被拒绝"的尴尬情况。

OpenCode 与 Claude Code 的核心区别对比

很多人把 OpenCode 当成"开源版 Claude Code"，但二者本质定位并不重合。Claude Code 是 Anthropic 官方为自家模型量身打造的一等公民工具，OpenCode 则是面向多模型生态的中立框架。

模型支持范围与成本控制

Claude Code 只能调用 Anthropic 自家模型（Sonnet 系列、Opus 系列、Haiku 系列），意味着所有任务都按 Anthropic 定价付费。OpenCode 支持 75 个以上 provider，包括 OpenAI、Anthropic、Google Vertex、Bedrock、Groq、Azure、OpenRouter，乃至 Ollama、LM Studio 这类本地推理后端。

实际工作流里这种灵活性很有用。文档生成、提交信息、变量改名这种轻活可以丢给便宜的小模型，复杂重构与架构思考再切回 Claude Sonnet 或 Opus，整体成本通常能压低 40–60%。

工作流与权限模型差异

Claude Code 默认偏保守路线，写文件、跑命令前会主动征询确认，新手友好但偶尔被打断节奏。OpenCode 偏透明路线——代码完全开源，安全团队可以审计，权限通过 build/plan 切换显式管理，对自动化与脚本化更友好。

对比维度	OpenCode	Claude Code
开源情况	MIT 开源，源码可审计	闭源，仅二进制分发
模型范围	75+ provider，含本地模型	仅 Anthropic 官方模型
自定义 endpoint	任意 provider 可改 baseURL	通过 ANTHROPIC_BASE_URL 改
交互界面	TUI / 桌面 App / IDE 插件	终端为主
权限策略	build / plan 显式切换	默认询问确认
成熟度	演进快，部分细节仍在打磨	体验更打磨
适合场景	多模型混搭、本地部署、定制化	一站式 Claude 体验

🎯 选择建议：如果你的工作流以 Claude 为主，但偶尔想让 GPT、Gemini 来兜底，建议在 OpenCode 中通过 API易 apiyi.com 同时配置多家模型，用同一把令牌切换。日常以原生 Claude Code 完成主线开发，复杂任务交叉验证时切到 OpenCode 即可。

适合谁用 OpenCode

OpenCode 的最佳读者画像是：愿意花 20 分钟读配置文档、对成本敏感、希望同一份工具链横跨多家模型、或者所在公司要求模型必须可审计的开发者。如果你只想"开箱即用 Claude"，Claude Code 仍然是更顺手的选择。

OpenCode 接入 APIYI 中转站的两种调用模式

回到读者最关心的问题：OpenCode 究竟用 OpenAI 兼容模式还是 Anthropic 原生格式？答案是两种都支持，取决于你在 opencode.json 里如何配置 provider。

模式一：OpenAI 兼容模式（最通用）

这是 OpenCode 文档主推的方式，也是接入第三方中转站最稳妥的路径。底层使用 Vercel AI SDK 的 @ai-sdk/openai-compatible 包，把任何符合 OpenAI Chat Completions 协议的 endpoint 包装成 OpenCode provider。APIYI 的 OpenAI 兼容入口是 api.apiyi.com/v1，可以同时调用 GPT、Claude、Gemini、DeepSeek 等数十个模型，统一成 OpenAI 格式。

它的优点是泛用，几乎所有模型都可以挂在同一个 provider 下。代价是部分 Anthropic 专属能力（如 extended thinking、原生 tool use 块）会经过协议转换，少量边角行为可能与 Anthropic 官方端点存在细微差异。

模式二：Anthropic 原生模式（用 Claude 时推荐）

OpenCode 的内置 anthropic provider 走的是 @ai-sdk/anthropic 包，请求路径是 /v1/messages，请求体格式是 Anthropic 官方文档定义的 Messages API。这一格式支持 content blocks、tool_use 块、extended thinking 等 Claude 特性，与 Claude Code 走的是完全相同的协议。

只要把 provider.anthropic.options.baseURL 指向 APIYI 的 https://api.apiyi.com，OpenCode 就会用 Anthropic 原生格式发送请求，由 APIYI 中转站转发给上游 Claude。这意味着你可以在 OpenCode 中获得与 Claude Code 几乎一致的 Claude 调用体验。

模式	底层包	APIYI Base URL	适合调用	协议保真度
OpenAI 兼容	`@ai-sdk/openai-compatible`	`https://api.apiyi.com/v1`	多模型混搭	标准 OpenAI
Anthropic 原生	`@ai-sdk/anthropic`	`https://api.apiyi.com`	Claude 全系列	与官方一致

🎯 配置建议：日常使用我们推荐双模式共存——同一份 opencode.json 同时配置 anthropic provider 与一个 openai-compatible provider，前者用于 Claude，后者用于 GPT/Gemini/DeepSeek 等其他模型。两个 provider 共用 API易 apiyi.com 同一把令牌即可，无需重复管理 Key。

3 步完成 OpenCode 与 APIYI 中转站配置

下面给出最小可运行的接入流程，按顺序执行即可。整套操作通常 5 分钟内能跑通。

第一步：安装 OpenCode 客户端

官方提供两种主流安装方式，按你的环境二选一。

# 方式 A：通过 npm 全局安装（推荐 Node.js 用户）
npm install -g opencode-ai@latest

# 方式 B：一键脚本安装（推荐 macOS / Linux）
curl -fsSL https://opencode.ai/install | bash

安装完成后执行 opencode --version 验证。Windows 用户可以通过 Scoop 或 WSL 使用。如果 npm 安装失败，多半是 Node 版本过低，建议升级到 18+ 或 20+。

第二步：在 APIYI 后台获取 API 令牌

登录 API易后台，在令牌管理页 api.apiyi.com/token 创建一把新令牌，建议命名为 OpenCode，并选择对应分组（如需调用 Claude，请确认该分组包含 Claude 系列模型）。复制得到的 sk-xxx 字符串，下一步要用。

🎯 令牌建议：访问 API易 apiyi.com 注册后，建议为每个客户端单独建令牌，比如 ClaudeCode 一把、OpenCode 一把、Cursor 一把。这样某一端出现异常请求时只需吊销对应令牌即可，不影响其他客户端。

第三步：编辑 opencode.json 配置文件

OpenCode 优先读取项目根目录下的 opencode.json，找不到再读用户级配置 ~/.config/opencode/opencode.json。下面给出 Anthropic 原生模式与 OpenAI 兼容模式共存的完整示例：

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "anthropic": {
      "options": {
        "baseURL": "https://api.apiyi.com",
        "apiKey": "{env:APIYI_KEY}"
      }
    },
    "apiyi-openai": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "API易 OpenAI 兼容",
      "options": {
        "baseURL": "https://api.apiyi.com/v1",
        "apiKey": "{env:APIYI_KEY}"
      },
      "models": {
        "gpt-4o": { "name": "GPT-4o" },
        "claude-sonnet-4-6": { "name": "Claude Sonnet 4.6" },
        "gemini-2.5-pro": { "name": "Gemini 2.5 Pro" }
      }
    }
  }
}

接着把令牌写到环境变量里：

# macOS / Linux
echo 'export APIYI_KEY="sk-你在APIYI后台拿到的令牌"' >> ~/.zshrc
source ~/.zshrc

# Windows PowerShell
$env:APIYI_KEY = "sk-你在APIYI后台拿到的令牌"

启动 OpenCode 后用斜杠命令 /models 选择模型，Claude 系列建议走 anthropic provider，其他模型走 apiyi-openai provider。

🎯 base URL 规律：Anthropic 原生模式不要加 /v1，因为 SDK 会自动追加 /v1/messages；OpenAI 兼容模式必须加 /v1。这一规则与 API易 apiyi.com 在 Claude Code 文档中给出的指引完全一致，记住"原生不加、兼容加"即可。

配置常见错误排查

报错信息	可能原因	处理方案
`Route /api/messages not found`	baseURL 写成了 `/v1`	去掉 `/v1` 后缀
`Required provider.anthropic.models`	自定义 baseURL 后缺少 models 字段	显式列出可用模型 ID
`401 Unauthorized`	令牌失效或分组不包含目标模型	重新生成 APIYI 令牌
`model not found`	模型 ID 与 APIYI 后台不一致	在 APIYI 模型广场查实际 ID
请求超时	网络抖动或上游限流	切换 APIYI 节点或重试

🎯 排错建议：遇到上述任意报错时，建议先用 curl https://api.apiyi.com/v1/models -H "Authorization: Bearer $APIYI_KEY" 直接验证令牌与网络可达性。这一步能在 30 秒内定位 90% 的问题，比来回改 opencode.json 要快得多。如果列表正常返回，则问题大概率出在 OpenCode 配置层。

OpenCode 与 APIYI 中转站的实战使用场景

配置跑通后，真正决定使用体验的是工作流。下面列出几个最常用的实战姿势。

场景一：用 plan 模式做无副作用代码评审

切到 plan 模式（按 Tab 键），输入 /解读这个仓库的鉴权流程，OpenCode 会扫描代码后输出一份分析报告，全程不写任何文件。这种用法适合 onboarding 新同事、做安全 review、或者对历史代码做架构梳理。

场景二：用 build 模式跑端到端开发任务

确认方案后切到 build 模式，下达 把鉴权中间件改成基于 JWT 的实现，并补上单测 这种端到端任务。OpenCode 会自动读相关文件、修改、运行测试、根据失败原因迭代。建议在 git 干净的分支上执行，方便回滚。

场景三：多模型协同与成本控制

利用 OpenCode 的 provider 抽象，可以把不同任务派给不同模型。例如：

文档与提交信息：走 apiyi-openai 下的 gpt-4o-mini，成本极低。
复杂重构与代码评审：走 anthropic provider 下的 claude-sonnet-4-6 或 Opus 系列。
涉及多语言／视觉内容：走 apiyi-openai 下的 gemini-2.5-pro。

🎯 成本提示：通过 API易 apiyi.com 调用时，所有模型均按实际 Token 用量结算，没有最低消费门槛。建议先用低价模型跑通流程，验证效果后再切高价模型，把预算花在刀刃上。

场景四：非交互模式接入 CI/CD

OpenCode 的 opencode run 命令可以把 prompt 直接拼到 shell 里，输出会按 stdout 返回，方便接入 GitHub Actions、GitLab CI 或定时任务。比如每周自动跑一次仓库结构审查、或者在 PR 合入前生成 changelog 草稿。

常见问题 FAQ

Q1：OpenCode 真的支持 Anthropic 原生 /v1/messages 协议吗？

支持。OpenCode 内置的 anthropic provider 使用 @ai-sdk/anthropic 包，请求路径就是 Anthropic 官方的 /v1/messages，请求体也是官方 Messages API 格式，与 Claude Code 走的是同一套协议。把 baseURL 指到 API易 apiyi.com 即可在 OpenCode 中获得与 Claude Code 几乎一致的体验。

Q2：如果只用 OpenAI 兼容模式，会丢失哪些 Claude 能力？

OpenAI 兼容模式下，Anthropic 专属的 tool_use 块、extended thinking、缓存控制头等特性会被协议层适配。功能上仍可用，但响应格式经过转换，部分细粒度行为（如 thinking token 计费、特定 stop reason）可能与原生模式略有差异。Claude 主线开发推荐走原生模式。

Q3：OpenCode 的配置文件支持 ${env:VAR} 还是 {env:VAR}？

最新版本统一为 {env:VAR} 语法，旧版本曾用 ${env:VAR}。如果 OpenCode 报 apiKey is undefined，先检查是不是写成了 ${env:APIYI_KEY}，按当前规范改为 {env:APIYI_KEY} 即可。

Q4：OpenCode 自带的 /connect 命令能否直接接入 APIYI？

可以。运行 /connect 选择 "Other"，输入 provider ID（如 apiyi-openai），粘贴 APIYI 令牌，OpenCode 会自动写入 opencode.json。但 /connect 默认走 OpenAI 兼容路径，如果你想走 Anthropic 原生模式，建议手动编辑 provider.anthropic.options.baseURL。

Q5：是否可以让 Claude Code 与 OpenCode 共用 APIYI 同一把令牌？

完全可以，且强烈推荐。API易 apiyi.com 的令牌不绑定客户端，同一把 sk-xxx 令牌可以同时被 Claude Code（通过 ANTHROPIC_BASE_URL）、OpenCode（通过 opencode.json）、Cursor、Continue 等多个客户端使用。后台账单可按调用来源统一查看。

Q6：OpenCode 的 plan / build 模式与 Claude Code 的权限确认是同一回事吗？

设计目标相近，但实现路径不同。Claude Code 是逐次询问，每次写文件、跑命令前都会弹确认。OpenCode 是模式切换，plan 模式从根本上禁掉了写权限，build 模式则默认放开。OpenCode 的方式更适合自动化场景，Claude Code 更适合需要逐步把控的场景。

Q7：APIYI 中转站调用 Claude 时延会比直连官方高吗？

API易 apiyi.com 在国内多个核心节点部署了入口，对 Claude、GPT、Gemini 等主流上游做了链路优化，国内用户实际体感的首字节延迟通常显著低于直连官方端点。具体数字可以在自己的网络环境下用 curl -w "%{time_starttransfer}" 实测对比。

总结：OpenCode + APIYI 的最佳实践组合

OpenCode 的真正价值在于把"模型选择权"交还给开发者，而 APIYI 这类中转站让这种灵活性有了真正落地的载体。两者搭配后，开发者既能在终端里享受到与 Claude Code 接近的 Claude 体验，又能随手切到 GPT、Gemini、DeepSeek 等模型做交叉验证，整套工作流只需要管理一个 OpenCode 配置文件加一把 APIYI 令牌。

回到本文最初的问题：OpenCode 同时支持 OpenAI 兼容模式与 Anthropic 原生格式，二者并不互斥。建议长期用户在 opencode.json 中并存两个 provider，Claude 走原生路径以保留全部能力，其他模型走兼容路径以最大化通用性。

🎯 最终建议：如果你正打算尝试 OpenCode，最省事的开局是注册 API易 apiyi.com，建一把令牌，按本文配置同时启用两种模式。一周后你会发现自己已经离不开"用一把令牌驱动所有模型"的工作方式，再也不想为每家模型单独维护账号和余额了。

— APIYI 技术团队 | 持续追踪 AI 编码代理生态，更多教程见 API易 apiyi.com 帮助中心

OpenCode 配置 API 中转站完整指南：3 步开启 Claude 原生与 OpenAI 兼容双模式

OpenCode 项目介绍：开源 AI 编码代理的核心定位

OpenCode 的架构设计与运行模式

OpenCode 的核心能力

OpenCode 与 Claude Code 的核心区别对比

模型支持范围与成本控制

工作流与权限模型差异

适合谁用 OpenCode

OpenCode 接入 APIYI 中转站的两种调用模式

模式一：OpenAI 兼容模式（最通用）

模式二：Anthropic 原生模式（用 Claude 时推荐）

3 步完成 OpenCode 与 APIYI 中转站配置

第一步：安装 OpenCode 客户端

第二步：在 APIYI 后台获取 API 令牌

第三步：编辑 opencode.json 配置文件

配置常见错误排查

OpenCode 与 APIYI 中转站的实战使用场景

场景一：用 plan 模式做无副作用代码评审

场景二：用 build 模式跑端到端开发任务

场景三：多模型协同与成本控制

场景四：非交互模式接入 CI/CD

常见问题 FAQ

总结：OpenCode + APIYI 的最佳实践组合

搞懂 Claude Code 联网搜索 2 种方式：自带 WebSearch 和 6 大 MCP 搜索插件对比指南

掌握 AI 漫剧制作的 5 个核心技巧：Sora 2 API 与 Nano Banana Pro 实战指南

用 OpenClaw 接入 Nano Banana Pro 图片 API 的 5 步完整教程

Gemini 3 Pro 预览版 3 月 9 日关停：迁移 Gemini 3.1 Pro 的 5 个关键问题和应对方案

API 中转站使用 OpenAI Function Call 的示例代码，确保跑通

无需魔法使用 ChatGPT API：一文通晓 20+ 主流客户端配置教程

OpenCode 项目介绍：开源 AI 编码代理的核心定位

OpenCode 的架构设计与运行模式

OpenCode 的核心能力

OpenCode 与 Claude Code 的核心区别对比

模型支持范围与成本控制

工作流与权限模型差异

适合谁用 OpenCode

OpenCode 接入 APIYI 中转站的两种调用模式

模式一：OpenAI 兼容模式（最通用）

模式二：Anthropic 原生模式（用 Claude 时推荐）

3 步完成 OpenCode 与 APIYI 中转站配置

第一步：安装 OpenCode 客户端

第二步：在 APIYI 后台获取 API 令牌

第三步：编辑 opencode.json 配置文件

配置常见错误排查

OpenCode 与 APIYI 中转站的实战使用场景

场景一：用 plan 模式做无副作用代码评审

场景二：用 build 模式跑端到端开发任务

场景三：多模型协同与成本控制

场景四：非交互模式接入 CI/CD

常见问题 FAQ

总结：OpenCode + APIYI 的最佳实践组合

类似文章