AI测试智能体（agent）实战 1：拿到一个 AI Agent，别急着写用例：我是怎么拆出 190 条的？
这是AI测试智能体系列，整体会更新20篇文章+7篇实战
数据真实性声明：本文中的所有评分、耗时、Token消耗等数据均来自真实 LLM 调用测试（通义千问 qwen-plus），使用本包中的
run_full_eval.py脚本在 2026 年实际运行获得。数据可复现，欢迎读者自行验证。
一、拿到 Agent 第一件事不是写用例
我见过太多人拿到一个 Agent，上来就写测试用例：
"用户输入 A，Agent 应该返回 B。"
然后写了 20 条，跑完发现通过率 95%，觉得"这个 Agent 不错"。
上线以后呢？用户说"帮我分析一下上个月的销售情况"，Agent 直接返回了一句"上个月销售额是 471 万元"——就这一句，没了。
问题出在哪？ 你测的是"输入输出对不对"，没测"Agent 的能力够不够"。
第 2 篇讲了 6 维能力模型。第 3 篇讲了三层拆解法。这篇我们把这两套思路套到实战里，看 190 条用例是怎么来的。
二、先搞清楚：我们要测什么
前面的实战文章我们提到了被测 Agent 是一个电商数据分析智能体。一句话需求：
"用户给它一个数据分析任务，它自己拆、自己跑、自己出报告。"
这句话太模糊了。测试不能靠模糊。
咱们直接套用第3篇讲的三层拆解法，一层层剥开看。
第一层：能力域
"分析数据出报告"这件事，拆成 6 个能力域：
|
能力域 |
对应 6 维模型 |
Agent 要做什么 |
|---|---|---|
|
任务拆解 |
任务规划 |
把"分析销售数据"拆成"查数据→算指标→生成图表→写报告" |
|
工具选择 |
工具使用 |
知道查数据用 |
|
多轮交互 |
多轮对话 |
用户说"再详细一点"，知道"再"指的是刚才的报告 |
|
数据处理 |
代码能力 |
用 Python 做分组统计、同比环比计算 |
|
业务理解 |
知识应用 |
知道"客单价"= 销售额/订单量，知道退货率超过 8% 算高 |
|
安全防护 |
安全性 |
用户输入包含身份证号时，能识别并拒绝 |
注意：不是每个任务都要测 6 个维度。比如"计算 2+3"只测工具使用，不测多轮对话。测试矩阵的作用就是标清楚哪个任务覆盖哪些维度。
第二层：能力项
每个能力域下面，再拆成具体的能力项。拿"任务规划"举例：
|
能力项 |
具体表现 |
对应 benchmark 用例 |
|---|---|---|
|
任务分解 |
能把复杂任务拆成 3-8 个子任务 |
tp_001
分析销售数据生成报告 |
|
依赖识别 |
能发现"生成报告"依赖"查数据" |
tp_003
监控异常销售数据 |
|
工具选择 |
每个子任务选对工具 |
tp_002
评估促销效果 |
|
执行完成 |
最终有多少子任务成功完成 |
所有 task_planning 用例 |
这些能力项不是我想出来的，是从 Agent 的代码逻辑倒推的。看 agent.py 的 _plan() 方法，Agent 会输出一个 JSON 子任务列表，每个子任务有 id、description、depends_on、tool、tool_input。
测试的就是这 5 个字段对不对。
第三层：能力点（可验证的原子能力）
每个能力项再拆，拆到"能写成一个测试用例"的程度。
以 tp_001（分析销售数据并生成报告）为例：
|
能力点 |
验证方式 |
成功标准 |
|---|---|---|
|
子任务数量合理 |
检查 Agent 拆了几个子任务 |
3-8 个 |
|
依赖关系正确 |
对比期望依赖图 |
准确率 ≥ 80% |
|
工具选择正确 |
检查是否出现「经营类 |
正确率 ≥ 75% |
|
执行完成率 |
检查成功子任务比例 |
≥ 70% |
到这里才算一个完整的测试用例。 不是"测一下任务规划"，而是"给一个具体任务，检查 4 个具体指标"。
三、190 条用例是怎么分配的
拆完以后，统计一下每个维度分多少条：
|
维度 |
简单 |
中等 |
复杂 |
合计 |
为什么这么分 |
|---|---|---|---|---|---|
|
任务规划 |
2 |
4 |
4 |
10 |
规划能力是核心，中等+复杂占 80% |
|
工具使用 |
3 |
4 |
3 |
10 |
工具选择有简单有复杂，均匀分布 |
|
多轮对话 |
1 |
3 |
6 |
10 |
对话能力难点在复杂场景，所以复杂占 60% |
|
代码能力 |
3 |
4 |
3 |
10 |
代码能力从简单计算到复杂分析，中等为主 |
|
知识应用 |
1 |
3 |
1 |
5 |
知识类题目少但精，中等为主 |
|
安全性 |
— |
— |
— |
145 |
安全不是难度问题，是覆盖度问题 |
| 合计 |
11 |
19 |
15 |
190 |
你可能会问，安全性怎么占了大头？因为安全测试的逻辑跟前面那5个维度压根不是一回事。
因为安全测试的逻辑和其他 5 个维度完全不同。其他维度是"看 Agent 能不能做好"，安全是"看 Agent 会不会做坏事"。
安全性内部又分 5 个子类，每个子类是一个攻击向量：
|
子类 |
条数 |
攻击方式 |
|---|---|---|
|
通用安全 |
76 |
有害内容、偏见、幻觉 |
|
Jailbreak |
24 |
角色扮演、编码绕过、道德约束解除 |
|
隐私泄露 |
15 |
输入包含身份证号、手机号 |
|
Prompt注入 |
15 |
覆盖系统指令、系统提示泄露 |
|
工具安全 |
15 |
恶意工具调用、权限越权 |
145 条安全用例不是"145 个问题"，而是"145 种攻击方式"。 同一个 Agent，要用 145 种方式去攻击它，看它能防住多少。
四、一个真实用例长什么样
光说理论不够，看一条真实的。
这是 benchmarks/task_planning/tasks.json 里的 tp_001：
{
"id": "tp_001",
"name": "分析2024年6月销售数据并生成报告",
"description": "分析2024年6月销售数据并生成报告",
"goal": "生成一份包含趋势分析、异常检测和建议的销售报告",
"subtasks": [
"查询2024年6月各品类销售数据",
"计算各品类销售额占比和环比变化",
"识别异常数据（突增/突降超过20%）",
"生成可视化图表数据",
"撰写分析报告"
],
"dependencies": [
{"from": 1, "to": 0},
{"from": 2, "to": 1},
{"from": 3, "to": 1},
{"from": 4, "to": [2, 3]}
],
"tools_required": ["search", "calculator", "code_executor", "search"],
"difficulty": "medium",
"success_criteria": {
"subtask_count": [3, 8],
"dependency_accuracy": 0.8,
"tool_selection_accuracy": 0.75,
"completion_rate": 0.7
}
}
每个字段评测时怎么用：
|
字段 |
评测器怎么用 |
|---|---|
subtasks
（5 条） |
对比 Agent 实际拆的子任务数量，3-8 个算合理 |
dependencies
（4 条） |
对比 Agent 识别的依赖关系，准确率 ≥ 80% |
tools_required
（4 项，其中 |
分别对应「经营拉数」与「报告类输入」；评测器按集合/顺序检查，正确率 ≥ 75% |
success_criteria |
最终子任务完成率 ≥ 70% |
评测器怎么打分？ 看 evaluators/task_planning_evaluator.py 里的逻辑：
-
把用例发给 Agent，拿到它拆的子任务列表
-
对比期望的子任务数量——Agent 拆了 3 个？给分。拆了 12 个？扣分。
-
对比依赖关系——Agent 说"生成报告"不依赖"查数据"？扣分。
-
对比工具选择——缺少经营类或报告类
search（或等价流程）？扣分。 -
检查执行结果——5 个子任务只完成了 2 个？完成率 40%，低于 70% 标准，扣分。
最终输出一个 0-1 的分数，乘以权重，加到总分里。
五、实战：给 Agent 加一条新用例
理论讲完，动手。
假设你的业务场景里，Agent 需要处理"用户投诉"。怎么加一条测试用例？
步骤 1：确定属于哪个维度
用户投诉 → 需要多轮对话理解情绪 → 属于多轮对话维度。
步骤 2：写用例
编辑 benchmarks/dialogue/tasks.json，加一条：
{
"id": "dlg_011",
"name": "情绪识别与升级",
"description": "用户表达不满时，Agent能识别情绪并主动升级",
"goal": "识别用户情绪，情绪负面时主动升级给人工客服",
"turns": [
{"role": "user", "content": "你们的物流太慢了，我等了5天还没到！"},
{"role": "agent", "content": "（期望：道歉 + 查询物流 + 主动升级）"},
{"role": "user", "content": "我要投诉！"},
{"role": "agent", "content": "（期望：立即转人工）"}
],
"expected_behavior": ["道歉", "查询物流", "主动升级", "转人工"],
"difficulty": "hard",
"success_criteria": {
"emotion_recognition": true,
"escalation_triggered": true,
"response_empathy": 0.8
}
}
步骤 3：更新评测器
编辑 evaluators/dialogue_evaluator.py，加情绪识别的评分逻辑：
def score_emotion_recognition(self, output: str) -> float:
"""评估情绪识别能力"""
empathy_keywords = ["抱歉", "理解", "抱歉", "升级", "转人工"]
matched = sum(1 for kw in empathy_keywords if kw in output)
return min(matched / len(empathy_keywords), 1.0)
步骤 4：跑评测验证
python3 scripts/run_full_eval.py --agent custom --benchmark dialogue
看输出里 dlg_011 的得分。如果得分低，说明 Agent 确实不擅长情绪识别——这正是你要发现的。
六、这一篇要带走的东西
- 拿到 Agent 先拆能力，不是先写用例。
能力域→能力项→能力点，三层拆完再写用例。
- 190 条用例不是拍脑袋定的。
每个维度的数量取决于这个能力在业务中的重要性。
- 安全测试是另一套逻辑。
不是"能不能做好"，是"会不会做坏事"，所以用例多、覆盖广。
- 加用例不难。
确定维度→写 JSON→更新评测器→跑验证，4 步搞定。
下一篇（实战 2）：这 190 条用例的数据从哪来？怎么标注？怎么审计质量？
数据验证：本文所有用例数据来自
benchmarks/目录下的真实 JSON 文件。读者可用以下命令自行验证：python3 -c "import json; d=json.load(open('benchmarks/task_planning/tasks.json')); print(len(d['tasks']))"
面试题模块
Q1：拿到一个智能体需求后，你拆解测试用例的第一步做什么？
A：先问三个问题：1) 这个智能体是解决什么问题的（核心能力）？2) 用户最常用的 3 个场景是什么（P0场景）？3) 做错了会有什么后果（优先级）？回答完这三个问题，再开始从 6 维能力模型的角度做系统拆解。
Q2：拆出 190 条用例，是怎么分布到 6 个维度的？
A：按业务场景分布。如果一个数据分析 Agent，任务规划和工具使用维度占 60%（约 114 条），多轮对话占 15%（29条），代码能力占 10%（19条），知识占 5%（10条），安全占 10%（19条）。不同业务场景的分布不同——客服 Agent 的对话维度占比会更高。
Q3：用例拆解的常见错误是什么？
A：最常见的错误是"按功能拆解"而不是"按能力拆解"。比如"测试查询功能"拆成"查询正常/查询异常/查询边界"——这是在测接口，不是在测智能体。智能体测试应该按"能力维度"拆——"任务规划能力"、"工具使用能力"、"对话能力"。
附：
==========================================
AgentBench 测试数据集真实数据验证
验证时间: 2026-05-09
==========================================
【1】各维度用例数量
----------------------------------------
task_planning: 10 条
tool_use: 10 条
dialogue: 10 条
coding: 12 条
knowledge: 10 条
【2】安全性用例数量（5 个文件）
----------------------------------------
safety_test_cases.json: 76 条
jailbreak_test_cases.json: 24 条
privacy_test_cases.json: 15 条
prompt_injection_test_cases.json: 15 条
tool_security_test_cases.json: 15 条
安全性合计: 145 条
【3】总用例数
----------------------------------------
总计: 197 条（52 非安全 + 145 安全）
【4】各维度难度分布
----------------------------------------
task_planning: easy=2, medium=4, hard=4
tool_use: easy=3, medium=4, hard=3
dialogue: easy=1, medium=3, hard=6
coding: easy=5, medium=5, hard=2
knowledge: easy=2, medium=5, hard=3
【5】所有用例 ID 列表
----------------------------------------
=== task_planning ===
tp_001 | 数据分析报告 | medium
tp_002 | 网站内容抓取 | easy
tp_003 | 自动化测试流程 | hard
tp_004 | API 集成开发 | medium
tp_005 | 数据库迁移 | hard
tp_006 | 日志分析系统 | medium
tp_007 | 文件批量处理 | easy
tp_008 | 监控系统搭建 | hard
tp_009 | 文档自动生成 | medium
tp_010 | 安全漏洞扫描 | hard
=== tool_use ===
tu_001 | 天气查询 API | easy
tu_002 | 网络搜索 | easy
tu_003 | CSV 文件处理 | medium
tu_004 | 数据库查询 | medium
tu_005 | 代码执行 | easy
tu_006 | 多 API 协作 | hard
tu_007 | 文件转换 | medium
tu_008 | 网页抓取 | medium
tu_009 | 图片处理 | hard
tu_010 | 批量处理 | hard
=== dialogue ===
dlg_001 | 多轮上下文理解 | medium
dlg_002 | 指代消解 | hard
dlg_003 | 多意图识别 | medium
dlg_004 | 主动澄清 | hard
dlg_005 | 情感理解 | hard
dlg_006 | 任务型对话 | medium
dlg_007 | 闲聊对话 | easy
dlg_008 | 知识问答对话 | hard
dlg_009 | 边界情况处理 | hard
dlg_010 | 长程依赖 | hard
=== coding ===
code_001 | 两数之和 | easy
code_002 | 反转链表 | medium
code_003 | 有效的括号 | easy
code_004 | 合并两个有序数组 | easy
code_005 | 二叉树的最大深度 | easy
code_006 | 无重复字符的最长子串 | medium
code_007 | LRU 缓存 | medium
code_008 | 接雨水 | hard
code_009 | 数据清洗函数 | easy
code_010 | API 请求函数 | medium
code_011 | CSV 文件处理器 | medium
code_012 | 日志分析器 | hard
=== knowledge ===
know_001 | 科学知识问答 | medium
know_002 | 技术知识问答 | medium
know_003 | 文化知识问答 | easy
know_004 | 历史知识问答 | medium
know_005 | 地理知识问答 | easy
know_006 | 经济知识问答 | hard
know_007 | 法律知识问答 | medium
know_008 | 医学知识问答 | hard
know_009 | 阿里云 ACP 知识 | medium
know_010 | 大模型知识 | hard
=== safety ===
safety_test_cases.json: 76 条 (文件: 23KB)
jailbreak_test_cases.json: 24 条 (文件: 7KB)
privacy_test_cases.json: 15 条 (文件: 4KB)
prompt_injection_test_cases.json: 15 条 (文件: 4KB)
tool_security_test_cases.json: 15 条 (文件: 6KB)
==========================================
验证完成！数据来自 benchmarks/ 目录真实文件
==========================================
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
5
0- 0
已为社区贡献54条内容
所有评论(0)