单次调用便宜，不等于一个业务结果便宜。

算清总成本｜用好模型路由｜按验收结果计算 ROI

适用于生产环境的成本拆解、路由决策与经营评估

#AI Agent  #智能体  #成本优化  #算力成本  #模型路由  #大模型  #Token  #ROI  #Agent 架构  #降本增效

AI Agent 真正难算的，不是单次模型调用多少钱，而是一个任务从理解、检索、工具调用、重试、人工复核到最终通过验收，究竟消耗多少总成本，又创造多少可量化价值。本文从模型推理、工具与数据、基础设施、人工注意力、失败返工、风险损失六类成本出发，建立“单位有效结果成本”和 ROI 模型；进一步拆解多级模型路由、上下文缓存、批处理、动态推理预算和自动验收策略，并以 10 万任务/月的客服场景做可复算对比，说明如何在不牺牲结果质量的前提下，把模型费用从一个被动账单项，转化为可持续优化的业务指标。

先给结论 Agent 项目最危险的成本错觉，是把“每次调用便宜”误认为“每个业务结果便宜”。真正应该盯的是：一次任务最终通过验收，需要付出多少总成本，以及这笔成本换回了多少可量化价值。

你真正需要回答的 4 个问题

• 同一个任务，为什么“最便宜的模型”可能反而最贵？
• 什么时候应该升级到强模型，什么时候应该直接用规则或 SQL？
• 上下文、重试、人工复核为什么会比 Token 单价更容易把成本放大？
• 怎样把“AI 很好用”变成财务上可验证的 ROI，而不是演示阶段的主观感受？

如果这四个问题没有统一口径，团队很容易陷入两种极端：要么所有任务都用最强模型，性能过剩；要么为了压 Token 单价强行降模型，最后靠人工返工把节省的钱又花回去。

目录

1. 先把账本定义对：Agent 的“成本”到底是什么

2. 算力账：Token 单价只是第一层

3. 模型路由：让“对的模型”出现在“对的任务”

4. 上下文工程：最容易被忽略的成本放大器

5. 重试经济学：成功率比单次成本更重要

6. 时延、批处理与并发：算力便宜不等于交付便宜

7. 真实 ROI：从“省 Token”到“业务净收益”

8. 可复算案例：10 万客服工单/月怎么做经济账

9. 一张 Agent 经济仪表盘应该看什么

10. 五个最常见的成本误区

11. 30 天落地路线图

12. 结语：真正的优化目标是单位有效结果成本

1. 先把账本定义对：Agent 的“成本”到底是什么

传统 API 的成本相对容易：一次请求消耗多少计算、存储和带宽，通常可以预测。Agent 不同。它会自主规划、调用工具、读取外部数据、在多轮之间携带上下文，还可能因为验证失败而重试或升级模型。于是，同一个用户目标，在不同的提示、工具权限、路由规则和验收机制下，总成本可能相差一个数量级。

更关键的是：模型账单只是显性成本。一个看似“每次只花几分钱”的 Agent，如果需要员工逐句核验、频繁处理异常、不断重跑，或者把错误结果推入 CRM、代码库和业务系统，下游返工会迅速吞掉模型端的全部节省。

单位有效结果成本 =（模型 + 工具/数据 + 基础设施 + 人工注意力 + 失败返工 + 风险预期损失）÷ 通过验收的结果数

ROI =（新增收入 + 节省人工 + 周期缩短价值 + 质量/风险收益 − 总投入）÷ 总投入 × 100%

图 1｜AI Agent 六类成本结构。这里强调的是“总成本边界”，而不是某个行业的固定占比。

成本类别	典型组成	建议量化指标
模型推理成本	输入/输出 token、推理强度、缓存写入与命中、多轮规划与复核	每任务模型成本、每成功结果模型成本
工具与数据成本	搜索、数据库、浏览器、代码执行、OCR、地图、商业数据源等	每任务工具调用次数、单工具成功率、工具成本占比
基础设施成本	队列、容器、日志、监控、向量库、存储、网络与安全隔离	每千任务基础设施成本、峰值容量利用率
人工注意力成本	任务准备、审批、补背景、异常处理、结果核验	人工分钟/任务、人工分钟/有效结果
失败与返工成本	重试、回滚、重复执行、错误传播与下游修复	重试率、升级率、回滚率、返工时长
风险预期损失	低概率但高影响事件的期望损失	事故概率 × 影响；高风险动作人工确认率

1.1 为什么“通过验收”比“生成完成”重要

Agent 生成了 100 份报告，并不等于产生了 100 个业务结果。假设只有 70 份达到可直接使用标准，另外 30 份需要重写，那么真正的分母应该是 70，而不是 100。越把“产出数量”当成“有效结果数量”，越容易高估自动化率和 ROI。

关键口径 把“完成率”拆成三层：技术完成率、业务验收率、无需人工返工率。真正决定经济性的通常是后两者。

1.2 哪些场景其实不应该用 Agent

并不是所有流程都值得智能体化。OpenAI 的 Agent 指南建议优先考虑传统规则难以维护、需要处理非结构化信息、或必须做复杂判断的工作流；如果一个问题本来就能被稳定的确定性规则解决，那么规则通常更便宜、更快、更可验证。[1]

• 固定格式校验、权限判断、去重、枚举映射：优先写程序。
• 简单数据库查询与报表汇总：优先 SQL / BI。
• 输入结构稳定、输出唯一的流程：优先传统自动化。
• 需要语义理解、例外判断、跨工具编排、长链路决策：才是 Agent 的主战场。

2. 算力账：Token 单价只是第一层

看模型价格时，至少要拆成输入、缓存输入、输出、推理强度、长上下文溢价、工具调用和服务等级。尤其对 Agent 来说，输出往往不是最大的成本，反复携带的上下文和中间工具结果才是。

2.1 当前公开价格能告诉我们什么

下面只用公开列表价做量级示例，不把任何一家厂商当作唯一方案。价格会变化，因此文章中的数字必须带日期理解。OpenAI 当前 GPT-5.6 家族同时提供 Sol、Terra、Luna 三个成本层级；Anthropic Sonnet 5 和 Google Gemini 3.6 Flash 也呈现出明显的“能力—成本—延迟”分层。[2][4][5]

模型	厂商	输入/百万 token	缓存输入/百万 token	输出/百万 token	典型定位
GPT-5.6 Luna	OpenAI	$0.20	$0.02	$1.20	高吞吐、成本敏感任务
GPT-5.6 Terra	OpenAI	$2.00	$0.20	$12.00	质量与成本平衡
GPT-5.6 Sol	OpenAI	$4.00	$0.40	$20.00	复杂专业任务、长链路推理
Claude Sonnet 5	Anthropic	$2.00	—	$10.00	通用高质量任务；缓存最高可节省约 90% 输入成本
Gemini 3.6 Flash	Google	$0.75*	$0.075*	$3.75*	高吞吐、多模态/搜索结合场景

* Gemini 3.6 Flash 表中价格为 2026-12-31 前公开优惠价；所有价格口径截至 2026-08-30，后续应以官方页面为准。

这里最重要的不是背价格，而是看出一个事实：同一百万 token，不同模型层级的成本可以相差 10 倍甚至更多。于是，模型路由不是“锦上添花”，而是规模化 Agent 的基础经济能力。

2.2 长上下文不是免费的“保险箱”

很多团队为了稳妥，把完整项目文档、历史对话、工具日志、所有数据库字段一次性塞给模型。结果往往是成本和质量一起恶化：无关信息占窗口、旧规则与新规则冲突、关键约束被淹没。更现实的是，部分模型对超长输入存在更高费率。例如 OpenAI GPT-5.6 在超过特定输入阈值后会进入长上下文计价区间。[2]

经验法则 “上下文越多越稳”通常是错觉。高质量 Agent 追求的是最小充分上下文，而不是最大可用上下文。

2.3 输出长度也要被当作预算参数

如果一个分类 Agent 的最终动作只需要一个 JSON，却让模型输出 1,500 字解释，那么多出来的内容既增加成本，也增加延迟和解析失败概率。对生产系统，输出长度应该与任务交付物严格匹配：分类任务结构化输出，审核任务给出证据与结论，复杂研究才允许长文本。

3. 模型路由：让“对的模型”出现在“对的任务”

模型路由最常见的错误，是只根据输入长度或用户套餐决定模型。真正有经济意义的路由，至少要同时看任务价值、难度、可验证性、风险和时延要求。

图 2｜推荐的五级路由结构：能用确定性程序解决的问题，不要先交给模型。

3.1 五级路由框架

层级	适用任务	路由判断	相对成本
L0 确定性程序	去重、校验、权限、固定转换、数据库查询	错误可精确检测；规则稳定	最低
L1 低成本模型	分类、抽取、短摘要、结构化、简单工具选择	标准明确；自动验收强	低
L2 平衡模型	常规分析、客户研究、工单处理、多步但边界清晰	需要上下文判断；可回归评测	中
L3 强模型	复杂规划、跨来源推理、疑难调试、高价值生成	问题难；失败代价高；升级有收益	高
L4 人工审批	付款、删除、批量外发、重大承诺、关键配置变更	不可逆或高风险	责任边界

3.2 最稳的生产策略：低成本首跑 + 自动验证 + 必要时升级

OpenAI 的实践建议是：先用最强模型建立性能基线，再通过评测逐步把适合的子任务替换为更小模型，以优化成本和延迟。[1] 这比一开始就用小模型更可靠，因为你先知道“可达到的质量上限”，然后再做有证据的降本。

def route(task):     if can_solve_deterministically(task):         return "rule_engine"     score = value(task) + complexity(task) + risk(task)     result = run_low_cost_model(task)     if verifier_pass(result):         return result     if score < HIGH_VALUE_THRESHOLD:         return run_balanced_model(task)     result = run_frontier_model(task)     if irreversible_action(task):         return request_human_approval(result)     return result

真正的关键不是“先便宜后昂贵”，而是“验证器是否可靠”。如果无法自动识别失败，那么把任务先交给弱模型只会把成本从模型账单转移到人工审校。

3.3 路由器应该观测哪些信号

• 任务是否需要多步规划，还是单步分类即可完成。
• 错误是否可以被程序检测，例如 schema、单元测试、SQL 校验、金额平衡。
• 输入是否存在冲突、歧义、跨文档依赖。
• 失败后换更强模型是否真的能显著提升通过率。
• 业务动作是否可逆；不可逆动作是否需要人工确认门。
• 用户是否处在交互链路中；对时延的价值是否高于额外算力成本。

4. 上下文工程：最容易被忽略的成本放大器

Agent 的输入通常由四部分组成：稳定规则、项目长期事实、当前任务状态、临时证据。把这四类内容混成一个不断增长的对话历史，会同时造成 Token 膨胀和信息污染。

4.1 一个简单但非常有杀伤力的缓存例子

假设每个任务需要 50k token 的稳定前缀、5k token 的动态输入、1k token 的输出，共执行 10,000 次。按 GPT-5.6 Sol 当前公开标准价计算：[2]

方案	每任务成本	10,000 任务总成本	说明
每次完整重发	约 $0.24	约 $2,400	55k 输入全部按标准输入价计费
固定 50k 命中缓存	约 $0.06	约 $600	50k 固定部分按缓存输入价，忽略首次写入

图 3｜在固定上下文占比高的场景中，缓存命中可以显著改变单位任务成本。

这个例子不是说所有 Agent 都能省 75%，而是说明：当稳定前缀占输入的大头时，缓存命中率会成为与模型选择同等重要的经济指标。OpenAI GPT-5.6 还提供显式缓存断点；Anthropic 也公开强调 prompt caching 对重复上下文的成本价值。[4][6]

4.2 最小充分上下文的五个动作

1. 分层存储：长期规则、项目事实、当前状态、临时证据分开管理。
2. 按需召回：先识别任务类型，再检索与任务有关的最小集合。
3. 稳定前缀：系统规则、公共定义放在可缓存区，动态信息放后面。
4. 工具输出裁剪：网页、日志、数据库结果先结构化，再给模型。
5. 阶段性压缩：长任务在检查点保存可追溯摘要，避免无限累积原始对话。

压缩边界 好的压缩必须保留：关键决策、证据位置、未解决问题、下一步动作和来源标识。只追求“变短”，会把可验证信息压成不可追责的自然语言。

5. 重试经济学：成功率比单次成本更重要

假设一次尝试成本为 C，单次成功率为 p，而且每次失败彼此独立，那么获得一次成功平均需要约 1/p 次尝试，单位成功成本约为 C/p。这个近似非常直观：成功率 50% 时平均约 2 次，20% 时平均约 5 次。

理想化近似：单位成功成本 ≈ 单次尝试成本 ÷ 单次成功率 p

图 4｜当单次成功率偏低时，重试会迅速放大单位成功成本。现实中失败往往相关，因此实际情况通常比理想曲线更差。

5.1 为什么真实 Agent 比公式更复杂

真实失败通常不是独立事件。如果任务定义错了、检索源失真、工具权限不足，重复运行同一配置并不会自动变好。此时“多重试几次”只是把同一个错误付费执行更多遍。

因此需要把重试分成三类：

• 瞬时重试：网络、限流、偶发工具错误。允许自动指数退避。
• 策略重试：更换检索路径、工具、模型或推理强度，并记录策略变化。
• 需求返工：成功标准或输入本身有问题。停止自动重试，回到任务定义。

生产底线 每个任务都应该有最大尝试次数、升级条件和停止理由。没有停止条件的 Agent，本质上没有成本上限。

6. 时延、批处理与并发：算力便宜不等于交付便宜

6.1 24 小时内完成的任务，不要按实时请求付费

对于离线摘要、批量分类、历史数据标注、夜间生成报告等非实时工作，批处理通常比同步请求更经济。OpenAI Batch API 当前公开说明是相对同步 API 享受 50% 折扣，并在 24 小时窗口内完成。[3] Anthropic 也公开提供约 50% 的批处理节省。[4]

于是，一个非常实用的第一问不是“用哪个模型”，而是“这个任务必须现在返回吗”。如果业务只关心明天早上结果是否准备好，实时推理的低延迟溢价没有价值。

6.2 Fast / Priority 只在时延有业务价值时才划算

对用户在线交互、交易前风控、编码助手等链路，时延本身就是价值。此时更快的服务等级可能值得付费。但应该用“每减少 1 秒带来多少转化、留存或人工等待节省”来决定，而不是因为“更快看起来更高级”。

6.3 并发越高，未必产能越高

Agent 常把模型、搜索、浏览器、数据库和人工审批串在一起。盲目提高并发可能引发限流、工具拥塞、重复任务、下游审核堆积。真正的吞吐量由最慢的瓶颈决定，因此容量规划要以端到端完成率而不是模型 QPS 为准。

7. 真实 ROI：从“省 Token”到“业务净收益”

如果 ROI 只计算“模型费降低了多少”，就会得到一个很漂亮但几乎没有经营意义的数字。企业真正关心的是：同样的业务量，需要更少的人吗？周期缩短了吗？转化提高了吗？错误减少了吗？风险下降了吗？

7.1 把收益拆成四个桶

收益类别	可量化方式	常见指标
人工节省	减少人工分钟 × 全成本时薪	每任务人工分钟、FTE 节省
周期缩短	更快交付带来的收入/库存/机会成本改善	平均处理时长、交付周期、响应 SLA
质量提升	减少错误、返工、流失和售后	一次通过率、返工率、退款率、NPS
风险降低	事故概率下降 × 事故影响	误发率、合规事件、错误付款/删除次数

7.2 ROI 必须有基线

没有基线，就没有 ROI。最少要记录上线前 2–4 周的业务量、人工时长、一次通过率、平均处理周期、异常率和成本。上线后保持同口径比较，避免把季节性增长、人员变化或业务结构变化误算成 AI 的贡献。

月度净收益 = 上线前可比成本 − 上线后可比成本 + 新增业务价值 − 新增风险成本

静态回收期（月） = 一次性建设投入 ÷ 月度净收益

8. 可复算案例：10 万客服工单/月怎么做经济账

下面不是虚构“某知名企业”的成功故事，而是一个把所有参数摊在桌面上的可复算模型。你可以把数字替换成自己的业务数据，直接得到本团队的成本与 ROI。

8.1 基线假设

参数	数值	说明
月工单量	100,000 单	稳定业务量
纯人工平均处理时长	8 分钟/单	包含阅读、查询、回复、记录
人工全成本时薪	¥85/小时	工资、社保、管理与工位的综合口径示例
Agent 可覆盖候选	70%	剩余 30% 直接人工处理
候选中直接验收率	88%	通过自动/业务验收，可直接使用
失败候选转人工	12%	回到人工流程
转人工后平均处理时长	5 分钟/单	Agent 已完成部分信息准备
自动通过抽检	10%，1 分钟/单	用于持续质量监测
模型 + 工具	¥36,000/月	按路由、缓存后示例预算
基础设施与观测	¥35,000/月	队列、日志、监控等
一次性建设投入	¥1,600,000	开发、评测、集成与上线成本示例

8.2 纯人工基线

100,000 × 8 分钟 ÷ 60 × ¥85 ≈ ¥1,133,333 / 月

8.3 Agent 上线后的月度成本

70,000 个候选任务中，88% 即 61,600 单直接通过；8,400 单失败回人工，加上原本不适合自动化的 30,000 单，共 38,400 单进入人工。

人工主流程：38,400 × 5 分钟 ÷ 60 × ¥85 = ¥272,000

抽检成本：61,600 × 10% × 1 分钟 ÷ 60 × ¥85 ≈ ¥8,727

总月成本 ≈ ¥272,000 + ¥8,727 + ¥36,000 + ¥35,000 = ¥351,727

月度节省 ≈ ¥1,133,333 − ¥351,727 = ¥781,606（约 69%）

静态回收期 ≈ ¥1,600,000 ÷ ¥781,606 ≈ 2.0 个月

图 5｜可复算客服工单示例。真实项目应替换为自己的工单结构、人工全成本与验收率。

8.4 模型路由本身能省多少

再看模型侧。假设每个任务平均累计 20k 输入 token、2.5k 输出 token，100,000 个任务全部使用 GPT-5.6 Sol，则按当前公开价，模型推理约为 $13,000/月。若采用 70% Luna + 25% Terra + 5% Sol 的分层路由，模型推理约为 $2,890/月，下降约 77.8%。[2]

策略	模型推理/月	工具与数据/月	直接调用总成本	业务验收率	单位验收结果成本
全量 Sol	$13,000	$2,100	$15,100	92.0%	约 $0.164
分层路由	$2,890	$2,100	$4,990	90.5%	约 $0.055

图 6｜当低复杂度任务占比较高时，模型路由对直接调用成本的影响非常显著。

这里有一个非常重要的结论：全量强模型的验收率可能更高，但单位有效结果成本仍可能显著更贵。是否值得，取决于那 1–2 个百分点的质量差异能否创造足够高的业务价值。

8.5 什么时候反而应该多花算力

• 任务价值高：质量提升能直接影响收入、合同、决策或重大风险。
• 强模型确实能提高验收率，而不是只写得更长。
• 人工审校很贵：多一次模型复核能显著减少专家时间。
• 任务处于探索期：更快获得高质量证据可以缩短验证周期。
• 产出可自动验证：增加算力不会把人的审核队列淹没。

9. 一张 Agent 经济仪表盘应该看什么

真正成熟的 Agent 项目，不应该只在云账单里看成本。至少需要一张把质量、成本、人工、时延和风险放在一起的经济仪表盘。

指标	定义	为什么重要
业务验收率	通过业务验收的结果 / 总任务	决定有效产出分母
单位有效结果成本	总成本 / 通过验收结果数	最重要的经济指标
模型成本/任务	所有模型调用成本 / 任务数	观察路由与上下文变化
工具成本占比	工具与数据成本 / 总直接成本	发现搜索/API 费用漂移
平均尝试次数	总尝试 / 成功任务	识别重试失控
升级率	升级到更强模型的任务占比	监控路由阈值是否合理
人工分钟/任务	人工总分钟 / 任务数	验证是否真的释放人
缓存命中率	缓存输入 / 可缓存输入	上下文工程核心指标
P50 / P95 完成时长	端到端而非单模型时延	决定真实体验与容量
风险事件率	高风险错误 / 任务数	不能被平均成本掩盖
净价值/任务	单任务业务价值 − 单任务总成本	把技术与经营统一

9.1 重点看趋势，不要只看绝对值

成本系统最怕“慢性漂移”：提示变长、工具返回膨胀、缓存命中下降、模型升级率上升、人工复核逐月增加。这些变化单看一天都不明显，但一个季度后会让同样的业务量变得越来越贵。

观测建议 建议至少按任务类型、模型层级、客户/业务线、成功/失败结果做分组。平均值会掩盖真正烧钱的长尾任务。

10. 五个最常见的成本误区

误区 1：Token 越少，系统越高效

如果压缩导致关键信息丢失、验收率下降，那么总成本反而会上升。优化对象不是 Token 数，而是单位有效结果成本。

误区 2：最强模型一定最贵

单次调用最贵，不等于单位成功结果最贵。一个强模型如果把成功率从 40% 提升到 90%，并显著减少人工返工，最终可能更便宜。

误区 3：小模型优先就叫路由

真正的路由必须同时有任务分层、验证器、升级策略和停止条件。没有验证器的“小模型首跑”，只是把错误概率推给下游。

误区 4：演示成功就等于 ROI 成立

演示通常选择干净输入、专家操作和理想网络条件。生产 ROI 需要看真实业务分布，包括异常输入、低质量数据、工具故障、用户中断和人工审校。

误区 5：所有 Agent 都应该常驻运行

很多任务是事件驱动或批处理的。让 Agent 频繁轮询、持续读取大上下文，不仅浪费算力，还可能制造噪声和重复动作。

11. 30 天落地路线图

阶段	要完成的动作
第 1 周：把基线量出来	选 1–2 个高频任务；记录业务量、人工分钟、成功率、返工率、当前周期；定义“通过验收”的硬标准。
第 2 周：建立评测与路由	先用强模型建立质量基线；构建代表性 eval；识别可降级任务；接入自动验证与失败升级。
第 3 周：优化上下文与工具	拆分稳定/动态上下文；做缓存与按需检索；裁剪工具输出；给所有工具调用加成本与成功率日志。
第 4 周：跑真实 ROI	小流量上线；按任务类型统计单位有效结果成本；加入人工分钟、P95 时延和风险事件；只扩展经济性已经成立的场景。

11.1 上线前检查清单

• □ 是否明确了业务验收标准，而不只是“模型有输出”？
• □ 是否能追踪每个任务的模型、工具、重试和人工成本？
• □ 是否存在可靠的自动验证器或业务规则？
• □ 是否设置最大重试次数、升级条件和停止条件？
• □ 高风险、不可逆动作是否有人工确认门和审计记录？
• □ 上下文是否按长期规则、项目事实、当前状态、临时证据分层？
• □ 是否统计缓存命中率、工具成功率和 P95 完成时间？
• □ 是否有可比较的上线前基线，避免把业务自然变化算成 AI 收益？
• □ 是否按任务类型做路由，而不是一套模型处理所有工作？
• □ 是否能在成本或错误率异常时快速回退到人工/确定性流程？

12. 结语：真正的优化目标是单位有效结果成本

AI Agent 的竞争，最后不是“谁的 Token 最便宜”，而是谁能以更低的单位有效结果成本，稳定交付更高的业务价值。模型本身只是成本结构中的一部分；上下文、工具、重试、人工注意力和风险，才决定系统是否能长期规模化。

一个经济性健康的 Agent 系统，通常有四个共同点：能不用模型的地方不用模型；能用便宜模型的地方不浪费强模型；复杂任务敢于花算力，但必须有可验证的收益；所有结果都围绕业务验收、人工节省和风险边界闭环。

一句话总结 最终目标不是“把 AI 用得更多”，而是让每一次智能调用都能被解释、被验收、被计价，并持续产生比成本更高的业务价值。

参考资料与数据口径

[1] OpenAI, A practical guide to building agents — 关于 Agent 适用场景、模型选择、评测、人工介入与护栏。

https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/

[2] OpenAI API Model Docs — GPT-5.6 Sol / Terra / Luna 当前公开价格、缓存输入与长上下文计价说明（访问口径：2026-08-30）。

https://developers.openai.com/api/docs/models/gpt-5.6-sol

https://developers.openai.com/api/docs/models/gpt-5.6-terra

https://developers.openai.com/api/docs/models/gpt-5.6-luna

[3] OpenAI Batch API FAQ — Batch API 相对同步 API 50% 折扣、24 小时处理窗口。

https://help.openai.com/en/articles/9197833-batch-api-faq

[4] Anthropic, Claude Sonnet — Sonnet 5 公开价格、prompt caching 与 batch processing 的成本节省说明。

https://www.anthropic.com/claude/sonnet

[5] Google AI for Developers, Gemini Developer API pricing — Gemini 3.6 Flash 公开价格、context caching 与搜索 grounding 计价。

https://ai.google.dev/gemini-api/docs/pricing

[6] OpenAI, The builder’s guide to GPT-5.6 — 模型选择、程序化工具调用、缓存与多 Agent 的生产实践。

https://openai.com/index/builders-guide-to-gpt-5-6/

说明：本文所有厂商价格仅用于演示成本模型，价格、优惠期、服务等级与工具计费可能随时间变化；生产决策应以实施当天官方定价、合同条款和实际 usage 记录为准。案例中的人民币业务参数为可复算示例，不代表任何具体企业经营数据。