1. 从coding plan 越来越贵说起一个被忽视的成本结构问题最近半年身边做开发的朋友几乎都在抱怨同一件事coding plan 越来越贵而且越来越慢。有人晒出账单一个月 token 用量折算下来比去年翻了两三倍有人吐槽 agent 跑一个中等复杂度的任务光等待响应就要几分钟中间还时不时断流重试。表面上看是涨价和变慢两个独立问题但真正拆开来看它们其实是同一个结构性矛盾的两面。我自己从去年开始密集使用各类 coding plan 和 agent 工具做日常开发从最初的兴奋到后来的精打细算再到现在的按需分配、混合调度中间踩过的坑足够写一本小册子。这篇文章不打算给你推荐某个具体产品而是想把 coding plan 的成本到底花在哪、为什么体感越来越慢、以及一个普通开发者能做的优化动作系统地讲清楚。无论你是刚接触 agent 开发的新手还是已经在生产环境跑自动化任务的老手都能从中找到可以直接抄作业的部分。先说结论coding plan 变贵变慢核心不是厂商单方面涨价而是任务复杂度上升、上下文膨胀、重试机制放大、以及 agent 架构本身的开销这四件事叠加的结果。理解了这四层你才知道钱到底烧在哪也才知道哪些优化是真有用、哪些只是心理安慰。2. 拆解 coding plan 的成本构成token 到底花在哪几个地方2.1 输入 token 才是大头而不是输出很多人第一次看账单会惊讶明明我让模型写的代码没多少行为什么 token 用量这么高原因在于coding plan 类任务的 token 消耗结构里输入 token 通常占 70% 到 90%输出反而只占小头。一次典型的 agent 编码任务输入部分至少包含这几块系统提示词system prompt、工具定义tool schema、历史对话、当前代码文件内容、相关文件片段、报错日志、以及检索到的文档。系统提示词和工具定义往往是固定的动辄几千 token而代码文件和历史对话会随着任务推进不断累积。你让 agent 改一个函数它可能先把整个文件读进来再把相关的三四个文件也读进来一轮下来输入就是几万 token。这里有个反直觉的点输出 token 贵但输入 token 多。所以真正烧钱的不是模型写了多少而是模型读了多少。这解释了为什么很多人觉得我什么都没干钱就没了——因为 agent 在后台反复读取上下文。2.2 上下文膨胀的复利效应agent 任务通常是多轮的。第一轮读文件 A第二轮读文件 B 并带上 A 的结论第三轮又读文件 C 并带上 A、B 的结论。每一轮的历史都在累积而大多数 agent 框架默认会把完整历史塞进下一次请求。于是 token 用量不是线性增长而是接近平方级增长。我实测过一个中等规模的重构任务单轮输入约 8000 token跑了 12 轮如果每轮都带完整历史总输入接近 60 万 token。而如果做历史压缩只保留关键结论和最近两轮总输入能压到 15 万以内。差距是四倍。这就是为什么同样一个任务有人花几块钱有人花几十块。2.3 重试与失败请求的隐性成本coding plan 变慢的体感很大一部分来自重试。网络抖动、限流、上下文超长、工具调用格式错误都会触发重试。而重试意味着同样的输入再发一遍token 照扣时间照等。更麻烦的是有些失败是半成功——模型已经生成了一部分输出但因为格式不对被丢弃重来。这部分输出 token 已经计费却没有任何产出。我在排查自己的 agent 日志时发现某些不稳定时段失败重试带来的额外 token 消耗能占到总量的 20% 到 30%。这不是小数目。2.4 一个简单的成本估算表为了让你对自己的任务成本有个直观感受我整理了一个粗略的估算框架。注意这只是量级参考具体单价因模型而异成本项典型占比可优化空间系统提示词与工具定义10%-20%中可精简工具数量代码文件读取30%-45%高可做片段检索历史对话累积20%-35%高可做历史压缩输出生成10%-20%低输出本身必要重试与失败5%-30%高可做幂等与退避看懂这张表你就知道优化重点应该放在文件读取和历史累积上而不是纠结模型输出那几行代码。3. 为什么体感越来越慢延迟的来源不止是模型3.1 首 token 延迟与总生成时间的区别很多人把慢笼统地归为模型慢其实要分两个指标首 token 延迟TTFT和总生成时间。首 token 延迟取决于排队、预填充prefill速度输入越长预填充越慢。总生成时间则取决于输出长度和生成速度。coding plan 任务里输入动辄几万 token预填充阶段就要花不少时间。你感觉半天没反应很可能卡在预填充而不是模型在思考。理解这一点很重要因为它意味着减少输入长度能直接改善首 token 延迟。3.2 工具调用的往返开销agent 和普通对话最大的区别是工具调用。每调用一次工具读文件、跑命令、搜索就要一次完整的往返模型输出工具调用请求、框架执行、结果回填、再请求模型。这个往返在本地可能几百毫秒但在网络环境下叠加起来就很可观。一个任务如果调用 20 次工具光往返开销就可能累积到十几秒甚至更久。而且每次回填工具结果都会增加上下文进一步拖慢下一轮。这是 agent 架构的固有开销只能优化无法消除。3.3 限流与排队被忽视的时间黑洞coding plan 高峰期限流是常态。你发出的请求可能先进入队列排队时间从几秒到几十秒不等。更糟的是有些框架在遇到限流后不做退避而是立即重试结果反复撞墙既浪费时间又浪费 token。我自己的做法是给所有请求加上指数退避加随机抖动并且在框架层面记录每次请求的排队时间。这样至少能知道慢到底是慢在排队还是慢在生成。很多时候换个低峰时段跑批量任务整体耗时能减半。3.4 慢和贵是同一个问题的两种表现把上面几点串起来看就清楚了输入越长预填充越慢首 token 延迟越高历史越累积每轮请求越大总时间越长重试越多无效等待越多。而这些慢的因素恰恰也是贵的因素——因为它们都在消耗 token。所以优化成本和优化速度本质上是同一件事控制上下文规模减少无效请求。4. 上下文管理把 token 花在刀刃上的几个实操手段4.1 用检索代替全量读取最有效的省钱手段是不要让 agent 无脑读整个代码库。正确做法是先用轻量检索关键词、符号索引、向量检索定位相关片段只把命中的片段喂给模型。具体操作上我通常这样做先让 agent 根据任务描述生成一组搜索关键词用本地工具比如 ripgrep 或简单的符号索引找出候选文件和行号然后只截取相关函数或类而不是整个文件。一个 2000 行的文件真正相关的可能只有 50 行。这一刀下去输入 token 能砍掉一大半。注意检索质量直接决定效果。检索太宽省不了钱检索太窄模型缺上下文会瞎猜。建议先宽后窄让模型自己判断还需要看哪个文件而不是一次性全塞。4.2 历史压缩保留结论丢弃过程多轮任务里历史压缩是刚需。我的策略是保留每一轮的结论和决策丢弃中间的试错过程。比如模型读了文件 A 得出这个函数需要改参数签名那就只保留这句话而不是保留它读文件 A 的完整内容。实现上可以每 N 轮做一次摘要把之前的对话压缩成一段结构化笔记已确认的事实、已做的修改、待办事项。下一轮只带这段笔记加最近一两轮原文。这样既保留了必要信息又避免了历史无限膨胀。4.3 工具定义的瘦身很多 agent 框架默认挂载一大堆工具每个工具的定义都是几百 token。如果你只用得到其中三五个剩下的就是纯浪费。我建议按任务类型动态加载工具集做代码修改时只挂文件读写和命令执行做检索时只挂搜索工具。工具定义从 5000 token 降到 1500 token每轮都省。4.4 一个可复用的上下文预算表给任务设一个上下文预算超了就触发压缩或截断这是防止成本失控的有效手段。下面是我常用的预算分配思路上下文部分建议预算占比超限处理系统提示与工具≤15%精简工具压缩提示当前任务描述≤10%保持精简相关代码片段≤40%检索截断只留相关行历史摘要≤20%定期压缩最近一轮原文≤15%保留保证连贯按这个比例控制单轮输入基本能稳定在可控范围不会出现某一轮突然爆表的情况。5. 模型与路由策略不是所有任务都值得用最贵的模型5.1 按任务难度分级调度coding plan 里最浪费钱的行为是用顶级模型干简单活。改个变量名、格式化代码、写个简单函数这些用轻量模型完全够用。真正需要强模型的是复杂重构、跨文件推理、疑难 bug 定位。我的做法是把任务分成三档简单任务走轻量模型中等任务走中档模型只有复杂任务才上顶级模型。实测下来整体成本能降 40% 以上而完成质量几乎没差别。关键是你要有一套判断任务难度的规则比如涉及文件数、是否需要跨模块推理、是否有明确报错信息等。5.2 失败降级与升级的组合拳另一个实用策略是先便宜后贵先用轻量模型试如果连续失败或输出质量不达标再升级到强模型。这样大部分简单任务用便宜模型就解决了只有真正难的才动用贵模型。反过来也可以先贵后便宜用强模型做一次规划把任务拆成清晰的子步骤然后子步骤用便宜模型执行。规划只做一次成本可控执行阶段大量省token。5.3 缓存能省的钱比你想的多很多 coding plan 任务有大量重复的输入前缀比如固定的系统提示、固定的工具定义、甚至重复读取的同一段代码。如果服务端支持前缀缓存prompt caching这部分重复输入可以大幅打折甚至免费。实操上要尽量把稳定不变的内容放在前面变化的内容放在后面。这样缓存命中率最高。我见过有人把动态的任务描述放在系统提示前面导致缓存完全失效白白多花钱。顺序这件事值得专门优化。5.4 路由失败的排查思路热词里频繁出现各种路由和 token 报错比如找不到某个 provider 的 api key、token 交换失败、上下文超长等。这类问题的排查有个通用套路先确认配置里 provider 名称和实际调用是否一致再确认密钥是否有效且未过期最后看请求体是否超出模型上下文上限。上下文超长是 coding plan 最常见的报错之一。遇到maximum context length这类提示不要急着换模型先检查是不是历史没压缩、文件读太多。多数情况下压缩上下文就能解决而不是模型不够强。6. Agent 架构里的隐藏开销工具、循环与状态管理6.1 工具调用次数比工具本身更贵前面提过每次工具调用都是一次往返。所以优化重点不是用哪个工具而是能不能少调用几次。比如读文件与其让模型一次读一个文件、来回好几轮不如在框架层做一次批量读取把多个相关文件一次性喂进去。这样往返次数从 5 次降到 1 次时间和 token 都省。6.2 循环终止条件要设死agent 最怕死循环。模型反复尝试同一个失败操作每次都消耗 token。必须在框架层设硬性终止条件最大轮数、最大 token 预算、连续失败次数上限。触顶就停交给人处理而不是让它无限试下去。我自己的默认配置是单任务最多 15 轮连续 3 次同类失败就终止总 token 超过预算就暂停并提示。这三道闸门救过我很多次。6.3 状态持久化避免重复劳动长任务如果中途失败从头再来是最亏的。应该把中间状态持久化已完成的步骤、已修改的文件、已确认的结论。失败恢复时从断点继续而不是重跑。这不仅能省钱还能大幅缩短恢复时间。6.4 安全边界不能省agent 能执行命令、读写文件安全边界必须提前划好。哪些目录可写、哪些命令禁止执行、敏感文件是否隔离这些都要在框架层硬性限制而不是靠提示词约束。提示词可以被绕过代码层面的限制才可靠。这一点在跑自动化任务时尤其重要别等出事才补。7. 我踩过的几个真实坑与对应解法7.1 全量读库导致单轮爆表早期我图省事让 agent 直接把整个项目目录读进来。结果一个中等项目单轮输入就冲到几十万 token不仅贵还频繁触发上下文超长报错。后来改成检索加片段读取单轮输入稳定在几万以内报错也基本消失了。这个坑的本质是把方便当成了必要。7.2 重试没做退避越重试越慢有段时间任务老是超时我以为是模型慢后来看日志才发现是限流后立即重试反复撞墙。加上指数退避和抖动之后同样的任务成功率明显提升总耗时反而下降。重试不是越多越好有节奏的重试才是有效的。7.3 缓存顺序放错白花冤枉钱我曾经把动态任务描述放在系统提示最前面导致前缀缓存完全失效。调整顺序后把固定内容前置、动态内容后置缓存命中率上来了成本肉眼可见地下降。这个坑很隐蔽因为功能上完全正常只是钱悄悄多花了。7.4 工具挂太多每轮都在为不用的工具付费有次排查成本发现工具定义占了每轮输入的近三成而实际用到的工具不到一半。按任务动态加载工具后这部分开销直接砍半。教训是默认配置往往是为通用性设计的不是为你的场景优化的。8. 把成本降下来的组合拳一套可落地的日常配置把前面所有手段串起来我现在的日常配置大致是这样一套组合任务进来先做难度分级简单任务走轻量模型上下文用检索加片段读取绝不整库读每五轮做一次历史压缩只留结论工具按任务动态加载所有请求带指数退避单任务设轮数和 token 双预算中间状态持久化支持断点续跑。这套配置跑下来同样的任务量我的月度成本比最初降低了大概六成平均任务耗时也缩短了将近一半。更重要的是稳定性上来了不再动不动就超长报错或者卡死。需要强调的是这些优化不是一次性的而是需要持续观察和调整。建议你至少每周看一次自己的 token 用量分布和失败日志找出最烧钱的那一类任务针对性优化。成本优化是个持续过程没有一劳永逸的银弹。最后分享一个我自己的小习惯给每个 agent 任务都打上标签记录任务类型、模型、轮数、token 消耗和耗时。积累一段时间后你就能清楚地看到哪类任务性价比最高、哪类最该优化。数据不会骗人凭感觉优化往往事倍功半。