Stop Treating Agent Eval Like a Leaderboard

每个做Agent开发的人，早晚都会碰到同一个问题：到底该把哪个版本推向线上？

换了模型、改过提示词、调了检索工具，跑完一批测试，平均分微动一下。可能某个版本赢了两分，也可能评委周一偏爱某个输出、周二又换了口味。于是你挑了个“平均分最优”的版本——但这往往不是最合理的决策方式。

Agent的表现从来不是简单的“好模型 + 好提示词 + 好工具”就能堆出来。真正有用的问题是：这些组件放在一起，到底配合得怎么样？一个帮小模型加分的提示词，放在强模型上反而可能拖后腿；语义搜索和开放式提示词是绝配，但和严格的步骤式提示词放在一起，效果可能大打折扣。

这篇文章介绍一种小而实用的测试方法。挑几个Agent的杠杆（模型、提示词、工具），让不同的配置在同样的样例上直接竞争。然后让评委只挑出每组中最好的和最差的输出，再用一个排序模型把这些“最好/最差”选择转化成每个配置、每次交互的效用得分。

核心观点：如果你只是孤立地给每个回答打分、排平均分、然后取最高配置，那你就把大量有用的信号浪费了。拿一组成长数据集来做直接对比，这本身就是它的价值所在。而“最好-最差”对比，能迫使评判落在真正有差异的地方。

你可以用Plackett-Luce模型配合因子交互项，把方法用得很深；如果你天生就是Agent优先的开发者，也可以把同样的结构交给一个评估Agent，让它自己跑循环。模型本身不是重点，重点是给下一个工程决策提供更干净的证据。

写给Agent优先的开发者

你不必手动操作这一切。

如果你的日常工作流是：给Agent一个目标、一套测试集、期望的输出、几个候选模型，再用一个评判Agent来审核结果——那这套方法依然适用。它只是给Agent提供了一个更好的评估协议。

可以试试这样提示：
设计一个小型因子网格，覆盖候选Agent配置。对每个测试样例，抽取几个配置独立运行。匿名化所有输出。让评判Agent从每组中选出一个最好和一个最差的回答。拟合一个Plackett-Luce、MaxDiff或等效的效用排序模型。报告哪些配置该上线、哪些该裁剪、哪些值得进一步测试，并解释模型/提示词/工具之间的交互似乎起了什么作用。

这就是对于Agent优先开发的实际价值。Agent可以自己生成候选、跑对比、检查效用结果，并提出下一轮配置方案。人类仍然负责决定什么重要，但系统在每个周期里都能获得更可靠的证据。
当然，在某些情况下，你还是需要深入细节搭出一个可重复的结构，以便完整捕捉高价值决策中的细微差别。

实验设计

任务。 一个Agent流水线从发片图片中提取结构化JSON。发片提取听起来不酷，但它恰恰是那种真正在线上运行的工作。模式固定、正确率至关重要、出错会引发下游问题。因此它是很好的评估场景：Agent要么拿对了字段，要么就是没拿对。

数据集来自HuggingFace上的shubh303/Invoice-to-Json：100份发片文档，每份文档用5个随机配置独立处理，总共499次线上运行（一次因无效被排除）。其中488次输出符合模式要求。

设计。 三个二元因子构成了配置空间，共8个不同的流水线：

两种提示词风格代表了不同的提取理念。系统性规划者偏向规则执行：给Agent明确的执行序列，限制工具使用。上下文跳跃者偏向语义和开放：先让Agent理解文档，然后更自由地提取所需内容。

两个工具都是确定性的桩（stub）。这点很重要：实验测试的不是OCR质量、实时检索质量或解析可靠性，而是Agent在工具接口变化时如何导航工具句柄和上下文执行。

评估协议。 对每张发片，从8个配置中随机抽取5个独立处理文档。然后由一个评判模型（claude-sonnet-4-6）在匿名批次中选出唯一最好和最差的输出。

这就是“最好-最差标度”（Best-Worst Scaling），也叫最大差异或MaxDiff式对比。评判者不需要给每个回答打1-10的虚假分数，只需要回答两个问题：这一批里哪个最好，哪个最差？

平均分能告诉你什么，又漏掉了什么

在引入排序模型之前，先看常规分析会给出什么结果。下面是把所有499次运行的宏观平均分按因子汇总后的数字：

差距很小。如果团队只盯着这张表，可能会合理推断：模型有点影响，提示词几乎没作用，工具选择几乎像抛硬币。

现在看看按配置统计的原始最好-最差胜率：

这比上一张表更有用，但依然不完整。它显示配置7很强，也让配置1看起来像清晰的第二选择，配置4则显得没那么有趣。

缺失的是竞争质量。一个在弱对手组里获胜的配置，不应该和在强对手组里获胜的配置得到同样的认可。打败一个顶级配置意义重大，打败一个弱配置则没什么了不起。

这就是为什么孤立分数和原始胜率都有局限。它们包含了有用信号，但没有充分考虑每个配置面对的对手有多强。

把“最好/最差”选择转化为效用得分

这里使用的模型叫做Plackett-Luce，它属于最好-最差对比模型家族。工作很简单：收集一批“最好/最差”的选择，然后估计每个选项的潜在效用得分。

通俗地说，模型在问：给定每个批次里一起出现的配置们，哪个配置在考虑了对手强弱之后始终被偏好？

这里的关键扩展是效应编码。每个因子水平编码为+1或-1，让模型能够估计两种信号：

主效应 估计某个因子单独看起来有多大帮助。交互效应 估计某个组合的效果比各部分的简单加总更好还是更差。

这个区分是本文的核心。有时你只需换上一个更好的模型就能获得大部分收益；但另一些情况下，模型只有和特定的提示词/工具配对才能发挥最佳效果。每个场景都不同。关键在于把配置作为一个整体来度量，而不是假设各部分可以干净地相加。

结果：有用的信号

特征重要性

第一个问题不是“哪个系数看起来聪明？”而是：哪个变化真正有影响？

在这组特定实验里，最大的信号是模型、提示词和工具之间的三重交互。这不意味着每个Agent评估都会这样。有些系统中，模型选择会占主导；另一些系统中，检索质量或OCR质量可能盖过一切。

但在这里，结果已经足够清晰：单独评估模型、提示词和工具会错失一大部分故事。提示词作为全局主效应很小，但它出现在了交互结构中。这意味着提示词的价值是条件性的——取决于它和哪个模型、哪个工具配对。

配置排名

下面是全部8个配置按Plackett-Luce总效用分的完整排名，每个项都明确列出。β项作用于单个因子（如模型选择），γ项显示因子间的交互（如模型和工具的配合方式）。

一旦考虑了竞争质量，排名就发生了变化。配置1从原始胜率的第二跌到第三。配置4从原始胜率的第四跃升到第二。配置5是个警示案例：它单纯从β项合计看是最强的，但一旦计入交互惩罚，总分跌到零以下。

这正是平均分通常埋没的信号类型。问题不仅在于“哪个组件最强？”，而是“哪个配置在面对强手时能赢？”

运营决策

上线：配置7

配置7 — GPT-5.4-mini / 上下文跳跃者 / 语义搜索 · 总分：+0.431

配置7以+0.431的得分明显获胜。它的单个组件基线不错，但还不足以单独解释这个结果。让它脱颖而出的原因是模型、提示词和工具之间互相强化。在这个设置下，上下文跳跃者和语义工具特别适合GPT-5.4-mini。

运营层面的教训不是“语义工具总是赢”或“开放式提示词总是赢”。教训更具体、更实用：这个配置作为一个整体在起作用。把它作为一个专用工作流上线，但不要假设同样的交互增益在换一个模型后还能保留。

上线：配置4

配置4 — GPT-5.4-mini / 系统性规划者 / 流式表格行 · 总分：+0.196

配置4通过另一条路径达到了+0.196。它将GPT-5.4-mini与系统性规划者和基于流式的工具配对。如果你的架构做流式集成比做语义搜索更简单，那这个配置就不只是一个备选方案——它是真正的生产候选。

这点很重要，因为真实的部署决策要考虑成本、延迟、集成复杂度和可靠性。统计上的赢家不一定是业务上的赢家。模型的价值在于它能给你一张更好的权衡空间地图。

值得深挖：配置1

配置1 — Haiku 4.5 / 系统性规划者 / 语义搜索 · 总分：+0.152

配置1是个有趣的案例。它是唯一一个虽然承担了模型惩罚但仍然为正的Haiku配置。这使它成为有用的证据，而不仅仅是一个陪跑者。

一个合理的解释是互补性。Haiku似乎比GPT更需要结构和工具支持。较弱的模型可能更依赖脚手架和语义工具，而较强的模型可能把同样的脚手架视为摩擦。

这就是为什么组件强度和配置强度不是一回事。一个较弱的组件仍然可以出现在一个强大的配置中——只要周围的组件能补偿它。

裁剪：配置5

配置5 — GPT-5.4-mini / 系统性规划者 / 语义搜索 · 总分：−0.066
单纯β项合计：+0.201（所有配置中最高）。但四个交互项全部为负。

如果只把各部分加起来看，配置5看起来不错：强模型、正面提示词、正面工具。但它的总效用分是−0.066。

这就是陷阱。各部分单独看很诱人，但组合起来的效果却不如预期。在这个设置下，系统性规划者和语义工具在GPT-5.4-mini下似乎产生了摩擦而非杠杆效应。

配置0和3也低于行动线。在线上系统中，可以将这些配置从轮换中移除，保留作为参考案例，把评估预算用在更强或更有信息的竞争者上。

下一步优化什么

特征重要性表回答了一个很多团队跳过的问题：在开始优化之前，哪个杠杆更值得投入精力？

在这个实验中，单独调整提示词是低杠杆操作。提示词在全局层面几乎没有提升。它的价值通过组合体现出来。因此下一步有用的测试不是“再试十种提示词”，而是“在那些提示词可能产生影响的模型/工具配对内部测试提示策略。”

同样的警告适用于模型替换。在某些情况下，换一个更强的模型就能解决大部分问题；在另一些情况下，它反而会破坏让一个更便宜或更小的配置生效的交互结构。这套方法能帮你判断自己处在哪种情形。

最高杠杆的工程工作通常发生在编排层：模型、提示词、工具、检索上下文和评判反馈如何作为一个系统运作。一个小型因子网格设计不会回答所有问题，但它作为第一轮筛选，远比孤立的榜单评分要好。

闭环：把评估结果反馈给Agent

这套方法最有用的版本不是一次性基准测试。

一旦估计出效用，结果就可以反过来喂给Agent系统本身。获胜的配置成为默认工作流。糟糕的配置被从轮换中移除。边界案例成为针对性的后续测试。如果一个路由器需要在模型/提示词/工具组合中做选择，那么拟合出的效用就成了该路由器的上下文，而不是停留在笔记本里的部落知识。

这个循环：测试配置 → 评判输出 → 估计效用 → 上线赢家 → 裁剪失败者 → 更新路由上下文 → 再次测试。

这就改变了评估的角色。它不再只是事后的一张成绩单。它成为了Agent学习循环的一部分。

局限与后续方向

这是一次演示，而不是一篇学术论文。样本量故意较小，工具是桩，置信区间较宽。这对于本文的目的来说是可以接受的：目标是展示直接对比能捕捉多少信号，而不是就这些特定模型、提示词或工具宣称普遍规律。

自然的扩展方向是：把OCR作为第四个因子、测试更广泛的模型家族、明确纳入成本或延迟、运行更多试次以收紧不确定性。同样的结构也可以作为LangSmith中的定期评估器来实现。

更大的要点值得带出去：Agent评估不应该只是给孤立回答打分、排平均分。当配置在共享样例上直接交锋时，你就能更干净地看到什么真正奏效。排序模型只是解释器，真正的价值在于对比结构本身。

所有代码、数据和结果都存放在agent-config-optimization仓库中。评判模型：claude-sonnet-4-6。

数据集：shubh303/Invoice-to-Json（HuggingFace），MIT许可证。

@misc{Invoice-to-Json,
title={Invoice-to-Json: A Document Understanding and Information Extraction Dataset},
year={2024}
}

两个Agent工具都是桩——本实验评估的是决策层，而非检索或解析质量。