引言

在昨天的文章中我们聊到，可观测性让团队第一次能够回答“Agent 到底在干什么”。而当 Agent 稳定跑起来之后，老板们问的第二个问题往往是：“它一个月要烧多少钱？为什么这么贵？”

一个未经优化的多智能体系统，成本可以是其理论下限的 5 到 20 倍。真正的浪费很少来自“模型太贵”，而是来自三类系统性浪费：用大炮打蚊子（简单任务用了顶级模型）、重复计算（同样的检索与推理反复执行）、以及失控的长尾（少数 Agent 陷入自循环，把预算烧穿）。

本文梳理 2026 年生产级的成本工程（Cost Engineering）与智能模型路由（Intelligent Model Routing）实践：如何度量成本、如何归因、以及如何在不牺牲质量的前提下把账单砍掉一大半。

一、先把成本变成可观测指标

你无法优化你无法度量的东西。成本工程的第一步，是把钱变成和延迟、错误率一样的一等指标。

延续可观测性的 Span 模型，我们在每个 LLM Span 上直接写入三组属性：

  • 用量：llm.prompt_tokens、llm.completion_tokens、llm.cached_tokens。
  • 价格：llm.model、llm.unit_price_in、llm.unit_price_out。
  • 归因：agent.task_id、agent.worker_id、tenant.id。
from opentelemetry import trace

tracer = trace.get_tracer("littlecorn.agent")

PRICING = {
    # 单位：美元 / 百万 token
    "flagship-large": {"in": 6.0, "out": 24.0},
    "mid-tier":       {"in": 0.8, "out": 3.2},
    "small-fast":     {"in": 0.1, "out": 0.4},
}

def record_llm_span(span, model: str, usage, tenant_id: str, worker_id: str):
    price = PRICING[model]
    cost = (
        usage.prompt_tokens * price["in"] / 1_000_000
        + usage.completion_tokens * price["out"] / 1_000_000
    )
    span.set_attribute("llm.model", model)
    span.set_attribute("llm.prompt_tokens", usage.prompt_tokens)
    span.set_attribute("llm.completion_tokens", usage.completion_tokens)
    span.set_attribute("llm.cached_tokens", getattr(usage, "cached_tokens", 0))
    span.set_attribute("llm.cost_usd", round(cost, 6))
    # 归因维度：没有归因的成本数据无法驱动任何优化决策
    span.set_attribute("tenant.id", tenant_id)
    span.set_attribute("agent.worker_id", worker_id)
    return cost
关键洞察：把 llm.cost_usd 写进 Span 后，成本就自动拥有了链路、租户、Worker 三个维度的切片能力。你会立刻发现：真正的成本黑洞往往不是最贵的那次调用，而是某个高频低价值环节。

二、成本归因：找出真正的黑洞

一旦成本可切片，就能构建一张成本归因表，按“单位产出成本”而非“总成本”排序：

维度指标说明
任务级单任务成本 (cost per task)端到端一次 Agent 任务的总花费
业务级单成功任务成本总成本 ÷ 成功任务数，惩罚失败重试
用户级单租户成本识别补贴过度或滥用的租户
阶段级规划/检索/生成/反思占比定位可优化环节

实践经验：在多数 Agent 系统中，“反思（reflection）”与“检索（retrieval）重排”两个环节常常占据了 40% 以上的成本，却只贡献不到 10% 的质量提升——这正是路由与缓存最该发力之处。

三、智能模型路由：让合适的模型做合适的事

模型路由是成本工程中回报最高的一招。核心思想：不是所有请求都值得用旗舰模型。2026 年主流的路由策略分为三层。

1. 静态路由（Static Routing）

按任务类型或阶段硬性指派模型。例如规划用旗舰模型（需要强推理），格式清洗用小型模型（只需遵循指令）：

STAGE_ROUTING = {
    "planning":     "flagship-large",   # 强推理，低频，值得
    "tool_call":    "mid-tier",         # 结构化输出，中频
    "summarize":    "small-fast",       # 摘要压缩，高频，便宜
    "format_fix":   "small-fast",       # 纯格式，极高频
}

def pick_model(stage: str) -> str:
    return STAGE_ROUTING.get(stage, "mid-tier")

仅此一招，在典型系统中即可降低 30%~50% 成本，且几乎无质量损失——因为大部分 token 花在了“不需要聪明”的环节。

2. 复杂度感知路由（Complexity-Aware Routing）

用一个小而快的路由分类器（可以是 0.1B 级小模型，甚至规则 + 嵌入相似度）先判断请求复杂度，再决定升级到旗舰模型：

def route_by_complexity(query: str, context) -> str:
    # 极简启发式：越短、越结构化、命中缓存的请求 → 用小模型
    if len(query) < 40 and looks_structured(query):
        return "small-fast"
    # 小分类器预测难度（0=易, 1=难）
    difficulty = router_classifier.predict(query, context)
    if difficulty < 0.3:
        return "small-fast"
    elif difficulty < 0.7:
        return "mid-tier"
    return "flagship-large"

复杂度路由的要点是“够用即止”：宁可偶尔让简单请求走小模型得到略逊但可接受的答案，也不要为 90% 的简单请求支付旗舰价格。用在线评估（见昨日文章）持续监控各路由分支的忠实度，一旦小模型分支质量下滑就自动收敛阈值。

3. 级联路由（Cascading / Fallback）

先用便宜模型回答，并用一个廉价的置信度校验器判断答案是否可靠；不可靠时才升级到更强模型。这是“延迟换成本”的经典权衡：

def cascading_generate(query: str) -> str:
    cheap = call_llm("small-fast", query)
    if confidence_ok(cheap, query):      # 规则 + 小模型自评
        return cheap                     # 约 70% 请求在此终止
    if confidence_ok(mid := call_llm("mid-tier", query), query):
        return mid
    return call_llm("flagship-large", query)

四、语义缓存：消灭重复计算

Agent 系统中大量请求是语义重复的（换个说法问同一件事）。相比精确字符串缓存，语义缓存按嵌入相似度命中，命中率可高出一个数量级：

def cached_answer(query: str, threshold: float = 0.95) -> str:
    qvec = embed(query)
    hit, score, cached = vector_cache.search(qvec, top_k=1)
    if hit and score >= threshold:
        return cached["answer"]     # 命中即零推理成本
    answer = run_agent(query)       # 未命中才真正执行
    vector_cache.upsert(qvec, {"answer": answer})
    return answer

配合提示词缓存（Prompt Caching）——把稳定不变的系统提示、工具定义、少样本示例放在前缀以享受缓存折扣——两项叠加常可节省 20% 以上的直接推理成本。

五、失控长尾与预算护栏

最危险的成本不是“贵”，而是“不可预测”。一个陷入自循环的 Agent 能在一夜之间烧掉数月预算。必须设置多层预算护栏（Budget Guardrails）：

  1. 单任务预算：为每次任务设置 token / 美元上限，超限即强制终止并降级返回部分结果。
  2. 循环探测：监控 Span 深度与重复工具调用签名，连续 N 次相同调用即熔断。
  3. 租户配额：按租户设置日/月预算，超限自动切换廉价模型或排队。
  4. 异常告警：单任务成本超过 P99 的 3 倍时实时告警。
class BudgetGuard:
    def __init__(self, max_usd: float, max_steps: int):
        self.max_usd, self.max_steps = max_usd, max_steps
        self.spent, self.steps = 0.0, 0

    def charge(self, cost: float):
        self.spent += cost
        self.steps += 1
        if self.spent > self.max_usd or self.steps > self.max_steps:
            raise BudgetExceeded(f"spent=${self.spent:.4f} steps={self.steps}")

六、单位经济性：比“总成本”更重要的指标

成本优化的北极星不是“总花费最低”，而是单位经济性（Unit Economics）最优。建议长期跟踪：

  • 单成功任务成本（Cost per Successful Task）：把失败重试计入分母，逼迫团队关注“一次性做对”。
  • 每美元质量分（Quality per Dollar）：Judge 质量分 ÷ 成本，衡量性价比。
  • 缓存命中率与小模型分流比例：两个最直接的成本杠杆。
经验法则：优化顺序永远是 消除浪费 → 缓存 → 路由 → 蒸馏。跳过前三步直接去训练小模型，往往是在优化一个本不该存在的成本。

七、与可观测性、评估体系形成闭环

成本工程无法独立存在，它与前几篇文章的架构天然闭环：

  1. 可观测性提供归因：Span 上的 llm.cost_usd 与归因维度是成本分析的数据基础。
  2. 在线评估提供质量约束：任何降本动作都必须通过质量门禁，避免“省了钱、废了产品”。
  3. 路由与缓存提供杠杆：在质量约束下，动态寻找成本与效果的帕累托最优点。

八、总结与展望

AI Agent 的成本工程，本质上是把“烧钱的黑盒”改造为“可度量、可归因、可调控”的经济系统。通过把成本写进 Span、建立单位经济性指标、实施分层模型路由与语义缓存、并设置严密的预算护栏，团队往往能在不牺牲质量的前提下把账单降低 50%~80%。

展望未来，随着自适应路由策略与价格感知调度器的成熟，Agent 将能够根据实时价格、负载与质量反馈自主选择最优执行路径——让自主智能体不仅聪明，而且经济。