系列第二十六篇 · 核心论点被测系统是对话式 Agent测试方也必须用对话行为模拟用户——多轮追问、自然语言歧义、情绪升级是用 Agent 测 Agent的本质。角色粒度以能测出独特系统行为为边界。一、测试方与被测方都是对话式客服 Agent 的输入是自然语言输出也是自然语言。这意味着它的接口不是 REST 参数而是一段对话。测试方如果只发固定请求、断言固定响应测的是系统对精确指令的处理而不是系统对真实对话的应对。真实用户不会一次把话说完不会用标准术语会输错订单号会不耐烦会在系统回复后继续追问。这些行为普通自动化脚本表达不了——脚本是确定性的对话是概率性的脚本是无状态的对话是有上下文的。所以被测系统是对话式 Agent测试方也必须是对话式 Agent。这就是用 Agent 测 Agent的本质。二、5 种横向角色职能/权限维度角色的第一层划分是职能/权限——谁在用这个系统。每个角色是一套行为约束 对话风格不是身份标签角色对话人格行为模式测出的系统能力普通消费者口语化、会追问、会输错订单号意图识别、参数抽取客服工作台先确认再操作、处理纠纷、安抚情绪人机协作、升级流程订单管理后台精确、批量、审批审批权限、操作确认数据分析看板只读、聚合查询只读边界、聚合正确性恶意/异常用户注入、越权尝试、超频安全防线、限流降级每个角色在模拟时Agent 的 system prompt 里注入对应的人格约束。比如普通消费者被约束为不主动给全订单号被追问才给会用那个冰箱指代商品可能会说错订单号。这样系统才真正面对真实用户而非配合的测试者。角色测试的两种形态同一套角色矩阵身份可以驱动两类测试形态测什么需要 Agent角色 非对话功能权限边界、并发、限流、只读、聚合❌ 脚本即可身份对话行为意图、抽取、情感、上下文理解✅ 必须 Agent对话人格本文聚焦对话行为形态。非对话功能审批权限、只读边界、注入拦截、限流用角色脚本即可覆盖方法论不在本篇展开——但角色矩阵身份两形态通用。细节第二章表格中测出的系统能力列订单管理后台的审批权限、数据分析看板的只读边界、恶意用户的安全防线、限流降级——这些属于非对话功能脚本即可测。Agent 的独特价值在对话中如何触发升级、用户情绪如何被识别这样的对话行为。三、普通消费者的 4 种纵向变体人群/行为维度横向角色只区分谁在用还不足以覆盖怎么用。同一个普通消费者表达方式的差异可能比跨角色的差异还大。所以对普通消费者做纵向细分变体对话特征测出的系统能力老年用户模糊描述“那个放冰淇淋的方盒子”、不懂术语、重复模糊参数抽取、耐心引导女性/年轻妈妈关注细节材质/安全/保修、情绪化表达情感识别、安抚对话技术小白不会表达需求“我不知道怎么查”引导式对话、澄清提问资深用户省略上下文“退了吧”、用行话上下文理解、意图判定细分原则粒度边界 能测出独特的系统行为。这是角色设计的方法论不是人口统计学罗列。两个变体若测出的是同一种系统行为就没必要细分。上面的 4 个变体各自对应一个独特的系统能力模糊抽取、情感识别、引导对话、上下文理解——各测一个不重叠。横向角色 × 纵向变体覆盖了谁在用怎么用两个维度。接下来我们看如何把这些角色落到实验中。四、对话行为的模拟实现4.1 多轮对话状态管理模拟用户不是发一条消息看响应而是基于系统回复继续对话。对话 ID 贯穿整场对话模拟用户我那个快递咋样了系统 请提供订单号或快递单号模拟用户哦对WB202405270001就是那个冰箱系统 订单 WB202405270001 正在运输中…模拟用户那能退吗系统 可以是否需要我为您申请退货每一轮模拟 Agent 读取系统回复决定下一步说什么。这测的是系统的多轮上下文能力——它是否记得这是同一个用户的同一件事。4.2 自然语言歧义生成模拟用户会被注入制造歧义的行为约束口语化“咋样了而不是查询订单状态”省略“那个冰箱而不是具体产品型号”指代“我买的而不是订单号”错误输错订单号如字母 O 与数字 0 混淆测系统是报错还是澄清这测的是意图识别和参数抽取在真实输入下的鲁棒性。4.3 行为约束角色 prompt 使用声明式规则即配置的思路约束测试方的模拟用户——规定它可以怎么说、不可以怎么说、被追问时必须给什么。4.4 并发调度多角色同时发起对话验证资源竞争多用户高并发下限流/降级是否按角色区分如监控流量旁路、恶意用户限流隔离性一个角色的对话状态是否污染另一个角色降级触发网关故障拒绝模式fail-closed时各角色的行为差异是否符合预期4.5 断言体系每一轮对话结束后断言三个层面对话正确性系统回复是否解决了用户问题权限边界越权操作是否被拦截UX 指标见下一节五、UX 维度让模拟用户打分功能测试问对不对UX 测试问好不好。模拟用户在每轮对话后对系统回复打分UX 指标评估方式说明回答质量复用 RAG 评估框架RAGAS指标忠实度、相关性、答案正确性项目已有 RAGAS 评测基础响应速度第 95 百分位延迟P95多轮对话的每轮等待时间对话流畅度多轮衔接是否自然系统是否记得上下文、追问是否恰当错误处理友好度规则判断出错时是否给出可操作提示“未找到订单请核对订单号” vs “查询失败”降级体验规则判断故障拒绝模式时是否清晰说明“网关暂时不可用请稍后再试” vs “系统错误”UX 测试是模拟用户的主观评估不是真实用户反馈。固定步骤的 UX 探测Agent 模拟角色不仅做自由对话还执行固定步骤如退货流程在每个步骤记录用户体验评分——脚本只关心最后结果对不对Agent 关心整个过程好不好步骤功能正确UX 评分发现问题进入订单页✅2/5找不到退货按钮点击退货✅1/5重复输入订单号填写退货理由✅3/5退货理由选项有限提交❌1/5失败无提示这种测试对功能测试有补充意义脚本测接口对不对Agent 测用户体验好不好。六、要点用 Agent 测 Agent被测是对话式测试方也必须是对话式角色是对话人格行为模式不是身份标签角色粒度 能测出独特系统行为不是人口统计学罗列横向角色 × 纵向变体覆盖谁在用怎么用两个维度功能正确是底线UX 是加分项——两者都要测 用 Agent 模拟多角色用户：对话式 Agent 系统的测试方法论
系列第二十六篇 · 核心论点被测系统是对话式 Agent测试方也必须用对话行为模拟用户——多轮追问、自然语言歧义、情绪升级是用 Agent 测 Agent的本质。角色粒度以能测出独特系统行为为边界。一、测试方与被测方都是对话式客服 Agent 的输入是自然语言输出也是自然语言。这意味着它的接口不是 REST 参数而是一段对话。测试方如果只发固定请求、断言固定响应测的是系统对精确指令的处理而不是系统对真实对话的应对。真实用户不会一次把话说完不会用标准术语会输错订单号会不耐烦会在系统回复后继续追问。这些行为普通自动化脚本表达不了——脚本是确定性的对话是概率性的脚本是无状态的对话是有上下文的。所以被测系统是对话式 Agent测试方也必须是对话式 Agent。这就是用 Agent 测 Agent的本质。二、5 种横向角色职能/权限维度角色的第一层划分是职能/权限——谁在用这个系统。每个角色是一套行为约束 对话风格不是身份标签角色对话人格行为模式测出的系统能力普通消费者口语化、会追问、会输错订单号意图识别、参数抽取客服工作台先确认再操作、处理纠纷、安抚情绪人机协作、升级流程订单管理后台精确、批量、审批审批权限、操作确认数据分析看板只读、聚合查询只读边界、聚合正确性恶意/异常用户注入、越权尝试、超频安全防线、限流降级每个角色在模拟时Agent 的 system prompt 里注入对应的人格约束。比如普通消费者被约束为不主动给全订单号被追问才给会用那个冰箱指代商品可能会说错订单号。这样系统才真正面对真实用户而非配合的测试者。角色测试的两种形态同一套角色矩阵身份可以驱动两类测试形态测什么需要 Agent角色 非对话功能权限边界、并发、限流、只读、聚合❌ 脚本即可身份对话行为意图、抽取、情感、上下文理解✅ 必须 Agent对话人格本文聚焦对话行为形态。非对话功能审批权限、只读边界、注入拦截、限流用角色脚本即可覆盖方法论不在本篇展开——但角色矩阵身份两形态通用。细节第二章表格中测出的系统能力列订单管理后台的审批权限、数据分析看板的只读边界、恶意用户的安全防线、限流降级——这些属于非对话功能脚本即可测。Agent 的独特价值在对话中如何触发升级、用户情绪如何被识别这样的对话行为。三、普通消费者的 4 种纵向变体人群/行为维度横向角色只区分谁在用还不足以覆盖怎么用。同一个普通消费者表达方式的差异可能比跨角色的差异还大。所以对普通消费者做纵向细分变体对话特征测出的系统能力老年用户模糊描述“那个放冰淇淋的方盒子”、不懂术语、重复模糊参数抽取、耐心引导女性/年轻妈妈关注细节材质/安全/保修、情绪化表达情感识别、安抚对话技术小白不会表达需求“我不知道怎么查”引导式对话、澄清提问资深用户省略上下文“退了吧”、用行话上下文理解、意图判定细分原则粒度边界 能测出独特的系统行为。这是角色设计的方法论不是人口统计学罗列。两个变体若测出的是同一种系统行为就没必要细分。上面的 4 个变体各自对应一个独特的系统能力模糊抽取、情感识别、引导对话、上下文理解——各测一个不重叠。横向角色 × 纵向变体覆盖了谁在用怎么用两个维度。接下来我们看如何把这些角色落到实验中。四、对话行为的模拟实现4.1 多轮对话状态管理模拟用户不是发一条消息看响应而是基于系统回复继续对话。对话 ID 贯穿整场对话模拟用户我那个快递咋样了系统 请提供订单号或快递单号模拟用户哦对WB202405270001就是那个冰箱系统 订单 WB202405270001 正在运输中…模拟用户那能退吗系统 可以是否需要我为您申请退货每一轮模拟 Agent 读取系统回复决定下一步说什么。这测的是系统的多轮上下文能力——它是否记得这是同一个用户的同一件事。4.2 自然语言歧义生成模拟用户会被注入制造歧义的行为约束口语化“咋样了而不是查询订单状态”省略“那个冰箱而不是具体产品型号”指代“我买的而不是订单号”错误输错订单号如字母 O 与数字 0 混淆测系统是报错还是澄清这测的是意图识别和参数抽取在真实输入下的鲁棒性。4.3 行为约束角色 prompt 使用声明式规则即配置的思路约束测试方的模拟用户——规定它可以怎么说、不可以怎么说、被追问时必须给什么。4.4 并发调度多角色同时发起对话验证资源竞争多用户高并发下限流/降级是否按角色区分如监控流量旁路、恶意用户限流隔离性一个角色的对话状态是否污染另一个角色降级触发网关故障拒绝模式fail-closed时各角色的行为差异是否符合预期4.5 断言体系每一轮对话结束后断言三个层面对话正确性系统回复是否解决了用户问题权限边界越权操作是否被拦截UX 指标见下一节五、UX 维度让模拟用户打分功能测试问对不对UX 测试问好不好。模拟用户在每轮对话后对系统回复打分UX 指标评估方式说明回答质量复用 RAG 评估框架RAGAS指标忠实度、相关性、答案正确性项目已有 RAGAS 评测基础响应速度第 95 百分位延迟P95多轮对话的每轮等待时间对话流畅度多轮衔接是否自然系统是否记得上下文、追问是否恰当错误处理友好度规则判断出错时是否给出可操作提示“未找到订单请核对订单号” vs “查询失败”降级体验规则判断故障拒绝模式时是否清晰说明“网关暂时不可用请稍后再试” vs “系统错误”UX 测试是模拟用户的主观评估不是真实用户反馈。固定步骤的 UX 探测Agent 模拟角色不仅做自由对话还执行固定步骤如退货流程在每个步骤记录用户体验评分——脚本只关心最后结果对不对Agent 关心整个过程好不好步骤功能正确UX 评分发现问题进入订单页✅2/5找不到退货按钮点击退货✅1/5重复输入订单号填写退货理由✅3/5退货理由选项有限提交❌1/5失败无提示这种测试对功能测试有补充意义脚本测接口对不对Agent 测用户体验好不好。六、要点用 Agent 测 Agent被测是对话式测试方也必须是对话式角色是对话人格行为模式不是身份标签角色粒度 能测出独特系统行为不是人口统计学罗列横向角色 × 纵向变体覆盖谁在用怎么用两个维度功能正确是底线UX 是加分项——两者都要测