Agent基准测试的"用户"是第二个模型，24.4%的成功运行违反了用户脚本

一个被忽视的测试盲区

在交互式Agent基准测试中，一个越来越普遍的做法是：让第二个语言模型扮演"用户"角色，控制Agent接收到的信息内容和时机。这种设计使得多轮任务测试成为可能，但同时也引入了一个关键问题——这个模拟用户本身也是测量工具的一部分，却几乎没有人对它进行评分。

UserProxyBench这篇论文正式命名了我在代码审查评估中反复遇到的一种失败模式。论文作者Ashish Jain和Armaan Sandhu在tau-bench系列基础上增加了一个评估层，专门测量"用户"是否完成了它被赋予的任务。

交互式Agent基准测试是相对于静态基准测试（如SWE-bench、MMLU）而言的一类评测范式：被测Agent需要与环境进行多轮交互才能完成任务，环境会对其动作做出反馈。在客户服务、代码审查、工具调用等场景中，环境反馈通常由另一个语言模型生成，以模拟真实用户的响应。

tau-bench是这类基准的代表作之一，由Sierra团队提出，覆盖零售和航空领域的客户服务场景，通过让Agent与模拟用户对话来完成退换货、改签等任务，以数据库的最终状态作为成功判据。

UserProxyBench在此基础上引入的关键变化是：不再只评判Agent是否改对了数据库，而是同时评判扮演“用户”的那个模型是否忠实执行了脚本化的用户剧本，从而把“测量工具本身”纳入了被测量的范围。

User Fidelity Score：测量模拟用户的表现

研究团队提出了"用户保真度分数"（User Fidelity Score, UFS）这一指标，定义为：模拟用户在其私有用户蓝图中满足所有适用标准的回合比例。评分标准由Claude Opus 4.8生成，每个任务包含4到8条原子标准，再由另一个模型GPT-5.6-Sol进行基础性和可达成性审查。

整个测试集覆盖电信、航空、零售、银行四个企业领域，共计375个任务、2141条标准。GPT-5.5作为固定Agent，七种不同的模型轮流担任用户代理，每个任务运行一次。

标准分为四个族：基础性、过早披露、目标偏离、信息遗漏。共19种失败模式，其中18种在实际测试中触发。唯一未触发的是自相矛盾，且该类目标准数为零——这说明分类体系并非人为填充。

**私有用户蓝图（private user blueprint）**指每个任务背后为模拟用户准备的一份隐藏脚本，包含该用户身份、诉求、以及哪些信息应在Agent主动询问后才能透露、哪些信息绝不能提前给出。它之所以“私有”，是因为被测Agent看不到这份蓝图，只能通过对话逐步获取信息，从而保证测试的公平性。

用户保真度分数分母是该蓝图中所有“适用标准”的回合数，分子是模拟用户实际满足这些标准的回合数，因此它衡量的是“剧本执行度”而非“任务完成度”。

**原子标准（atomic criteria）**指粒度细到可独立判定的单条规则，例如“在Agent询问订单号之前不提及订单号”。将标准拆到原子级可以避免复合标准中“部分满足”带来的评分歧义，也便于用确定性脚本或模型逐条核对。

令人不安的数据

仅仅更换用户代理、保持Agent不变，平均任务奖励就波动15.2个百分点。一个基准测试的结果因为一个它不评分的组件而发生变化。

更令人警觉的是：24.4%的成功回合中存在用户规范违规。接近四分之一的通过运行中，"用户"违反了自己的契约。

主要失败模式是过早披露信息。每个代理都收到相同的明确指令："逐步披露信息。等待Agent询问具体信息后再提供。"但它们持续不遵守这一指令。

七个代理的平均UFS从0.599到0.864不等。Gemini-3.5-Flash表现最好，达到0.864；GPT-5.4-mini表现最差，仅为0.599，同时在Agent奖励上也最差（0.644）。Sonnet-4-6的保真度为0.778，奖励得分为0.784——排名因查看不同列而翻转。

奖励分数看不到的失败

这才是对运行评估的人来说最关键的部分。

在成功回合中，过度披露信息的代理导致固定Agent减少了1.06次工具调用和0.26次提问，这一趋势在所有七个代理中一致出现。相同奖励，更少工作量。Agent看起来同样有能力，但实际上执行的是一个被严格简化的任务，因为"用户"替它完成了部分信息收集工作。

在七个代理共同完成的374个任务中，平均Agent轮次与UFS的相关系数达到r=0.955，而任务奖励与UFS的相关系数仅为r=0.594。如果你想确认正在评估的交互是否是你设计的交互，保真度分数能追踪到，而奖励分数基本不能。

这与LLM评判者面临的问题形态相同：当评分者本身是另一个模型，而你又只看最终分数时，相关性误差会隐藏在一个看起来干净的数字里。用户席位是另一个可能发生这种情况的地方。

对AI代码审查评估的启示

大多数代码审查基准测试使用固定的真实PR语料库和人工标注的真值，所以"用户"是数据集，不会行为失常。这是真实优势，也是我持续推动人们回归语料库而非演示的原因。

但一旦转向交互式评估，你又在构建一个模拟器。任何让Agent提出澄清问题、请求重新运行或与合成PR作者协商范围的测试框架，内部都有一个用户代理。

如果要对此评分，代理需要自己的评分列——不是"Agent是否解决了问题"，而是"模拟对手是否执行了被赋予的角色"。

论文中无评判者的探测方法是最值得复制的细节：在电信领域，他们检查了全部658条轨迹与金标准用户写操作，发现54次遗漏写入。其中23次通过了所有适用标准，20次通过了直接相关的标准。LLM评判的标准遗漏了机械检查免费捕获的问题。有金标准操作时用确定性检查，没有时才用模型评判。

**无评判者探测（judge-free probing）**指不依赖任何模型判断、而是用确定性程序直接比对轨迹与金标准操作是否一致的方法。在论文的电信域中，金标准操作是标准用户应当执行的写操作序列（如某时刻更新地址、某时刻确认退款），因此可以用集合比对的方式机械地找出“遗漏写入”。

这种方法的价值在于它把“是否漏做某动作”变成一个可判定的集合运算问题，绕开了模型评判的模糊性与相关性偏差。代价是它要求存在显式的、可枚举的金标准动作；对于开放式对话或主观质量评价，仍需回退到模型评判。因此实践中常见的组合策略是：有金标准操作时优先用确定性检查，仅在无法机械判定时才引入LLM评判。

角色提示无法提供控制力

有一项配套研究值得与上述发现放在一起考量。Persona Following Is Not Selective Control审计了八个黑盒LLM，发现改变角色提示中的一个属性会偏移提示中从未提及的属性的答案。

将用户描述为更爱冒险，他们的颜色选择就会变化。研究者称之为"特质条件补全"：模型将角色视为关于这个人的证据，并将推断出的画像延伸到未指定的领域。

然后他们测试将非目标属性声明为中性是否能修复问题。不能。在五个开源权重检查点中，目标属性仍然在51%到81%的项目中泄漏，即使模型正确报告了声明的状态。

所以"我们用详细角色提示了模拟器"并不能证明角色是唯一在操控它的东西。方向性声明可以通过简单遵循指令来通过，这正是为什么你需要中性状态来观察失败。

**特质条件补全（trait-conditioned completion）**描述了一种现象：当提示词将用户描述为具有某种性格（如“更爱冒险”）时，模型不会把这一属性限制在提示提到的维度上，而是把它当作关于这个人整体性格的证据，进而推断出未提及的关联属性（如颜色偏好、风险承受度）。

这意味着角色提示不构成选择性控制：你无法通过“只改变X、其他保持不变”来隔离变量，因为模型内部的推断会把X泄漏到Y、Z上。

对于基准测试而言，这直接威胁到“只更换用户代理、保持Agent不变”的对照实验有效性——你以为只换了用户模型，实际上同时改变了它泄露信息的倾向、语气、主动性等一连串未被声明的属性。把非目标属性显式声明为中性也无法修复，因为模型仍会从已声明属性中推断未声明属性。

交互式评估报告应有的内容

• 给模拟器评分，而不只是给Agent评分。在奖励数字旁边发布保真度数字。
• 有金标准操作时使用确定性探测，并说明哪些标准由模型评判。
• 列出代理名称和版本。一个你没列出的组件导致15.2分的奖励波动，是没人能复现的结果。
• 固定工具。自托管和BYOK方案让你固定模型，使审查者成为唯一的变量。CodeRabbit标准方案捆绑固定厂商模型且不支持BYOK，而Kodus在每个方案上运行BYOK且零代币加价，模型是配置中的一行而非移动目标。不同的设计选择，不同的可复现性故事。

成本方面也是真实存在的。七个代理的用户侧每次模拟成本从0.0063到0.1841不等。Qwen3.6-35B、Gemma-31B和GPT-5.4-mini在成本-UFS平面上被标记为严格劣支配，意味着有更便宜的选项在保真度上得分更高。"选择满足保真度门槛的最便宜代理"是可以应用的规则而非口号。

作者自己的警示

UFS由LLM评判，且Claude Opus 4.8既编写标准又评分轨迹。只有验证器是不同模型。作者在讨论中指出了这一点，并标记了十任务五十标准的单评分者人工审计、每任务一次运行、服务价格随时间变化等局限。

这是一个诚实的局限性说明，也正是自审盲点所警告的确切设置：生成器和评分者是同一模型是已知的相关性风险，无评判者探测发现54次遗漏写入表明这种效应在这里是活跃的。这没问题。论文的重点是测量缺口，无论保真度数字本身是否需要第二个评判者，这个缺口都是真实的。

同一故事的不同尺度

还有一项由UC Berkeley合作完成、在COLM发表的研究发现：十分钟的AI辅助在工具被拿走后可测量地降低了人们在难题上的坚持度，涉及三次随机实验共1222名参与者。

将这一发现与"减少1.06次工具调用"的结果放在一起看，它们像是同一故事在不同尺度上的呈现。卸载困难部分一直有效，直到你测量剩下的东西。在基准测试案例中，剩下的是一个悄悄变简单的任务的通过分数，而没人能从奖励列看到这一点。

这并不意味着交互式评估是坏的。它意味着用户席位是承重结构，而在大多数人发布数字的测试框架中，它未被测量。给它评分、命名、固定版本，并把保真度数字放在奖励数字旁边——因为那才是读者在看的地方。