|

OpenCode 配置 API 中轉站完整指南:3 步開啓 Claude 原生與 OpenAI 兼容雙模式

OpenCode 是 2026 年最受關注的開源 AI 編碼 Agent 之一,主打"模型無關、終端優先"的設計哲學,讓開發者既能跑 Claude,也能調用 GPT、Gemini、本地模型,甚至混搭使用。它和 Claude Code 一樣跑在終端裏,但走的是另一條路線——把 provider 抽象成可插拔的配置項,由用戶自己決定底層模型。

許多讀者問站長我一個非常具體的問題:從配置上看 OpenCode 似乎是用 OpenAI 兼容模式調用的,那麼它是否支持 Anthropic 的原生格式?接入 APIYI 這類第三方中轉站時怎麼選才合適?

opencode-apiyi-third-party-api-configuration-guide-zh-hant 图示

本文從英文官方文檔與源碼角度做了完整考證,先講清楚 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 則是面向多模型生態的中立框架。

opencode-apiyi-third-party-api-configuration-guide-zh-hant 图示

模型支持範圍與成本控制

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。

opencode-apiyi-third-party-api-configuration-guide-zh-hant 图示

模式一: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 blockstool_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 幫助中心

Similar Posts