评估自动化任务或智能体时，团队习惯把任务成功率当作核心甚至唯一指标。这样做看起来直观：成功就是成功，失败就是失败。但实际项目中，耗时和费用同样影响可用性。比如一个数据处理流程成功率高达98%，平均耗时8分钟，单次成本0.8元；另一个方案成功率95%，平均耗时40秒，单次成本0.03元。如果只看成功率，第一个方案胜出，但放到批量执行场景，第二个方案可能更划算。
为什么单看任务成功率会失真
任务成功率反映的是正确完成的比例，但它不回答完成得有多快、花了多少钱。假设一个客服机器人回答准确率达到96%，但平均响应时间12秒，单次推理成本0.6元；另一个版本准确率93%，平均响应时间1.8秒，单次成本0.08元。在每天几万次调用的生产环境里，后者可以把整体响应时间和月度账单压到更低水平。
更关键的是，成功率本身还可能被样本分布影响。如果测试集里简单任务占比过高，成功率数值会虚高；一些耗时很长、资源消耗很大的复杂任务即使全部成功，也不能说明系统具备良好的综合性能。因此，需要引入效率和成本两个维度，把单一指标扩展为多维评估。
从评估角度看，单指标还容易让优化方向跑偏。团队为了把成功率从95%提到97%，可能会引入更复杂的模型、更长的重试链或更多上下文，结果成功率上升了1到2个百分点，但耗时和成本却翻倍。综合评估可以暴露这种不划算的改进，让资源投向真正影响业务的地方。
效率与成本的量化方法
效率通常用平均耗时、P95耗时或超时率表示。平均耗时直观，但容易被少数极慢任务拉高；P95耗时更适合反映大多数请求的体验。实际做综合评分时，可以先把耗时映射到0到1区间。例如设置一个业务可接受的时间上限，超过上限时效率得分接近0，低于某个理想值时得满分。
成本则需要统计单次任务的平均费用。成本可能包含模型调用费、云服务器费用、数据库读写费用以及人工介入成本。不同系统的成本结构差异很大，因此最好按照实际账单统计，而不是粗略估算。和耗时一样，成本也需要设定上下限，例如预算上限0.5元、理想值0.02元。归一化公式可以采用线性归一化，也可以使用对数压缩，避免极端值对得分影响过大。
这里涉及的归一化逻辑可以用一个小函数实现：normalize(value, min_val, max_val, reverse)。当reverse=True时，数值越小得分越高，适合处理耗时和成本。通过这种方式，耗时、费用和成功率可以放到同一量纲下比较，为后续加权评分做好准备。
加权综合评分与场景化阈值
把成功率、效率和成本归一化之后，需要决定各自权重。权重没有统一标准，取决于业务阶段和目标。离线批处理任务通常对成本更敏感，可以设置成功率为0.5、效率为0.2、成本为0.3；实时交互场景则更看重响应速度，可以设置成功率为0.5、效率为0.4、成本为0.1。关键是让权重公开透明，团队能够根据目标调整。
除了权重，还应加入惩罚项。比如成功率低于90%直接扣分，或者耗时超过120秒、成本超过0.5元再额外扣分。这样即使某个方案平均得分不低，只要触发了硬性限制，就会被拉低排名，避免高风险方案被加权平均掩盖。
场景化阈值也要与业务SLA对齐。若某个流程要求必须在3秒内返回，那么效率上限就不能设成10秒；若预算上限是每千次3元，成本归一化上限就应依据单次平均成本0.003元来计算。把这些约束条件写进评估配置，可以防止评估体系脱离实际。
实现一个综合评估器
下面给出一个Python示例，用来计算包含成功率、平均耗时和平均成本的综合得分。函数会先对耗时和成本做反向归一化，再结合成功率加权，并处理成功率低于基线或超限的情况。
def normalize(value, min_val, max_val, reverse=False):
"""将指标映射到0到1区间，reverse为True时数值越小得分越高"""
if max_val == min_val:
return 1.0
ratio = (value - min_val) / (max_val - min_val)
ratio = max(0.0, min(1.0, ratio))
return 1 - ratio if reverse else ratio
def composite_score(success_rate, avg_time, avg_cost, weights=None, penalties=None):
# 默认权重：成功率0.6，效率0.25，成本0.15
weights = weights or {"success": 0.6, "efficiency": 0.25, "cost": 0.15}
penalties = penalties or {"time_limit": 120, "cost_limit": 0.5, "min_success": 0.9}
time_score = normalize(avg_time, 0, penalties["time_limit"], reverse=True)
cost_score = normalize(avg_cost, 0, penalties["cost_limit"], reverse=True)
score = (success_rate * weights["success"] +
time_score * weights["efficiency"] +
cost_score * weights["cost"])
# 惩罚项：成功率低于基线时按差值额外扣分
if success_rate < penalties["min_success"]:
score -= (penalties["min_success"] - success_rate) * 0.5
elif avg_time > penalties["time_limit"] or avg_cost > penalties["cost_limit"]:
score -= 0.1
return round(max(0.0, min(1.0, score)), 4)
plan_a = composite_score(0.98, 480, 0.8)
plan_b = composite_score(0.95, 40, 0.03)
print(plan_a, plan_b)
在这个示例里，plan_a代表了高成功率但慢且贵的方案，plan_b代表成功率略低但快且便宜的方案。运行后可以看到，plan_b的综合得分通常更高，因为它没有触发额外惩罚，且效率和成本表现突出。团队可以把这段逻辑接到评估流水线里，对版本、模型或流程配置批量打分。
评估器还可以继续扩展。例如加入P95耗时、超时次数、重试次数等指标，或者对不同任务类型分组统计，再计算加权平均。对于波动较大的系统，可以按小时或天取滑动窗口，避免偶然波动影响结论。更重要的是，把评估结果与线上A/B测试数据结合，能验证综合得分是否真的反映了业务收益。