200个智能体、201万次工具调用：谁在为你的AI买单？

我们团队上个季度上线了 200 个内部智能体。每月的账单高达 2,011,438 次工具调用。财务部门问了那个老问题：“哪个模型在吞噬我们的预算？”

直觉上的答案——“显然是前沿模型”——是错误的。而它之所以错误，揭示了智能体系统实际花费金钱的方式中一些有用的信息。

反直觉的部分

在智能体循环中，大部分 Token 消耗并不发生在你想象中的硬核推理步骤里。而是发生在那些枯燥的中间环节：

• 对模型已经看过的文档进行重新格式化的 60 行检索代码，
• 两个工具之间的 JSON 数据重塑，
• 每次行动前触发的“下一步该用哪个工具”分类器，
• 压缩无人阅读转录内容的摘要生成过程。

这些都不需要前沿模型。它们需要一个模型——一个便宜的、被路由到特定子任务的模型。但整个循环都被硬编码为使用一个“默认”模型，导致每个子任务都支付了前沿模型的价格。

我们进行了测量：大约 80% 的账单是由那些在较小模型上以约 1/20 的成本就能满足质量要求的子任务产生的。

这是一个路由问题，而不是提示词工程问题

你不能用更巧妙的系统提示词来解决这个问题。你需要让路由器能够看到子任务的边界。

与其设置 agent.llm = frontier_model，不如让每个子任务声明它的需求：

subtasks:
  retrieve_context:
    min_capability: embedding-lookup
    route_to: small-retriever      # 便宜，无需推理
  classify_next_tool:
    min_capability: light-classification
    route_to: mini-classifier      # 微小，快速
  synthesize_answer:
    min_capability: frontier-reasoning
    route_to: frontier-model       # 只有在这里我们才付费

路由器会选择能满足 min_capability 的最便宜模型。智能体的行为不会改变。但账单会。

flowchart LR
    A[Sub-task emitted] --> R{Router}
    R -->|embedding-lookup| S[small-retriever]
    R -->|light-classification| M[mini-classifier]
    R -->|frontier-reasoning| F[frontier-model]
    S --> L[per-step ledger]
    M --> L
    F --> L
    L --> C{PDPA-aligned?}
    C -->|yes| OK[serve in SG-hosted region]
    C -->|no| B[route to compliant region]

按步骤的成本归因是缺失的一半

如果你看不到成本，路由就毫无帮助。大多数团队只有一个费用项：“LLM”。这掩盖了问题——财务部门只看到一个数字，而不是决策依据。

将成本关联到每个子任务，而不是每次请求：

def route(subtask):
    model = cheapest_that_clears(subtask.min_capability)
    cost = price_per_1k[model] * estimate_tokens(subtask)
    ledger.log(subtask.name, model, cost)   # 按步骤记录，而非按请求
    return model

现在，账单可以按能力层级读取：“检索 $X，分类 $Y，合成 $Z。”当合成成本激增时，你知道应该攻击哪个子任务——而不是责怪哪个模型。

成本和合规性在同一层收敛

让团队惊讶的是，路由器也是必须实施数据驻留规则的地方。某些子任务涉及受监管的客户数据，因此即使有更便宜的模型在其他地方可用，它们也必须保留在与 PDPA 对齐的新加坡托管区域中。

因此，削减账单的同一层路由也执行了司法管辖区限制。成本优化和合规性不再是单独的会议——它们变成了一个配置块。

这才是真正的突破：路由层不是你必须忍受的基础设施。它是你将成本和约束表达为代码的地方。

留给你的问题

如果你将智能体循环中的每个子任务映射到能满足其质量门槛的最便宜模型，你当前的账单中有多少比例还能幸存？

没有要推销的工具，没有要点击的链接。只是这一点：大多数智能体账单实际上是伪装成其他东西的路由账单。