成本与延迟评测
1. 定义与边界
成本与延迟评测衡量 Agent 完成任务所需的模型 token、工具调用、检索、重试、人工接管和端到端耗时。它不是简单看单次模型调用价格,因为 Agent 的成本来自完整执行循环。
2. 为什么重要
一个成功率略高但成本翻倍、P95 延迟不可接受的 Agent,不一定适合上线。成本和延迟会影响用户体验、基础设施预算、并发容量和故障恢复。
3. 核心机制
每个节点都应记录:
- 耗时:start_time、end_time、duration_ms。
- token:input_tokens、output_tokens、cached_tokens。
- 费用:model_cost、tool_cost、infra_cost。
- 重试:retry_count、backoff_time、failure_reason。
4. 工程实现
统一成本事件:
{
"trace_id": "tr_001",
"span_id": "s_model_2",
"component": "model",
"model": "example-model",
"input_tokens": 3210,
"output_tokens": 420,
"latency_ms": 1800,
"estimated_cost_usd": 0.012
}
评测报告同时看成功率和成本:
unit_success_cost = total_cost / successful_tasks
latency_budget_pass = p95_latency_ms <= target_p95_ms
5. 生产实践
- 给每类任务设置延迟预算和成本预算,不要用全局阈值。
- 记录端到端耗时和分段耗时,定位是模型慢、检索慢还是工具慢。
- 对重试设置上限,避免循环导致成本雪崩。
- 评测不同上下文长度、工具数量、检索 top_k 对成本和质量的影响。
6. 常见反模式
- 只看模型调用价格,忽略工具服务和人工接管成本。
- 用平均延迟掩盖 P95/P99 问题。
- 上线前没有压测并发下的工具链路。
- 允许 Agent 无限反思、无限重试。
7. 评测方法
| 指标 | 用途 |
|---|---|
| P50/P95/P99 Latency | 用户体验和容量规划 |
| Token per Task | 模型成本基线 |
| Cost per Successful Task | 成本收益判断 |
| Retry Cost Ratio | 重试消耗占比 |
| Tool Latency Contribution | 定位瓶颈工具 |
| Timeout Rate | 判断稳定性 |
8. 安全与治理
成本异常也可能是安全信号。例如 prompt injection 诱导 Agent 读取大量文档、循环调用工具或导出数据。成本监控应和安全告警联动。
9. 权威资料
- OpenAI Usage and cost docs: https://platform.openai.com/docs/guides/production-best-practices (核对日期:2026-05-09)
- OpenTelemetry metrics: https://opentelemetry.io/docs/concepts/signals/metrics/ (核对日期:2026-05-09)
- Google SRE Book - Monitoring Distributed Systems: https://sre.google/sre-book/monitoring-distributed-systems/ (核对日期:2026-05-09)
17. 主控验收清单
- 是否同时报告 cost per run 和 cost per success。
- 是否按模型、工具、重试、人审拆分成本。
- 是否报告 P50/P95/P99,而不是只看平均延迟。
- 是否把重试成本和循环工具调用单独统计。
- 是否将成本异常接入安全告警。
- 是否按任务类型和风险等级分片。
- 是否比较冷缓存和热缓存。
- 是否记录 prompt、模型、工具版本带来的成本变化。
- 是否设置单 run 硬预算和日预算告警。
- 是否评估降级策略对成功率的影响。
- 是否把人工审核成本纳入高危任务。
- 是否有成本回放报告支撑上线。
- 是否识别少数超长任务对 P99 的影响。
- 是否把超预算样本回流到回归集。
- 是否定期复核价格和模型路由策略。
- 是否对供应商限流导致的排队延迟单独统计。
- 是否区分用户等待时间和后台异步完成时间。
- 是否把超长上下文样本单独列入优化 backlog。
- 是否验证成本熔断后的用户体验和安全结果。
10. 二次精修:成本延迟联合评测
成本与延迟必须和成功率一起看。便宜但失败率高,或者快但频繁转人工,都不是有效优化。
| 指标 | 公式 | 用途 |
|---|---|---|
| Cost per Run | 总成本 / run 数 | 看预算消耗 |
| Cost per Success | 总成本 / 成功任务数 | 看单位有效成本 |
| P95/P99 Latency | 端到端耗时分位数 | 看用户体验 |
| Tool Wait Time | 工具耗时总和 | 定位慢依赖 |
| Retry Cost Ratio | 重试成本 / 总成本 | 发现错误放大 |
| Human Review Cost | 人工时长 * 单位成本 | 评估审批策略 |
11. 评测流程
12. 成本事件格式
{
"run_id": "run_123",
"case_id": "case_001",
"agent_version": "1.8.2",
"model": "gpt-5",
"input_tokens": 5200,
"output_tokens": 850,
"tool_cost_usd": 0.04,
"model_cost_usd": 0.12,
"latency_ms": 6420,
"success": true
}
13. 决策表
| 变化 | 可能结论 | 动作 |
|---|---|---|
| 成本降、成功率不变 | 有效优化 | 扩大灰度 |
| 成本降、成功率降 | 可能过度降级 | 看失败切片 |
| 延迟降、工具错升 | 并发或省略步骤有风险 | 恢复关键校验 |
| 成本升、成功率升 | 可能值得 | 算 ROI 和预算 |
| P99 升高 | 少数任务卡死 | 查队列、慢工具、重试 |
14. Gate 示例
cost_latency_gate:
max_cost_per_success_delta: 0.15
max_p95_latency_ms: 8000
max_retry_cost_ratio: 0.2
min_task_success_delta: -0.02
report_by: ["task_type", "tool_combo", "risk_level"]
15. 安全联动
成本异常可能是攻击信号:注入诱导长输出、循环工具调用、批量检索或导出数据。成本告警应能关联 trace、用户、prompt 版本和工具链路,并在高风险场景触发限流或人工复核。
16. 补充权威资料
- OpenTelemetry metrics: https://opentelemetry.io/docs/concepts/signals/metrics/ (核对日期:2026-05-09)
- Google SRE Book - Monitoring Distributed Systems: https://sre.google/sre-book/monitoring-distributed-systems/ (核对日期:2026-05-09)