做 AI Agent 成本评估时，最常见的误区是把一次用户点击等同于一次模型调用。
实际链路通常更像这样：
用户请求
→ Planner 拆任务
→ Retriever 生成检索词
→ Tool 执行
→ Evaluator 判断结果
→ 失败重试 / 改写
→ Synthesizer 输出最终答案
前台只有一次操作，后台可能已经发生 4～8 次模型请求。此时继续比较“单次 API 调用谁更便宜”，很容易得到错误结论。
用 workflow_id 把成本串起来
每条模型调用日志都应该带同一个 workflow_id：
type ModelCallLog = {
workflowId: string
step: 'planner' | 'retriever' | 'evaluator' | 'synthesizer'
model: string
inputTokens: number
outputTokens: number
latencyMs: number
retries: number
status: 'success' | 'failed'
}
然后以工作流为单位聚合：
costPerSuccessfulWorkflow =
totalModelCost / successfulWorkflowCount
为什么分母必须是“成功工作流”？因为失败的 Agent 任务同样会消耗 Token、调用工具和触发重试。如果把失败任务排除在总成本之外，指标会显得很好看，但无法反映生产环境。
一个反直觉的例子
方案 A：
- 100 个任务花费 18 元；
- 成功 82 个；
- 每个成功工作流约 0.22 元。
方案 B：
- 100 个任务花费 14 元；
- 成功 55 个；
- 每个成功工作流约 0.25 元。
方案 B 的总账单更低，但每个有效结果更贵。若还要人工返工，它的真实成本会继续上升。
四个优化点
1. 按节点选择模型
关键词生成、分类、格式校验不一定需要最强模型。把复杂推理节点和机械节点拆开，通常比全链路使用同一模型更经济。
2. 控制上下文重复
不要让每个节点都携带完整对话历史。为每一步生成最小必要上下文，尤其要关注工具返回的大段文本。
3. 给重试设置预算
重试需要指数退避、最大次数和总耗时上限。否则上游拥塞时，Agent 会用更多请求制造更严重的拥塞。
4. 先小流量验证路由
OpenAI-compatible 接口很方便，但上线前仍要对真实任务做压测，观察成功率、P95 延迟、429 和模型输出一致性。
WoofAPI 可以作为 OpenAI-compatible 方案之一先做非核心工作流验证。部分 GPT 路线在特定“官方输入价格”比较中可低约 95%，但模型、输入/输出计费和实时线路不同，最终以价格页为准。
推荐的验证顺序是：
cURL 最小请求 → 框架接入 → 20～50 个真实任务 → 3～7 天小流量观测
如果你正在用 Dify、LangChain 或自研 Agent，可以留言 COST + 框架名，我后续把成本统计模板整理出来。
