阶跃星辰发布了旗舰模型 Step 5 Preview。与强调某个榜单分数不同，这次发布把重点放在一条更贴近生产环境的边界上：在能力、成本、效率和场景覆盖之间寻找“帕累托前沿”。当 Agent 从生成答案转向调用工具、操作系统并完成多步骤任务时，这套衡量方式比单项能力排名更有现实意义。
为什么 Agent 模型不能只看准确率
普通问答通常可以用一次输入、一次输出和一个正确率指标评估。真实世界的 Agent 任务则包含更多变量：模型需要理解目标、选择工具、处理工具返回值、纠正执行错误，并判断任务何时结束。
因此，即使两个模型最终都完成了任务，它们的生产价值也可能明显不同：
- 一个模型调用 5 次工具，另一个调用 20 次；
- 一个模型在 8 秒内完成，另一个需要 40 秒；
- 一个模型成本较高但能覆盖复杂任务，另一个更便宜却只适合固定流程；
- 一个模型成功率高，但容易触发无效操作或产生不可恢复的副作用。
Step 5 Preview 所强调的“帕累托前沿”，可以理解为：如果没有另一个方案能够在不牺牲任何关键指标的情况下全面超过它，那么这个方案就位于候选前沿。前沿上可能同时存在多个模型配置，分别适合高价值任务、低延迟交互或大规模后台处理。
把“能力”拆成可以观测的任务指标
Agent 评估不应停留在“回答看起来不错”。团队可以围绕真实任务记录至少四类指标：
| 维度 | 可观测指标 | 需要警惕的问题 |
|---|---|---|
| 能力 | 任务成功率、约束满足率、恢复成功率 | 只测知识问答，未测工具执行 |
| 成本 | 单任务 token、模型费用、外部 API 费用 | 忽略重试和无效工具调用 |
| 效率 | 端到端延迟、推理轮数、工具调用次数 | 只统计模型首字延迟 |
| 覆盖 | 可完成的任务类型、工具兼容性、长流程稳定性 | 用少量简单样本代表全部业务 |
“成功”也需要由业务定义。例如，客服 Agent 创建退款单时，不仅要检查最终回复，还要验证订单状态、退款金额、审计记录和权限边界。对于会修改外部状态的操作，评测环境应使用沙箱、测试账号或可回滚事务。
动手计算候选配置的帕累托前沿
下面是一个只依赖 Python 标准库的最小评测脚本。它使用模拟结果演示如何同时比较成功率、平均成本和 P95 延迟。接入真实系统时，可以把 RESULTS 替换成离线评测平台导出的数据。
from dataclasses import dataclass
@dataclass(frozen=True)
class Candidate:
name: str
success_rate: float # Higher is better
avg_cost_usd: float # Lower is better
p95_latency_s: float # Lower is better
coverage: float # Higher is better
RESULTS = [
Candidate("step5-preview-default", 0.91, 0.082, 7.4, 0.88),
Candidate("step5-preview-fast", 0.87, 0.049, 4.8, 0.81),
Candidate("baseline-large", 0.89, 0.110, 9.2, 0.84),
Candidate("baseline-small", 0.78, 0.031, 3.9, 0.65),
]
def dominates(a: Candidate, b: Candidate) -> bool:
no_worse = (
a.success_rate >= b.success_rate
and a.avg_cost_usd <= b.avg_cost_usd
and a.p95_latency_s <= b.p95_latency_s
and a.coverage >= b.coverage
)
strictly_better = (
a.success_rate > b.success_rate
or a.avg_cost_usd < b.avg_cost_usd
or a.p95_latency_s < b.p95_latency_s
or a.coverage > b.coverage
)
return no_worse and strictly_better
def pareto_frontier(candidates: list[Candidate]) -> list[Candidate]:
return [
candidate
for candidate in candidates
if not any(
dominates(other, candidate)
for other in candidates
if other != candidate
)
]
for item in pareto_frontier(RESULTS):
print(
f"{item.name:24} "
f"success={item.success_rate:.0%} "
f"cost=${item.avg_cost_usd:.3f} "
f"p95={item.p95_latency_s:.1f}s "
f"coverage={item.coverage:.0%}"
)
运行方式：
python pareto_eval.py
示例中的模型名称和数值只是演示数据，不代表官方测评结论。真正落地时，每条记录最好来自同一批任务、相同工具权限和一致的超时策略，否则成本和成功率无法公平比较。
还可以给评测结果增加安全指标，例如越权操作率和不可恢复错误率。安全指标不宜简单折算成一个加权总分；更稳妥的做法是先设置硬门槛，淘汰不满足要求的配置，再对剩余候选计算帕累托前沿。
从评测结果走向模型路由
帕累托前沿不是为了选出唯一冠军，而是为了支持更细致的部署决策。可以根据任务价值和复杂度建立分层路由：
- 低风险、结构固定的任务优先走低成本配置；
- 长流程或需要多工具协作的任务进入能力更强的配置；
- 涉及付款、删除和权限变更的任务增加人工确认，不把模型能力当作安全授权；
- 首次执行失败后，根据错误类型升级模型，而不是无条件重复请求。
评测集也应持续更新。真实流量中的超时、工具参数错误、循环调用和人工接管案例，都是下一轮回归测试的重要样本。否则模型可能在静态基准上表现稳定，却无法覆盖不断变化的业务环境。
采用前的检查清单
评估 Step 5 Preview 这类面向 Agent 任务的旗舰模型时，可以重点确认以下事项：
- 使用端到端任务成功率，而不是只比较单轮回答；
- 将重试、工具调用和外部服务计入单任务总成本；
- 分别统计平均延迟和 P95/P99 长尾延迟；
- 对高风险工具设置权限、幂等、审计和人工确认；
- 在同一数据集和执行环境下比较候选配置；
- 保留前沿上的多个方案，为不同任务建立路由策略。
Step 5 Preview 的核心命题并不是宣称某个单项指标压倒所有模型，而是把主力模型的竞争带回工程现实：Agent 是否能以可接受的成本和延迟，稳定完成足够广泛的任务。对开发团队而言，真正值得建设的不是一张静态排行榜，而是一套能持续测量这条边界的评测与路由系统。