Agent成本追踪：给AI员工记一本明白账

可视化演示

动态展示Planner/Executor/Critic三Agent的Token消耗与费用归因至追踪系统的过程，切换per-call/per-session/per-agent/per-user四种粒度观察成本分布。

成本构成分析——账单上都有什么

回到奶茶店。店长小智每接一单，柜台上的“原料清单”都会多出几行：茶叶、牛奶、珍珠、杯子，再加一只打包袋。在 AI 世界里，这张清单就是每次 API 调用的账单——Agent 读到的提示词是输入 Token，它生成的回答是输出 Token，就像顾客的订单和做出来的奶茶。账单左栏写着数量，右栏写着单价，末尾加总就是一次调用的总费用。看懂这张小票，是成本追踪的第一步。

值得留意的是，“一次任务”不等于“一次调用”。小智接到“推荐奶茶”的任务，可能要先查库存、再算成本、最后写推荐语，对应三次 API 调用（Call）。每一次调用都独立计费，而且输入和输出的单价往往不一样——高端模型好比金骏眉茶底，输出贵；轻量模型好比绿茶包，便宜得多。这也是为什么追成本要从“单次调用成本”这个最小单位算起，再把同一任务的多次调用叠加。

把一次调用拆开看，成本由两部分构成：输入 Token 量与输入单价之积，加上输出 Token 量与输出单价之积。厂商通常按“每千 Token”计价，所以 Token 数要除以 1000 再乘单价，公式如下：

除了这两笔大头，账单上还常藏着“附加费”：调用搜索或代码工具的计费、重试失败请求的支付、缓存命中的折扣价。就像打包袋和外卖配送费不起眼，积少成多却影响月底利润。老板若只盯着主料价格，就会漏掉这些悄悄漏钱的缝隙，而这正是成本追踪要全部纳入视野的原因。

追踪指标体系——记账本上记什么

有了小票，接下来得决定记账本上写哪些数字。奶茶店老板每天早上会看三样东西：昨晚总营收、每单均价、最热卖的品类。对应到 Agent 成本追踪，就是三个核心指标：累计 Token 消耗、单次调用成本、成本趋势。累计 Token 是“总共多少杯”，单次调用成本是“平均一杯多少钱”，成本趋势则是“最近一周是涨是跌”。

上下文长度是一个容易被忽略的指标。多轮对话里，历史记录每轮都要作为输入重新发送，就像顾客每加一次“少冰”，小智都要把整张订单重新读一遍。对话越长，每次调用的输入 Token 就越多，成本呈“复利式”上涨。所以追踪指标不仅要看单次请求，还要监控上下文长度随轮次的增长曲线，它往往是成本悄悄变高的元凶。

把多次调用的成本累加起来，就得到累计总成本。若把每次调用的成本记为 $\mathrm{Cost}_i$，任务共调用 $N$ 次，则总成本是：

这套指标体系就像奶茶店的日报表：有了累计、均值、趋势三个维度，老板不仅能回答“花了多少”，还能回答“花得值不值”“下个月会不会更多”。账本上的数字不再是冷冰冰的总量，而是可以指导经营决策的仪表盘。

计量统计口径——怎么数珍珠才算对

记账之前先得解决一个根本问题：珍珠到底怎么数？是按粒数，还是按重量？不同数法，同一碗珍珠奶茶能数出不同的结果。Token 的计数也是一样——它不等于字符数，而是由模型自带的 Tokenizer 按“词元”切分出来的。英文里“world“是一个 token，中文”你好”可能被切成一个或两个 token，代码里的特殊符号又有自己的切法。

这就是为什么很多新手用“字符数除以 4”估算 Token 会翻车。那条经验法则只对英文文本大致成立，对中文、混合语言、JSON 结构文本误差很大。正确的做法是：用目标模型的 Tokenizer 对实际文本做离线计数，再把结果与厂商账单比对；日常开发时可以先用经验公式做数量级估算，但一旦涉及对账、预算，就必须以 Tokenizer 和调用日志为准。

一个常用的经验估算法则：英文文本约 4 个字符对应 1 个 token，中文文本每字约 0.6 到 1 个 token。写成公式就是：

回到奶茶店：精确数珍珠要用专门的小秤（Tokenizer），而“目测大概多少粒”（字符估算）只能用于开店前的成本预估。真正月底对账时，还是得抓着小票（调用日志）一粒粒核对，绝不能用估算值糊弄供应商——这就是计量口径的意义。

监控预警机制——账本上的报警器

奶茶店的冰箱上贴着一张库存表，珍珠低于红线就亮红灯，提醒你赶紧补货。成本追踪同样需要一个报警器：当累计成本接近预算，或者某一次调用的花费异常暴涨，系统要立刻喊停。否则等月底看到账单才惊呼“怎么这么多”，一切已经来不及。报警器要解决两个问题：一是阈值设在哪，二是怎么滤掉噪声避免误报。

阈值设定有个常见误区：把预警线设在预算的 100%，等用完再响。可成本是连续增长的，等响铃时钱已经花出去了。正确做法是分级预警：70% 提醒、90% 限流、100% 熔断。另一面，单次调用的成本天然有波动——某次任务上下文特别长，某次搜索工具返回特别大，都会造成尖峰。直接用原始数据设阈值，容易被尖峰反复触发，让人产生“狼来了”的疲劳。

要识别真实的趋势信号，可以对成本序列做指数移动平均（EMA）平滑。令 $C_t$ 为当日成本，$\alpha$ 为平滑系数，则：

报警器装好后，还要配上异常检测：当某一次调用的成本超出历史均值好几个标准差，立刻记录调用链、定位是哪个子任务烧的钱。就像奶茶店冰箱既看整体库存，也查是哪一包原料受潮变质。有了这层机制，成本问题不再是月底的“惊吓”，而是日常经营里随时可以处理的小波澜。

成本优化策略——省钱四妙招

记账和报警都做好了，接下来是老板最关心的话题：怎么省钱？奶茶店省钱有四招：换更便宜的原料、减少浪费、优化配方、批量采购。对应到 Agent 成本，就是模型降级、提示词精简、缓存复用、上下文压缩。四招不冲突，可以叠加使用，效果往往立竿见影。

先看最简单的一招：模型降级。并不是所有任务都需要最贵的大模型。回一句“订单已收到”，用轻量小模型就足够，就像普通奶茶用基础茶包而高端特调才用金骏眉。其次是提示词精简，把 prompt 里冗长的背景说明压缩成要点，输入 Token 直接变少。如果说降级是换原料，精简就是少放料——两者都能立刻降低成本。

第三招是缓存复用。如果多个用户问同样的问题，或者同一个 Agent 反复处理相似的指令，可以把计算结果缓存下来。缓存命中率的公式很直观：

第四招是上下文压缩：多轮对话过长时，把历史记录做摘要，只保留关键信息，而不是每次原样重发。就像小智不用把每个顾客三年前的偏好都背下来，只记一张“口味卡”就够了。四招配合，成本通常能降 30%–60%，而用户体验几乎不受影响——这才是让老板睡得着觉的省钱妙招。

预算分摊管理——总店如何给分店分账

最后一步，是算总账。奶茶店开了三家分店，总部每月给一笔总预算，怎么分？按各分店上月营业额的比例最公平。Agent 成本也一样：公司总共批了 $B_{\mathrm{total}}$ 的 AI 预算，要分给客服、搜索、内容生成等项目，合理的依据是各项目的预估调用量占比。

这个分配过程就是成本分摊。实际操作中，先统计每个项目过去一段时间的 Token 消耗和调用次数，预测下个月的用量，再按占比切预算。某项目预估调用量为 $M_i$，所有项目总预估为 $\sum M_j$，则该项目分得的预算是：

分摊之后，还要做到账单透明：每个项目组能看到自己的累计成本、调用明细和剩余预算，就像分店店长能随时看到自家营业额和成本。定期导出账单、按项目归档，既方便财务结算，也为下一次预算预测提供了数据基础。到这一步，奶茶店的账本才真正闭环——从看懂小票，到记账、报警、省钱、分账，Agent 成本追踪的完整体系就搭建起来了。

AI 应用场景

Python 演示

class AgentCostTracker:    """模拟一个 Agent 调用成本追踪器，记录 Token 与 Call 成本"""     def __init__(self, price_in=0.003, price_out=0.004, budget=2.0, cache_price=0.0003):        self.price_in = price_in        self.price_out = price_out        self.budget = budget        self.cache_price = cache_price        self.calls_list = []        self.cache_hits = 0        self.total_calls = 0     def estimate_tokens(self, text):        """按字符数粗估 Token 数（中文约 0.6 token/字）"""        return max(1, int(len(text) * 0.6))     def log_call(self, prompt, reply, cached=False):        """记录一次调用，按是否命中缓存分别计价"""        if cached:            cost = self.estimate_tokens(prompt + reply) / 1000 * self.cache_price            self.cache_hits += 1        else:            t_in = self.estimate_tokens(prompt)            t_out = self.estimate_tokens(reply)            cost = t_in / 1000 * self.price_in + t_out / 1000 * self.price_out        self.total_calls += 1        self.calls_list.append(cost)     def total_cost(self):        """返回累计总成本"""        return sum(self.calls_list)     def avg_cost(self):        """返回单次调用平均成本"""        if not self.calls_list:            return 0.0        return self.total_cost() / len(self.calls_list)     def hit_rate(self):        """返回缓存命中率"""        if self.total_calls == 0:            return 0.0        return self.cache_hits / self.total_calls     def over_budget(self):        """判断是否超预算"""        return self.total_cost() >= self.budget  def main():    tracker = AgentCostTracker(budget=0.05)    for i in range(10):        prompt = "请推荐一份三天的北京旅游行程" + str(i)        reply = "第一天去故宫，第二天去长城，第三天去颐和园。" * 3        cached = i % 3 == 0        tracker.log_call(prompt, reply, cached=cached)        print("第{}次调用: 成本${:.4f}, 累计${:.4f}".format(            i + 1, tracker.calls_list[-1], tracker.total_cost()))    print("平均单次成本: ${:.4f}".format(tracker.avg_cost()))    print("缓存命中率: {:.1f}%".format(tracker.hit_rate() * 100))    print("是否超预算: {}".format("是" if tracker.over_budget() else "否"))  if __name__ == "__main__":    main()

1. def estimate_tokens(self, text):模拟 Tokenizer 按字符粗估 token 数，中文经验系数 0.6。
2. cost = t_in / 1000 * self.price_in + t_out / 1000 * self.price_out复现正文核心公式：输入输出分开计价再相加。
3. self.calls_list.append(cost)每一笔 Call 都落账，后续可以算累计和均值。
4. self.cache_hits += 1命中缓存单独计数，用于计算命中率。
5. return self.cache_hits / self.total_calls命中率公式的代码化，命中率越高说明复用越好。
6. if tracker.over_budget():模拟预算熔断：累计成本触碰上限即触发告警逻辑。

常见误区

面试题