评估 AI 工作流，应按验收任务计账

HTTP 200、JSON 能解析、业务结果可用，是三件不同的事。比较 AI 工作流时，如果把每次接口返回都算成成功，重试越多，报表反而可能越好看。作者主张：按最终验收通过的任务计数，再把相关尝试的费用一起算进去。

这套方法适合评估带重试的 AI 调用，但原文没有模型对比实验。作者供职于多模型 API 平台 Tokatlas，文章由其指示 AI agent 生成，示例也是虚构数据。它提供的是核算方法，不是选型榜单。

一次任务重试三次，到底算几次成功

假设一个任务失败后重试两次，最后得到一个合格答案，它只贡献一个通过验收的任务，不能记成三次成功。

要把账算清楚，日志应当每次调用占一行：同一个任务沿用稳定的 job_id，每次尝试分配唯一的 attempt_id。HTTP 状态、解析状态和业务验收结果分别记录。

验收标准还必须先定，再比较供应商。例如发票提取任务，可以要求所有必填字段都与已标注的原始材料一致。能返回合法 JSON，只能说明格式过关，字段内容仍可能错误。

接口调用成功，不能直接当成业务任务完成。

费用不知道，就不能当成零

超时、错误响应、缺少 usage 字段，甚至客户端取消连接，都不能证明供应商没有收费。作者建议采用含义明确的费用来源，例如供应商账单；拿不到就保留未知。

下面的代码按任务去重统计验收结果，同时保留每次尝试的费用，避免把未知金额藏进平均值：

from decimal import Decimal

def summarize(attempts):
    seen = set()
    jobs, accepted = set(), set()
    known_cost = Decimal("0")
    unknown_costs = 0
    for a in attempts:
        key = a["attempt_id"]
        if key in seen:
            raise ValueError("duplicate attempt_id")
        seen.add(key)
        jobs.add(a["job_id"])
        if a["accepted"] is True:
            accepted.add(a["job_id"])
        raw = a.get("billed_cost")
        if raw is None:
            unknown_costs += 1
        else:
            cost = Decimal(str(raw))
            if not cost.is_finite() or cost < 0:
                raise ValueError("invalid billed cost")
            known_cost += cost
    complete = unknown_costs == 0
    return {
        "jobs": len(jobs),
        "attempts": len(attempts),
        "accepted_jobs": len(accepted),
        "acceptance_rate": len(accepted) / len(jobs) if jobs else None,
        "known_cost_subtotal": str(known_cost),
        "attempts_with_unknown_cost": unknown_costs,
        "cost_per_accepted_job":
            str(known_cost / len(accepted)) if complete and accepted else None,
    }

rows = [
    {"job_id":"A", "attempt_id":"A-1", "accepted":False, "billed_cost":"0.01"},
    {"job_id":"A", "attempt_id":"A-2", "accepted":True,  "billed_cost":"0.02"},
    {"job_id":"B", "attempt_id":"B-1", "accepted":False, "billed_cost":None},
]
print(summarize(rows))

关键是 if complete and accepted else None：只有费用完整且至少一个任务通过验收，才计算单位合格任务的 API 成本。

示例中有两个任务、三次尝试、一个合格任务。已知费用小计为 0.03，但还有一次费用未知，所以单位合格任务成本保持空值，不能拿 0.03 当最终结果。这些金额假设使用同一种货币，与 Tokatlas 定价无关。

什么条件下，这个指标才有可比性

作者给了三个约束。

首先，比较双方要使用相同输入、相同验收规则和相同重试上限。失败尝试，以及始终没产出合格结果的任务，都必须纳入。

其次，货币和费用范围要一致，不能把单次调用费用与整月账单混算。代码假定输入日志已经满足这个条件，并未替你检查。

最后，要明确什么时候结账。仍在运行的任务批次应排除，或明确标为未完成。超时调用后来补到账单，应更新原来的尝试，不能再增加一条调用记录。

这个指标只衡量 API 成本。人工审核、排队、托管和任务延迟，还需要另外记录。

我的判断

我认可它把比较单位拉回「验收通过的任务」。只看 token 单价，确实无法回答完成一件事要花多少钱；只看 HTTP 成功率，也无法判断答案是否可用。

局限在于验收规则。发票字段可以对照标注，代码生成是否合格却常常还涉及需求理解和人工判断。原文没有说明如何处理这类验收，也没有给出实际供应商的对照数据，不能据此认定某种模型更省钱。

它适合作为选型账本的一部分。价格、验收率和完成时间仍要一起看，尤其不能把更高的人工审核负担藏在较低的 API 费用后面。

能拿来做什么

• 给 Node 服务中的 AI 调用增加任务与尝试两层标识，把重试费用归回原任务，并分别记录响应、解析和验收结果。
• 比较 AI 编程 API 前，先准备一小组脱敏或合成案例，写明验收规则与重试上限，再运行同一组测试。
• 对接供应商时，除了询问 token 价格，还要确认响应和用量信息能否支持逐次对账；费用未知时保留空值，后续补齐。