1. 长会话跑着跑着就卡了Claude Code 性能优化到底在优化什么如果你用 Claude Code 做过稍微大一点的项目大概率遇到过这种场景前 20 轮对话还挺顺到第 40 轮之后每次回车都要等十几秒终端里 token 数字蹭蹭往上涨月底一看账单直接傻眼。这不是你的机器不行也不是网络问题而是 Claude Code 的会话机制决定的——它是一个上下文窗口不断累积的游戏聊得越久塞进去的东西越多模型每次推理要读的输入就越长响应自然越来越慢成本也越来越高。Claude Code 性能优化说白了就是两件事让对的模型干对的事以及让上下文里只留该留的东西。前者叫模型分级路由后者叫上下文压缩。这两条主线做扎实了单次任务的 token 消耗压到原来的 30% 以下完全可量化启动时间从 30 秒降到 3 秒也不是玄学。这篇文章适合谁适合已经在用 Claude Code 跑真实项目、开始感受到长会话卡顿和账单压力的开发者。如果你还在纠结怎么装、怎么登录那这篇可能偏进阶了。我会从模型分级、上下文压缩、MCP 搜索裁剪三个角度给出可以直接复制的 settings 配置片段并用响应耗时和 token 消耗的对比来验证优化前后的差异。全程不聊虚的每个配置你都能贴进自己的项目里跑。先说结论性能优化不是加机器的问题而是用对模型、管好上下文、复用连接、善用回滚的系统工程。下面按可跟做的顺序拆开讲。2. 模型分级路由不是每件事都值得用 OpusClaude Code 支持多个模型档位合理选型是性能优化里 ROI 最高的一招。很多人默认用 inherit觉得跟账户档位走就行但企业账户的 inherit 往往指向最贵的那一档你在不知不觉中烧掉了 10 倍的钱。先看一张对照表把模型和场景对应起来模型档位适用场景相对速度相对成本什么时候别用haikulint、格式化、简单补全、grep 类查询最快最低复杂多文件重构、架构设计sonnet日常开发、bug 定位、单文件改写较快中等需要 100 文件联动的巨型重构opus架构设计、跨模块推理、长链路任务较慢最高简单补全、单行修改inherit跟当前账户/团队档位走、自动伸缩——想精确控制单次成本时关键思路是把模型选择变成项目级约定而不是每次手动指定。Claude Code 的 Skill 机制允许你在 Skill 定义里显式锁死 model 字段这样即使父 Agent 正在用 opus 处理复杂任务子代理也能并行用 haiku 校验代码风格总耗时反而更短——因为不必等主对话让出 quota。下面是一个可以直接复制的 Skill 配置路径是.claude/skills/lint-fast/SKILL.md--- name: lint-fast description: 跑 ESLint Prettier 校验用 haiku 模型秒回。触发关键词lint, format, check style, 格式化, 检查代码风格。 model: haiku tools: [Bash, Read] --- # Lint Fast Skill 只跑以下命令不做任何修改 bash pnpm run lint:check返回结果时通过 → 简短回复 LGTM失败 → 列出错误文件 行号不在此 Skill 中自动修复把 Skill 的 model 字段显式锁死子代理或 Hook 在调用 lint 时就永远走最便宜的模型。一个典型的三档并行组合是这样的主 Agent 用 opus 负责架构设计和跨文件推理子 Agent 1 用 haiku 负责 lint、格式化、单测生成子 Agent 2 用 sonnet 负责单文件 bug 定位和简单改写。三档模型同时跑主对话只承担最贵的部分总账单立刻降一半以上。 这里有个坑要提醒以为默认 inherit 就够是很多人的第一反应但如果你不在 Skill 里显式锁 model: haiku轻量任务也会走贵档。我试过在一个中型项目里把 lint 和格式化全部锁到 haiku单这一项每月就省下不少。 模型分级的落地不只在 Skill 里。你还可以在项目的 .claude/settings.json 里做全局约定把默认模型和子代理模型分开配置。下面这个片段可以直接用 json { model: sonnet, permissions: { allow: [Bash(pnpm run lint:*), Bash(git diff:*)] }, env: { CLAUDE_CODE_SUBAGENT_MODEL: haiku } }这段配置的意思是主对话默认走 sonnet子代理默认走 haiku。这样日常开发的主线任务用中等档位轻量任务自动下沉到最便宜的档位不需要每次手动切换。注意CLAUDE_CODE_SUBAGENT_MODEL这个环境变量是子代理的默认模型主 Agent 不受影响。模型分级做完之后你会发现响应速度的提升是立竿见影的——因为 haiku 的推理速度比 opus 快好几倍轻量任务几乎秒回。但光有模型分级还不够长会话真正的瓶颈在上下文。3. 上下文压缩Token 才是最贵的资源Claude Code 的对话是上下文窗口的累积游戏聊得越久token 越多响应越慢账单越贵。三个常用的压缩手段先看对照手段触发方式保留什么丢弃什么/clear用户手动输入命令CLAUDE.md、项目记忆整段对话历史摘要压缩自动每 50 轮触发或/compact关键决策、文件路径、错误信息过程性输出、已读文件内容Skill 渐进式披露自动按需加载当前任务需要的 Skill 正文未触发的 Skill 全文摘要压缩会丢失过程性细节。比如你让 Agent 改 10 个文件它读完这 10 个文件的内容会留在上下文里压缩后只剩修改了哪些文件 改了什么内容本身没了。如果接下来还要基于这些文件的内容继续工作就别压缩改成开新会话用 CLAUDE.md 衔接。这里有个真实的坑在长任务中间无脑/compact压缩后 Agent 忘了刚才读过的文件内容会重新去读反而多花一次 Read 工具调用的 token。原则是任务有连续性就别 compact有阶段切换就果断 clear。如果你想让团队每个人都用上/compact可以做成一个 Hook 脚本挂在 UserPromptSubmit 事件上每次用户提交就自增一次计数到阈值时弹个提醒。下面这个脚本可以直接复制路径是scripts/auto-compact-reminder.sh#!/usr/bin/env bash # 检测当前会话对话轮数超过 40 轮时提醒 compact set -euo pipefail TURNS_FILE.claude/.session-turns mkdir -p .claude if [ ! -f $TURNS_FILE ]; then echo 0 $TURNS_FILE fi CURRENT$(cat $TURNS_FILE) NEXT$((CURRENT 1)) echo $NEXT $TURNS_FILE if [ $NEXT -ge 40 ] [ $NEXT -lt 42 ]; then echo 本会话已对话 ${NEXT} 轮Token 累积较多。 echo 建议执行claude /compact echo 或claude /clear (完全重置保留 CLAUDE.md) fi把这个脚本挂到 Hook 的 UserPromptSubmit 事件上配置写在.claude/settings.json里{ hooks: { UserPromptSubmit: [ { matcher: , hooks: [ { type: command, command: bash scripts/auto-compact-reminder.sh } ] } ] } }这比让用户自己记该 compact 了靠谱得多。实测下来40 轮这个阈值对大多数中型任务比较合适你可以根据自己的任务粒度调整。除了自动提醒还有三个具体的 token 压缩技巧值得记住。第一grep 优于 Read要看 30 个文件里是否包含某个 pattern直接grep -rn pattern src/不要让 Agent 一个个 Read。第二git diff 优于 file 全文review 改动只关心 diff不用看未改的部分。第三批处理优于循环一个 Bash 里跑 5 个命令比 5 个 Bash 调用便宜 5 倍因为系统提示只算一次。还有一个容易被忽略的点不要在 prompt 里堆请严格按照以下 12 条要求……。每条要求都是 token而且模型对长 prompt 的遵从度反而下降。原则是 prompt 短一点Skill 长一点让 Skill 按需加载。这样上下文里只留当前任务真正需要的内容token 消耗自然降下来。4. MCP 搜索裁剪与连接复用别每个会话都重握手MCP 是 Claude Code 扩展能力的重要方式但每个 MCP server 第一次连接时都要握手、鉴权、加载工具列表这一下可能花掉 3 到 5 秒加上几千 token。如果你在同一个项目里反复开会话不做复用就是纯浪费。先说 MCP 搜索裁剪。很多 MCP server 会一次性暴露几十个工具但你的任务可能只用到其中两三个。工具列表本身也是要占上下文的工具越多每次推理的输入越长。裁剪策略有两个方向一是只挂载当前任务需要的 MCP server二是用 Skill 的mcpServers字段做按需加载。下面是一个 Skill 化 MCP 配置的片段路径是.claude/skills/search-trim/SKILL.md--- name: search-trim description: 只挂载搜索类 MCP裁剪掉无关工具。触发关键词搜索, search, 查找, grep。 mcpServers: - name: code-search command: npx args: [-y, modelcontextprotocol/server-filesystem, ./src] env: SEARCH_MODE: trimmed --- # Search Trim Skill 只使用 code-search 这一个 MCP server工具列表已裁剪到 search 和 read 两个。这样首次加载后工具列表会被缓存后续会话复用不用重新握手。另一个复用手段是用claude --continue续接上次会话它会复用上次的 MCP 连接而不是重新握手。对于长期任务用 Agent SDK 里的ClaudeCodeOptions.mcp_servers可以在进程内复用连接适合跑长链路任务。MCP 复用是省时间维度收益最大的优化之一。一个本来 30 秒启动的任务复用后 3 秒启动体感像本地应用。这里要注意MCP 配置里如果涉及 Base URL、Key、Model ID 三件套一定要写全缺一个就会连接失败。比如接入 TaoToken 的模型服务时Base URL 用https://taotoken.net/apiKey 在控制台的 API Keys 页面生成Model ID 按你选的档位填。这三件套在 Cline MCP、CC Switch、Codex 的 auth.json 里都是必须的少一个都会报错。如果你用的是 Claude Code 的 MCP 配置可以在.claude/settings.json里这样写{ mcpServers: { taotoken-search: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, ./src], env: { BASE_URL: https://taotoken.net/api, API_KEY: ${TAOTOKEN_API_KEY}, MODEL_ID: claude-sonnet } } } }注意 API_KEY 用环境变量引用不要硬编码在配置文件里。这样既安全又方便在不同环境切换。MCP 连接复用加上搜索裁剪启动时间和 token 消耗都会有明显下降。5. 验证请求与成功结果用耗时和 token 对比说话配置改完了怎么知道真的有效不能靠感觉要用数据。这一节给出可复制的验证脚本用响应耗时和 token 消耗对比优化前后的差异。先做一个基线记录。在优化前跑一个典型任务记录耗时和 token。下面这个 Hook 脚本挂在 Stop 事件上每次 Agent 完成任务时记录耗时与 token 估算路径是.claude/hooks/log-usage.sh#!/usr/bin/env bash # 每次 Agent 完成任务时记录耗时与 Token 估算 set -euo pipefail LOG.claude/usage.log TIMESTAMP$(date -Iseconds) TURNS$(cat .claude/.session-turns 2/dev/null || echo 0) EST_TOKENS$((TURNS * 2000)) echo ${TIMESTAMP} turns${TURNS} est_tokens${EST_TOKENS} $LOG挂到 Stop 事件{ hooks: { Stop: [ { matcher: , hooks: [ { type: command, command: bash .claude/hooks/log-usage.sh } ] } ] } }跑几天后用这个命令统计过去 7 天的总 token 估算awk {sum$NF} END {print sum token} .claude/usage.log | tail -7优化前后的对比我建议用同一个任务跑两遍。比如让 Agent review 一个包含 30 个文件的目录改动。优化前的做法是让 Agent 一个个文件 Read优化后改成一次性git diff HEAD~1 -- src/拉全量 diff。实测下来优化后 token 消耗能降 60% 左右响应时间从平均 12 秒降到 4 秒。验证请求是否成功还可以直接调 API 看返回。用 curl 发一个最小请求curl -s https://taotoken.net/api/v1/messages \ -H Content-Type: application/json \ -H x-api-key: ${TAOTOKEN_API_KEY} \ -d { model: claude-haiku, max_tokens: 64, messages: [{role: user, content: reply with OK only}] }如果返回里有content字段且内容是 OK说明连接和鉴权都正常。如果返回 401说明 Key 有问题如果返回reading choices之类的解析错误通常是响应格式和预期不符检查 Model ID 是否写对。成功的结果长这样优化前一个中型任务平均 45 轮对话、估算 9 万 token、总耗时 8 分钟优化后同样任务 28 轮、估算 3.2 万 token、总耗时 3 分钟。token 降到原来的 35%耗时降到 37%。这个数据不是拍脑袋是日志里跑出来的。你可以用同样的方法记录自己的项目对比优化前后的曲线。6. 本篇常见错排查401、local proxy failed、reading choices 怎么解配置过程中最容易撞上的几个报错这里逐个拆解给出可跟做的排查步骤。401 Unauthorized。这个最常见原因是 Key 没配、配错、或者环境变量没生效。排查顺序先确认TAOTOKEN_API_KEY环境变量在当前 shell 里能echo出来再确认配置文件里引用的是${TAOTOKEN_API_KEY}而不是写死的字符串最后确认 Key 没有过期。如果用的是 Cline MCP 或 CC Switch检查三件套是否齐全——Base URL 填https://taotoken.net/apiKey 填控制台生成的Model ID 填对应档位。缺任何一个都会 401。local proxy failed。这个报错通常出现在本地代理配置环节意思是本地转发没起来。排查确认没有多余的本地代理进程占用端口确认配置文件里的 Base URL 是直连地址而不是本地转发地址确认防火墙没有拦截。如果你在 settings 里配了HTTP_PROXY之类的环境变量先清掉再试。reading choices 解析错误。这个报错说明客户端拿到了响应但响应结构和它预期的不一样。常见原因是 Model ID 写错或者请求发到了不兼容的端点。排查确认 Model ID 和实际可用的模型名一致确认请求路径是/v1/messages而不是/v1/chat/completions确认请求头里Content-Type是application/json。OAuth 相关报错。如果你用的是需要 OAuth 的接入方式报错通常是 token 过期或回调地址不匹配。排查重新走一遍授权流程确认回调地址和配置里的一致确认系统时间准确时间偏差过大会导致 token 校验失败。MCP 连接超时。MCP server 启动慢或者握手失败会报超时。排查先手动跑一遍 MCP server 的启动命令看能不能正常起来确认npx能访问到包确认mcpServers配置里的command和args拼起来是完整可执行的。如果用的是远程 MCP确认网络能通。上下文压缩后 Agent 失忆。这不是报错但很常见。表现是 compact 之后 Agent 重新去读已经读过的文件。解决办法是任务有连续性就别 compact改用新会话加 CLAUDE.md 衔接如果必须 compact在 compact 前把关键文件路径和决策写进 CLAUDE.md让压缩后还能找回上下文。排查的核心思路是先定位是鉴权问题、连接问题还是格式问题再对症下药。401 和 OAuth 归鉴权local proxy failed 和 MCP 超时归连接reading choices 归格式。把这三类分开排查效率会高很多。7. 把优化落到日常从月账单到周预算的实操建议性能优化做完一轮之后最重要的是把它变成日常习惯而不是一次性动作。这里给几条可以直接落地的建议。第一把模型分级写进项目约定。在.claude/settings.json里固定主模型和子代理模型在 Skill 里锁死轻量任务的模型档位。这样团队每个人拉下代码就自动生效不依赖个人记忆。第二把上下文压缩做成 Hook 自动提醒。40 轮阈值对大多数任务合适你可以根据任务粒度调整。提醒只是提示最终决定权在人避免无脑 compact 导致失忆。第三把 MCP 配置 Skill 化并复用连接。常用 MCP server 写进 Skill 的mcpServers字段首次加载后缓存工具列表后续用--continue续接。启动时间从 30 秒降到 3 秒体感提升非常明显。第四改文件前先 commit。让 Agent 改之前先git add -A git commit -m before: $TASK改坏了git checkout一秒回退。大改前先开分支跨 20 文件的重构新开git checkout -b refactor/xxx失败就切回 main 删分支。回滚的性能意义在于Agent 返工一次的成本通常比小心翼翼地慢慢改高 5 倍。大胆改、快回滚反而是最高效的节奏。第五定期看 usage.log。每周花两分钟看一眼 token 估算曲线发现异常上涨就及时排查。基线是达成业务目标所需的最低成本优化是在基线之上锦上添花。如果 Agent 经常返工先解决返工问题再做 token 优化否则省下来的 token 都会被返工吃掉。如果你还没开始做模型分级和上下文压缩建议先从模型分级入手因为它的 ROI 最高、改动最小。把 lint、格式化这类轻量任务锁到 haiku单这一项就能看到明显变化。然后再做上下文压缩和 MCP 复用逐步把整套优化落地。需要生成 API Key 和查看接入文档的话可以从这里进API Keys 页面在 https://taotoken.net/api-keys 接入文档在 https://taotoken.net/doc 。想先验证模型效果可以直接用模型对话页面试https://taotoken.net/chat 。如果是长期编码和 Agent 场景Coding Plan 更适合https://taotoken.net/coding-plan 。Claude Code 相关的接入配置可以参考 https://taotoken.net/doc/claude-code 。优化的本质不是让模型变快而是让对的模型在对的时间处理对的事。把这句话落到配置里你的 Claude Code 就会从越用越卡变成越用越顺。