企业官网建设流程全解析

我把 DeepSeek 接进 Claude Code，一个改 bug 的小任务跑了快十分钟，回来一看用量统计，token 消耗是用官方 API 时的十几倍。这是我最近在开发者群里看到频率最高的抱怨之一。说实话，Claude Code 本身并没有“针对第三方 API 变慢”的功能，但当你把任何 Anthropic 兼容端点接到这个 CLI 工具里，就会发现：模型推理变慢、token 用量暴涨，几乎是必然的。

这个现象不是玄学，也不是某个 API 服务商故意限速，而是 Claude Code 的架构设计、提示词协议、工具调用机制，加上第三方模型的格式遵循能力共同作用的结果。这篇分享我会从根因拆到实操，先讲清楚为什么慢、为什么烧 token，再给一套我实测过、可复现的调优与基准测试方案。适合正在把第三方模型接入 Claude Code 做日常编程辅助的人，也适合被 token 账单吓到、想搞清楚钱花在哪的人。

1. 先盘现象：慢在哪个瞬间，token 又是怎么“暴涨”的

1.1 三个典型现场，帮你对号入座

先别急着调参，先确定你遇到的是哪一种“慢”。我观察到的第三方 API 接入 Claude Code 后的异常，基本可以归成三类。

第一类是“首响应极慢”。你发出一个指令，Claude Code 界面上的状态指示器转了好几圈，几十秒甚至一两分钟都没有任何输出。这种慢不是模型生成慢，而是请求在服务端排队、或者在 prefill（预填充处理）阶段花掉了大量时间。第二类是“过程卡顿”。任务执行倒是没有完全卡死，但每完成一个小步骤，都要停顿几秒甚至十几秒才开始下一步，整体节奏像老式幻灯片。如果你在日志里打开 verbose 模式，会发现每个工具调用之间都有明显的空白期。第三类是“空转”。模型在反复读取同一个文件、反复列出同一个目录，或者生成了大段解释性文字但迟迟不调用工具。这种情况下 CPU 没闲着，但做的都是无用功。

至于 token“暴涨”，大部分人的体感是：同样一个任务，用官方 API 跑一遍可能消耗 200k token，换成第三方模型直接飙到 1M 甚至更多；或者任务没干多少事，上下文的滚动速度却快得吓人，聊着聊着就触发 context compaction（上下文压缩），然后压缩后又很快再次触顶。

1.2 “慢”和“token 暴涨”是同一个根因的两面

我最早排查这个问题时，也一度把它们当成两个独立故障，结果发现是同一个根因的两面。

Claude Code 的工作方式，决定了每一次模型调用都要携带一份庞大的上下文。系统提示词、工具定义、历史消息、项目文件内容，全都堆在一次请求里。第三方 API 在服务端要读完这么厚的请求才能开始生成，于是你感受到的“慢”就出现了；而同一份请求，每多调用一次模型，就多计一次完整 token 费。当模型因为不理解工具格式而反复试探、反复出错时，请求轮数成倍增加，token 自然就“暴涨”了。

所以后面所有分析都围绕同一个核心问题：第三方模型在 Claude Code 的协议框架下，用比官方模型更多的轮数、更大的上下文体量，完成了相同的事情。轮数多了，总耗时增加；每一轮携带的内容多了，总 token 增加。这两者在数学上是相乘的关系，不是相加。

2. Claude Code 的 harness 架构，为什么专为官方模型“定制”

2.1 两层提示词协议：orchestrator 与 task agent

想要理解 token 为什么涨，先得理解 Claude Code 不是“一个模型在跟你对话”，而是一套多代理协作系统。当你给它一个稍微复杂的任务时，它内部会拆出 orchestrator（总控）和多个 task agent（子代理）。总控负责规划、拆解任务、决定下一步调用哪个工具；子代理被派去改文件、读代码、执行命令，然后把结果回传。

这个架构的代价是：子代理需要继承主上下文，总控又需要等待子代理的结果。每一次任务切换、每一次子代理启动，都会带来额外的上下文拷贝，token 就在这些交接中不断膨胀。第三方模型如果本身对“子代理指令遵循”不敏感，还会出现总控让子代理跑偏、子代理返回一堆无关信息、总控再重新规划的情况，等于白白消耗了一整轮的输入 token。

更麻烦的是，这个架构默认是为 Claude 系列的指令遵循能力设计的。官方模型被训练成“拿到子代理指令就立刻执行，只在必要时汇报中间结果”；但不少第三方模型更习惯“长篇解释再做决定”，于是它们会在子代理环节输出大段推理，而这些推理对任务没有任何帮助，只会堆进上下文。

2.2 工具调用协议：XML 式的函数调用对第三方模型并不友好

Claude Code 的工具调用走的是 Anthropic 生态的 XML 风格协议，模型需要输出结构化的 tool_use 块，Claude Code 再解析这些块去真正执行工具。

问题在于，Anthropic 官方模型对这种协议的训练量非常充足，模型天然知道“该给函数传哪些参数、如何在多个工具之间抉择、什么时候需要 parallel tool use”。而第三方模型大多是在 OpenAI 风格的 function calling 数据上训练的，接到 Anthropic 格式后，虽然通常也能生成可解析的块，但稳定性差很多。

我实测中最常见的情况有三种：一是模型生成了格式合法但语义错误的调用，比如读文件时把路径参数写错，Claude Code 执行报错，模型被迫重新生成；二是模型倾向于“一次只调一个工具”，而官方模型会并行调用多个独立工具，这导致相同任务下第三方模型的轮数多出好几倍；三是模型有时会生成两套工具调用，一段放在思考里，一段放在正式回复里，Claude Code 只认正式部分，思考里的那部分成了纯浪费。

这些差异累积起来很可怕。每多一次报错重试，就要重新发送整段上下文；每少一次并行，就多一轮完整请求。第三方模型在工具协议上的不熟练，是 token 膨胀的第一大来源。

2.3 官方模型被“调教”过的行为习惯，第三方模型很难复刻

除了工具协议本身，Claude 系列在代码场景还有一些“行为习惯”，这些习惯其实是 Anthropic 在训练时特意强化的，用户往往感知不到，但换到第三方模型时就会立刻露出破绽。

比如官方模型倾向于“只读必要片段”。它拿到一个文件路径后，会先读文件头部、搜索关键符号、再看相关函数定义，而不是把整个文件全部灌进上下文。第三方模型更常见的是“读全文件、列全目录”，生怕漏掉信息。一次两次没关系，当代码库规模一大，行为差异直接体现在上下文总量上。

再比如官方模型有很好的“错误恢复习惯”。工具执行报错时，它会基于错误信息做小步修正，而不是重新读一遍所有材料。第三方模型在遇到报错时，往往会“退回到更大范围的上下文”——重新列出目录、重新读文件、把之前所有结论推翻重来。这种回退式行为，是 token 消耗的第二大来源。

所以你会发现，即便第三方模型本身能力不差，放进 Claude Code 这个“为官方模型量身定制”的框架里，也会因为行为模式不匹配而显得又笨又贵。

3. 把一次请求拆开看 token 到底流向了哪里

3.1 请求体的四个组成部分，谁在持续膨胀

很多人以为 token 用量主要由“我说的自然语言”决定，这是误解。在 Claude Code 里，你每一次模型调用，请求体由四部分构成：

• 系统提示词：Claude Code 内置的一整套行为规范，包含角色定位、工作方式、输出要求，这部分是非常大的固定开销。
• **工具定义：**所有可用工具的 schema 描述，也就是“模型可以调用哪些函数、函数长什么样、参数有哪些”，这也是一块很大的固定开销。
• 会话历史：从任务开始至今的所有消息，包括你的话、模型的回复、工具执行结果。
• 当前上下文：刚读入的文件内容、最新执行命令的输出、最近一次工具报错等。

前两部分对官方模型来说，可以通过 Anthropic 的 prompt caching 大幅降低费用；对不支持缓存的第三方 API 来说，它们会原封不动地出现在每一次请求里。而会话历史是线性增长的，任务执行越久、工具调用越多，这部分就越膨胀。

3.2 输出侧：思考块、工具调用文本与重复啰嗦

输入侧已经够大了，输出侧的问题更隐蔽。Claude 官方模型有一种“预算式思考”的机制，在后台用专门的 reasoning 通道进行推理，而 CLaude Code 可以设置是否让用户看到推理过程。但当你换成第三方模型时，往往不存在这个隐藏通道——模型的思考会以普通文本的形式直接生成出来，然后这些文本又成为下一轮请求的输入。

换句话说，官方模型可以“偷偷想”，第三方模型只能“大声想”。想得越多，token 就越多，而且这些想法还会污染后面的上下文。如果第三方模型还有长推理解码能力（比如用了 CoT 风格的数据训练），输出长度会更失控。我见过一个极端的例子：让模型修一个简单的正则错误，它在动手前足足输出了几千 token 的“推理”，其中包括了它对正则表达式语义的完整分析，而这段分析对工具的最终调用没有任何帮助。

3.3 一个第三方模型接入后的实测 token 画像（示例数据）

下面用我做过的一组粗糙实测来说明，任务统一是“在一个大约 1.5 万行的中型 Python 项目里定位一个数据竞态 bug 并修复”，模型分别用官方 Claude 和某第三方代码模型，都能完成，但画像完全不同：

注意，这不是严谨的评测，任务不同结果差异极大，但趋势非常稳定：第三方模型的请求轮数、工具调用次数和输出 token 都会有数量级的上升。输入 token 的上升主要靠轮数驱动，输出 token 的上升则是模型“爱写解释”的体现。

这张表也解释了为什么很多人在账单出来后会吓一跳：第三方 API 往往单价确实比官方便宜，但消耗量是官方的好几倍甚至十几倍，最后总成本不一定省多少，速度还慢了五倍。

3.4 缓存机制差异放大了三到十倍的成本差

官方 Claude 费用并不是你印象中的“每百万 token 多少美元”那么贵，因为 Anthropic 有 prompt caching：同一段系统提示词和工具定义在短时间内重复使用，可以按缓存命中的低价计费，并且缓存命中的请求响应也更快。

第三方 API 绝大多数不支持这个机制，或者即便支持，缓存策略也和 Anthropic 的风格不一样。比如有的模型服务是按字符数直接计费，有的把“缓存 token”也按原价收，有的缓存过期时间非常短，Claude Code 一次任务跑十几分钟，缓存早就失效了。

这意味着，同样的固定开销（系统提示词 + 工具定义），官方模型可能只按几十 k token 的有效成本计算，第三方模型则每次请求都按全价算。这部分差距不是模型能力造成的，纯粹是计费机制错配。你在对比“官方贵还是第三方贵”时，如果只比较单 token 单价，会严重低估官方模型的性价比。这也是“token 暴涨”里最冤的一部分。

4. 为什么第三方 API 在 Claude Code 里感觉“特别慢”：五个硬瓶颈

4.1 TTFB 与 prefill：上下文越长，等第一个字越久

当你发出一个请求，第三方模型的 API 要做的事是：接收请求体 -> 处理前缀提示（prefill）-> 开始逐字生成。prefill 阶段需要把所有输入的 token 跑一遍 transformer，上下文越长，这个阶段越慢。Claude Code 恰恰是“把大量上下文塞进一次请求”的专家，于是你在第三方 API 上遇到了最糟的组合：足够长的上下文，加上不够快的 prefill 引擎。

生活类比一下：你请一位师傅修水管，每次都要先让他读完整本维修手册再加一大叠历史维修记录，他才能动手。手册越厚、记录越多，他进入正题就越慢。官方模型等于已经把这本手册背熟了，第三方模型每次都要从头翻一遍。

这个延迟差异你跟模型自己的 prompt playground 对比时尤其明显：在网页上随便问一句，第三方模型挺快的；一旦通过 Claude Code 接入，上下文从几百 token 变成几十万 token，prefill 时间就开始以秒甚至分钟计。

4.2 流式输出的缺失：不是不响，是“攒着一口气说完”

Claude Code 默认走流式（SSE）输出，期望模型一边生成一边吐结果。官方 API 对这个模式的适配非常到位，用户看到的是“字在蹦出来”的即时反馈。

第三方 API 的流式实现往往不稳定，或者压根只是“伪流式”服务端等全部生成完再一次性吐给你。表现就是：你这边半天没动静，突然整段文本刷出来，然后立刻进入工具调用阶段。由于 Claude Code 的工具执行依赖完整输出块，模型要先把全部文本生成完，harness 才能解析并执行工具，所以你感知到的延迟就是“完整生成全部回复”的耗时，而不是首 token 延迟。

4.3 上下文触顶后的连锁反应：裁剪、遗忘、重读

Claude Code 默认按官方模型的大上下文窗口设计会话管理策略。它假设模型能容纳非常长的对话历史，所以“聊到一半自动压缩”这件事并不常发生。但不少第三方模型的上下文窗口更小（比如 64K、128K），在 Claude Code 生成长会话时很容易触顶。

一旦触顶，第三方 API 通常会返回 contextual timeout 或者 context length exceeded 错误，Claude Code 的应对方式就是裁剪历史（compaction），只保留总结后的精华再重新发起请求。这个总结过程本身又是一轮大输出。更糟的是，裁剪后的摘要经常丢掉关键细节，导致模型后续对代码的理解出错，于是又回到“重读文件、重跑命令”的循环里。

这就是为什么有些任务越跑越慢：它在反复做“触顶 -> 压缩 -> 遗忘 -> 重读”的循环，每一步都在烧 token，每一步都在拉长耗时。

4.4 并发调用与限流：多个子代理互相抢额度

Claude Code 在执行任务时，如果并行度允许，会同时发出多个工具调用或同时运行多个子代理。这个设计在官方 API 的高配额下毫无压力，但第三方 API 的配额通常按 RPM（每分钟请求数）和 TPM（每分钟 token 数）限制，远低于官方。

一旦并发数撞上第三方限流，API 会返回 429 或者连接超时。Claude Code 收到错误后会退避重试，而重试意味着同一份请求再发一遍，token 再计一次。如果任务规模大，并发触顶几乎是必然的。

这时候你看到的“慢”是排队慢：请求在服务端排队，或者在客户端退避等待。表面看起来是模型不行，实际上是配额被自己的并发策略吃光了。

4.5 单次输出限制的错配：模型被迫用更多轮次完成同一件事

官方模型的单次最大输出 token 可以设得很高，Claude Code 默认给的输出预算也比较宽松。第三方模型服务里，有些会把单次输出限制在 2K、4K 之类的低档位，理由是避免超额算力消耗。

这个小限制在普通对话里无所谓，但在 Claude Code 里是致命的：模型本来就话多，还要在有限的输出额度里完成“思考 + 工具调用 + 结果说明”，往往没说完就被截断，Claude Code 拿到的输出块可能是不完整的。结果就是模型需要分两轮、三轮才能把本可以一轮干完的事干完，轮数翻倍，token 也随之翻倍。

5. 实操优化：把第三方 API 在 Claude Code 里的成本速度调到能用的程度

5.1 模型选型标准：代码专项能力优先于通用 chat 能力

不是所有第三方模型都适合塞进 Claude Code。我踩过几次坑之后总结出的选型优先级是：代码专项能力 > 格式遵循能力 > 上下文窗口 > 价格 > 通用对话能力。

一个模型在工具体系里的“格式遵循能力”往往比它的通用智商更重要，因为它直接决定了工具调用的稳定性和轮数。选型时哪怕模型推理能力稍弱，只要工具调用准确率高，整体体验反而更好。我建议用小规模的“重活”测试，比如让它用 Claude Code 改一个已知 bug，观察它调用工具的链路是否短路。

5.2 必须改的配置项和环境变量

这里列一份我实测后收益最大的配置清单。

首先是环境变量，在接入第三方兼容端点时这样设置：

export ANTHROPIC_BASE_URL="https://your-third-party-endpoint" export ANTHROPIC_MODEL="your-model-id" export ANTHROPIC_AUTH_TOKEN="your-api-key"

这里有个容易被忽略的点：确认你的第三方端点是否对/v1/messages这个路径做了完整的 Anthropic 兼容。有些服务只兼容了简单的对话补全，工具调用和流式支持得很差，直接决定了慢和 token 浪费的程度。

其次是输出限制，如果账号允许，把单次输出调高一些：

export CLAUDE_CODE_MAX_OUTPUT_TOKENS=8192

这个值通常能缓解 4.5 里提到的“没说完就被截断”问题。我甚至见过有文章把它调到 16000，效果更彻底，但对模型的输出稳定性要求更高。第三方模型如果容易在超长输出下偏离格式，就维持 8192 最稳。

再次是在交互界面里调整 thinking budget。Claude Code 有/config命令，里面可以设置思考预预算。第三方模型往往没有官方的隐藏推理通道，把 thinking 预算调低或直接关闭，反而能减少“大声想”的文本量。

最后，删掉不必要的 Prompt 附加内容、关闭自动更新检查之类的杂项，能小幅降低请求体。虽然这部分不是大头，但每一个 token 在第三方 API 的高轮数模式里都会被放大。

5.3 会“省 token”的会话管理习惯

调参数只能解决固定开销，真正决定 token 总量的是会话历史的管理习惯。我这里说的不是魔法，而是一套省 token 的工作流。

第一，及时拆任务。Claude Code 的会话历史是滚动的，一个会话里塞的任务越多，历史越臃肿。单个任务做完就/clear，让下一次任务从零开始。第二，善用上下文压缩。感到对话变卡、token 消耗变快时，手动执行/compact比让系统自动压缩更可控，你可以选择保留哪些关键结论。第三，控制文件读取范围。先让模型读目录结构，再精确读目标文件，不要一上来就@整个大文件夹。Claude Code 里大文件的直接注入非常烧 token，很多人的 token 暴涨就是这么来的。

第四，别让模型“确认”每一件事。Claude Code 默认会在关键操作前征求确认，这个交互过程非常烧 token。如果你对工具行为有信心，可以在会话里让它开启自动批准相关操作，省掉一长串确认对话。

5.4 中间层代理能解决什么、不能解决什么

有人会建议你在 Claude Code 和第三方 API 之间再加一层代理，把请求格式转换、缓存、限流、密钥管理都包起来。这类方案确实能解决一些问题，但你要分清哪些是它能解决的，哪些不能。

能解决的是：缓存。如果你自己构建的代理层对相同请求体做了一层缓存，可以明显降低重复的 prefill 时间和输入 token 费用。不过要注意，Claude Code 每次请求体几乎都不同，历史的滚动导致缓存命中率实际没有想象中高。能解决的还有：格式转换，把 Anthropic 风格工具调用转换成符合目标模型的格式，这能提升工具的稳定性；还有配额调度，通过排队和重试策略消化并发限制。

不能解决的是：模型本身在工具协议上的不稳定，和“话痨”倾向。代理可以把格式转正确，但没法让模型少说话、少犯错、少走弯路。所以中间层是优化手段，不是银弹。

5.5 什么时候该果断放弃第三方 API 路线

聊到这一步，我给你泼点冷水。第三方 API 适合的是“低频、轻量、对成本高度敏感”的代码辅助场景。比如你只是偶尔让 Claude Code 帮你补全片段、做简单解释、写测试用例，这类任务闭环短、轮数少，第三方模型的吃相还看得过去。

但如果你要让 Claude Code 做复杂的跨文件重构、长链路排错、多文件迭代，第三方模型在协议遵循和行为习惯上的短板会被放大到不可接受。我测过几个场景，结论很一致：代码库越大、任务链路越长，第三方模型相对官方模型的效率差距越大。刚开始一个简单的改动差距可能只有两倍，但当任务复杂度上升，差距能拉到五倍以上。

一个低成本判断方法：任务超过 20 个工具调用还没收敛，果断换回官方模型。第三方 API 的省钱逻辑在长任务里几乎不成立。

6. 自己动手做一个接入基准测试，替换前先量化

6.1 固定任务、固定代码库、固定观测指标

我强烈建议你在正式把某个第三方 API 接入 Claude Code 之前，先跑一遍标准化的基准测试。这套基准我用了很久，关键点就是“三个固定”：固定一个小代码库（比如开源项目里一个几十文件的中型模块），固定的一个任务（比如“解释数据流并修复一个内存泄漏”），固定的观测指标。

观测指标至少要有：完成耗时、总输入 token、总输出 token、工具调用次数、请求轮数、报错重试次数。前两个是结果，后四个是根因。你拿到手后会发现，不同模型在同一个任务上的差异非常直观。

对比时还要加一组“对照组”：同一个任务，先用官方模型跑一遍，再换第三方模型。没有对照组，你很难说清慢和贵是模型问题还是任务本身的问题。

6.2 一张表格跑完三组对照实验

我习惯用下面这样的表格记录，你直接抄就行：

注意，费用换算不要只看单价，要把总 token 乘单价，再加报错重试的惩罚。第三步我会讲这个公式。

6.3 如何把 token 用量换算成费用并预估重试惩罚

很多人的成本核算方法是错的：他们拿官方模型和第三方模型各自的每百万 token 单价直接对比，然后得出“第三方便宜 90%”的结论。但真正算成本，要按“一次完整任务的加权消耗”来算：

任务总费用 ≈ 输入 token × 输入单价 + 输出 token × 输出单价 + 每条报错重试的输入 token × 输入单价

重试惩罚尤其容易被低估。一次工具报错，意味着上一轮输出白费，还要重新发送整段上下文让模型重新生成。第三方模型的报错重试率如果从 1% 涨到 20%，对总费用的影响是指数级的。

我见过一个很搞笑的项目：一个第三方 API 单 token 单价确实只有官方的十分之一，但在 Claude Code 里跑同样的任务，token 用量是官方的十二倍，报错重试率还高得吓人，最终实际花费反而更多。基准测试的意义就在这里：帮你提前避开这种“看着便宜、用着更贵”的坑。

7. 我自己的选择与一点额外提醒

跑完这么多对照，我现在采用的双轨策略是：日常轻量任务走第三方模型，用/clear频繁切会话，严格控制任务长度，token 成本确实能压到官方模型的五分之一以内；但一旦遇到跨文件重构、疑难 bug 排错、大范围代码审查这类“重任务”，我立刻切回官方模型，绝不犹豫。这个切换的成本，比在第三方模型上反复折腾要低得多。

最后提醒一个容易忽略的细节：登录和刷新 token 报错，与 API 鉴权 token 是两码事。Claude Code 里有自己的账号登录机制，报错会提到 refresh token 或 sign-in could not be completed，这属于 CLI 自身的认证流程问题，跟你接入第三方 API 时设置的ANTHROPIC_AUTH_TOKEN没有关系。别混在一起排查，否则会浪费大量时间。

第三方 API 接入 Claude Code 这件事，本质上不是不能做，而是别在长任务上硬扛。掌握上下文管理、合理配置参数、先基准后接入，就能把它真正变成省钱的工具，而不是烧钱又费时的计时炸弹。