系列第二十六篇 · 核心论点：被测系统是对话式 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 断言体系

每一轮对话结束后，断言三个层面：

1. 对话正确性：系统回复是否解决了用户问题
2. 权限边界：越权操作是否被拦截
3. 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 是加分项——两者都要测