前阵子我用 Code Agent 跑一个跨模块的代码重构任务清单列了 12 步预计半小时跑完结果账单出来后我盯着数字愣了好一会儿——这一个任务消耗的 Token比我平时手动编码一周花掉的还多。更扎心的是真正有价值的输出只占一小部分剩下的大半都消耗在反复确认语境、重复读取文件、以及把没改几行的整个文件重新输出一遍上。我相信不少用过 Cursor、Codex、Claude Code 或自建 Agent 的工程师都有过类似体验。Code Agent 的 Token 成本表面看是模型贵不贵的问题实际更多是用法对不对的问题。这篇文章我会把自己踩过的坑、算过的账、以及调整前后的实测数据全部摊开。先分析 Token 到底烧在哪里再分别对比「换模型」和「换模式」两条省钱路线的适用场景最后给出一套可以直接抄的配置方案和问题排查清单。不管你是准备自己封装 Code Agent 的开发者还是重度使用现成工具写代码的人都能从里面找到对应的省 Token 策略。1. 先算账Code Agent 的钱到底花在哪了1.1 token 计费的三个隐藏点很多人只盯着单价大多数 API 平台都按 Token 计费但代码任务的账单里最容易忽略的是三个机制。第一输入和输出单价不一样。输出 Token 通常比输入贵不少部分旗舰模型输出单价能达到输入的 3 到 4 倍。你让 Agent 生成一大段代码或者重写整个文件输出费用会迅速膨胀。第二工具调用的返回结果也会折算进输入 Token。Agent 每执行一次搜索、查看文件、运行测试返回内容都会追加到上下文里成为下一次请求的输入部分。换句话说Agent 每摸一次文件你都在为这一摸付费。第三历史消息会被重复计费。多轮对话中第 N 轮请求会把前 N-1 轮的消息原封不动再发一遍。对话越长每一轮的新增成本就越高。这三条叠加起来就是为什么一个看起来不复杂的 Agent 任务能轻易烧掉几万甚至几十万 Token。用一个不恰当但很好懂的类比你请了个实习生他每看一页资料都要先付一次阅读费而且每问一个问题之前所有看过的资料都要重新付一遍阅读费。这个成本模型跟我们的直觉是完全相反的。1.2 上下文滚雪球任务越做越贵的数学原理我见过太多人忽略上下文累积的可怕之处。写代码时人类会记得之前看过的内容但 Code Agent 不行它每一轮都是无状态的所有信息都要靠 Token 重新传递。假设一个中等复杂度的任务Agent 需要 20 轮交互每轮新产生的内容平均 30K Token。第一轮请求的上下文是 30K第二轮累计到 60K第三轮 90K以此类推。那么总输入 Token 量就是 30K 60K 90K ... 600K约等于 6.3M Token。你没看错一个 20 轮的任务总输入量能到几百万 Token。如果输入单价是每百万 Token 几美元光输入成本就是几十美元。而如果任务里还夹杂了几次全量文件重写输出 Token 也会轻松突破十万级。这就是上下文滚雪球效应的数学本质。降本的第一优先级永远是把「累计输入量」压下来而不是盯着单次请求的单价看。1.3 我的一次真实账单拆解说个我真实跑过的例子。一个 Rust 项目让 Agent 修改 3 个模块的错误处理逻辑。任务总共 8 步我记录了每一步的 Token 消耗估算任务步骤累计上下文输入(Token)输出(Token)说明1. 初始化 读取主入口文件8,000400读取文件返回完整内容2. 搜索错误处理相关调用12,000600返回搜索结果片段3. 读取 3 个相关文件25,000800大文件全文进入上下文4. 修改文件 A全量重写32,0004,500输出完整文件实际改动很小5. 跑测试 读取编译错误38,0001,200测试输出全部进上下文6. 修改文件 B全量重写45,0004,000同样问题输出全量文件7. 再次跑测试52,000800上下文已经很大了8. 最终修复 总结58,000600收尾输出算下来单任务的输入累计约 270K Token输出约 13K Token。如果用的是中档模型这个任务大概会花掉 1 到 2 美元如果换旗舰模型可能就到 5 美元以上了。关键发现是什么主要成本在输入 Token而输入 Token 的最大来源是「反复读取同一批文件内容」和「测试输出整体进上下文」。这两个毛病不治光换便宜模型只是把 5 美元变成 2 美元治标不治本。2. 换模型换的不是牌子是成本结构2.1 旗舰、中档、本地模型差价到底有多大先给结论不同档次的模型单价的差距远超一般人想象。我做了一个粗略分档具体价格请以各平台最新定价为准模型档次参考代表单价相对量级典型适用任务旗舰模型GPT-4.1、Claude Sonnet 等高架构设计、跨模块重构、复杂 bug 定位中档模型GPT-4o mini、Claude Haiku 等约为旗舰的 1/5 到 1/10单文件修复、补全、测试修改经济模型国产开源/闭源性价比款约为旗舰的 1/20 到 1/50写注释、格式化、生成测试桩、简单问答本地小模型7B/14B 量化模型接近零成本代码补全、短片段生成很多人会觉得「换模型」就是换成同一厂商的低配版但更聪明的做法是彻底改变成本结构。本地模型虽然能力弱但处理「格式化」「重命名变量」「生成重复代码」这类模式化任务完全够用成本几乎为零。我现在的策略是三个梯队搭配能用本地模型解决的绝不动在线 API能用经济模型解决的绝不动中档模型只有真正需要复杂推理的任务才动用旗舰模型。2.2 模型路由一个系统里同时用多个模型只选一个模型是省不了几个钱的。现实世界的代码任务难度分布基本符合二八法则大约 80% 的任务是简单、机械、模式化的只有 20% 需要真正强大的推理能力。如果你让旗舰模型处理那 80% 的简单任务就是在拿高射炮打蚊子。正确姿势是给 Agent 配上模型路由。我的一个简化版路由思路任务描述里出现「重构」「设计」「跨模块」等关键词或者涉及文件数量大于 3 个走旗舰模型任务描述是「修复 bug」「补全函数」「单个文件改动」走中档模型任务描述是「写注释」「格式化」「生成测试桩」走最便宜的模型甚至本地模型路由逻辑可以很朴素落地在代码里就是一个 if-else。关键是你要把路由信号拆出来任务类型、涉及文件数量、目标模块的复杂度。这些信号在 Agent 收到用户请求的最初几秒就能拿到不需要等模型输出再判断。2.3 免费 token 与订阅额度白嫖也要讲策略不少平台会提供免费 Token 额度或订阅套餐内的用量比如 OpenAI 的 API 免费层、Codex 订阅自带用量、国内平台的免费 Token 计划等等。热词里有人问「codex 怎么接千问 token plan 的 api」本质上就是想用更便宜的第三方模型把 Codex 的使用成本打下来这个思路是对的。但免费额度有个陷阱容易让你放松对用量的警觉。一个失控任务可能一次性烧掉整月免费额度后面再干活就全走付费通道了。我的建议是给 Agent 加两层保险单任务 Token 上限估计一个任务最多需要多少 Token超过就自动终止或降级模型每日用量告警超过设定阈值就暂停所有 Agent 任务直到你确认「这个钱值得花」另外不同平台的 Token 计量口径略有差异尤其是中文和代码场景下中文分字、代码分支同一段内容的实际 Token 数可能差不少。你在对比价格时一定要用官方 Tokenizer 实测一段有代表性的中文代码而不是只看宣传文案里的「价格×数量」。3. 换模式改动用法比换模型省钱更直接3.1 局部编辑优先别让 Agent 每次都全量重写这是我最想强调的一点。同样的功能需求「全量重写」和「只返回改动点」的输出 Token 差距可以到 5 到 10 倍。很多 Agent 工具默认会把修改后的完整文件输出成一大段代码实际改动其实只有十几行。这是输出 Token 最大的浪费源头。解决方式有两种。第一种换支持 search/replace 或 apply_patch 格式的工具。这类工具允许模型只输出「要替换的原始片段」和「新片段」由工具层自己应用补丁。第二种如果你用的工具不支持就在 prompt 里明确约束。我在实测中用过一段效果很不错的提示词约束提示 修改文件时只返回 unified diff 格式的改动内容不要输出完整文件。如果文件超过 200 行尤其注意只输出变更的代码块和相关上下文。加上这段约束之后同一个修复任务的输出 Token 从 4500 降到了 900 左右。成本变化是立竿见影的。3.2 上下文瘦身清会话、按行读文件、用 git diff输入 Token 是大头瘦身收益最直接。我总结了几条高频使用的上下文管理技巧。第一新任务开新会话。不要在一个会话里连续处理多个问题每增加一轮对话后面所有请求都要背着前面的历史成本越来越高。开一个新会话上下文从零开始一次任务的 Token 总量能少一半以上。第二用「行号区间读文件」替代「读整个文件」。告诉 Agent 只需要读sed -n 100,150p src/foo.rs的输出而不是cat src/foo.rs。对 1000 行的文件这样能把单次读取的 Token 从 8000 压到几百。第三用git diff呈现变更而不是直接把文件内容丢给 Agent。你要让 Agent 理解改动逻辑时一份简洁的 diff 比完整文件有效得多也更便宜。第四精简系统提示词。每个 system prompt 里的字都会进入每一轮请求的上下文。很多人为了保险在系统提示里塞了十几条规则实际每条规则都在为每一轮 Token 付费。把和当前任务无关的指令全部删掉。3.3 用代码索引检索别把整个仓库喂给模型当代码库足够大时还有一个更系统的做法先建索引再检索。原理就是把代码库按函数或类切块每一块用 embedding 模型转成向量查询时只取与当前任务最相关的 Top N 个片段喂给模型。这也是 Cursor、Copilot 这些成熟工具内置的 codebase index 的底层思路。自建 Agent 的落地方式也不复杂。用 SQLite 存代码块元数据用一个小型开源 embedding 模型或 API 生成向量。任务开始前根据用户描述和当前修改文件检索出 3 到 5 个相关代码块每块大约 200 到 400 行的规模拼进上下文。实测下来一个本来需要读取 15 个文件、上下文顶到 80K Token 的任务用索引检索后只需要输入 8K Token。压掉 90% 的输入成本这是其他手段很难做到的。3.4 限制工具调用轮数和输出长度第三个模式层面的问题是「试错式操作」。Agent 在执行命令失败后往往会反复尝试同样的错误命令每一次尝试都烧掉一轮上下文。我在 Agent 配置里强制设置了两个上限最大工具调用轮数设定为 8 轮。达到上限后Agent 必须输出一份「当前进展、待确认问题、下一步计划」的总结由人来接管而不是无限重试。最大单次输出长度设定为 4000 Token。超过这个长度Agent 必须拆分任务或改用概要输出。这个限制能倒逼模型拒绝全量重写式的输出。还有一个技巧把常用的命令封装成高质量工具。很多 Agent 框架允许你自定义工具比如「读取 N 个文件的指定行号区间」「搜索最近提交中与关键词相关的改动」。工具返回的信息如果更精准Agent 依赖「先 ls 再 grep 再 cat」的长链路探索就会减少每一链都是 Token 成本。4. 实操配置省钱模式的落地参考4.1 模型路由配置示例我自己在用的配置大致是这样的你可以直接照着改# agent_config.yaml model_router: default: economic_model max_context_tokens: 32000 rules: - match_keywords: [重构, 设计, 跨模块, 架构] model: flagship_model max_context_tokens: 128000 - match_keywords: [修复, 补全, 单文件改动, 测试修改] model: mid_model max_context_tokens: 64000 - match_keywords: [写注释, 格式化, 生成测试, 重命名] model: local_model max_context_tokens: 16000这里我刻意没写具体模型名。模型推陈出新太快写死了反而误导人。你自己选型的原则很简单先跑同一批基准任务对比输出质量和价格再确定各档位的实际型号。如果不用 YAML也可以直接在代码里写路由函数def route_task(task_description: str) - str: if any(k in task_description for k in [重构, 设计, 跨模块]): return flagship_model if any(k in task_description for k in [修复, 补全, 单文件]): return mid_model return economic_model注意路由信号不要只依赖关键词。更稳的信号还包括「涉及文件数量」「预计改动行数」「是否需要运行测试」。文件数量可以在任务开始的工具调用阶段收集改动行数可以用git diff --stat预先评估。这些信号比我见过的一些团队直接让模型自己选模型靠谱得多。4.2 上下文管理的配置文件上下文管理也可以配置化。我在同一个配置文件里维护了几个关键参数max_steps: 8限制工具调用轮数max_output_tokens: 4000单次输出上限session_rotate_threshold: 5超过 5 轮交互后强制新开会话prompt_caching: true开启平台缓存的重复前缀折扣关于缓存多说一句。Anthropic、OpenAI 等平台都提供了 prompt caching 机制对重复发送的相同前缀比如系统提示词、固定文件内容给予折扣部分能到 50% 到 90%。它的前提是「前缀要稳定重复」所以你在写 system prompt 时要尽量把不变的内容放前面、变化的内容放后面。频繁改前缀缓存就没用了。4.3 在 Codex 里接第三方模型的经验热词里有个具体问题「codex 怎么接千问 token plan 的 api」。这类 CLI 工具接第三方模型原理其实是一样的把 base_url 指向提供 OpenAI 兼容协议的网关地址然后把模型名改成对应的第三方型号再配好 API Key。以接千问为例大致是这样export OPENAI_BASE_URLhttps://dashscope.aliyuncs.com/compatible-mode/v1 export OPENAI_MODELqwen-coder-plus export OPENAI_API_KEY你的千问API Key不同版本 Codex 对环境变量的读取方式可能略有差异有的版本还支持在配置文件里指定。核心验证方法很简单先发一个最小的补全请求确认返回格式兼容再跑一个包含多文件读取和工具调用的任务确认工具调用协议也没问题。几个容易踩的坑第三方模型的工具调用支持程度不一有些模型会返回不符合 OpenAI 格式的工具调用导致 Agent 流程卡死。遇到这种情况先降级到普通消息模式或者换一个对工具调用兼容性更好的模型。不要忘记设置超时和重试。第三方网关在高峰期可能比较慢Agent 内部如果超时重试机制不健全一次网络抖动就可能烧掉几轮无效 Token。本地模型同样可以作为 Codex 的端点只要它暴露了 OpenAI 兼容的服务端口。4.4 token 生命周期如何避免任务跑到一半认证失效热词里大量出现 token 失效、token exchange failed、auth token is unavailable这在 Code Agent 场景里太常见了。Agent 任务常常要跑十几分钟甚至更久而 access token 的有效期往往只有几十分钟任务跑到一半认证就断了。JWT 机制下标准做法是 refresh token 和 access token 配合access token 短时有效refresh token 长时有效在 access token 过期时用 refresh token 换取新的 access token。Code Agent 这种长耗时任务必须要支持自动续签。我遇到的几个典型情况和排查思路报错sign-in could not be completed / token exchange failed优先检查系统时间是否准确时间偏差过大会导致 JWT 验签失败。然后检查本地凭据缓存是否需要重置。多数情况下重新登录一次就能解决。报错codex auth token is unavailable通常是凭证文件丢失或权限不对也可能是环境变量覆盖了已有的登录态。确认环境变量优先级重新执行一次 login。报错token endpoint returned 403 forbidden: country这类问题通常是账号的地区信息与实际出口 IP 的地区不一致。调整账号设置或更换出口网络后重新授权即可。注意 我不在这里展开任何与网络通道相关的具体设置只讨论账号和认证配置层面的排查。工具类的网络问题请先确认你的使用环境是否符合平台的服务条款。自建服务平台时我的建议是给 Agent 进程挂一个「令牌看门狗」任务开始前检查 access token 剩余有效期低于 5 分钟就先刷新任务执行中捕获到认证相关错误不要立刻报错而是先刷新 token 再重试一次。这一套逻辑本质上就是标准的 JWT 续签流程在 Agent 场景里的落地。5. 常见问题速查与避坑经验5.1 一份常用报错速查表这部分内容是我和几个朋友在实际使用 Code Agent 过程中总结出来的不敢说覆盖所有情况但遇到这几个高频坑的概率极高。报错信息常见原因快速处理办法sign-in could not be completed / token exchange failed登录态失效、认证服务器异常、系统时间偏差检查系统时间重新登录清空本地凭据缓存后重试codex auth token is unavailable凭证文件丢失或权限不对、环境变量被覆盖重新执行 login检查环境变量优先级token endpoint returned 403 forbidden: country账号地区信息与出口网络不一致检查账号地区设置确认出口网络符合服务条款access token could not be refreshedrefresh token 过期或已被吊销重新授权让「令牌看门狗」自动换取新的 refresh token任务跑到一半突然断掉重试要重新花钱access token 中途过期配置自动续签把大任务拆成多个小任务分段执行5.2 模型换便宜了还是贵检查这四个盲区有些人换了便宜模型账单还是没降下来。我见过的大多数情况问题出在四个盲区。第一个盲区是上下文没瘦身。换模型只改变了单价但用量不变总额自然降得不明显。先解决反复读大文件、历史消息越滚越长的问题再换模型。第二个盲区是工具调用太多。统计一轮任务的工具调用次数如果超过 15 次说明 Agent 在探索阶段消耗过多。优化手段就是我在 3.4 里说的限制轮数、封装高质量工具。第三个盲区是输出还是全量。确认你的 Agent 用的是 diff 格式而不是完整文件格式。这一个盲区能造成 5 到 10 倍的输出成本差距。第四个盲区是缓存没开启。检查平台是否支持 prompt caching以及你的 prompt 前缀是否足够稳定。开启缓存后重复上下文的摊销成本会大幅下降。5.3 我的实测结果模式优化的收益远大于模型降级我拿同一个中等难度任务做过四组对比控制变量后得到的数据大致如下方案组合相对总成本旗舰模型 默认模式100%基准中档模型 默认模式40%中档模型 上下文瘦身15%中档模型 上下文瘦身 模型路由10%第一组到第二组只换模型成本降到四成效果当然有但不算惊艳。第二组到第三组加上上下文瘦身成本从四成直接降到一成五这就是模式优化的威力。再把路由加上最终降到一成。为什么模式优化比模型降级更猛因为模型降级只影响单价而模式优化同时压低了「输入总量」和「输出总量」这两个真正的大盘。单价降一半是一半用量降 80% 就是到两成。两边叠加才是 90% 以上的成本削减。5.4 一个容易被忽略的忠告prompt 里别反复唠叨最后分享一个很多人没注意到的点有些团队习惯在 prompt 里反复强调规则比如「请你只修改必要代码」「请你保持代码风格一致」「请不要输出多余内容」每条都写好几遍。这些「唠叨」有个致命的成本隐患——prompt 里的每一个字都会在每一轮请求中重复计费。正确做法是把所有规则一次性提炼进 system prompt并且在主 prompt 里不要重复。系统提示里写「只输出必要代码」主 prompt 里就不需要再说一遍。重复的规则不会让模型更听话只会让你的 Token 账单多出几个百分点的水分。我个人现在的习惯是小任务直接走经济模型大任务才开旗舰模型全程开启局部编辑和 diff 输出再配合上下文缓存。一趟常规任务跑下来成本基本能控制在使用模式优化之前的一成左右。如果你还没有认真审视过自己 Code Agent 的 Token 去向我建议你先打开最近一次大任务的完整请求日志看看输入 Token 是怎么滚起来的多半能发现一大半可以砍掉的成本。先把模式做对再考虑要不要降级模型这个顺序不能反。