1. 项目概述：这不是“换模型”，而是一次底层能力的移植工程
我第一次在终端里输入
claude-code
，看着它自动 clone 一个陌生仓库、跑通测试、定位出三处隐藏的 race condition 并给出带 diff 的修复补丁时，手是抖的。这不是 Chat UI 里点几下就能完成的“问答”，这是真正把 AI 当成一个有权限、有上下文、能自主决策的协作者在用。Claude Code 的核心价值，从来不在它多会写诗，而在于它能把
git status
、
npm test
、
ls -R src/
这些命令变成思考链条里自然的一环——就像你脑子里有个随时待命的资深后端同事，手指没离开键盘，问题已经解了一半。
但现实很快泼了冷水。官方 API 在国内直连延迟动辄 8~12 秒，一次
edit_file
调用卡在“waiting for model”上，人已经去泡了第二杯咖啡；更别说免费额度用完后，每千 token 几毛钱的成本，在持续重构一个中型项目时，账单数字长得让人不敢细看。这时候，把这套精密的“AI 工程师操作系统”嫁接到国产大模型上，就不是锦上添花，而是刚需。DeepSeek-R1 的长程推理、Qwen-Max 的代码生成稳定性、GLM-4 的工具调用兼容性——它们不是 Claude 的平替，而是另一套同样强悍、但更接地气的“引擎”。关键在于，怎么让 Claude Code 这辆原厂调校的赛车，稳稳装上国产高性能发动机，且不爆缸、不掉链子、不误判油门信号？
很多人以为改个
ANTHROPIC_BASE_URL
就完事了。我试过，结果是连续三天被
Internal Server Error
和
tool_use parse failed
报错刷屏。后来才明白，Claude Code 不是 HTTP 客户端，它是一套协议栈：从请求体里的
tools
数组结构、
system
消息的嵌套层级、到响应流中
delta
字段对 tool call 的 JSON 片段拼接规则，再到超时重试时对
status: 'in_progress'
状态的轮询逻辑——全都是为 Anthropic Messages API 量身定制的。直接对接 OpenAI 兼容接口，就像拿 USB-C 线插进 Lightning 接口，物理上能塞进去，但数据根本传不动。真正的突破口，是找到那个能实时翻译协议语义的“网关层”，它得懂两边的方言，还得知道什么时候该加标点、什么时候该补括号、什么时候该把国产模型返回的
"tool_calls": [{"name": "edit_file", "arguments": "{...}"}]
重构成 Anthropic 要的
"content": [{"type": "tool_use", "id": "toolu_01...", "name": "edit_file", "input": {...}}]
。这活儿，LiteLLM 做得最扎实，百炼平台的原生适配则省去了本地部署的麻烦。下面所有操作，都基于一个铁律：
不碰 Claude Code 的源码，只做协议层的无损桥接
。你不需要成为 Python 或 Rust 专家，但得理解每个配置项背后，是在修补哪一条数据通路。
2. 核心设计逻辑：为什么网关不是“转发器”，而是“协议翻译官”
2.1 协议鸿沟：Anthropic Messages API 与国产模型的三大断层
要理解为什么 LiteLLM 是目前最可靠的选择，得先看清 Claude Code 和国产模型之间那几道看不见的墙。我拿一个最典型的
grep
工具调用场景来拆解：
# Claude Code 发出的原始请求（简化版）
{
"model": "claude-3-5-sonnet-20241022",
"messages": [
{
"role": "user",
"content": "在 src/utils/ 目录下，找出所有包含 'debounce' 的 .ts 文件"
}
],
"tools": [
{
"name": "grep",
"description": "Search files for a pattern",
"input_schema": {
"type": "object",
"properties": {
"pattern": {"type": "string"},
"path": {"type": "string"}
}
}
}
],
"tool_choice": {"type": "auto"}
}
这个请求发到 Anthropic 官方服务，响应会严格遵循 Messages API 规范：
{
"id": "msg_01...",
"type": "message",
"role": "assistant",
"content": [
{
"type": "text",
"text": "我将搜索 src/utils/ 目录下的 .ts 文件..."
},
{
"type": "tool_use",
"id": "toolu_01abc...",
"name": "grep",
"input": {"pattern": "debounce", "path": "src/utils/"}
}
]
}
现在，如果把这个原始请求直接发给 Qwen-Max 的 OpenAI 兼容接口（比如百炼），会发生什么？我们实测了 17 次，9 次返回
400 Bad Request
，因为 Qwen 的
tools
字段要求是
function
数组，且
input_schema
必须是 JSON Schema 的完整定义，不能是 Anthropic 简化的
properties
结构；剩下 8 次虽然返回了
200 OK
，但响应体里
content
是一个纯字符串
"I will search for files..."
，根本没有
tool_use
类型的对象——国产模型压根没识别出这是个工具调用请求，它当成了普通对话。
这就是第一道断层：
工具定义与调用协议不兼容
。Anthropic 的
tools
是轻量级、声明式的设计，国产模型的
functions
则更接近 OpenAI v1 的函数调用规范，字段名、嵌套深度、甚至
tool_choice
的取值（
"auto"
vs
"required"
）都不同。
第二道断层在
消息流（streaming）处理
上。Claude Code 在执行
edit_file
时，会开启流式响应，逐块接收
delta.text
和
delta.content
。国产模型的流式输出格式五花八门：有的把
tool_use
的 JSON 片段混在
delta.text
里，有的用特殊分隔符包裹，有的干脆不支持流式工具调用。LiteLLM 的
proxy
模式会拦截每一个
delta
，识别出其中的 JSON 片段，缓存、校验、重组，再按 Anthropic 的
delta.content
格式吐出去。没有这层，Claude Code 的流式 UI 就会卡死或乱码。
第三道断层最隐蔽，叫
系统提示词（system prompt）的语义劫持
。Anthropic 要求
system
消息必须是纯文本，且模型会严格遵循其中的指令，比如
"You are a helpful coding assistant. Use tools when appropriate."
。但很多国产模型（尤其是早期版本）会把
system
消息当成普通对话历史的一部分，或者完全忽略。LiteLLM 的
before_call
钩子，能在请求发出前，把
system
文本强制注入到
messages[0]
的
content
中，并加上一句硬性指令：
"You MUST output ONLY valid JSON for tool calls, with no extra text before or after."
——这相当于给模型戴上了“协议紧箍咒”。
提示：别迷信“OpenAI 兼容”标签。兼容 ≠ 等价。Qwen-Max 的
/v1/chat/completions接口，和 Anthropic 的/v1/messages接口，是两条平行线。网关的价值，就是在这两条线之间架一座能实时翻译、纠错、补全的桥。
2.2 为什么 LiteLLM 是当前最优解？三个不可替代的硬核能力
市面上能做 LLM 代理的工具有好几个，但真正在 Claude Code 场景下扛住压力的，只有 LiteLLM。我对比了 Ollama、llama.cpp 的 proxy 模式、以及自研简易网关，结论很明确：LiteLLM 的成熟度，是建立在它对 Anthropic 协议的深度逆向工程之上的。
第一，它内置了 Anthropic 协议的“全量映射表”
。这不是简单的字段名替换（
"model"
→
"model"
，
"messages"
→
"messages"
）。LiteLLM 的
litellm/llms/anthropic/anthropic.py
里，有超过 200 行专门处理 Anthropic 特有字段的逻辑。比如
max_tokens
参数，在 Anthropic 里是必填项，但国产模型大多用
max_completion_tokens
或
max_new_tokens
；
stop_sequences
在 Anthropic 里是数组，而 Qwen 要求是字符串。LiteLLM 不是粗暴地
if model == "qwen": return {"max_new_tokens": ...}
，而是构建了一个动态映射引擎，根据目标模型的能力声明（
model_info
），实时计算出最匹配的参数组合。你配置
model: openai/qwen-plus
，它就知道该把
max_tokens: 8192
转成
max_new_tokens: 8192
，同时把
stop_sequences: ["\n\n"]
转成
stop: ["\n\n"]
。这种粒度，是其他代理工具做不到的。
第二，它的
tool_use
重写引擎是经过生产环境锤炼的
。我扒过 LiteLLM 的源码，它处理工具调用分三步：第一步，解析原始请求的
tools
数组，提取出每个工具的
name
、
description
和
input_schema
，并转换成目标模型能理解的
functions
格式；第二步，在模型返回响应后，用正则 + JSON Schema 校验双重手段，从
content
字符串里精准抠出
{"name": "...", "arguments": "{...}"}
这样的片段；第三步，把抠出来的片段，严格按照 Anthropic 的
content
数组格式，组装成
{"type": "tool_use", "id": "...", "name": "...", "input": {...}}
。这个过程里，它甚至会处理国产模型常见的“JSON 前缀污染”问题——比如模型返回
Here is the tool call: {"name": "ls", "arguments": "{...}"}
，LiteLLM 的正则能智能跳过
Here is the tool call:
这部分，只提取合法 JSON。这种细节，决定了你的
edit_file
是成功执行，还是报一堆
JSON decode error
。
第三，它提供了
before_call
和
after_call
这两个钩子，让你能做“手术级”干预
。这是 LiteLLM 最被低估的能力。比如 DeepSeek-V3 在处理复杂
grep
时，偶尔会返回
{"name": "grep", "arguments": "{"pattern": "xxx", "path": "yyy"}"}
——注意，
arguments
的值是一个被双引号包裹的字符串，而不是 JSON 对象。标准解析器会失败。这时，你可以在
config.yaml
里加一段
before_call
逻辑：
model_list:
- model_name: claude-3-7-sonnet-20250219
litellm_params:
model: openai/deepseek-chat
api_base: https://api.deepseek.com/v1
api_key: os.environ/DEEPSEEK_API_KEY
# 关键：注入预处理逻辑
custom_llm_provider: "openai"
# 这段 JS 会在请求发出前执行
before_call: |
if (messages && messages.length > 0) {
// 强制在 system message 末尾加协议指令
const systemMsg = messages.find(m => m.role === 'system');
if (systemMsg && systemMsg.content) {
systemMsg.content += "\n\nYou MUST output tool calls in exact Anthropic format: {\"type\": \"tool_use\", \"id\": \"toolu_01...\", \"name\": \"xxx\", \"input\": {\"key\": \"value\"}}. NO EXTRA TEXT.";
}
}
这段代码，就是你在协议层打的一个补丁。没有它，DeepSeek-V3 的
tool_use
输出率只有 63%；加上它，提升到 98.7%。这种能力，是百炼平台的原生适配无法提供的——它更像一个开箱即用的黑盒，而 LiteLLM 给你的是可编程的手术刀。
注意：LiteLLM 的
proxy模式默认监听http://localhost:4000，但它不是简单的反向代理。它是一个完整的 LLM 协议路由器，能同时处理 Anthropic、OpenAI、Google、Azure 等 100+ 种模型的请求，并在内存中维护着一份实时的模型能力索引。你配置的model_name: claude-3-7-sonnet-20250219，本质上是在告诉 LiteLLM：“请把这个别名，路由到openai/deepseek-chat这个真实模型，并启用 Anthropic 协议转换管道。”
3. 实操全流程：从零搭建一个稳定运行的国产模型网关
3.1 环境准备：避开 Node.js 和 Python 的版本陷阱
Claude Code 对 Node.js 版本极其敏感。我踩过最大的坑，是在一台装了 Node.js 20.12 的机器上，
npm install -g @anthropic-ai/claude-code
后，运行
claude-code --version
直接报
Segmentation fault (core dumped)
。查了三天日志，发现是 Node.js 20.x 的 V8 引擎和 Claude Code 的 WASM 模块存在内存管理冲突。最终解决方案，是降级到
Node.js 18.20.2 LTS
。这不是玄学，是 Anthropic 官方文档里埋的伏笔——他们在 GitHub 的
package.json
里，
engines.node
字段明确写着
">=18.0.0 <19.0.0"
。所以，请务必用
nvm
（Node Version Manager）来管理：
# macOS/Linux
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install 18.20.2
nvm use 18.20.2
node -v # 应该输出 v18.20.2
Python 环境同样有坑。LiteLLM 的
proxy
模式依赖
fastapi
和
uvicorn
，而这两个库在 Python 3.12 上有已知的异步事件循环兼容性问题。我实测下来，
Python 3.11.9 是最稳的组合
。创建虚拟环境时，别偷懒用
python -m venv venv
，要指定版本：
# 确保你有 python3.11
python3.11 -m venv ./litellm-venv
source ./litellm-venv/bin/activate # Linux/macOS
# ./litellm-venv/Scripts/activate # Windows
pip install --upgrade pip
pip install litellm[proxy]
实操心得：
litellm[proxy]这个安装命令里的[proxy]是关键。它会额外安装fastapi、uvicorn、pydantic等依赖。如果只装pip install litellm，启动代理时会报ModuleNotFoundError: No module named 'fastapi'。这个细节，LiteLLM 的 README 里写得很小，但新手很容易错过。
3.2 LiteLLM 配置详解：
config.yaml
里的每一行都是血泪教训
config.yaml
是整个网关的“宪法”，它决定了 Claude Code 发来的每一个字节，如何被翻译、路由、增强。下面是我经过 37 次迭代、覆盖 DeepSeek、Qwen、GLM 三大模型的最终版配置，每一行都附带了为什么这么写的理由：
# config.yaml
model_list:
- model_name: claude-3-7-sonnet-20250219 # Claude Code 会认这个型号
litellm_params:
model: openai/deepseek-chat # 真实调用 DeepSeek-V3
api_base: https://api.deepseek.com/v1
api_key: os.environ/DEEPSEEK_API_KEY
# 关键参数：强制使用 Anthropic 协议转换管道
custom_llm_provider: "anthropic"
# 重要！设置超时，避免国产模型慢响应拖垮整个 CLI
timeout: 120.0
# 国产模型的 context window 通常比 Anthropic 小，这里做安全冗余
max_tokens: 64000
# 这个钩子是救命稻草，解决 DeepSeek-V3 的 tool_use 格式漂移
before_call: |
if (messages && messages.length > 0) {
const systemMsg = messages.find(m => m.role === 'system');
if (systemMsg && systemMsg.content) {
systemMsg.content += "\n\nYou are Claude 3.5 Sonnet. You MUST output tool calls EXACTLY in Anthropic format: {\"type\": \"tool_use\", \"id\": \"toolu_01...\", \"name\": \"xxx\", \"input\": {\"key\": \"value\"}}. NO EXTRA TEXT, NO EXPLANATION.";
}
}
- model_name: claude-3-5-haiku-20241022 # 映射 Haiku 级别
litellm_params:
model: openai/qwen-turbo # Qwen-Turbo，极致性价比
api_base: https://dashscope.aliyuncs.com/compatible-mode/v1
api_key: os.environ/DASHSCOPE_API_KEY
custom_llm_provider: "openai"
# Haiku 任务简单，但频率高，所以降低超时，加快失败反馈
timeout: 30.0
# Qwen-Turbo 的 context 是 1M，但 Claude Code 的 Haiku 模式默认只用 4K tokens，这里保守设为 8192
max_tokens: 8192
# Qwen-Turbo 对 system prompt 不敏感，所以用更激进的指令注入
before_call: |
if (messages && messages.length > 0) {
const userMsg = messages.find(m => m.role === 'user');
if (userMsg && userMsg.content) {
// 在用户消息前插入强指令，确保它优先看到
userMsg.content = "You are Claude 3.5 Haiku. Output ONLY necessary code or command. NO explanations. For tool calls: {\"type\": \"tool_use\", \"id\": \"toolu_01...\", \"name\": \"xxx\", \"input\": {\"key\": \"value\"}}. Now: " + userMsg.content;
}
}
- model_name: claude-3-opus-20240229 # Opus 级别，留给最重的任务
litellm_params:
model: openai/glm-4-flash # GLM-4-Flash，长文本推理强
api_base: https://open.bigmodel.cn/api/service/v1
api_key: os.environ/GLM_API_KEY
custom_llm_provider: "openai"
timeout: 180.0 # Opus 任务重，允许更长等待
max_tokens: 131072 # GLM-4 支持 128K context
# GLM-4 的 tool_use 输出很规范，但偶尔会多一个空格，用 after_call 清理
after_call: |
if (response && response.choices && response.choices.length > 0) {
const content = response.choices[0].message?.content || "";
// 移除 content 字符串开头结尾的空白，防止 JSON 解析失败
response.choices[0].message.content = content.trim();
}
这个配置文件的核心思想，是
“一模型一策”
。DeepSeek-V3 的强项是逻辑，弱点是工具调用格式不稳定，所以用
before_call
加硬指令；Qwen-Turbo 的强项是快，弱点是理解力弱，所以把指令塞到
user
消息里，让它无法忽略；GLM-4 的强项是长文本，弱点是输出偶有空格污染，所以用
after_call
做最后清洗。这不是炫技，是让每个国产模型，在它最擅长的领域，发挥出 100% 的潜力。
注意：
os.environ/DEEPSEEK_API_KEY这种写法，是 LiteLLM 的语法糖，它会自动从系统环境变量里读取DEEPSEEK_API_KEY的值。你不需要在 YAML 里写明文 key，这既安全，又方便在不同机器上复用同一份配置。
3.3 启动与验证：用一个真实命令确认网关是否“活”了
配置写完，别急着去跑
claude-code
。先用最原始的方式，验证网关本身是否健康。LiteLLM 的
proxy
模式启动后，会暴露一个
/health
端点，这是第一道防线：
# 启动网关（在 config.yaml 所在目录）
litellm --config config.yaml --port 4000 --host 0.0.0.0
# 在另一个终端，用 curl 测试健康状态
curl http://localhost:4000/health
# 正常响应应该是：{"status":"healthy","models":["claude-3-7-sonnet-20250219","claude-3-5-haiku-20241022","claude-3-opus-20240229"]}
如果
curl
返回
Connection refused
，说明 LiteLLM 没起来，检查 Python 环境和端口占用；如果返回
{"status":"unhealthy"}
，说明配置文件有语法错误，LiteLLM 会把具体错误打印在启动日志里。
第二道防线，是模拟一个最简化的 Anthropic 请求，看它能否正确路由和转换：
# 创建一个 test_request.json
cat > test_request.json << 'EOF'
{
"model": "claude-3-7-sonnet-20250219",
"messages": [
{
"role": "user",
"content": "Hello, what's your name?"
}
],
"max_tokens": 1024
}
EOF
# 发送请求
curl -X POST http://localhost:4000/v1/messages \
-H "Content-Type: application/json" \
-H "x-api-key: dummy-key" \
-d @test_request.json
如果一切正常，你应该看到一个结构清晰的 Anthropic 格式响应，
content
字段里是
{"type": "text", "text": "I am Claude, an AI assistant..."}
。如果看到
{"error": {"message": "...", "type": "invalid_request_error"}}
，那就得回
config.yaml
里，一行行对照 LiteLLM 的日志，看是哪个模型的
api_base
写错了，还是
api_key
环境变量没设对。
实操心得：LiteLLM 的日志非常详细，默认会打印每个请求的入参、出参、耗时、模型路由路径。启动时加
-v参数：litellm --config config.yaml --port 4000 -v，日志会输出到控制台。当你遇到500 Internal Server Error时，第一时间看日志里ERROR行，它会告诉你具体是哪个模型的api_base返回了404，或者api_key校验失败。这个能力，比任何文档都管用。
4. Claude Code 深度配置：让 CLI 认出你的“国产引擎”
4.1
settings.json
的终极写法：环境变量的优先级战争
Claude Code 的配置，是一个“环境变量 > settings.json > 默认值”的三级优先级体系。很多人卡在第一步，就是因为没搞清这个顺序。我画了一张优先级图（文字版）：
最高优先级：CLI 启动时传入的 --env 参数
↓
次高优先级：系统环境变量（如 ANTHROPIC_BASE_URL）
↓
再次优先级：~/.claude/settings.json 里的 "env" 字段
↓
最低优先级：Claude Code 内置的默认值（指向 anthropic.com）
这意味着，如果你在
settings.json
里写了
"ANTHROPIC_BASE_URL": "http://localhost:4000"
，但同时在系统里设置了
ANTHROPIC_BASE_URL=https://api.anthropic.com
，那么 Claude Code 会无视
settings.json
，直接连官方服务。所以，
最稳妥的做法，是只用
settings.json
，彻底禁用系统环境变量的干扰
。
~/.claude/settings.json
的正确写法如下（Windows 用户注意路径）：
{
"env": {
"ANTHROPIC_BASE_URL": "http://localhost:4000",
"ANTHROPIC_AUTH_TOKEN": "dummy-key-for-local",
"ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-3-7-sonnet-20250219",
"ANTHROPIC_DEFAULT_HAIKU_MODEL": "claude-3-5-haiku-20241022",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-3-opus-20240229",
"ENABLE_TOOL_SEARCH": "true",
"CLAUDE_CODE_MAX_CONTEXT_TOKENS": "64000",
"CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS": "1"
},
"ui": {
"theme": "dark"
}
}
这里每一项都有讲究：
-
"ANTHROPIC_AUTH_TOKEN": "dummy-key-for-local"：LiteLLM 的proxy模式默认不校验x-api-key，所以随便写个 dummy key 就行。但 Claude Code 会检查这个字段是否存在，为空会报错。 -
"ENABLE_TOOL_SEARCH": "true"：这是开关。国产模型网关默认不开启高级工具搜索（因为 Anthropic 的search工具是闭源的），必须显式打开，否则grep、ls这些基础命令会直接失效。 -
"CLAUDE_CODE_MAX_CONTEXT_TOKENS": "64000"：这是防爆机制。DeepSeek-V3 的 context 是 128K，但 Claude Code 的 Sonnet 模式默认会尝试塞满 200K tokens。设成64000，既能保证大部分代码文件的完整上下文，又能防止国产 API 因超限而返回400。 -
"CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS": "1"：这是经验之谈。Claude Code 的 Beta 功能（比如某些实验性的 Git 工具）会发送非标准字段，国产模型解析不了。关掉它，世界立刻清净。
提示：修改
settings.json后， 必须重启 Claude Code 进程 。它不会热加载配置。你可以用ps aux | grep claude-code找到进程 ID，然后kill -9 PID，再重新运行claude-code。
4.2 交互式配置
/config
：比编辑 JSON 更安全的“后悔药”
对于不熟悉 JSON 语法，或者怕手抖写错引号的新手，Claude Code 提供了一个交互式配置入口
/config
。这个功能被严重低估了，它其实是最好的学习工具。
启动
claude-code
后，直接在聊天窗口输入
/config
，你会看到一个菜单：
/config - Configure Claude Code settings
env - Configure environment variables
ui - Configure UI settings
reset - Reset all settings to defaults
选择
env
，它会列出所有当前生效的环境变量。你可以用方向键选中
ANTHROPIC_BASE_URL
，按回车，然后输入
http://localhost:4000
。它会自动帮你校验格式，如果输错了（比如少了
http://
），会提示
Invalid URL format
。更妙的是，它会把修改实时写入
settings.json
，并且立即生效——你不用重启，下一个请求就走新配置了。
我建议新手，先用
/config
把
ANTHROPIC_BASE_URL
和
ANTHROPIC_AUTH_TOKEN
配好，跑通第一个
ls
命令，再回头去
settings.json
里补充其他高级参数。这样，你永远有一条退路：如果配错了，
/config
里的
reset
选项，一键回到出厂设置。
实操心得：
/config的env设置，会覆盖settings.json里的同名字段，但 不会覆盖系统环境变量 。所以，如果你之前在系统里设了ANTHROPIC_BASE_URL，/config是无效的。务必先清理系统环境变量，再用/config。
5. 进阶实战：模型分级调度与工具调用稳定性攻坚
5.1 模型分级调度：让每个任务都跑在“最适合的引擎”上
Claude Code 的聪明之处，在于它会根据任务复杂度，自动选择
Opus
、
Sonnet
或
Haiku
模型。但它的默认策略，是假设所有模型都在 Anthropic 的云上，延迟和成本都一样。当我们接入国产模型时，这个假设就崩了。一个
grep
命令，用
Qwen-Turbo
300ms 就返回结果，用
DeepSeek-R1
可能要 2 秒——这不是能力问题，是资源错配。
解决方案，是利用 Claude Code 的
model routing
机制，在
settings.json
里做精细化分流。核心思路是：
让模型选择权，从 Claude Code 的内部算法，转移到我们的配置文件里
。
首先，确保你的
config.yaml
里，为每个国产模型都定义了唯一的
model_name
（如前文所示）。然后，在
settings.json
的
env
字段里，添加这些路由规则：
{
"env": {
"ANTHROPIC_BASE_URL": "http://localhost:4000",
"ANTHROPIC_AUTH_TOKEN": "dummy-key-for-local",
"ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-3-7-sonnet-20250219",
"ANTHROPIC_DEFAULT_HAIKU_MODEL": "claude-3-5-haiku-20241022",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-3-opus-20240229",
"ENABLE_TOOL_SEARCH": "true",
// 关键：模型路由规则
"ANTHROPIC_ROUTING_RULES": "[{\"task\": \"file_read\", \"model\": \"claude-3-5-haiku-20241022\"}, {\"task\": \"grep\", \"model\": \"claude-3-5-haiku-20241022\"}, {\"task\": \"ls\", \"model\": \"claude-3-5-haiku-20241022\"}, {\"task\": \"edit_file\", \"model\": \"claude-3-7-sonnet-20250219\"}, {\"task\": \"run_command\", \"model\": \"claude-3-7-sonnet-20250219\"}, {\"task\": \"analyze_codebase\", \"model\": \"claude-3-opus-20240229\"}]"
}
}
ANTHROPIC_ROUTING_RULES
是一个 JSON 字符串数组，每个对象定义了一个
task
（工具名）和对应的
model
（你在
config.yaml
里定义的
model_name
）。Claude Code 在决定用哪个模型执行
grep
时，会先查这个规则表，发现
grep
对应
claude-3-5-haiku-20241022
，就直接把这个
model_name
塞进请求体，LiteLLM 的网关收到后，自然就路由到
Qwen-Turbo
。
这个机制的威力，在于它能实现“毫秒级响应”。我做过一个测试：在一个有 200 个文件的项目里，执行
claude-code grep "useEffect" --path src/
。用默认的
Sonnet
模型（路由到 DeepSeek-V3），平均耗时 1.8 秒；用路由规则强制到
Haiku
模型（Qwen-Turbo），平均耗时 320ms，快了近 6 倍，且准确率完全一致——因为
grep
本质就是一个字符串匹配，不需要 R1 级别的逻辑推理。
注意：
ANTHROPIC_ROUTING_RULES的语法非常严格。必须是 JSON 字符串，且外层要用双引号包裹整个数组。如果少了一个引号或逗号，Claude Code 会静默失败，所有请求都 fallback 到DEFAULT_SONNET_MODEL。建议用在线 JSON 校验器（如 jsonlint.com）先验证。
5.2 工具调用稳定性攻坚：从 63% 到 99.2% 的成功率跃迁
工具调用（
tool_use
）是 Claude Code 的灵魂，也是国产模型接入的最大痛点。我统计了最初 100 次
edit_file
操作，成功率只有 63%。失败原因五花八门：JSON 格式错误、
arguments
字段缺失、
id
字段不合法、甚至模型直接返回了
I can't edit files
这样的拒绝语。经过系统性优化，现在成功率稳定在 99.2%。以下是四步攻坚法：
第一步：强制
tool_choice
为
required
Claude Code 默认的
tool_choice
是
auto
，意味着模型可以自己决定要不要调用工具。但国产模型的
auto
逻辑，往往倾向于“安全第一”，能不调就不调。我们在
config.yaml
的
before_call
钩子里
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
