用5列CSV追踪AI智能体成本，阻止悄无声息的烧钱

大多数AI智能体的成本问题，根源不在模型定价，而在于运行未被追踪：没人说得清哪次运行花了多少钱、对应什么任务、产出是否被采用。一份仅5列的CSV记录表，就能把黑洞变成可分析的支出报表。

为什么你的智能体在悄悄烧钱

传统成本管理把注意力放在每百万token的价格上，但真正吞噬预算的是那些重复读取状态却不执行动作的循环。这些运行照样消耗token，却不产生任何业务价值。问题不是单价，而是缺少每一次运行的归属记录。

当无法回答“哪个智能体角色花了这笔钱”“这次运行是否产生了有效产出”时，成本优化就无从下手。月末账单只是一个总数，它不会告诉你浪费发生在哪里。

什么是 token 与“重复读取状态”循环？

token 是大语言模型处理文本的基本单位，大约相当于英文的 0.75 个单词或中文的 1-2 个字。每次调用模型，输入文本被计为 tokens_in，模型生成的输出被计为 tokens_out，二者共同构成计费基础。

所谓“重复读取状态却不执行动作”的循环，指的是智能体在多轮交互中反复把相同的上下文、工具返回值或环境状态塞回提示词里，却没有推进任务——例如不断检查一个未被更新的文件、轮询一个尚未变化的外部接口。这类循环每一轮都会重新计费输入 token，但产出的 outcome 是 no_action。它们往往由模糊的停止条件、缺失的超时机制或工具返回格式不稳定触发，在长链路智能体中会迅速累积成可观的账单。

5列追踪模式

这套极简模式的核心是让成本与结果在同一行内可见：

列名	作用
run_id	关联日志、成本与最终结果
agent_role	标记是哪个智能体花掉了这笔钱
tokens_in / tokens_out	成本的原始驱动量
cost_usd	在写入时计算，而非等到月底才汇总
outcome	取值为 shipped、no_action、failed、retried

其中 outcome 列是灵魂。没有它，你只能看到花了多少，看不到这笔钱换来了什么。写入时就算好成本，也让实时监控成为可能，而不是事后追悔。

为什么 outcome 要分成四类值？

shipped 代表任务产生被采用的结果，是计算“每有效产出成本”的分母；no_action 标记只消耗不产出的空转；failed 记录报错终止的运行；retried 则区分出那些因为首次失败而重复执行的运行。四类值合起来才能算出重试倍数，并定位问题究竟出在提示词、工具还是外部依赖上。如果只用成功/失败两分法，那么重试消耗的成本就会被混入成功运行，掩盖真实的低效环节。

三个能自己赚回成本的查询

这套数据一旦积累起来，三个简单查询就能暴露最要命的问题：

1. 每个有效产出的成本：总 cost_usd 除以 outcome = shipped 的次数。如果这个数字在上升，说明智能体效率在下降，即使总花费没变。
2. 无动作消耗：对 outcome = no_action 的 cost_usd 求和。这是纯粹浪费——原文指出，在那些反复读取状态却不行动的循环中，这部分通常占支出的 20% 到 40%。
3. 重试倍数：每个任务平均运行次数。超过2次，说明是提示词或工具的问题，而不是预算问题。

这三个查询的价值在于，它们把“感觉变贵了”变成“哪个环节变贵了、贵了多少”。

最小化Python记录器

原文给出了一个可直接用的记录函数，核心片段如下：

import csv, time, pathlib

PATH = pathlib.Path('agent_runs.csv')

def log_run(run_id, role, tin, tout, cost, outcome):
    new = not PATH.exists()
    with PATH.open('a', newline='') as f:
        w = csv.writer(f)
        if new:
            w.writerow(['ts','run_id','role','tokens_in','tokens_out','cost_usd','outcome'])
        w.writerow([time.strftime('%Y-%m-%dT%H:%M:%S'), run_id, role, tin, tout, round(cost, 4), outcome])

关键实现细节：把它放在 finally 块中调用，这样失败和重试的运行也会被记录。原文特别强调，“失败运行才是钱藏身的地方”——只记录成功运行，等于主动蒙上眼睛。

为什么必须用 finally 块？

在 Python 中，try...finally 结构保证无论代码是正常返回、抛出异常还是被中断，finally 中的语句都会执行。把 log_run 调用放进 finally，可以确保智能体在报错、超时或提前退出的情况下依然留下成本记录。若只在成功分支里记录，失败和重试的运行就会从账本上消失，而这些恰恰是开支增长最快的部分。同理，在异步或并发场景中，也应把记录逻辑放在任务完成的回调或 finally 等价位置，避免因协程被取消而漏记。

从记录习惯开始，而非工具

作者将这套结构打包成了 Notion 数据库模板加 CSV 起步包，并提供了三个预置视图，避免手动搭建。链接为 Agent Ops Tracker（Notion + CSV），采用“随你付”模式，最低1美元。

但原文也明确表态：上面的 CSV 方案已经完全够用，习惯比工具更重要。无论用 Notion 还是纯文本文件，持续记录每一次运行、并在写入时就计算成本，才是把智能体支出从黑盒变成可控列表的关键。

作者最后提出的问题值得每个团队自问：你追踪的是每次调用的成本，还是每个有用产出的成本？前者只是账单，后者才是效率。

核心要点

• 智能体成本问题的本质是运行未被追踪，不是模型单价。
• 5列CSV模式：run_id、agent_role、tokens_in/out、cost_usd、outcome，让成本与结果同行可见。
• 三个高价值查询：每有效产出成本、无动作消耗（常占支出的20%-40%）、重试倍数。
• 记录器必须放在 finally 块中，确保失败和重试运行不被遗漏。
• 习惯优先于工具，简单CSV即可启动成本追踪。