路由器到底怎么评？Agent-as-a-Router评估体系详解：AvgPerf、CumReg与Perf/$指标-平芜编程栈

【免费下载链接】agent-as-a-router

The official implementations of Agent-as-a-Router: Agentic Model Routing for Coding Tasks.

项目地址：https://gitcode.com/gh_mirrors/ag/agent-as-a-router

Agent-as-a-Router（ACRouter）是一个"以智能体做路由器"的开源项目：它把多个大模型当作后端，按任务动态选择最合适的模型。那么一个模型路由器到底好不好？只看"任务通过率"远远不够——你还得看它花了多少钱、离最优选择差多远。本文带你完整理解 Agent-as-a-Router 的评估体系：核心指标AvgPerf、CumReg、Perf/$分别是什么、怎么计算、又该如何读懂官方评测表。

为什么评估路由器不能只看通过率？

同一个编程任务，不同模型的表现和价格差异巨大：有的模型解题快但便宜，有的模型能力强但价格贵好几倍。路由器的工作，就是给每个任务挑一个"性价比最优"的后端模型。

因此，官方评估不只关心"做对了多少题"，而是同时追踪质量、成本、遗憾值（regret）、单位成本收益四个维度。这套口径定义在评测配置 router_eval.md 中，是理解全部评测表的钥匙。

评测数据底座：CodeRouterBench 与 OOD176

所有指标都算在两套任务流上（数据规模详见 experiments.md）：

任务流	规模	说明
CodeRouterBench ID	9,999 个任务 × 8 个模型	分布内（in-distribution）编码任务，主报告用 2,919 题的测试集
OOD176	176 个任务 × 8 个模型	当前公开的分布外（out-of-distribution）评测集，由 Old112 + 过滤后的 New64 统一构建

8 个后端模型（如 claude-sonnet-4-6、claude-opus-4-6、kimi-k2.5、gpt-5.4、MiniMax-M2.7 等）及其美元定价元数据记录在 models.json，成本由此推算，无需真实调用 API 即可离线复现全部指标。

三大核心指标逐个拆解 🎯

AvgPerf%：路由器有多"准"？

AvgPerf% = 任务平均表现百分比，直观理解就是"这套路由策略下，任务的平均解决率"。例如 ACRouter 在 OOD176 上 AvgPerf = 73.30，表示 176 个任务平均有 73.3% 被解决。它是质量维度，越高越好，也是和其他方案横向对比的第一列。

CumReg：离"上帝视角"还差多远？

CumReg（Cumulative Regret，累计遗憾值）衡量路由器与"成本感知 Oracle"之间的差距。计算逻辑在 ood_repro.py：

每个任务的奖励定义为：reward = perf − 0.1 × cost（成本权重 0.1 见 constants.py），即"解出题目得分、花多少钱扣多少分"；
Oracle 假设每个任务都能选中"奖励最高的那个模型"，它的遗憾为 0；
路由器每做一个任务，实际奖励与 Oracle 最优奖励的差值累加，就是 CumReg。

越低越好，Oracle 恒为 0。它回答的问题是：这个路由器在"选模型"这件事上，总共浪费了多大潜力？比如 ACRouter 在 OOD176 上 CumReg 仅 15.9，而一些静态训练策略高达 95 以上，差距一目了然。

Perf/$：每一美元买到多少表现？

Perf/$ = AvgPerf% ÷ 总成本（$Total），衡量的是成本效率，越高越好。这个指标能揭示一个有趣现象：某些"Always-便宜模型"策略 Perf/$ 数值很高，但那是因为分母（成本）太小、且 AvgPerf 也低——单看任何一列都可能误判，三个指标必须放在一起读。这正是官方坚持"质量 + 成本 + regret + Perf/USD 同时记录"的原因（见论文工件声明 PAPER.md 中的claim:cost-aware）。

如何读懂官方评测表？附真实示例

把 20+ 个路由器放到同一张表里对比，就是官方的 ood176_baseline_table.md。节选几行感受一下：

路由器	ID AvgPerf%	ID CumReg	OOD AvgPerf%	OOD CumReg	OOD Perf/$
Oracle（理论上限）	57.00	0.0	78.98	0.0	2.86
ACRouter（本方案）	49.98	205.5	73.30	15.9	0.85
LinTS（在线老虎机）	46.48	307.4	53.98	46.4	1.05
Always-Opus 4.6（单模型）	43.83	387.1	63.64	43.7	0.33
Random（随机选择）	38.75	533.6	40.34	70.9	0.73

读表三步法：

先看 AvgPerf%：ACRouter 在 OOD 上 73.30%，仅次于 Oracle（78.98%），明显领先所有单模型和基线方案；
再看 CumReg：15.9 接近 Oracle 的 0，说明它选模型时"几乎没有选错"，而随机策略高达 70.9；
最后看 Perf/$：ACRouter 为 0.85，低于一些低分基线——这是"用更高的绝对质量换取成本效率"的权衡，AvgPerf 才是主目标。

完整逐路由器明细可查机器可读版本 ood176_baseline_metrics.csv，参考输出位于outputs/baselines_ood176/。

辅助指标：$Total、rAcc 与 Apply_ok%

主表之外还有三个"体检指标"（定义见 router_eval.md）：

$Total：后端总花费（美元）。ACRouter 跑完 ID 2,919 题花费 $22.31，OOD176 花费 $86.72；
rAcc：路由器选择与 Oracle 最优选的一致率，验证"选模型"本身是否可靠；
Apply_ok%：补丁能否成功应用到代码库的比例，是 OOD 流特有的工程化验证信号。

ACRouter 在 OOD176 上使用的具体策略是"k=2 验证-升级级联"：先按 MiniMax → Kimi → GPT-5.4 → GLM-5 的顺序尝试，未解决且至少两次廉价尝试能成功应用补丁时，才升级到 claude-opus-4-6，实现逻辑见 ood_repro.py。

自己动手：离线复现整套评估

整个仓库无需 API Key，即可复现所有数字 🛠️：

# ID 分布内复现（对应 AvgPerf=50.14, CumReg=202.0, $22.31, Perf/$=2.25） python scripts/run_id.py --output-dir outputs/tmp/id # OOD176 ACRouter 复现（对应 AvgPerf=73.30, CumReg=15.9, $86.72, Perf/$=0.85） python scripts/run_acrouter_ood176.py --output-dir outputs/tmp/acrouter_ood176 # 全部基线 + 论文风格对比表 python scripts/run_baselines_ood176.py --output-dir outputs/tmp/baselines_ood176

如果你有自己的模型或自己的评测任务，可以用配置驱动的管线 run_pipeline.py 评估：只需提供tasks.jsonl+model_results.jsonl和模型定价，脚本会自动算出同一套 AvgPerf / CumReg / Perf/$ 指标，示例配置见 eval_pipeline.example.json。数据格式要求可在 score_matrix.md 中查阅。