跳到主要内容

用于多轮 Agent 评估的合成用户:当你的测试固件需要“反击”时

· 阅读需 11 分钟
Tian Pan
Software Engineer

单轮评估擅长一件事:在用户输入一次后便离开的任务中对模型进行排名。但对于你实际发布时会遇到的故障模式,它们毫无用处。比如在第三轮对话时就忘记用户目标的 Agent;在礼貌的重复询问下(“你确定吗?能再检查一下吗?”)就屈服并推翻正确答案的 Agent;或者在第四轮对话时还在问第二轮已经问过的澄清问题的 Agent,因为它读不懂自己的历史记录。这些问题都不会出现在对话仅进行一次交互就结束的基准测试中。

你可以进行真实用户评估,但每次发布都需要耗费数百小时的人工审查,而且问题往往在发布三周后才浮出水面。或者,你可以构建由 LLM 驱动的合成用户——具有人物角色 (Persona)、目标、耐心和放弃阈值的机器人——每晚针对待选 Agent 运行数千次对话。这是 τ-bench、AgentChangeBench 以及 2025–2026 年大多数生产级对话评估方案背后的方法。这种方法行之有效,直到它失效为止,而它失效的方式往往能让你更深刻地了解你的评估流水线,而不是合成用户本身。

合成用户究竟需要具备什么

一个有用的合成用户并非只是“一段写着‘你是一个客户’的提示词”。它由四个要素组成,在模拟器成为 CI 中的核心环节之前,必须明确指定每一项。

人物角色 (Persona)。 人口统计学和行为属性——领域专业知识、词汇风格、情感基调、提供未被要求的细节的意愿。人物角色应该从真实的生产流量集群中提取种子,而不是凭空想象。例如,AgentChangeBench 定义了五个具有明确行为特征、交互风格和协作水平的人物角色——并不是因为五个是正确数字,而是因为一个显然是错误的。

目标。 模拟用户试图完成的任务。目标必须足够具体,以便进行评分(例如:取消订单 #4421 并要求退款至原支付方式),而且不能直接告诉 Agent 目标——必须通过对话引导出来。τ-bench 的评估之所以有效,正是因为它将对话结束时的数据库状态与标注的目标状态进行对比,而不是看 Agent 的自我报告。

耐心预算。 用户在感到挫败之前能容忍多少轮对话。他们如何表达这种挫败感——回复更简短、重复自己的话、威胁要离开。真实用户的耐心是有限的,而一个过于耐心的模拟器会导致故障模式:流水线会将 Agent 评为“最终正确”,但走的是一条真实客户绝不会容忍的路径。

放弃阈值。 用户何时放弃。这应根据生产环境的流失曲线进行校准——如果你有 40% 的真实用户在三次未得到解答的澄清问题后选择放弃,那么你的模拟器也应该这样做。如果没有这一项,你就是在针对一个能礼貌容忍 Agent 任何折磨的群体进行优化。

如果这四个要素缺失了三个,那么你拥有的不是用户模拟器,而是一个戴着某种角色的 LLM 独白。

捕捉真实故障的架构

最有用的合成用户流水线看起来更像是一个小型分布式系统,而不是一个提示词模板:

  • 角色库: 从真实流量集群中提取种子。根据意图、词汇和轮次长度分布进行集群化,然后按比例采样人物角色。这保证了“啰嗦且困惑的初次使用者”在评估覆盖范围中的比例与他们实际出现的频率一致。
  • 目标注入: 模拟用户真实的到访情况。真实用户不会在第一轮就宣布他们的目标(“我想取消订单 4421 并获得退款”)。他们往往表达得很模糊(“嗨,我上周买的东西有点问题”)。编码这种延迟会迫使 Agent 经历它原本会跳过的澄清环节。
  • 耐心和放弃采样: 每次对话都会从根据生产日志校准的分布中采样耐心预算和放弃阈值。达到阈值的对话被判定为用户放弃,而不是 Agent 失败——Agent 的得分会反映出这一点。
  • 轨迹级评判器: 不要对每一轮的质量评分并取平均值。要对整个对话进行评分。用户达到目标了吗?Agent 是否自相矛盾?它是否问了两次同样的问题?对话结束时用户的情绪状态是变好了、变坏了还是没变?这些是轨迹的属性,而不是任何单轮对话的属性。

轨迹评判是目前大多数团队仍在重建 2024 年代基础设施的地方。单轮质量得分汇总出的数字可能看起来很漂亮,但对话整体却可能语无伦次。目标成功率指标,加上失败原因的根因分析分类法,大约是构建一个有用流水线的底线。

镜像陷阱 (The Hall of Mirrors Trap)

这里开始变得有趣了。合成用户评估最大的失败模式并非角色设定糟糕,而是模拟器与 Agent 共享先验知识。它们在同一个互联网数据上训练,使用重叠的数据进行微调,并由来自相同工程背景的人编写提示词。因此,当模拟器生成一个问题时,Agent 发现它很好回答;当 Agent 发出一个漫无边际的回复时,模拟器觉得出于礼貌应该接受。

评估变成了一个镜像陷阱。双方都是 LLM,双方都了解沟通惯例,对话显得连贯仅仅是因为两个高度对齐的模型在共同协作。然而,当真实用户到来时,用不同的语态问同样的问题,Agent 就会崩溃。

2026 年一项名为《迷失在模拟中》(Lost in Simulation) 的研究对此进行了量化:仅仅通过更换扮演用户的 LLM,Agent 的成功率波动可达 9 个百分点,而且模拟器会系统性地低估 Agent 在困难任务上的表现,同时高估其在中等难度任务上的表现。更糟的是,模拟器会引入对话痕迹——某些短语、对冲词、补全模式——这些是真实用户不会产生的,而 Agent 应对这些痕迹的能力与其应对人类的能力毫无关系。该研究还显示,对于说非裔美国英语 (AAVE) 和标准美国英语 (SAE) 的用户,评估结果存在明显差异:模拟器对自己训练过的方言更在行,其对 Agent 的测量也继承了这种不对称性。

实际上,这意味着你的合成用户流水线中最重要的指标不是针对模拟器的目标成功率,而是模拟器与生产环境的偏差 (simulator-versus-production divergence):这是一个定期的基准测试,用于对比模拟器的对话分布(轮次长度、放弃率、澄清模式、词汇多样性)与实际生产日志。如果它们发生偏离,你的评估就不再是在测量你认为你在测量的东西,任何在合成基准上的提升在被信任之前都需要重新验证。

校准的纪律:没人愿意买单的那部分

合成用户流水线是校准出来的,而不是配置出来的。这种区别正是大多数团队投入不足的地方。

根据生产环境的流失曲线校准耐心值和放弃率。 如果真实用户在智能体给出第三次无用回答后有 30% 的概率会离开,那么你的模拟器也应该如此。这些数据来源于你的日志,而不是提示词工程师的直觉。每季度重新校准一次,因为用户行为会发生变化——尤其是在 UI 变更或竞争对手发布新功能之后。

根据真实意图簇校准目标分布。 生产流量中的故障报告比例应该与评估集中的故障报告比例相匹配。如果真实对话中有 12% 是“我的退款在哪里”,那么你的合成对话中也应该有 12% 是这个主题。当这个比例发生漂移时(这种情况必然会发生),评估系统就会对那些无关紧要的改进给出高分,而忽略掉真正严重的回归问题。

根据真实流量的 n-grams 校准词汇量。 合成用户默认使用干净、中规中矩的词汇。而真实用户会使用错别字、地域性措辞、语码转换(code-switching)、句中修正和表情符号。如果模拟器剥离了所有这些细节,生成的评估结果就是在衡量智能体针对一个并不存在的群体所表现出的性能。

对标留出的人工评审对话进行校准。 每季度抽取一百场真实对话,让人类按照合成用户评判器所使用的同一套轨迹标准进行评分,并检查合成用户评判器的结论是否一致。如果相关性低于上一季度,说明你的评判器发生了漂移,或者模拟器发生了漂移,亦或两者兼有——此时正确的做法是在信任下一次发布决策之前,先修复评判器。

这些工作都不光鲜。这部分流水线无法在演示中大放异彩。但这正是能抢在用户发现之前捕捉回归问题的评估系统,与那些在生产环境曲线下滑时还在自我陶醉的评估系统之间的本质区别。

警惕组织失效模式

这套机制出错的典型路径非常直接:团队针对合成用户群体微调智能体,智能体变得非常擅长回答合成群体提出的问题,然后在处理真实用户提出的问题时出现了性能回归并上线。CI 图表在上升。留存率曲线在下降。团队盯着这种背离现象,慢慢意识到模拟器只是用户的模型,智能体是针对模型进行优化的,而真实用户从未参与其中。

防御手段主要是流程性的。将模拟器与生产环境的背离视为阻碍发布的指标,而不是一个仅供参考的氛围感仪表盘。按照固定的节奏从真实流量中更新人格(Persona)库,而不是等到“有人发现它过时了”才去更新。保留一个规模小、成本高、速度慢的人工评估队列,在每个候选版本上运行,即使在合成用户流水线规模化之后也要坚持——尤其是在规模化之后,因为那时跳过人工检查的诱惑力最强。

一个能够有力反击的合成用户评估系统——拥有真实用户认可的人格、针对真实流失曲线校准的耐心预算,以及与人工评分高度相关的评判器——是严肃的智能体团队所能构建的杠杆率最高的基础设施之一。而不具备这些特性的合成用户评估系统,只是在用昂贵的方式验证你智能体已有的行为。从外部看,这些基础设施看起来一模一样。区别在于团队中是否有人在为每一次发布进行那些枯燥的校准工作,周而复始,长此以往。

未来趋势

坦率地说,最终状态是混合模式。内部循环使用合成用户——快速、廉价、覆盖每个 PR,并广泛覆盖意图空间和性格空间。建立一个小规模的生产流量影子流水线,将候选智能体与生产环境对话进行镜像对比,发现合成用户遗漏的回归问题。定期使用人工评分队列对两者进行审计。合成用户流水线并不是要取代另外两者;它是为了让另外两者的使用场景足够稀少,从而让你有财力把它们做好。

做得对的团队将交付更少的多轮对话回归。做不到的团队则会不断地从用户那里得知,他们的智能体又无法进行哪些对话了。

References:Let's stay in touch and Follow me for more thoughts and updates