設定

config.json、18 個內建 provider、環境變數與進階鍵

配置檔在哪

~/.opencodereview/config.json,三種方式編輯:

內建 provider

名稱協定Base URLAPI key 環境變數
anthropicanthropicapi.anthropic.comANTHROPIC_API_KEY
openaiopenaiapi.openai.com/v1OPENAI_API_KEY
dashscopeopenaidashscope.aliyuncs.comDASHSCOPE_API_KEY
volcengineopenaiark.cn-beijing.volces.comARK_API_KEY
deepseekopenaiapi.deepseek.comDEEPSEEK_API_KEY
kimiopenaiapi.moonshot.cnMOONSHOT_API_KEY
z-aiopenaiopen.bigmodel.cnZ_AI_API_KEY
baidu-qianfanopenaiqianfan.baidubce.comQIANFAN_API_KEY
siliconflowopenaiapi.siliconflow.comSILICONFLOW_GLOBAL_API_KEY
完整 18 家清單(含 minimax、iflytek、tencent、novita…)見上游 configuration.md——此處列代表。

自訂 provider

任何不在表上的名稱都視為自訂,至少提供 url 與 protocol(anthropic / openai / openai-responses):

ocr config set provider                             my-gateway
ocr config set custom_providers.my-gateway.url      https://gateway.internal.com/v1
ocr config set custom_providers.my-gateway.protocol openai
ocr config set custom_providers.my-gateway.model    llama-3-70b
ocr config set custom_providers.my-gateway.api_key  "$MY_API_KEY"

用 Ollama 跑本地模型

ocr config set provider                          ollama
ocr config set custom_providers.ollama.url       http://127.0.0.1:11434/v1
ocr config set custom_providers.ollama.protocol  openai
ocr config set custom_providers.ollama.model     qwen3:32b
ocr config set custom_providers.ollama.api_key   ollama

Ollama 忽略 API key,但自訂 provider 要求非空 api_key,設任意佔位即可。模型本身必須支援原生工具呼叫——選型前看 FAQ 的 "No tool calls parsed"。

超時

鍵作用域預設
providers.<name>.timeout_secper-provider—
llm.timeout_sec舊版 llm 段—
OCR_LLM_TIMEOUT 環境變數覆蓋全部300 秒

每檔 prompt 上限

ocr config set max_tokens 200000
# 或單次覆蓋
ocr review --max-tokens 200000

預設 58,888 token。按檔案計算,與輸出上限、--max-tokens-budget 各自獨立。

其他進階鍵

鍵用途
llm.retry_codes讓 OCR 對非標準 4xx 臨時錯誤使用重試(如 403,400)
providers.<name>.extra_body發送廠商專屬欄位(如 Bedrock 風格 {"thinking":{"type":"disabled"}})
language評審評論的語言(中文 / English,預設英文)
mcp_servers.<name>MCP server 設定(見 MCP 頁)
telemetry.*OpenTelemetry 設定(見 遙測頁)

複用既有環境變數

已配好 Claude Code 的 ANTHROPIC_*,或 OCR 自己的 OCR_LLM_* 環境變數,OCR 自動識別,無需再寫 config。

📖 教學解說:設定深入解析

端點解析鏈:六步找 LLM

OCR 用六步找到 LLM:① OCR_LLM_URL 環境變數 → ② config.json 的 llm.* → ③ config.json 的 providers.* → ④ ANTHROPIC_BASE_URL → ⑤ ANTHROPIC_* → ⑥ OCR_LLM_*。第一步找到完整的 (URL, token, model) 三元組就停。優先級:env > config。所以 CI 用 env、本地用 config 是最佳實踐。

自訂 provider 的 protocol 取值

protocol 決定 OCR 如何與你的 LLM 端點通訊:

  • openai——標準 OpenAI chat completions API(適用大多數相容端點)
  • anthropic——Anthropic Messages API(用 x-api-key header)
  • openai-responses——OpenAI Responses API(較新格式)

不確定?用 openai——90% 的第三方端點都相容。

Ollama 的隱藏陷阱

Ollama 端點雖然忽略 API key,但自訂 provider 要求 api_key 非空。設 ocr config set custom_providers.ollama.api_key ollama(任意佔位)。更關鍵的:模型必須支援原生 function calling。只在文字中「描述」工具呼叫的模型(如 deepseek-r1)永遠無法配合——選有 tools 標籤的模型。

🔍 Worked Example:配置自訂 provider + 測試

Step 1 — 設定 provider

ocr config set provider my-gateway

Step 2 — 設定 URL

ocr config set custom_providers.my-gateway.url https://gateway.internal.com/v1

Step 3 — 設定 protocol

ocr config set custom_providers.my-gateway.protocol openai

Step 4 — 設定 model

ocr config set custom_providers.my-gateway.model llama-3-70b

Step 5 — 設定 API key

ocr config set custom_providers.my-gateway.api_key "$MY_API_KEY"

Step 6 — 測試連通性

ocr llm test

預期產出

✓ LLM endpoint reachable
✓ Model: llama-3-70b
✓ Auth: valid
Connection test passed.

常見錯誤與診斷

錯誤訊息診斷修復
ocr llm test 回 401/403token 缺 scope、過期或廠商不匹配確認 llm.use_anthropic 與 URL 匹配
No tool calls parsed模型不支援原生 function calling選有 tools 標籤的模型(qwen3/claude/gpt-4)
custom_providers requires non-empty api_keyOllama 忽略 key 但自訂 provider 要求非空設任意佔位:ocr config set ...api_key ollama

練習 / 驗收清單

  • 能找到 config.json 位置並描述三種編輯方式
  • 能區分內建 vs 自訂 provider
  • 能說明 protocol 的三種取值
  • 能解釋超時與 max_tokens 的優先級
  • 能配置 Ollama 本地模型
看完這頁你應該能說出:config 檔位置與三種編輯方式、內建 vs 自訂 provider、protocol 的三種取值、以及超時與 max_tokens 的優先級。

延伸閱讀:快速開始 · CLI 參考 · FAQ

① 進階真實情境 Worked Example:把設定變成團隊的「版本化 config-as-code」

情境

你們團隊 5 個人各自在本機亂設 config.json,有人用 dashscope、有人用 siliconflow、模型也不一致,評審品質忽高忽低。你要建立一套版本化的團隊設定:每個人 clone 下來直接可用,CI 與本機行為一致。

Step 1 — 建立團隊設定腳本(版本化、可重放)

# scripts/ocr-configure.sh —— 團隊唯一事實來源
ocr config set provider                    siliconflow
ocr config set model                       deepseek-v3
ocr config set language                    中文
ocr config set max_tokens                  120000
ocr config set llm.retry_codes             "403,400"
ocr config set providers.siliconflow.timeout_sec 180

Step 2 — 用 extra_body 關掉不需要的 thinking 輸出(省 token)

ocr config set providers.siliconflow.extra_body \
  '{"thinking":{"type":"disabled"}}'

某些廠商回傳的 reasoning tokens 也會計費。用 extra_body 傳廠商專屬欄位——這是 ocr config set 能帶 JSON 值的實例。

Step 3 — 驗證端點連通性 + 確認生效的設定

ocr llm test
ocr config set 2>/dev/null || cat ~/.opencodereview/config.json | jq .

Step 4 — 把腳本提交進 repo,新人一鍵設定

git add scripts/ocr-configure.sh && git commit -m "chore: team ocr config"

為什麼選這條審查路徑

與其讓每個人手工按 TUI,不如把「決策點」鎖進腳本:誰是預設 provider、用哪個模型、多少 token、幾秒超時、retry 哪些碼——全部是可 review 的 diff。改設定 = 開 PR = 走 code review,這本身就是在 dogfood OCR 的工程紀律。CI 不跑這個腳本(它有自己的 OCR_LLM_* env),因為 env 優先級更高、且 CI 用 secret 更安全。

預期產出

✓ LLM endpoint reachable
✓ Model: deepseek-v3
✓ language=中文, max_tokens=120000
Config file at ~/.opencodereview/config.json (rewritten by next set)

② 深入原理擴充:端點解析鏈的優先級與「看起來有效其實沒生效」

六步解析鏈其實是「三組候選」

六步可以重組成三組:(1) OCR_LLM_* 環境變數、(2) config.json 的 llm.* / providers.*、(3) ANTHROPIC_* 環境變數。第一步找到「完整 (URL, token, model) 三元組」就停。這表示:你以為 config.json 是唯一來源,但只要 shell 裡殘留一個 ANTHROPIC_BASE_URL,整個解析就會被它劫持。

「看起來設定有效但其實沒生效」的案例

# 你在 config.json 設了:model = claude-opus-4-6
# 但 ~/.zshrc 有:export ANTHROPIC_MODEL=claude-sonnet-4-5
# → 解析鏈第 5 步先命中 ANTHROPIC_MODEL,你的設定被跳過

ocr review --provider anthropic --model claude-opus-4-6  # 顯式覆蓋才有效

「我明明設了 model 為什麼跑出來是另一個?」——九成是殘留的 ANTHROPIC_* 或 OCR_LLM_* 環境變數優先於 config。診斷:env | rg 'ANTHROPIC|OCR_LLM'。顯式的 --provider/--model 命令列旗標優先級最高,是「我要確保這次用這個」的最終手段。

③ 診斷式疑難排解

症狀可能原因解決方案
設了 model 但實際跑的是別的殘留的 ANTHROPIC_* / OCR_LLM_* env 優先於 configenv | rg 'ANTHROPIC|OCR_LLM' 找殘留;用 --model 顯式覆蓋
config set 後檔案被「重新格式化」每次 set 會重寫整個 JSON,手動排版被覆蓋把想保留的註解/格式寫進 set 腳本,別手改 JSON
extra_body 沒生效protocol 不支援該欄位,或 key 名不符廠商規格對照廠商 API 文件確認欄位名與值格式
timeout_sec 設了沒用per-provider timeout 被 OCR_LLM_TIMEOUT env 覆蓋unset OCR_LLM_TIMEOUT 或直接設 env 當統一值
CI 行為與本機不同CI 用 env、本機用 config,兩者沒同步把決策點寫進版本化腳本,CI 用 env 覆蓋「只有 CI 該有」的差異

④ 進階挑戰題

  1. 挑戰一:你的團隊用 Ollama 本地模型 + 一個雲端模型做 fallback。設計一套 config 與腳本,讓「ocr llm test 先測本地、失敗才提示改用雲端」。
  2. 挑戰二:解釋「env > config」優先級下,為何 --provider/--model 命令列旗標仍然有效——它們在解析鏈的哪一層介入?
  3. 挑戰三:retry_codes 把 403 加入重試清單的風險是什麼?在什麼情況下「重試 403」是安全的?

① 專案級端到端 Worked Example:集中式「多環境設定治理」

情境

你的 OCR 要跑在 開發者本機(dev)、CI(staging)、內部模型閘道(prod) 三個環境,但每個環境的 provider、模型、超時、retry 都不一樣。你要一套「設定即程式碼」的治理方案:環境分層、secret 不外洩、變更可 review。

Step 1 — 用環境變數表達「環境差異」

# .env.example(提交進 repo,不含 secret)
# dev(本機): 開發者自己的 key
export OCR_LLM_URL="https://api.siliconflow.com/v1"
export OCR_LLM_MODEL="deepseek-v3"
# ci(GitHub Actions secret): 集中管理的 key
export OCR_LLM_URL="https://gateway.internal.com/v1"
export OCR_LLM_MODEL="claude-opus-4-6"
# prod(內部閘道): 內網模型,diff 不出網
export OCR_LLM_URL="http://vllm.internal:8000/v1"
export OCR_LLM_MODEL="qwen3-32b"

因為「env > config」,每個環境只需注入對應的 OCR_LLM_*,config.json 只放「三個環境共用的決策」。

Step 2 — config.json 只放「共用決策」

# 共用決策(提交進 repo 給人 review)
ocr config set language            中文
ocr config set max_tokens          150000
ocr config set telemetry.enabled   true
ocr config set telemetry.exporter  otlp
# secret 一律走 env,永遠不寫進 config.json

Step 3 — 建立「環境生效驗證」腳本

# scripts/verify-env.sh <dev|ci|prod> —— 每次改設定後先驗證再上
source ".env.$1"
env | rg 'OCR_LLM|ANTHROPIC' | sed 's/=.*/=/'   # 確認沒有殘留
ocr llm test   # 確認三元組真的生效

Step 4 — 把設定流程接進 CI(secret 只在 CI 注入)

# GitHub Actions: secrets 裡放 prod 的 OCR_LLM_*,跑評審前不用任何 ocr config set
# 本機 dev 的人用 .env.dev + 自己的 key —— 兩者互不污染

為什麼選這條路徑

多環境設定的核心規則是「環境差異走 env、共用決策走 config、secret 只走 env」。因為解析鏈「env > config」,只要每環境注入 OCR_LLM_*,config 就退居「共用預設」——不用在 config 裡做條件分支。secret 永不進 config.json(它是純文字、易被 commit),一切可 review、可重放。

預期產出

dev:  siliconflow / deepseek-v3 / 自己的 key
ci:   gateway / claude-opus-4-6 / 集中 key(Actions secret)
prod: vllm / qwen3-32b / 內網、無 key
驗證: 三環境 ocr llm test 全過,git diff 只看到 .env.example 與共用 config

② 效能 / 品質 / 安全深度:設定三面向

效能:設定直接決定成本

幾個設定的成本槓桿:max_tokens 越大,壓縮觸發越晚但每次 prompt 越大;retry_codes 把 403 加入重試可能放大成本(每次都重試到成功或超時);providers.<name>.extra_body 關掉 thinking 輸出可直接省下 reasoning token。成本敏感環境:用 extra_body 關 thinking + 調低 max_tokens。

品質:設定漂移是品質殺手

「本機跟 CI 行為不一致」九成是設定漂移——本機殘留 ANTHROPIC_* env、或本機 config 比 CI 新。品質措施:① 把「共用決策」全部集中到一個版本化腳本;② CI 的 model 版本 pin 住(claude-opus-4-6@2026-08-01 風格);③ 每次評審的 JSON llm.provider/model 欄位就是「設定快照」——拿它跟團隊標準對照。

安全:設定的安全風險

① api_key 寫進 config.json 就會被 ocr config set 重寫時保留在純文字檔——避免手改 config.json 放 key;② 殘留的 ANTHROPIC_AUTH_TOKEN 可能把流量導向非預期端點——定期 env | rg 'ANTHROPIC|OCR_LLM' 檢查;③ 自訂 provider 的 url 若被改寫,評審的 diff 會送到惡意端點——config.json 用 600 權限保護。

③ 文件間比較對照表

面向本文(設定)相關文差異說明
provider18 內建 + 自訂 + protocol 三種取值mcp.html設定頁管「LLM 端點」;MCP 頁管「工具端點」——兩者都寫進 config.json 但屬不同命名空間
端點解析六步解析鏈、env > configfaq.html(no valid endpoint)FAQ 是「報錯時的診斷」;設定頁教「為何是這個優先級」——因果 vs 症狀
telemetry 設定只提 telemetry.* 鍵telemetry.html設定頁管「開關」,telemetry 頁管「怎麼用」(exporter/span/metric/儀表板)
OCI 環境env 注入 OCR_LLM_*cicd.html設定頁說明「env 優先」;CI/CD 頁把這變成「secret 只在 CI 注入」的實務

④ 互動式檢核清單

進階驗收:你能治理多環境的 OCR 設定嗎?

  • - [ ] 能把環境差異(dev/ci/prod)用 OCR_LLM_* env 表達而非 config 分支
  • - [ ] 能保證 secret 永不寫進 config.json,只走 env/CI secret
  • - [ ] 能用 env | rg 'ANTHROPIC|OCR_LLM' 找出殘留 env 並診斷「設了沒生效」
  • - [ ] 能用 extra_body 關掉 thinking 輸出省 token
  • - [ ] 能說明 retry_codes 把 403 加入重試的風險與適用條件
  • - [ ] 能用 JSON 輸出的 llm.provider/model 當設定快照做漂移檢查