别只算 Token：Agent 交付成本的六张账单

用户527467561421
0 阅读5分钟

如果模型价格表今天下降了 20%，但你的成本看板只显示“本月 Token 少花了多少钱”，这张看板对 Agent 系统还不够用。

线上真正需要回答的是：100 个任务里，有多少达到同一个验收门槛？为了这些合格结果，一共调用了几次模型、多少工具，等了多久，又花了多少人工时间复核和返工？

近几天，OpenAI 在 GPT-5.6 官方页更新了 Sol 的 API 与 credit 临时降价信息。比降价幅度更值得工程团队注意的是 OpenAI 在另一篇成本文章里采用的口径：不要只算调用价格，要算每个成功任务的完整成本。

先定义成功，再谈便宜

我会把一次 Agent 运行拆成三层：

type Run = {
  runId: string;
  taskId: string;
  attempt: number;
  modelTier: "economy" | "balanced" | "strong";
};

type Artifact = {
  taskId: string;
  version: number;
  uri: string;
};

type GateResult = {
  taskId: string;
  artifactVersion: number;
  passed: boolean;
  reasons: string[];
  reviewer: "machine" | "human";
};

Run 成功，只代表调用结束；Artifact 存在，只代表生成了东西；只有 GateResult.passed 才代表工作达到交付标准。

这三个概念混在一起，模型降价后最容易得到一份“调用成功率更高、可用结果却没有增加”的漂亮报表。

六张账单缺一张，归因都会偏

Agent 工作流中的六张成本账单

第一张是模型账：输入、缓存读写、输出与不同处理档位。第二张是工具账：搜索、浏览器、图片、存储、数据库与第三方 API。第三张是重试账：超时、选错工具、格式失败、上下文缺失以后重复执行的成本。

第四张是复核账。人花七分钟确认事实和权限，往往比一次普通模型调用更贵。第五张是返工账：不是简单重跑，而是带着验收意见生产新版本。第六张是等待账：排队、页面加载、人工审批和外部任务轮询带来的端到端延迟。

可以先不把每一秒等待折成货币，但事件不能丢：

type CostEvent = {
  taskId: string;
  attempt: number;
  kind: "model" | "tool" | "review" | "rework" | "wait";
  amount?: number;
  durationMs?: number;
  stage: string;
  reason?: string;
  at: string;
};

有了 taskId 和 attempt，你才不会把第三次重试当成第三个新任务。

一条 SQL 看出“便宜”有没有传导到交付

假设成本事件与验收结果已经落表：

WITH task_cost AS (
  SELECT
    task_id,
    SUM(COALESCE(amount, 0)) AS total_cost
  FROM agent_cost_event
  WHERE created_at >= :start
    AND created_at < :end
  GROUP BY task_id
), passed AS (
  SELECT DISTINCT task_id
  FROM quality_gate
  WHERE passed = TRUE
    AND gate_version = :gate_version
)
SELECT
  SUM(c.total_cost) / NULLIF(COUNT(p.task_id), 0)
    AS cost_per_successful_task
FROM task_cost c
LEFT JOIN passed p USING (task_id);

这里有一个容易漏掉的条件：gate_version。如果降价前的“合格”要求三条引用，降价后只要求有正文，两个周期的成功任务成本不可比较。

不要全量切换模型，先做风险分流

模型变便宜后，最常见的操作是把默认值整体改掉。更稳妥的做法是按失败代价和可验收性分流。

模型分流后仍需经过统一验收门槛

function chooseTier(task: Task): ModelTier {
  if (task.canAutoVerify && task.reworkCost === "low") {
    return "economy";
  }
  if (task.risk === "high" || task.isPublicAction) {
    return "strong";
  }
  return "balanced";
}

路由之后还要补两条生产规则：

  • 每个档位只有有限的重试预算；
  • 失败后升级一次，而不是在便宜档无限循环。

例如 economy -> balanced -> human，每一步都写入升级原因。否则便宜模型“试五次总有一次能过”的策略，很容易把 Token、省下的钱和人的耐心一起消耗掉。

失败原因要能指导下一次改动

不要只记录 failed=true。至少把失败拆成：

missing_context
wrong_tool
schema_invalid
source_unverified
brand_mismatch
permission_denied
page_state_uncertain

如果主要是 missing_context，换更贵模型未必有用；应该先修检索与输入资料。如果主要是 schema_invalid，工具契约或输出校验更值得改。如果 brand_mismatch 集中出现，品牌资料和验收样例可能不够清楚。

成本优化的对象因此不只是模型，而是整条交付链。

Tipkay 在这件事上的取舍

这也是我们做 Tipkay 时比较在意的一点：岗位 AI 员工不只返回一段生成内容，还要继续处理相应的素材、排版、文件与发布准备，关键动作再交给用户确认。Tipkay 面向经营者和小团队，按实际使用量计费，不使用时不产生消耗。

这并不意味着“按量”天然更便宜。只有把岗位的模型调用、工具动作、失败重试与最终验收串到同一个 taskId 上，团队才能知道一次工作到底花了什么。一个人的生意，也能有一支专业团队；管理这支团队时，同样需要交付口径。

本周就能做的最小改造

选一个重复度高的工作流，先做四件事：

  1. 给任务、尝试和产物版本分配独立 ID；
  2. 写一个不会随模型变化的验收门槛；
  3. 记录六类成本与失败原因；
  4. 用同一批任务对比不同路由，观察成功任务成本、首次通过率和人工复核时间。

强模型不保证一次成功，便宜模型也不等于低质量。真正需要被验证的是：在你的任务、工具和验收标准下，哪条路径能用更少的总成本稳定交付。

下一次价格表变化时，别先问“每百万 Token 便宜了多少”。先打开 Trace，看看一件真正完成的工作便宜了多少。

资料

avatar
文章
阅读
粉丝