Agent 成本怎么算：开发、运行与维护

给 AI Agent 算账，只盯着每百万 token 的价格，很容易低估真正的投入。BigCircle 创始人 Tirth 把费用拆成建设、运行和上线维护三部分：模型调用只是其中一项，工具接入、失败处理、人工审核和后续回归，都要有人买单。

这篇最有用的地方，是把「Agent 太贵」拆成了可以检查的工程问题。不过，文中的 token 用量是算例，部分节省比例来自团队估计，产品价格与规则也有明确日期，不能直接当成你的预算表。

建设费用为什么大多花在模型之外

作者给「建设完成」定的标准，是系统能接住真实任务。为此，需要工具、调用权限、评估集，以及某一步失败后的处理路径。选模型只是其中一个决定。

他们的 DevOps Agent 花了约四个月交付。时间主要用来读取真实 AWS 账号的资源、配额和限制，循环检查模板的结构与语义，并在执行变更前向工程师展示架构图，由人审核。

这些工作有实际原因：模型可能编造资源类型，也可能生成当前区域或配额不允许部署的模板。失败的 stack 又可能需要几分钟才能回滚，因此不能把「先执行，失败再改」当作正常验证流程。

另一套行政助理 Agent 接入了一百多个系统。许多操作藏在 SSO（单点登录）和多因素认证后面，没有可用 API。每个集成都带来工具契约、登录流程和新的失败情况。

作者认为，如果 Agent 只能完成一条流程的 70%，仍需人维持完整操作顺序，节省就很有限。这个判断适合强调流程连贯性的任务，但原文没有给出人力对照数据，不能推导成「自动完成 70% 都没有价值」。

比较建设报价时，至少要看清：工具覆盖哪些操作，谁检查权限，有没有评估集，失败后谁接手。固定范围报价的前提，也是这些范围在开工前约定清楚。

十轮任务为什么会花掉单次回复的约 24 倍

Agent 的调用次数由执行过程决定，工具返回内容还会进入后续上下文。前面的记录越长，后面的输入就越贵。

作者采用的算例是：初始系统提示词和工具定义共 6,000 tokens，执行 10 轮，每轮输出 300 tokens 的工具调用，再加入 2,000 tokens 的工具结果。按原文所列、截至 2026 年 10 月 22 日的 GPT-6 Luna 价格，输入每百万 tokens 为 $0.10，输出为 $0.50。

不算缓存和推理，单任务约 $0.018，是单次回复的约 24 倍；每天 10,000 个任务，约 $179。轮数增加时，每轮还要重新支付此前记录的输入费用，所以并非简单乘以 10。

推理也占预算。原文称 Luna 默认 reasoning effort 为 medium，推理 tokens 按输出计费。如果每轮再花 1,000 reasoning tokens，单任务增加约 $0.005，涨幅约 28%。这里假设旧推理不会再次输入；作者同时指出，GPT-5.6 系列默认会把此前推理带入下一轮。因此，模型迁移后，即使单价下降，总费用也可能上涨。

工具数量还会影响执行路径。他们的行政助理 Agent 在直接列出约 30 个工具后，开始选择看似合理却不正确的工具。后来改成先查询工具注册表，再提供少量相关契约，才支撑了一百多个工具。

这是团队案例中的经验阈值，不是所有模型通用的「30 个工具上限」。它提醒我们：工具列表变长，增加的不只是输入费，还有选错后重试和补救的费用。

缓存能降多少，要看具体复用了什么

Prompt caching 复用的是重复前缀。按原文对 2026 年 10 月 22 日规则的描述，OpenAI 支持的模型默认开启缓存，GPT-5.6 及之后模型的最短前缀为 1,024 tokens；读取价格是普通输入的十分之一，写入是 1.25 倍。默认有效期为 30 分钟，每次读取刷新有效期。

但作者也承认，所引用缓存规则没有明确列出 Luna，只看到其模型页标注缓存输入为每百万 tokens $0.01，因此假设它适用相同写入费率。这是计算前提，尚不能当成已确认规则。

在每轮及时到达、旧前缀完全不变的条件下，算例读取 136,800 缓存 tokens、写入 26,700 tokens，加上 3,000 输出 tokens，费用从约 $0.018 降到约 $0.006。后续每轮只新增 2,300 tokens。但如果重试修改了前面的记录，从修改位置开始就不能继续套用原先的缓存收益。

应用层缓存解决的是另一笔账。作者的 Prospex 研究引擎优先复用此前的提取和检索结果，据团队估计，重复外部 API 调用减少了 50% 至 60%。这个比例没有给出对照方法，能借鉴的是缓存策略，以及持续观察命中率的做法。

真正的预算上限必须挡在下一次调用之前

告警只能告诉你花了多少钱，调用前的代码才能阻止继续花钱。

作者建议同时限制轮数、工具调用数、金额和子 Agent 数量。子 Agent 必须共享父任务的剩余额度；如果每个子任务都重新获得完整预算，整体支出仍会失控。重试和模板修订也要有次数上限，失败调用必须计费，修不好就停止并转交人工。

上限应依据已完成的正常任务设置，给最长正常流程留出余量。框架默认值未必适合你的任务，把限制写进提示词也无法替代程序检查。

云平台限额只能兜底。原文称，AWS spend limits 于 2026 年 9 月 16 日推出，仍向有限客户开放，月度用量达到上限后暂停项目资源；可选机制会提前约四天暂停高费用资源，候选来自包括 Lambda、Bedrock 在内的五项服务。Google Cloud Spend Caps 自 2026 年 7 月 29 日进入公开预览，到月度上限后限制单个项目中的一项服务。它们粒度较粗，也会影响正常任务。

作者还引用 Jatin Bansal 的事故记录：2025 年 11 月，四个 LangChain Agent 中的 analyzer 和 verifier 相互循环，11 天花了 $47,000。该数字是转述案例，原文没有提供独立核验材料。

停止之后，记录还要留下来。每次调用的 run id、工具、放行或拒绝、token 数量及停止原因，应写到 Agent 凭证无法删除或改写的存储中，并包含子任务和失败尝试。每月再把这些记录与供应商账单对齐，纳入重试、超时、取消以及被丢弃的输出。仍有差额，就继续查评估任务、预热调用或共用密钥的其他服务。

上线维护同样要列入报价：工具、提示词或模型变更后重跑评估；有人处理停止的任务；工具契约声明输入、输出和副作用。作者还举了律师持续修正商标草稿、ESG 流程为每条映射事实记录框架版本的例子，说明这笔工作不会在交付当天结束。

我的判断

我认同把三类费用分开算，也认同将预算检查放进调用路径。这能把报价和运行账单里的责任边界讲清楚。

但原文没有给出通用建设价格，四个月交付也不能直接换算成普通团队的人天预算。约 30 个工具后的选错问题、70% 自动化收益有限，以及外部 API 调用减少 50% 至 60%，都带有具体任务前提。其中有团队观察，也有估计，缺少统一对照数据。

缓存算例尤其适合用来理解费用结构，不适合直接预测账单。真实任务的输出长度、推理量、重试次数和命中率都可能不同，Luna 写入费率还用了假设。

另外，固定脚本和预先编排的工作流值得先比较。步骤已经确定的任务，未必需要把下一步选择权交给 Agent。原文开头也明确提醒：一个脚本或一次查询能完成的工作，应先走更简单的路径。

能拿来做什么

• 做 Node Agent 服务时，把轮数、工具次数、费用和子任务数量集中到一次任务的预算对象中，在调用供应商前检查，并让所有子任务共享剩余额度。
• 给 AI 编程助手接入大量工具前，记录实际选错情况，再判断是否需要工具注册表和按需加载契约，别直接照搬「30 个」这个案例阈值。
• 做成本验证时，用真实完成任务的轨迹统计输入、输出、推理、失败和缓存命中情况，再比较模型或缓存策略，避免只比较每百万 token 的价格。
• 评审采购或内部立项时，分别列出建设、运行和上线维护，明确评估集、权限检查、人工接手以及账单核对由谁负责。