What · 是什么
27 个内置 LLM provider（anthropic/openai/dashscope/deepseek/z-ai/kimi/...）+ 自定义端点，覆盖国内外主流模型
内置 27 个 LLM provider，覆盖国内外主流大模型服务商：anthropic、bedrock(AWS SigV4)、openai、edenai、gemini、dashscope、dashscope-tokenplan、volcengine、deepseek、tencent-tokenhub、hy-tokenplan、iflytek、kimi、kimi-global、z-ai、z-ai-coding、mimo、minimax、minimax-cn、baidu-qianfan、ollama-cloud、novita、xai、litellm、siliconflow、siliconflow-cn、mistral
每个 provider 携带完整的连接元数据：BaseURL（API 端点）、AuthHeader（认证头格式）、EnvVar（对应环境变量名）、Models（可用模型列表），开箱即用
支持 custom_providers 自定义 provider，可指向任意端点，包括私有化部署的 LLM（内网/自建网关）
国内用户可直接选择 DashScope（阿里通义）或 DeepSeek，无需海外网络即可使用
provider 体系与协议层解耦：provider 决定连谁，协议（openai/anthropic 等）决定怎么连
provider 选择可通过 config.json 的 providers/custom_providers 段或命令行 --provider 参数指定
Why · 为什么
原理 · Principle
避免厂商锁定：一套 CLI 即可在 OpenAI/Anthropic/国内各家模型间切换，评估与迁移成本低
适配国内网络与合规环境：内置 DashScope、DeepSeek、Volcengine、百度千帆等国内端点，直连无需代理
满足私有化需求：企业可通过 custom_providers 接入内网模型网关，代码审查数据不出内网
How · 怎么做
持久配置：在 config.json 的 providers 段配置官方 provider（models 列表、max_tokens 等参数）
私有化接入：在 custom_providers 段定义自定义端点，配置 base_url、auth_header、env_var、models 等字段
命令行指定：ocr review --provider deepseek --model deepseek-chat
环境变量覆盖：OCR_LLM_URL/OCR_LLM_TOKEN/OCR_LLM_MODEL 可覆盖 provider 的连接信息
AWS 场景：选 bedrock provider，配合 anthropic-bedrock 协议（SigV4 签名）走通鉴权
查看当前生效的 provider 与模型配置，确认 BaseURL/AuthHeader 与密钥是否就绪
案例 · Cases
| 代表性案例 |
|---|
| 国内用户：--provider deepseek --model deepseek-chat 直连使用，无需代理 |
| 阿里云用户：选 dashscope（通义千问系列），与云上环境天然匹配 |
| 企业私有化：custom_providers 指向内网 vLLM/统一网关端点，审查数据不出内网 |
| AWS 环境：bedrock provider + anthropic-bedrock 协议，模型名进 URL 路径完成 SigV4 请求 |
反模式 · Anti-patterns
- 误以为 27 个 provider 全部开箱即用：未设置 provider 对应 EnvVar 的密钥时鉴权必然失败
- 选海外 provider（openai/gemini 等）而不考虑网络：国内直连可能超时，应改用国内 provider 或代理
- 混淆 provider 与协议：bedrock 必须配 anthropic-bedrock 协议做 SigV4 签名，配成 openai/anthropic 会 403
- custom_providers 只配 base_url 不配 AuthHeader/协议，导致 401 或协议不匹配报错
正反实例论证 · Evidence
正例 · Pro
国内用户直连 DeepSeek 内置 provider
{ "providers": { "deepseek": { "models": ["deepseek-chat", "deepseek-reasoner"] } }}27 个内置 provider 均已携带 BaseURL/AuthHeader/EnvVar/Models 元数据，deepseek 属国内端点，直连无需代理；密钥经其对应 EnvVar 注入，代码零改动即用。
反例 · Con
海外 provider 无密钥且无代理直连
{ "providers": { "openai": { "models": ["gpt-4o"] } }}未设置 openai 对应 EnvVar 的密钥，且国内环境无代理直连海外端点：要么 401 鉴权失败，要么连接超时。应改用 deepseek/dashscope 等国内 provider。
正例 · Pro
custom_providers 接入私有化端点
{ "custom_providers": { "internal-llm": { "base_url": "http://llm.internal:8080", "auth_header": "Authorization: Bearer", "env_var": "INTERNAL_LLM_TOKEN", "models": ["internal-model"] } }}自定义端点 + 对应鉴权头与密钥环境变量，审查数据不出内网；同时按端点能力选协议（OpenAI 兼容选 openai，Claude 兼容选 anthropic）。
反例 · Con
custom_providers 只配 base_url
{ "custom_providers": { "internal-llm": { "base_url": "http://llm.internal:8080" } }}缺 auth_header/env_var 时鉴权必然 401；若协议也未与端点匹配（如端点实为 Anthropic 兼容却走了 openai 协议），请求格式同样报错。
正例 · Pro
AWS 场景选 bedrock provider + SigV4 协议
ocr review --provider bedrock --model <bedrock-model># 协议配 anthropic-bedrock（SigV4 签名，模型名进 URL 路径）bedrock 内置 provider 与 anthropic-bedrock 协议组合，AWS 凭证签名后即可调用 Bedrock 模型。
反例 · Con
混淆 provider 与协议
ocr review --provider bedrock --model <bedrock-model>export OCR_LLM_PROTOCOL=openaibedrock 必须配 anthropic-bedrock 协议完成 SigV4 签名；配 openai 协议缺失签名，请求返回 403。provider 决定连谁，协议决定怎么连，两者不能混搭。