Agent 重试的真实成本：你付的是整段上下文，不是一次调用

在传统 HTTP 客户端里，重试是一件便宜的事：请求失败了，再发一次同样的请求，账单只是把那一次调用的成本重复一遍。但在 AI Agent 的循环里，重试的逻辑彻底变了——你重试的不是一次失败的调用，而是产生这次调用的整段对话，而且整段对话的费用你都要再付一遍。

这篇源自 dev.to 的分析提出了一个被几乎所有成本看板忽视的问题：当一个 turn 可能失败时，"调用次数"（calls）就是错误的计费单位。

重试的算术：为什么 3 次尝试可能花掉 7 倍成本

A retry costs the whole context, not the failed call

核心机制其实非常简单，没有任何抽象层挡在中间。作者给出的伪代码揭示了问题所在：

messages = build_turn(task)          # 1x context
for attempt in range(3):
    try:
        return call_model(messages)  # 你为 len(messages) 付费
    except TransientError:
        messages.append(error_about_that_call)
        messages.append("try again")  # 上下文现在更大了

关键在于：每次失败后，代码都会向 messages 追加错误信息和"再试一次"的提示。这意味着下一次调用是在更长的 prompt 上计费的。

作者算了一笔账：三次尝试分别按 1x、2x、4x 的上下文计费，加起来是 7 个单位的开销——而这份工作本来只值 1 个单位。换句话说，重试不是把成本翻倍，而是在一个 turn 内让上下文滚雪球式增长，带来远超直觉的费用。

这正是 HTTP 重试与 Agent 重试的本质差异：前者重发的是"最便宜的那一条请求"，后者重发的是"已经喂给模型的一切"——系统提示、工具结果、历史对话全都要重新计费。

这里的计费逻辑需要一点背景说明。主流大模型 API（OpenAI、Anthropic、Google 等）均按 token 数量计费，且输入 token 和输出 token 分开计价。每次调用时，messages 列表中的全部历史内容都会作为输入 token 被计费——模型无法"记住"上一次调用，每次都必须从头接收完整上下文。这与数据库连接或 HTTP 长连接完全不同，没有任何"会话状态"在服务端保持。因此，当重试循环向 messages 追加错误信息时，下一次调用的输入 token 数量会线性增加，费用也随之叠加。对于包含大量工具返回结果或长系统提示的 Agent，单个 turn 的 token 数可能已经达到数万，此时每次重试的边际成本远高于初次调用。

为什么"成功率"这个指标会掩盖真相

大多数团队的评测看板只有一列核心指标：成功率。但作者用一张推演表格说明了它的误导性：

模型	成功率	每次调用成本	每个正确答案成本
A	0.60	1.0	1.67
B	0.95	1.6	1.68
C	0.99	2.4	2.42

乍看之下模型 A 单次调用最便宜，似乎是最划算的选择。但按"每个正确答案的成本"来算，A 和 B 其实打平，而 C 要贵出一半。作者特别说明，这张表是"推演出来的算术"，不是对真实模型的测量——重点在于它揭示的形状（shape），对任何"失败集中在长 turn 早期"的模型都成立。

作者主张真正值得追踪的指标是每个正确答案的成本（cost per correct answer），因为这是唯一无法通过"更安静地失败"来优化的指标。重试恰恰会在成功率看不见的地方拖垮它：一个失败后又恢复的模型，为那次失败付了钱，而恢复却被记成了一次成功。

「每个正确答案的成本」在经济学上等价于单位产出成本（cost per unit output），是制造业和广告行业的标准效率指标（如 CPM、CPA），但在 AI 评测体系中尚未成为惯例。其计算方式为：总费用 ÷ 成功完成的任务数。这个指标的关键特性在于它同时惩罚"失败率高但便宜"和"成功率高但昂贵"两种极端，迫使工程师在准确性与成本之间做显式权衡，而不是将二者分别优化后再合并判断。值得注意的是，当失败主要集中在上下文较长的 turn（例如多工具调用链的后期步骤），这一指标与简单的"平均调用成本 ÷ 成功率"之间会出现系统性偏差，后者会低估真实开销。

重试还丢掉了它自己产生的证据

这是文章中一个容易被忽略但很有价值的观察。第一次尝试返回 503，是关于那个端点的真实观测——它可能是整次运行里信息量最大的事实。

但重试成功后，干净的回执发了出去，唯一留存的记录只说"一切正常"。结果是：你付了两次钱，却只保留了两个事实里更糟的那一个。

作者因此改变了日志策略——记录重试路径本身，而不只是最终结果：

receipt.attempts.append({
    "n": attempt,
    "error": repr(e),
    "context_tokens": len(messages),  # 你实际被计费的数字
    "outcome": "recovered",
})

其中 context_tokens 才是真正告诉你"这次重试到底便宜不便宜"的字段，而几乎没有任何系统会记录它。

作者没有主张的部分：严谨的边界

值得称道的是，作者对自己论点的边界非常诚实。他提到自己是在别人某个基准测试的评论区争论这个问题，对方指出那是"不同的实验"。作者承认对方说得对：那个基准隔离的是"是否该重试"这个决策问题（针对 API 请求），而这与他的论点无关。

他明确区分了两个问题：

重试安全性（retry-safety）：要不要重试、重试是否安全。
重试 + 上下文的定价（retry-plus-context pricing）：重试到底花了多少钱。

作者坦言自己没有在真实运行上测量过这个结论，上面的图表和表格都是"写明假设的推演示例，而非遥测数据"。他之所以相信这个结论成立，不是因为某个具体 Agent 的行为，而是因为它直接从 API 的计费方式推导而来。这种对数据来源的坦诚，在同类技术博客中并不常见。

一行代码就能带走的实践建议

如果从这篇文章只带走一件事，作者的建议是：在你的重试计数旁边打印 len(messages)。

这行代码不花任何成本，却是"重试很贵"和"知道到底贵多少"之间的分水岭。对于正在构建 Agent 系统、关心推理成本的工程团队来说，这是一个几乎零成本就能落地的可观测性改进。

从更宏观的视角看，这篇文章提醒我们：Agent 时代的成本模型和传统 API 调用有本质区别。当对话上下文成为计费主体，任何在 turn 内部累积上下文的操作——重试、工具调用链、多轮纠错——都可能带来非线性的费用增长。用"调用次数"衡量 Agent 成本，就像用"发送包数"衡量一次视频会议的带宽，单位本身就错了。