判断 Agent 是否划算，应比较完成同一任务、达到同一验收标准后的总成本。单次调用的 token 价格只覆盖其中一部分；重试、工具、托管、人审、集成和运维可能改变排序。
本文根据 LearnAgent 原文重算并修订，价格资料核验于 2026-10-03。文中的金额示例以美元、未计税和地区差异说明计算方法，不代表采购报价或未来价格。
先确定比较单位
“每次调用”“每个会话”和“每个成功任务”不能混用。一次成功的代码修复可能包含多轮模型请求、检索、测试及人工审查；一次便宜但失败的调用没有交付相同结果。
建议按下式汇总一个评估批次：
每成功任务成本 =（模型费 + 工具及第三方 API 费 + 运行与存储费 + 人工审查与返工费 + 分摊的集成维护费）÷ 通过验收的任务数
同时报告总任务数、成功率、延迟、质量与失败类型。零成功的批次不能通过除法得到有意义的单位成本，应直接标为未达到目标。
模型费用要按实际类别计算
| 项目 | 需要记录的输入 | 常见误差 |
|---|---|---|
| 未缓存输入 | 精确 model ID、token 数、上下文档位 | 把总输入与未缓存输入重复计算 |
| 缓存读取 | 命中 token、实际 cache-read 费率 | 假设每次都能命中完整前缀 |
| 缓存写入及保存 | 写入 token、TTL、存储时长与相应费用 | 只算读取优惠，漏算创建缓存 |
| 输出 | 可计费输出与 reasoning/thinking 口径 | 只数可见回答文本 |
| 其他 | 工具调用、联网、批处理、服务等级等 | 把 batch 折扣用于在线请求 |
比较表必须把币种、日期、模型 ID、在线或 batch、上下文阈值和地区写在同一行。ChatGPT 中的产品显示名，也不能在未经核验时当成 API 中可独立购买的 SKU。OpenAI API 定价
以 Gemini 2.5 Pro 的标准在线价格说明：输入不超过 200k 的档位为每百万输入 token $1.25、输出 $10；更长输入档位为 $2.50 和 $15。较低的 batch 价格不能套到标准在线输出，还应检查 thinking 和缓存存储的计费说明。Google Gemini API 定价
DeepSeek 的当前型号、缓存命中/未命中和峰谷规则也应按实际请求对应的官方表填写。旧型号的单一输入输出价格不能代表所有当前套餐。DeepSeek 官方价格
缓存算例
下面只演示一组已经明确的费率假设：未缓存输入 $5/百万、输出 $25/百万、缓存读取 $0.50/百万。使用时先核对所选模型和服务档位是否适用。Anthropic 定价与缓存
- 若 50,000 是未缓存输入，另有 40,000 缓存读取，输出 15,000：费用为 0.05×5 + 0.04×0.5 + 0.015×25 = $0.645
- 若 50,000 是总输入，其中 40,000 已缓存，未缓存仅 10,000：费用为 0.01×5 + 0.04×0.5 + 0.015×25 = $0.445
两种情形都未计缓存写入、工具及其他费用。应使用实际 usage 字段，先确认包含关系再计算。缓存前缀变化、TTL 到期和路由差异都可能降低命中率，不应把一次理想命中外推成整月节省比例。
框架开销如何测
框架可能通过额外提示、工具描述、重试或多代理轮次增加请求，但不存在适用于所有应用的统一“框架多花 20%—50% token”常数。
LangGraph checkpoint 把状态持久化到后端，本身不是模型请求；只有再次送入模型的内容才产生对应输入费用，图拓扑也不必进入提示词。OpenAI Agents SDK 同样提供 Sessions 等持久会话功能，不能把“原生 SDK”概括为没有记忆。LangGraph 持久化、OpenAI Sessions
测试时固定模型、提示目标、任务样本和验收规则，分别记录模型返回的 usage、调用次数、重试原因及工具结果大小。供应商文档中某种工具调用的 token 开销，只能用于对应模型和接口，不能改名后当作另一家 SDK 的固定成本。
部署成本需要负载参数
Serverless 不能统一按“每次调用几分钱”报价。Lambda 涉及请求和执行资源时长；Cloudflare Workers 则有套餐、请求与 CPU 等口径。长时间等待外部工具的 Agent 与短计算函数，应分开估算。AWS Lambda、Cloudflare Workers
向量存储至少需要向量维度、数据量、查询和写入 QPS、副本、区域、内存/存储、备份及最低消费。仅给“一百万向量”，不足以得出 Pinecone、Qdrant 或自托管 pgvector 的准确月费。自托管的软件许可成本与机器、值班、升级成本也应分列。Pinecone、Qdrant
人效与现金回报分开核算
固定团队工资不变时，增加 AI 开支不会自动减少现金支出。更快交付可能有价值，但那是需要另行评估的产能、收入或机会成本变化，不能直接从工资里扣出“节省”。
Anthropic 的内部研究观察到每工程师每日合并 PR 的变化，并调查了员工工作中使用 Claude 的情况；这不是所有开发团队的普遍因果结果，也不能直接推成工资节省率。合并 PR 数还需结合任务复杂度、质量和返工解读。原始研究
一个可信的 ROI 表应分别列出：新增现金成本、实际减少的现金支出、估计新增价值，以及估计所依赖的假设。没有已实现的现金节省时，清楚写零；不要用“+67% PR”乘工资得到虚构利润。
选型建议
小规模试点先用少量模型和简单编排，保留完整 usage 与人审记录。负载增大后，再根据测量结果考虑缓存、路由、批处理、自托管或多代理；每次优化都复测成功率与质量。
更便宜的模型可先进入低风险、易验证的子任务，但不预设它一定适合“简单任务”，也不预设昂贵模型一定适合复杂任务。保留升级模型和人工处理的路径。最终选择能在预算、时延和质量约束下稳定交付的组合，而不是单价表的最低一行。