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 一个简单的成本估算表

为了让你对自己的任务成本有个直观感受，我整理了一个粗略的估算框架。注意这只是量级参考，具体单价因模型而异：

看懂这张表，你就知道优化重点应该放在"文件读取"和"历史累积"上，而不是纠结模型输出那几行代码。

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 一个可复用的上下文预算表

给任务设一个上下文预算，超了就触发压缩或截断，这是防止成本失控的有效手段。下面是我常用的预算分配思路：

按这个比例控制，单轮输入基本能稳定在可控范围，不会出现某一轮突然爆表的情况。

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 消耗和耗时。积累一段时间后，你就能清楚地看到哪类任务性价比最高、哪类最该优化。数据不会骗人，凭感觉优化往往事倍功半。