一条 Prompt 为什么消耗多次请求？AI 编程 Agent 的计费结构

你只输入了一行很短的 prompt。之后一看，当日配额已经少了一块——或者按量计费时，扣掉的钱明显配不上那条回答的价值。"我输入的"和"被计量的"之间的落差不是 bug，它就是编程 Agent 的工作方式本身。理解这一点，决定的是你的配额能撑过一整天，还是上午就见底。

一条 prompt ≠ 一次模型调用

现代编程 Agent 在跑一个循环。循环的每一轮都是一次独立的模型请求，而一条 prompt 带出好几次请求是常态而非例外。Google 在文档里直接写明了这一点：Gemini CLI 和 Gemini Code Assist agent 模式下，"一条 prompt 可能产生多次模型请求"，且每日请求上限按用到的所有模型版本聚合计算（Google Cloud, "Quotas and limits"，2026-09-17 查证）。

这个循环大致长这样：

你输入一行 prompt
├─ 模型请求 1：读计划 + 工具定义，决定下一步
├─ 模型请求 2：读完第一个文件后处理其内容
├─ 模型请求 3：编辑之后决定验证方式
├─ 工具执行（shell 命令、测试）——发生在请求之间，不在请求里
└─ 模型请求 N：生成最终总结

同样的模式存在于各家工具中，只是计量口径不同。Anthropic 的 Claude Code 文档解释说：每一轮都会重发整段对话，而每次使用工具都会带着那批工具结果再发一次请求——所以一个开了整天的会话里，哪怕只是一句一行的问题，也会为整段对话再次计量（Anthropic, "Manage costs effectively"，2026-09-17 查证）。

计量什么，计数器在哪里

各家 Agent 计量的单位并不相同。你消耗的东西取决于认证方式和产品形态：

各家文档里的数字会变，但结构不会。Google 的 Gemini API 文档把每分钟请求数（RPM）、每分钟 token 数（TPM）、每日请求数（RPD）列为三个常设维度，并指出任何一项触顶都会触发限流错误——哪怕其他项还有余量（Google AI, "Rate limits"，2026-09-17 查证）。

两个值得记住的推论：

短 prompt 可能是昂贵的 prompt。 成本跟着 Agent 做了什么走——读了多少文件、改了多少、验证跑了几次、重试了几回——而不是跟着你的句子长度走。一个回答前先读十个文件的 Agent，在看得见的那次调用之外，还做了十次搬运上下文的请求。

重试和报错也是循环的一部分。 因限流而失败的请求，也可能已经消耗了触发它的每分钟/每请求预算（失败请求是否计费因厂商和产品形态而异——别急着下结论，"每分钟限制大概率已消耗，账单为准"才是准确的说法）。

示例 trace（模板，不是真实日志）

为了把循环讲具体，一个典型的小任务大概长这样。这是供你与自己的遥测数据对比的示意形状，不是对任何真实会话的测量：

prompt："给登录函数加输入校验"                    （示例）
├─ 请求 1   读计划 + 工具 schema                 ~2k tokens 输入
├─ 工具：读 auth.ts（150 行）
├─ 请求 2   处理文件 + 提出修改                  ~20k tokens 输入
├─ 工具：应用修改
├─ 请求 3   验证一轮                            ~25k tokens 输入
├─ 工具：跑测试
└─ 请求 4   总结结果                            ~30k tokens 输入

看得见的 prompt 只有一行。被计量的是四条各自携带累计上下文的模型请求，外加四次工具执行。按请求数配额算，一天就去了 4 个；按 token 计量的套餐里，请求 2 到 4 每次都重读大段相同上下文——真正的成本就压在这里。

测量你自己的会话（清单 + 记录表）

厂商已经提供了足够停下猜测的遥测数据。每个工具该看的：

• Gemini CLI：会话中运行 /stats model——显示当前会话的 token 用量，以及与你当前配额相关的限制（CLI 官方文档，2026-09-17 查证）。
• Claude Code：运行 /usage——Session 区块显示按模型的 token 数与费用，订阅用户还能看到套餐用量条和 Prompt cache 行（输入中来自缓存的比例）。/insights 会分析跨会话的使用模式。
• 所有工具通用：确认它是否记录每次请求的 token 数——不少工具会写会话 transcript 或 debug 文件，grep 就能提取。

然后把看到的东西记下来，让数字不再是轶事：

记上几个真实会话，你就会得到自己的 prompt 与请求之比——上面所有配额说明背后藏着的正是这个数字。如果工具不暴露请求数，就在那一栏写"N/A"，别估：诚实的 N/A 好过自信的虚构。

知道这些之后做什么

按请求数做预算，不按 prompt 数。 如果套餐写的是每天 1,000 个请求，而一个中等编码任务要吃掉好几个，那就按这个现实分配——你花的单位不是"prompt"。

有意识地让上下文保持精瘦。 循环后面的请求会重发前面的上下文。保持小的会话保持便宜；积攒了一天历史的会话让之后每一轮都变贵。任务结束就压缩或新开，比把历史拖进无关工作便宜。

按任务重量路由，而不是按习惯。 机械修改和样板代码不值得消耗最稀缺的配额。把前沿模型的请求留给真正需要的活——这也正是"在主力 Agent 旁边挂一个便宜的计量模型"的论据。

meshcode 支持多个 Agent 在并行窗格中同时运行，你可以把机械任务指给更便宜的计量表，把稀缺的每日请求留给真正需要的工作——每个工具用自己的账号、各自限额下接入。

相关阅读：为什么各条 Gemini 产品线的上限不是一个数字 · AI 编程 Agent token 成本对比 · 给 Claude Code 省 token 的方法。

👉 下载 meshcode