What's in the Box? Distinguishing Acceptable Traces from Unacceptable Ones

盒子里有什么？区分可接受轨迹与不可接受轨迹 | Towards Data Science

Agentic AI

盒子里有什么？区分可接受轨迹与不可接受轨迹

将零散的需求转化为可部署的代理

Doster Esh

2026年10月20日

16分钟阅读

在Google上关注我们

分享

作者图片

这是我关于为代理开发复杂优化框架的系列文章之一。我之前的文章讨论了通过头对头配置比较来识别模型、工具和提示的更优组合。在本文中，我将探讨如何将竞争性评估指标合并为一个有意义的综合评分，以反映多团队目标。结合使用时，团队可以识别需要优化的部分而不引发回归问题。

业务问题优先

最近的一项调查显示，生产代理系统面临不同优先级的拉扯。系统必须准确并为用户提供高质量输出。它需要控制预算。它需要快速运行。有一个关于雇佣承包商的启发式规则：你可以按时、按预算或保证质量……三者中选其二。在最高标准下同时实现三者非常困难，但应先设定最低标准并不断追求进步。

忽视这一点的成本是可衡量的。CLEAR框架报告称，相似准确度的代理成本可能相差高达50倍，且针对准确度优化的代理成本是同等性能的成本敏感替代方案的4.4至10.8倍。该框架还显示，单次运行时代理成功率为60%，但在八次运行的一致性测试中成功率降至25%。这些结果来自一篇预印本论文，但趋势与大多数团队在生产环境中的观察一致。

大多数团队已经具备必要要素：Jira工单、产品经理需求、财务预算、服务等级协议（SLOs）、支持工单、轨迹数据、评估数据集和仪表板。他们通常缺乏的是在目标与代理配置决策之间建立清晰的转换层。

产品团队设定质量下限。

财务团队设定成本上限。

工程团队设定延迟和可靠性阈值。

风险团队设定政策约束。

代理团队将每个配置与相同的标准盒子进行评分。评分不会取代现有工具。它将零散的需求转化为嵌入其中的可优化评估层。

让业务需求设定有意义的阈值，然后用这些阈值指导改进。重点不是抽象地构建最快、最便宜或最好的代理。重点是决定对特定业务问题而言什么是可以接受的，并根据该操作范围评估代理配置。无论团队结构如何，让所有人达成共识：首先确保在盒子范围内，然后在范围内进行优化。

上方图片展示了轨迹损失端点随损失持续增加的定位情况。点从初始的小而蓝色（表示低损失）开始，随着轨迹超出盒子范围逐渐变大并转为红色。右上角代表每个因素在阈值处的归一化“劣度”(1, 1, 1)。该角落的损失被归一化为1。图片由作者提供。

在本文其余部分，我将以通俗语言定义这个盒子，用约40行NumPy代码构建评分函数，比较两个示例模型配置，并展示评分如何集成到LangSmith、Phoenix和DSPy等评估工具中。

···

为什么单独的评估体系并不足够

组件指标仍然不可或缺。它们能告诉你代理为何失败。但如果新模型提升了质量却导致延迟超出客户容忍极限，这种问题应该体现在评分中，而不是每次都要引发新一轮的人工争论。

场景

你有五位评估者与追踪历史相关联。什么因素最重要？是否需要做出任何调整？如果在提示中增加细节以提高可靠性，是否会影响延迟？如果使用更强的模型，预算是否会失控？更具体地说：你的每条追踪成本预算是多少？客户在重新启动或放弃前能容忍多少秒的等待？当提取准确率低于什么水平时，自动化将不再具有价值？

这些商业问题会嵌入到代理开发中，无论你是否主动去思考它们。当代理反复突破这些阈值时，业务机会将流失，开发人员也会陷入尴尬境地。你必须决定每次偏离标准的严重程度：略微偏离成本目标可能是痛苦但可接受的。向交易桌提供不完整或不准确的响应可能构成解雇级错误。关键在于当真正出现问题时，要能生成可衡量的预警。

“我们应测量什么”转变为“我们应优先处理什么”

TDS实践指南已经很好地列举了需要测量的指标。Pratik Rupareliya的12项指标评估框架涵盖了检索、生成、代理行为以及生产和延迟成本。Mukul Sood的离线评估框架覆盖了路由、LLM作为裁判的评分和RAG指标。这两篇都是启动评估套件的优秀快速读物。它们提供了森林中的树木，但列表过于密集，更容易让工程师或代理遗漏某些指标。缺失的是森林视角：一个能判断代理是否完成业务所需工作的整体视图。在生产环境中，这种视角关乎速度和专注度：我们一次只能处理有限的信息量。

如何构建评分体系

下面我将展示如何构建自己的综合评分体系。我将定义变量，展示如何标准化和缩放指标，组合各组成部分并计算一个同时考虑均值和方差的总分。最终结果将捕捉大量商业洞察，并将其转化为能有效指导代理开发的数学表达。

定义边界：阈值、惩罚和优先级

阈值（Tau）定义了你不希望跨越的界限。从最低可接受水平开始设定，但后期可以作为反映持续改进的抱负目标。

惩罚系数（k）定义了跨越阈值后惩罚的陡峭程度。对于法律或隐私防护这类容忍度低的领域，惩罚系数应设置得很高——这些指标无需在边界内优化，但超出边界时需要明显的警示标志。成本和延迟相关的惩罚系数可以设置得较低。

权重（lambda）定义了相对商业优先级，尤其是在边界内。数据和战略将驱动这些权重的设定。初始可设为等权重，随后根据数据和业务需求进行调整。

这些参数使产品、财务、工程和风险团队能够在这些优先级转化为代码之前，公开讨论并达成共识。

每个阈值都应对应一个业务事实。在下面的示例配置中，数字仅为说明性用途：每条追踪记录0.10美元的成本上限可能来自财务预算除以预期流量；5秒的延迟限制可能来自产品分析中用户重新启动或放弃操作的时间点；0.80的质量下限可能来自人类必须重新处理工作的准确度阈值。您的具体数值会有所不同。重要的是有人能解释每个数值的来源。阈值应从保守的起点设定，这意味着这些是可接受范围的真实边界。在此基础上，它们可以逐渐变得更加理想化。

有时代理超出范围是有合理原因的

对于代理来说，容忍度并不总是非黑即白，因为问题的本质通常是不确定的。你可能无法简单地说：任何追踪记录都不能超出范围。聊天对话可能会长时间持续，或提出复杂问题，这些都会合理增加延迟。有时你确实需要使用昂贵的模型来解决复杂问题。

因此不要使用绝对标准。训练代理的方式应如同训练宠物：当它们在围栏的安全范围内时，可以自由奔跑、探索和冒险。当它们跨出边界进入繁忙街道时，菲多就必须拴着狗绳。

然而，你不能仅通过避免不良结果来运作。在明确的边界内，你也希望推动改进并识别围绕合理权衡的优先事项。只要客户满意度保持强劲，与追求完美响应相比，最小化预算更为重要。你可能愿意为保持客户参与度的快速响应支付更多成本。产品决策者会设置反映业务优先级的权重（lambda）。权衡在边界内比边界外重要得多。

良好的阈值、惩罚和权重反映了战略和战术优先级。

它们为高管、产品经理、开发人员和性能工程师提供了一个共同语言，用于讨论期望目标、可行方案和可接受范围。优先级上的分歧可以公开、坦率地进行。团队在会议中解决分歧，而不是在生产环境中。这节省了后续的开发时间和挫败感。

附注：用通俗语言解释数学概念

数学术语 | 通俗解释 ---|--- tau (τ) | 最小可接受结果/边界/阈值 k | 越界带来的痛苦程度/边界的硬度 lambda (λ) | 业务优先级权重 L2范数 | 理想状态的综合距离 阈值角归一化 | 使得分1.0表示"所有因素都达到阈值" RMSLoss | 更倾向于较低的平均损失和较低的方差

在代码中设置配置

text

metric_config = {
"cost": {
"column": "cost_usd",
"direction": "lower_is_better",
"tau": 0.10,
"k": 2,
"lambda": 1.0,
},
"latency": {
"column": "latency_seconds",
"direction": "lower_is_better",
"tau": 5.0,
"k": 2,
"lambda": 1.0,
},
"quality": {
"column": "quality_score",
"direction": "higher_is_better",
"tau": 0.80,
"k": 2,
"lambda": 2.0,
},
}

将每个指标转换为归一化的"不良程度"

成本、延迟和错误指标已经指向相同方向：越低越好。质量指标并非如此，因此需要转换。准确性变为1 - 准确率。归一化后，每个指标都有相同含义：低于1表示在边界内，1表示阈值，高于1表示超出边界。

python

def normalized_badness(series, tau, direction):
"""
将每个指标转换为归一化劣度。
x < 1 表示良好
x = 1 表示处于阈值
x > 1 表示劣度
"""
if direction == "lower_is_better":
return series / tau
if direction == "higher_is_better":
return (1 - series) / (1 - tau)
raise ValueError(f"Unknown direction: {direction}")

对于 "higher-is-better" 分支，预期指标范围在 0 到 1 之间且 τ 小于 1。完美得分对应 0，阈值对应 1，得分为零时对应 1/(1 − τ)，当 τ = 0.80 时该值为 5。这就是图 2 中逆质量轴可以远超 1 的原因。

图 2. 每个轨迹的归一化劣度，按配置分类。圆圈在框内；X 标记在框外。图片由作者提供。

在左侧可以看到，超出框外的轨迹沿着垂直的“逆质量”轴分布……这意味着代理的准确性低于甚至远低于 80% 的阈值。虽然 47% 的轨迹在框内，但仍存在一些较大的遗漏。在右侧，成本和延迟错误占主导地位，但只有少数轨迹得分显著超出框外。

一个可能不太明显但重要的点是，我使用了三个因素来展示这种组合指标，因为这便于以三维框的形式可视化。你可以添加更多指标来满足优先级需求。

构建平滑阈值损失函数

当轨迹安全位于框内时，损失函数应保持平滑；当轨迹穿过边界时，损失函数应逐渐增大。平滑的 softplus 惩罚函数能实现这种行为，同时保持可微分性并兼容优化引擎。

def softplus(z):
"""
max(0, z) 的平滑版本。
softplus(z) = log(1 + exp(z))
"""
return np.logaddexp(0, z)
def threshold_loss(x, k=2):
"""
凸阈值惩罚函数。
x < 1 表示在可接受区域。
x == 1 表示正好处于阈值。
x > 1 表示在可接受区域外。
P(x) = softplus(k * (x - 1))^2
"""
return softplus(k * (x - 1)) ** 2

Softplus 函数在阈值以下接近于零，在阈值以上接近于直线，因此平方后会在框内产生几乎平坦的惩罚，在框外则呈现近似二次的惩罚。在阈值本身，损失值为 (ln 2)² ≈ 0.48（对于任意 k 值），这正是阈值角归一化能够生效的原因。表 2 展示了 k 值如何改变损失函数的形状，以阈值处损失值的倍数形式表示。

表 2. 两种 k 值下相对于阈值（x = 1）的损失值

归一化劣度 x

0.5

0.8

1.0

1.2

1.5

2.0

k = 2

0.20×

0.55×

1.0×

1.7×

3.6×

9.4×

k = 10

≈0×

0.03×

52×

208×

表格还解释了为什么在框内进行权衡更为重要。当 k = 2 时，即使轨迹的代价仅为上限的一半，其阈值损失仍达到五分之一，因此 lambda 可以对所有位于框内的配置进行排序。当 k = 10 时，框内所有轨迹的得分都接近于零，lambda 只衡量违规情况。选择 k 值时需考虑这一点。

将损失函数聚合为配置级目标

单个轨迹得分虽然有用，但配置选择通常基于多个轨迹。RMSLoss 将一组轨迹损失转换为一个目标函数，该函数同时偏好较低的平均损失和较低的方差。这一点非常重要，因为生产问题通常出现在分布的尾部，而不仅仅是均值附近。

Trace 分数呈右偏分布且接近对数正态分布：大多数跟踪值接近零，少数会突然飙升。RMSLoss 对分数取 log(1 + score)，将其转换为接近正态分布的形式，然后利用一个简单公式：RMS² = 均值² + 方差。对于典型分数相同的两个配置，其区分依据是跟踪值的离散程度，离散程度更大的配置会处于劣势。转换回原始分数尺度后，结果会反映在原始分数量级上。

评分代码：aggregate_losses() 和 score_traces()

def aggregate_losses(losses, method="l2_norm"):
losses = np.asarray(losses)
if method == "sum":
return losses.sum(axis=-1)
if method == "l2_norm":
return np.linalg.norm(losses, ord=2, axis=-1)
if method == "max":
return losses.max(axis=-1)
raise ValueError(f"Unknown aggregation method: {method}")
def score_traces(df, metric_config, score_name="threshold_score", method="l2_norm"):
"""
批量对多个跟踪进行评分。
返回一个包含新增列的 df 拷贝：
- <metric>_x
- <metric>_loss
- <metric>_weighted_loss
- <metric>_inside_box
- threshold_score
- inside_box
"""
scored = df.copy()
weighted_loss_columns = []
inside_box_columns = []
lambda_sum = sum(config["lambda"] for config in metric_config.values())
# 阈值角点的参考分数：所有因子的 x_f = 1
reference_losses = []
for metric_name, config in metric_config.items():
value = scored[config["column"]]
# 这会根据阈值 tau 调整损失
x = normalized_badness(series=value, tau=config["tau"],
direction=config["direction"])
# k 调整凸性。更大的 k 表示跨越阈值成本很高
loss = threshold_loss(x=x, k=config["k"])
# lambda 是因子权重，归一化后总和为1
# lambda 在阈值内（未被 k 控制时）尤其重要
lambda_normalized = config["lambda"] / lambda_sum
weighted_loss = lambda_normalized * loss
x_col = f"{metric_name}_x"
loss_col = f"{metric_name}_loss"
weighted_col = f"{metric_name}_weighted_loss"
inside_col = f"{metric_name}_inside_box"
scored[x_col] = x
scored[loss_col] = loss
scored[weighted_col] = weighted_loss
scored[inside_col] = x <= 1
weighted_loss_columns.append(weighted_col)
inside_box_columns.append(inside_col)
# 所有归一化因子等于1时的损失：盒子的角点
reference_loss = threshold_loss(x=1.0, k=config["k"])
reference_losses.append(lambda_normalized * reference_loss)
loss_matrix = scored[weighted_loss_columns].to_numpy()
raw_score = aggregate_losses(loss_matrix, method=method)
reference_score = aggregate_losses(reference_losses, method=method)
scored[score_name] = raw_score / reference_score
scored["inside_box"] = scored[inside_box_columns].all(axis=1)
return scored

def RMSLoss(scores) -> float:
"""
对 log1p(scores) 的均方根进行计算，并映射回原始分数尺度。
由于 Trace 分数呈右偏分布，因此在对数空间进行计算：
RMS² = 均值² + 方差：均值相等时，方差越大越差。
当没有方差时，直接返回原始分数。
"""
log_scores = np.log1p(scores)
rms = np.sqrt(np.mean(np.square(log_scores)))   # = sqrt(mean^2 + var), ddof=0
return float(np.expm1(rms))
summary = (
scored.groupby("config")["threshold_score"]
.agg(traces="size", RMSL=RMSLoss,
mean_score="mean", median_score="median")
)

可视化损失

/think

图3。每条轨迹的加权损失，按配置划分。与图2中的轨迹相同。图片由作者提供。

在此之前，我们查看的是调整后的因子得分（成本、延迟、质量）。现在我们看到的是实际的加权得分。在左侧，几乎没有成本或延迟损失——它始终是一个便宜且快速的模型，但以质量为代价。在右侧，您可以看到框内有更大的分布范围，但框外严重受罚的轨迹更少……主要集中在成本过高的区域。

阅读结果：样本轨迹展示的信息

小型快速模型生成便宜且快速的轨迹，但许多失败情况会沿质量轴上升。大型精确模型有更高的成本和延迟压力，但严重质量失败的情况更少。根据阈值设置，任何一种答案都可能是合理的。这就是关键：得分使权衡关系变得明确。

表3。配置级别摘要

config

traces

RMSL

mean score

median score

log1p std

inside-box rate

large_accurate_model

47

1.04

0.99

0.62

0.36

0.53

small_fast_model

53

1.54

1.50

0.63

0.58

0.47

表4。按因子计算的平均归一化不良度和损失

cost score

latency score

inv. quality score

cost loss

latency loss

quality loss

0.95

0.80

0.55

0.64

0.31

0.08

0.39

1.08

0.02

0.03

1.24

首先查看中位数。对于两个模型，典型轨迹得分几乎相同（0.62 vs. 0.63）。差异在于尾部：小型模型的得分在对数尺度上分布更广（标准差0.58 vs. 0.36），这使其RMSLoss达到1.54，而大型模型仅为1.04。由于质量的权重是成本或延迟的两倍，这些尾部遗漏决定了比较结果。收紧成本上限或提高成本权重，结果可能会反转；这是设定框图的人需要讨论的问题，而不是阅读仪表板的人的判断。

如果一个团队花时间真正理解其用例的商业驱动因素和技术限制，这个单一指标可以作为智能识别代理出现问题的简写方式。它还提供了将商业权衡转化为开发决策的机制。模型选择变得简单一些。首先，模型需要生成大部分位于框内的轨迹。然后您可以优化您认为重要的因素——也许是降低成本。您可以获得异常值识别和更精细的决策制定。

这在代理评估堆栈中的位置

阈值感知的标量化得分充当决策规则。它不会替代组件指标、帕累托分析或您的评估框架。它是一个可以嵌入这些框架中的评分层，可以作为自定义评估器记录，可以在DSPy或Afnio等框架中进行优化，或在LangSmith、Phoenix、Braintrust、DeepEval、Weave或MLflow中跨轨迹进行比较。轨迹存储保留原始事件。评估器生成组件指标。阈值感知得分将这些指标转化为决策规则。

我还没有深入讨论优化引擎和技术，但“框得分”具有良好目标函数的特征（单调性、凸性、可训练性）。

表5。框架术语对照

文章概念

LangSmith

Braintrust

Phoenix

Weave

MLflow / DeepEval / DSPy

追踪 / 运行

运行 / 追踪

追踪 / 日志

跨度 / 追踪

调用 / 追踪

运行 / 测试用例 / 程序运行

组件指标

评估器 / 反馈键

评分器

评估 / 注释

指标 / 自定义指标 / DSPy 指标

配置元数据

标签 / 元数据

元数据

跨度属性

属性

参数 / 标签

标量化阈值分数

自定义评估器或反馈指标

自定义评分器

客户端评估作为注释记录

评分器输出

用于比较/优化的指标

配置级聚合

实验摘要评估器

实验对比

数据框 / 分组注释

评估摘要

运行摘要 / 资产 / 优化器目标

为什么这不仅仅是一个随意的公式

近期研究和行业文章越来越一致认为智能体评估是多维的。我们已经经历了第一波关于大规模原型设计中token消耗的炫耀阶段……现在是时候在可衡量的更少消耗下获得更高性能了。我们需要系统来做出可重复且盈利的决策。

路由论文表明这并非哲学偏好：现实系统已经在成本-质量-延迟的权衡下优化模型/工具选择。许多团队缺失的步骤是将这些权衡转化为单一的部署感知决策规则。

这些权衡的规模并不小。RouteLLM 报告在某些情况下成本降低超过 2 倍而不会损失响应质量。BEST-Route 选择模型及从该模型采样的响应数量，报告成本降低高达 60%，性能下降不足 1%。近期预印本 AgentRouter 对多步骤智能体工作流的每一步进行路由，报告成本降低 72% 同时保持 97.3% 的前沿质量。对于多智能体系统，ProtocolBench 发现通信协议选择本身可使完成时间变化高达 36.5%。对于中型公司而言，这可能意味着数十万的节省，或使预算效率翻倍。这些是英雄级的数字。

每个系统都必须决定权衡曲线上的哪个点足够好。这个决策就是方框中记录的内容。

如何与团队采用该方法

• 从三个指标开始。
• 与产品、财务、工程和风险部门开会设定阈值。
• 评估最近的追踪记录。
• 检查失败案例。
• 创建新配置并优化提示、工作流、内存或模型。
• 仅当商业含义变化时调整阈值。
• 使用标量分数进行选择，使用组件指标进行诊断。
• 在元数据中与智能体配置一起版本化评分配置文件（每个 τ、k 和 λ），这样评分变化可以追溯到智能体变更或策略变更。

结论

留在框内不是将智能体开发简化为一个魔法数字。这是为团队提供一个共享的操作语言。数学是智能体和人都能理解的语言。定义“足够好”的含义。惩罚越界追踪。优化。部署。

包含示例追踪、评分函数和图表的笔记本在 GitHub 上。如果你用自己的阈值尝试这个方法，我很想听听你的框最终出现在错误位置的案例，以及需要什么才能移动它。

关于我

Doster Esh – 由AI驱动的数据科学家，曾担任电力交易员和量化分析师。我致力于寻找结构化复杂决策空间的方法，将统计学与机器学习方法结合到AI代理中，并将这些想法转化为实用工具。您可以通过www.knowledgealgorithms.com找到我。

参考文献

[1] Mehta, S. (2025). 超越准确性：评估企业级智能体AI系统的多维框架. arXiv:2511.14136. https://arxiv.org/abs/2511.14136

[2] Yehudai, A., Eden, L., Li, A., Uziel, G., Zhao, Y., Bar-Haim, R., Cohan, A., & Shmueli-Scheuer, M. (2026). 基于LLM智能体的评估综述. 计算语言学协会年会论文集：ACL 2026, 26690–26714. https://aclanthology.org/2026.findings-acl.1330/

[3] Rupareliya, P. (2026, 5月13日). 构建生产级AI智能体的评估框架：来自100+部署的12个指标体系. Towards Data Science. https://towardsdatascience.com/building-an-evaluation-harness-for-production-ai-agents-a-12-metric-framework-from-100-deployments/

[4] Sood, M. (2026, 3月24日). 生产就绪的LLM智能体：离线评估的综合框架. Towards Data Science. https://towardsdatascience.com/production-ready-llm-agents-a-comprehensive-framework-for-offline-evaluation/

[5] Ong, I., Almahairi, A., Wu, V., Chiang, W.-L., Wu, T., Gonzalez, J. E., Kadous, M. W., & Stoica, I. (2024). RouteLLM：基于偏好数据的LLM路由学习. arXiv:2406.18665. https://arxiv.org/abs/2406.18665

[6] Ding, D., Mallick, A., Zhang, S., Wang, C., Madrigal, D., Hipolito Garcia, M. D. C., Xia, M., Lakshmanan, L. V. S., Wu, Q., & Rühle, V. (2025). BEST-Route：具有测试时最优计算的自适应LLM路由. 第42届国际机器学习会议论文集（ICML），PMLR 267, 13870–13884. https://proceedings.mlr.press/v267/ding25d.html

[7] Paul, R. K., & Nandy, S. (2026). AgentRouter：面向成本优化多步骤智能体工作流的异构模型路由. arXiv:2609.22951（预印本）. https://arxiv.org/abs/2609.22951

[8] Du, H., Su, J., Li, J., Ding, L., Yang, Y., Han, P., Tang, X., Zhu, K., & You, J. (2026). ProtocolBench：应选择哪种LLM多智能体协议？第43届国际机器学习会议论文集（ICML），PMLR 306, 26649–26695. https://proceedings.mlr.press/v306/du26l.html