智能体成本治理：State of FinOps 2026 对你的 Token 账单说了什么

FinOps Foundation 在 2026 年 2 月 19 日发布了第六份年度《State of FinOps》调查：1,192 位从业者、覆盖超过 830 亿美元的年云支出，其中 98% 表示自己现在已经在管理 AI 支出——而 2025 年是 63%，2024 年只有 31%。同一份调查把 AI 成本管理列为该领域最紧缺的技能（FinOps Foundation，2026 年 2 月 19 日）。两年之内从三成到接近全部，这个变化速度本身就说明了问题：AI 支出已经不是技术账，而是治理账。同时另一件事也在发生——每 token 的单价持续下降，而智能体的账单持续上升。

按决策计账，而不是按 token 计账

一、为什么单价下降、账单上升

答案在乘法里：账单约等于「每 token 单价 × 每次决策消耗的 token 数」。第一项这几年确实在下降，第二项却因为架构而急剧上升。一次对话式请求可能只有几千 token；而一个编码智能体为了修一个 bug，会读取代码库、探索失败路径、迭代补丁，很可能消耗掉十几万甚至更多输入 token，而其中大部分内容在上一轮已经出现过。这解释了一个反复出现的现象：单价谈判成功、月账单仍然翻倍。要控制它，就要把度量单位从 token 换成「每次决策」。

# ledger.py - bill by decision, not by token
def record(decision_id, task, model, usage, usd):
    return {
        "decision_id": decision_id,          # one business decision
        "task_family": task,                 # bug_fix | triage | research
        "model": model,
        "input_tokens": usage.input_tokens,
        "cached_input_tokens": usage.cache_read_input_tokens,
        "output_tokens": usage.output_tokens,
        "cost_usd": round(usd, 6),
        "cost_per_decision": None,           # filled at decision close
    }

# "Tokens per month" cannot be argued with in a review meeting.
# "7.4 cents per triaged ticket" can.

缓存稳定前缀，别缓存问题本身

二、把预算封顶做在网关层

Boomi 在其 2026 年 9 月 2 日的官方新闻稿中把成本治理和治理能力放在一起描述：为每个智能体设置速率限制与财务上限，实时跟踪活跃智能体的用量、性能与 token 消耗，从而识别高效工作负载、标记「消耗大量 token 却没有产出」的智能体，并在未受监控的调用造成财务意外之前重新分配预算。这段描述的工程含义是：封顶要发生在调用之前，而不是账单之后。单次调用上限、单智能体日额度、每分钟调用数这三类限制，就是最有效的护栏。

# assembly.py - cache the stable prefix, never the question
STABLE_SYSTEM = load("prompts/system.md")        # tens of thousands of tokens
TOOLS = load("prompts/tools.json")

def build(question: str):
    return {
        "model": MODEL,
        "cache_control": {"type": "ephemeral"},   # automatic caching
        "system": [{"type": "text", "text": STABLE_SYSTEM,
                    "cache_control": {"type": "ephemeral"}}],
        "tools": TOOLS,
        "messages": [{"role": "user", "content": question}],
    }

# Order matters. Cache breakpoints go on stable prefixes; put volatile
# content (today's ticket, fresh search results) after them.
# Changing tools, images, or thinking settings invalidates the cache.

每周复盘三个数字

三、缓存是唯一能显著改变量级的杠杆

Anthropic 的官方提示缓存文档给出的价格结构很清楚：5 分钟缓存写入的成本比基础输入 token 高 25%，1 小时缓存写入是基础输入的两倍，而缓存命中只按基础输入价格的一小部分计费；一个请求最多可以设置 4 个缓存断点，缓存在至少 5 分钟无活动后过期（Anthropic 文档，Prompt caching）。关键在于顺序：把稳定的系统提示、工具定义与规范文档放在前面并打上断点，把每轮的易变内容放在后面。文档同时指出，改动思考参数、图片或工具设置都会让缓存失效——这也是很多团队「明明开了缓存但省不下来」的原因。

-- cache_hit.sql - is caching actually working?
SELECT date_trunc('day', ts)                                  AS day,
       model,
       SUM(cache_read_input_tokens)                           AS cached_in,
       SUM(input_tokens)                                      AS fresh_in,
       ROUND(100 * SUM(cache_read_input_tokens)
             / NULLIF(SUM(input_tokens + cache_read_input_tokens), 0), 1)
                                                              AS cache_hit_pct,
       SUM(cost_usd)                                          AS spend
FROM llm_calls
GROUP BY 1, 2
ORDER BY 1 DESC;

-- Watch two things: the hit percentage, and whether spend fell when it rose.
-- A rising hit rate with flat spend means your volatile prefix is wrong.

四、可观测性：三个必须看的数字

第一个是「缓存命中率」，可以用响应中的 cache_read_input_tokens 与 cache_creation_input_tokens 计算；只统计 token 总量的话，你会看到账单变化而不知道为什么。第二个是「每决策成本」，按任务族分组；只看月度总量无法归因到任何团队。第三个是「无产出决策数」——消耗了预算却没有留下可复用产物的调用，这类调用通常不是失败，而是提示词或工具设计的问题。三者合起来，才能把「AI 花了很多钱」变成「哪一类决策贵、为什么贵」。

# guard.py - the controls that actually stop a runaway agent
LIMITS = {
    "per_call_max_usd": 0.50,        # a single call should never be large
    "per_agent_day_usd": 75.00,      # hard financial cap per agent
    "per_agent_day_tokens": 2_000_000,
    "per_agent_calls_per_min": 60,
}

def preflight(agent, estimate):
    if estimate > LIMITS["per_call_max_usd"]:
        return {"decision": "reject", "reason": "estimate over per-call cap"}
    if spend_today(agent) + estimate > LIMITS["per_agent_day_usd"]:
        return {"decision": "halt", "reason": "daily cap reached"}
    if rate_ok(agent) is False:
        return {"decision": "throttle", "reason": "rate limited"}
    return {"decision": "allow"}

# Caps, quotas, and throttles. Boring infra; the reason a large agent
# programme does not become a large surprise.

五、这周就能上线的五段代码

第一段是决策级账本：每次调用记录模型、输入/输出 token、缓存读取 token 与成本，并在决策结束时回填「每决策成本」（代码示例 1）。第二段是提示词装配：把稳定前缀标上缓存断点，易变内容放后面（代码示例 2）。第三段是缓存命中率查询（代码示例 3）。第四段是网关护栏：单次上限、日额度、速率三类限制（代码示例 4）。第五段是每周复盘查询：按任务族输出决策数、支出、每决策成本与缓存命中率（代码示例 5）。加起来不到一百行，但它们决定了下个月的账单是否可解释。

-- weekly_finops.sql - the review, in one query
WITH base AS (
  SELECT task_family,
         COUNT(*)                       AS decisions,
         SUM(cost_usd)                  AS spend,
         SUM(cost_usd) / COUNT(*)       AS cost_per_decision,
         SUM(cache_read_input_tokens)
           / NULLIF(SUM(input_tokens + cache_read_input_tokens), 0) AS cache_hit_pct
  FROM agent_decisions
  WHERE decided_at >= CURRENT_DATE - INTERVAL '7 days'
  GROUP BY 1
)
SELECT task_family,
       decisions,
       ROUND(spend, 2)                     AS spend_usd,
       ROUND(cost_per_decision, 4)         AS usd_per_decision,
       ROUND(100 * cache_hit_pct, 1)       AS cache_hit_pct
FROM base
ORDER BY spend_usd DESC;

-- Bring three things to the meeting: cost_per_decision by family,
-- cache hit rate, and the list of decisions that produced no artifact.

六、每周复盘该带哪三个数字

带三个数字进会：按任务族的「每决策成本」、缓存命中率、以及零产出决策清单。然后只问三类问题。哪个任务族的单位成本在上升，是提示词变长了还是检索范围变宽了？命中率下降的模型或功能点，是不是有谁新增了动态内容放在前缀里？零产出决策集中在哪一类任务，应该改提示词、改工具，还是直接下线？这套复盘不需要新的采购，只需要埋点与一个人负责；而没有负责人的成本治理，最终都会退化成月底惊讶。