Splunk 开源 Token Meter：给编码 Agent 装一个实时成本仪表

这个月，某个 Agent 处理了一句 15 个字左右的用户请求，最后烧掉了 6 万 token。其中 62% 是模型在重读它已经看过的上下文，还有 3,000 token 花在了这个任务根本不会用到的工具 schema 上。这不是谁写错了代码，而是 Agent 架构的默认行为。Splunk（Cisco 旗下）在 9 月开源了 Token Meter：一个「本地优先」的成本仪表，读取你电脑上 Agent 已经写下的日志，把这些数字实时摊在你面前。它不解决浪费，但它让浪费第一次变得可见——而这是所有优化的起点。

把一笔糊涂账变成一张成本地图

一、为什么 Agent 的账单会复利增长

聊天机器人时代的心智模型是「一次提示等于一次调用」，Agent 把这个前提打破了。Agent 是一个循环：规划、调用工具、读回结果、再规划。而 API 是无状态的，所以每一步都要把累积的全部上下文重新发一遍。看一个真实形状的例子：用户问「查一下这位客户最近三笔订单能不能退款」，大约 12 个词。系统先送 1,500 token 的系统指令、3,000 token 的工具 schema（其中包含这个任务用不到的）、2,500 token 的客户数据检索，于是用户的 20 个 token 在模型开口之前就膨胀成了 7,000 个输入 token。然后循环开始：第二次调用 10,000 token，第三次 13,000，第四次随着工具结果堆积到 17,000。到第五次，模型已经在重复处理同一段上下文第四遍了。一个本该不到 1 万 token 就能完成的五步任务，最终消费了 4 万以上。

# Token Meter is local-first: it reads the trace logs your agents
# already write to disk, then prices them against public model rates.
# Here is the shape of that math on a captured session record.
RATES = {"gpt-5.6-terra": (3.00, 15.00), "claude-sonnet": (3.00, 15.00)}

def session_cost(records):
    total = 0.0
    for r in records:
        in_rate, out_rate = RATES[r["model"]]
        total += r["input_tokens"] / 1_000_000 * in_rate
        total += r["output_tokens"] / 1_000_000 * out_rate
    return round(total, 4)

# A run that "looked cheap per step" is only cheap until you sum the loop.

二、六个桶：你的 token 到底买了什么

把一笔糊涂账变成地图的方法是分类。Agent Tokenomics 把每次调用的 token 分进六个桶：上下文 token（系统指令、对话历史、工具 schema，随每次调用同行）、推理 token（模型思考、规划、链式推导）、检索 token（RAG 拉回来的文档）、工具 token（工具返回的结果，它们会进入上下文并在后续每一步里继续同行）、协调 token（多 Agent 系统里的角色提示、同步消息、共享状态）、治理 token（校验、安全检查、评估、人工复核触发）。最后一个桶最反直觉：它常常在账单上完全不可见，因此也从来不被预算。斯坦福数字经济实验室的研究发现，重复发送的上下文可以占到 Agent 推理账单的 62%，而其中的浪费非常具体——无关的 schema、过期的历史、本该被缓存却没有缓存的稳定前缀。在真实生产里这类数字很惊人：有审计显示同一团队做相似工作的开发者之间存在 20 倍的支出差距；也有一家公司在把 token 支出分类并重构架构后，月支出从 8.7 万美元降到 2.4 万美元，而速度指标没有变化。

// Classify tokens into buckets so you know which spend bought progress.
const BUCKETS = ["context", "reasoning", "retrieval", "tool", "coordination", "governance"];

function classify(call) {
  const out = Object.fromEntries(BUCKETS.map((b) => [b, 0]));

  out.context = call.systemTokens + call.historyTokens + call.toolSchemaTokens;
  out.reasoning = call.reasoningTokens;
  out.retrieval = call.ragTokens;
  out.tool = sum(call.toolResults.map((t) => t.tokens));  // responses ride along
  out.coordination = call.multiAgentTokens;
  out.governance = call.evalTokens + call.reviewTokens;   // usually invisible

  return out;
}

// Rule of thumb from published analyses: re-sent context can be the
// single largest line, so attack that bucket first.

三、Token Meter 是什么：看得见的本地仪表

Token Meter 是 Splunk 开源的本地优先用量与成本仪表（源自 Galileo Agent Labs）。它做的事情很朴素：读取你本机 Agent 会话已经写在磁盘上的 trace 日志，把它们折算成 token 用量、估算成本、上下文压力、等待时间、输出速度、工具调用和会话时长，然后汇总到一个界面上。它支持 Claude Code、Codex、Cursor、OpenCode、Kiro 和 Pi；在 macOS 上有菜单栏小组件，Linux 上有托盘组件，Windows 版本还在 beta。三个特性值得划重点：它是纯 Python 标准库实现，分析 trace 不需要任何 API key；它不上报任何遥测，数据不出本机；它自带一个本地 MCP 服务，让 Codex 或 Claude 可以在有界范围内查询证据。安装后打开 http://127.0.0.1:8722，跑一次正常会话，然后在 Sessions 里选它即可。

# Cost per accepted task is the real price of one good result:
# model cost + tool/runtime cost + human review cost.
def cost_per_accepted_task(model, tool, review_rate, minutes_reviewed, hourly):
    review = (minutes_reviewed / 60) * hourly
    return round(model + tool + review * review_rate, 4)

# A "cheap" $0.02 support answer looks efficient, until 40% need a
# 15-minute human review at $30/hour:
reviewed = cost_per_accepted_task(0.02, 0.00, 0.40, 15, 30)   # ~3.02
clean = cost_per_accepted_task(0.02, 0.00, 0.00, 0, 30)       # 0.02
print(reviewed, clean)   # the blended number sits far above the invoice

四、真正该盯的两个指标

光看总花费没用，你需要两个能反映价值的指标。第一个是 token 产出率（token yield）：每百万 token 换来多少个「成功会话」。它的前提是你先定义「成功」——比如任务完成、幻觉低于阈值、没有人需要升级到人工，只有全部满足才算成功。第二个、也是更接近现实的一个，是「每个被接受任务的成本」：模型成本 + 工具/运行时成本 + 人工复核成本。这个公式会打碎很多假象。一个用便宜模型跑、看起来每任务只要 0.02 美元的客服 Agent，如果 40% 的回答需要人工复核、每次 15 分钟、客服时薪 30 美元，那么这些回答的真实成本大约是 3.02 美元；干净的那批才维持在 0.02 美元——而混合后的真实数字远远高于发票上的那个数。

// Token yield = successful sessions per million tokens.
// You must define "successful" before the number means anything.
function tokenYield(sessions, qualityBar) {
  const successful = sessions.filter((s) =>
    qualityBar.every((check) => check(s))   // done, no hallucination, no escalation
  ).length;

  const tokens = sessions.reduce((sum, s) => sum + s.totalTokens, 0);
  return (successful / tokens) * 1_000_000;
}

// A refund lookup and a summarization are different workflows,
// so each gets its own bar and its own yield. Never blend them.

五、从哪开始：先用你已经有的数字

一个常见的错误是上来就换模型、砍上下文。正确的起点是你现在就能拿到的数字：每个 API 响应本来就返回输入和输出 token 总数。先按这个粒度跑一周，找出支出最高的几个工作流，再随着 tracing 的完善逐步加上更细的分桶。两个必要的背景数字：企业 AI 支出从 2024 年每家公司约 120 万美元涨到 2026 年的约 700 万美元，而同期每 token 的价格下降了约 280 倍——单位变便宜了，消费量却爆炸；有报道称 Uber 在 4 月就用完了 2026 年全年的 Claude Code 预算。这说明问题不在单价，而在「没有人知道钱花在哪一步」。

# Guard the runaway. Alert on the distribution, not just the average:
# a handful of very long sessions usually dominates the bill.
def budget_alerts(sessions, monthly_budget, p95_minutes=45):
    spend = sum(s["cost"] for s in sessions)
    if spend > 0.8 * monthly_budget:
        alert("agent budget at 80% - inspect the top spenders")
    for s in sessions:
        if s["minutes"] > p95_minutes:
            alert("session " + s["id"] + " ran long: " + str(s["minutes"]) + " min")
# Splunk's Token Meter streams this live, entirely on your machine:
# no API keys, no telemetry, dashboard at http://127.0.0.1:8722

六、清单：把可见性变成预算纪律

五个动作。第一，先测量再优化，别凭直觉砍上下文。第二，把「成功」写成可执行的判定条件，否则 token 产出率没有意义。第三，把人工复核成本算进单位经济，它经常是账单的十倍。第四，告警设在分布上而不是均值上——极少数超长会话通常主导账单，所以要盯 P95 会话时长和「超过上限仍在运行」的会话。第五，把工具返回值当成一等成本：那一次调用很便宜，但它的返回会留在上下文里，跟着后续每一步一起计费。最后记住一句话：token 不是账单上的小数点，它是智能的营运资本；你要问的不是「花了多少」，而是「哪一部分买到了进展，哪一部分什么都没买到」。