AI Agent 测试入门：从回答问题到执行任务

摘要

和普通问答不同，Agent 的核心不是回答问题，而是执行任务。问题也因此变得更危险：理解错任务、选错工具、参数传错、失败乱重试、结果假完成。这篇文章从意图识别、任务拆解、工具调用、异常处理、安全确认几个角度，系统说明 Agent 应该怎么测。

前面的几篇，我们已经逐步走过了几类典型 AI 测试场景：

• AI 测试的基本认知
• Prompt 测试
• AI 生成测试用例功能测试
• RAG 知识库问答测试

如果说前面这些场景，更多还是围绕“生成内容”或“回答问题”，那么从这一篇开始，我们进入一类更复杂、也更接近未来业务形态的 AI 系统：

AI Agent

为什么说它更复杂？

因为 Agent 不只是“说”，而是开始“做”。

比如用户不再只是问：

请帮我总结这份文档。

而是直接说：

• 帮我分析需求并生成测试用例
• 帮我创建 Jira 任务
• 帮我查一下最近一周的线上故障并整理成报告
• 帮我预约会议并通知相关人员

这时候，AI 不再只是一个问答助手，而变成了一个会拆任务、调工具、执行步骤、返回结果的“任务执行者”。

这也意味着，Agent 测试不再只是测回答质量，而要测：

它有没有理解对任务？
它有没有选对工具？
它的执行顺序对不对？
参数传递有没有问题？
失败时会不会乱试？
高风险操作有没有确认？
最终结果到底是不是可靠？

所以，Agent 测试最核心的问题不是：

它会不会回答。

而是：

它能不能在正确、受控、安全的前提下完成任务。

这篇文章就专门讲清楚：AI Agent 到底怎么测。

---

一、先明确：Agent 和普通聊天机器人到底差在哪？

这是做 Agent 测试前必须先想清楚的一件事。

很多人看到 Agent 的第一反应是：

不就是更聪明一点的聊天机器人吗？

但如果从测试视角看，二者差别其实很大。

普通聊天机器人的核心能力

通常是：

• 理解问题
• 组织回答
• 输出内容

也就是说，它的终点是：

给你一个答案。

AI Agent 的核心能力

通常是：

• 理解目标
• 拆解任务
• 选择工具
• 调用工具
• 处理结果
• 决定下一步
• 最终完成任务

也就是说，它的终点不是“回答”，而是：

完成一件事。

一个最直观的例子

普通问答场景：

“怎么创建 Jira 任务？”

AI 回你一段步骤说明。
这属于“告诉你怎么做”。

Agent 场景：

“帮我根据这份需求生成测试用例，并创建 Jira 任务。”

AI 不只是解释，而是可能真的去：

1. 读取需求
2. 生成测试用例
3. 调 Jira 接口
4. 创建任务
5. 返回任务链接

这属于“替你去做”。

所以 Agent 测试比普通问答测试复杂，是因为它从“输出内容”变成了“执行行为”。

---

二、为什么 Agent 测试更难？

因为 Agent 的问题不再只出现在“答案对不对”，而可能出现在整个执行链路的任何一步。

举个例子，用户说：

帮我把这份需求分析成测试点，并创建 5 个 Jira 子任务。

Agent 可能需要经历下面这个流程：

理解用户意图
  ↓
读取需求文档
  ↓
提炼功能点
  ↓
生成测试点
  ↓
组装 Jira 参数
  ↓
调用 Jira API
  ↓
创建任务
  ↓
返回结果

这条链路里，任何一步出错，最终结果都可能有问题。

比如：

• 意图理解错了，创建成 Bug 而不是任务
• 文档读取不完整，导致测试点缺失
• Jira 参数传错，字段不合法
• 创建成功了，但返回结果没对上
• 失败后乱重试，重复建单
• 明明是高风险操作，却没有确认

所以 Agent 测试更难，是因为你测的不再是一个答案，而是一条行为链路。

---

三、Agent 测试到底在测什么？

一句话概括：

测它是不是能把任务正确地做完，并且过程可控。

拆开来看，至少包括 6 个层面。

1. 意图识别

用户到底想让它做什么，它有没有理解对。

2. 任务拆解

它有没有把复杂任务拆成合理步骤。

3. 工具选择

它有没有调用正确的工具，而不是乱调。

4. 参数传递

工具调用时，参数、字段、上下文是否正确。

5. 异常处理

调用失败、结果异常、信息不足时，它是否处理得当。

6. 权限与安全

高风险动作是否确认，越权动作是否拦截，敏感数据是否保护。

所以 Agent 测试不是只测“内容”，而是测：

理解、决策、执行、回退、边界。

---

四、怎么拆 Agent 的测试链路？

推荐一个非常实用的拆法：按“执行闭环”拆。

用户发起任务
  ↓
Agent 理解任务
  ↓
Agent 制定计划
  ↓
Agent 调用工具
  ↓
Agent 处理工具结果
  ↓
Agent 输出最终结果

每一步都可以测。

1. 用户输入层

重点看：

• 用户目标是否明确
• 模糊表达是否能正确理解
• 复合目标是否能识别
• 冲突目标是否能发现
• 缺少必要信息时是否会追问或提示

例如：

“帮我处理一下这个需求。”

这个输入其实很模糊。
Agent 如果直接开始生成内容，可能就有问题。

2. 意图理解层

重点看：

• 是回答问题，还是执行任务
• 是要查信息，还是改系统
• 是生成草稿，还是直接提交
• 是单步任务，还是多步组合任务

例如：

“帮我建一个 Jira。”

这里至少要识别：

• 是需求任务还是缺陷任务
• 项目是什么
• 标题是什么
• 优先级是什么
• 是否真的要创建，而不是只生成草稿

3. 任务规划层

重点看：

• 是否拆解出合理步骤
• 顺序是否正确
• 是否遗漏关键动作
• 是否引入了无关动作

例如：

“帮我读取需求文档，提炼测试点，并发给项目群。”

一个合理计划可能是：

1. 读取文档
2. 提炼测试点
3. 组织输出
4. 发送消息

如果它先发消息再读文档，顺序就不对。

4. 工具调用层

重点看：

• 是否选择了正确工具
• 是否调用次数合理
• 是否把工具当成万能选项乱试
• 是否在不需要工具时过度调用

这一层是 Agent 测试里非常关键的一层。

例如本来只需要读取文档并总结，结果 Agent 却多次无意义调用搜索、数据库、日历等工具，就属于工具选择或规划问题。

5. 结果处理层

重点看：

• 工具返回成功后是否正确消费结果
• 工具返回空值时是否处理得当
• 工具返回异常时是否回退
• 多工具结果之间是否正确拼接

例如读取到了需求文档，但提炼测试点时遗漏核心规则，问题就不一定在工具，而在 Agent 对结果的再处理。

6. 最终输出层

重点看：

• 是否真的完成了用户目标
• 输出是否和执行结果一致
• 是否有虚假完成
• 是否能把失败说清楚
• 是否给出下一步建议

这一层非常重要，因为用户最终感知的只有结果。

---

五、Agent 测试最容易出现哪些问题？

Agent 常见问题，通常比普通问答更隐蔽，也更危险。

1. 理解对了一半

用户要的是“创建 Jira 子任务”，Agent 却只生成了一份任务文案，没有真正创建。
或者反过来，用户只是想先看草稿，Agent 却真的提交了。

这类问题本质上是：

对任务目标理解不完整。

2. 计划看起来合理，但执行顺序错

例如应该先查权限、再执行操作，结果它先执行再发现没权限。
或者应该先确认用户意图，再发通知，结果它直接发了。

3. 工具选错

例如：

• 应该调用 Jira API，却去搜网页
• 应该读取当前文档，却错误读取历史文件
• 应该发群消息，却发成私聊

这类问题在业务里影响很大。

4. 参数传错

例如 Jira 创建任务时：

• 项目 key 错
• issue type 错
• 标题错位
• 描述内容缺失
• 优先级字段没传

很多 Agent 看起来“会调工具”，但其实真正落地时，问题都死在参数传递上。

5. 失败后乱重试

这是很典型的一类问题。

比如创建 Jira 第一次失败了，它没有判断失败原因，而是重复重试三次。
如果第一次其实已经成功，只是返回异常，就可能造成重复建单。

6. 没有高风险确认

例如：

• 删除日程
• 发通知给多人
• 更新线上配置
• 创建正式工单
• 修改关键数据

这类动作如果没有二次确认，就是很高风险的设计问题。

7. 假装完成

这是 Agent 很容易给人的错觉。

它可能输出：

已帮你创建任务。

但实际上任务并没有成功创建，或者只是在本地组织了一段文本。

所以 Agent 测试一定要验证“结果真实性”，不能只看自然语言输出。

---

六、怎么设计 Agent 测试场景？

设计 Agent 测试场景时，建议至少覆盖下面 5 类。

1. 单步任务场景

用于验证最基本能力。

例如：

• 帮我总结这份文档
• 帮我查询某个任务状态
• 帮我生成一份测试点草稿

这类场景的重点是：

• 目标理解是否正确
• 工具是否选择正确
• 输出是否匹配任务

2. 多步任务场景

用于验证拆解能力。

例如：

• 读取需求 → 生成测试点 → 创建 Jira
• 查询线上问题 → 汇总数据 → 输出日报
• 创建会议 → 邀请参与人 → 发送通知

这类场景重点测：

• 任务顺序
• 中间结果传递
• 整体闭环

3. 信息不足场景

用于验证边界控制。

例如：

帮我建个 Jira。

这个输入明显缺信息。
合理的 Agent 不应直接乱建，而应提示补充：

• 项目
• 标题
• 类型
• 优先级
• 描述

4. 工具失败场景

用于验证异常处理能力。

例如：

• Jira API 超时
• 文档读取失败
• 权限校验失败
• 日历创建失败
• 消息发送失败

这时候要看它是否：

• 识别失败
• 准确说明失败原因
• 合理重试
• 避免重复执行
• 给出下一步建议

5. 高风险操作场景

用于验证安全性。

例如：

• 删除已有事项
• 修改正式数据
• 对多人发送通知
• 创建正式工单
• 覆盖旧配置

这些场景下要看：

• 是否需要确认
• 确认文案是否明确
• 未确认时是否阻断执行
• 已确认后是否正确执行

---

七、Agent 测试用例可以怎么写？

下面给一个适合入门的用例表结构。

用例标题	场景类型	检查点	预期结果	优先级
单步生成测试点	单步任务	意图理解、输出质量	能正确读取需求并生成测试点	P0
生成测试点并创建 Jira	多步任务	任务拆解、参数传递、执行闭环	成功创建 Jira，并返回真实链接或标识	P0
信息不足时创建任务	信息不足	边界控制	明确要求补充信息，不应乱创建	P0
Jira 创建失败处理	工具异常	异常处理	正确说明失败，不重复乱建单	P0
高风险通知操作	高风险任务	二次确认	未确认前不执行通知发送	P0
多轮补充任务执行	多轮场景	上下文保持	能在补充信息后继续正确执行	P1
错误工具选择防护	工具调用	工具选择正确性	不应调用无关工具	P1
执行结果真实性校验	结果校验	假完成识别	输出结果必须与真实执行结果一致	P0

这类用例和传统功能测试最大的区别在于：

它测的不是页面动作，而是任务执行闭环。

---

八、Agent 输出怎么评估？

Agent 测试如果只看“像不像做成了”，风险很大。

建议至少建立一个基础评分框架。

示例评分维度

评分项	分值	说明
意图理解准确性	20	是否正确理解用户目标
任务拆解合理性	20	是否规划出合理步骤
工具选择正确性	15	是否选对工具
参数传递准确性	15	调用工具时参数是否正确
异常处理能力	15	失败时是否正确处理
安全与确认机制	15	高风险操作是否可控

总分 100 分。

一个简单判断方式

• 90 分以上：可作为灰度上线候选
• 75～89 分：可用，但需继续补强边界和异常处理
• 60～74 分：存在明显执行风险
• 60 分以下：不建议进入正式任务场景

对 Agent 来说，评分时尤其要重视两项：

• 异常处理
• 安全确认

因为这两项决定了它是不是“敢放到真实业务里”。

---

九、为什么高风险操作一定要确认？

这是 Agent 和普通聊天机器人最大的风险分界线之一。

因为一旦 Agent 具备真实执行能力，它就不只是“给错答案”，而可能直接造成业务后果。

例如：

• 给错误的人发通知
• 删除了本不该删除的数据
• 创建了一堆错误工单
• 更新了错误配置
• 给无关人员发送敏感信息

这些问题，光靠“模型聪明一点”是解决不了的。
必须通过机制设计控制。

所以高风险动作通常要满足三个条件：

1. 操作前明确确认

例如：

即将向项目群发送通知，共涉及 36 人，是否确认发送？

2. 确认文案必须具体

不能只写“是否继续”。
要说清楚：

• 做什么
• 影响谁
• 风险是什么

3. 未确认不得执行

如果只是“建议确认”，但没确认也照样执行，那这个机制没有意义。

所以 Agent 测试里，确认机制不是体验优化项，而是安全底线项。

---

十、Agent 测试结论应该怎么写？

和前几类 AI 功能一样，Agent 的测试结论不能只写：

功能基本可用。

因为 Agent 的风险不只在“能不能用”，更在于“可不可控”。

示例测试结论

本轮测试覆盖单步任务、多步任务、信息不足、工具调用异常、高风险操作确认及执行结果校验等场景。
整体来看，当前版本已具备基础任务执行能力，能够在结构清晰、边界明确的任务中完成信息读取、内容生成及部分工具调用闭环。

当前主要问题包括：

1. 复合任务下步骤拆解仍存在顺序不稳定问题；
2. 个别工具调用场景存在参数遗漏；
3. 工具失败后的回退策略不够稳定；
4. 高风险操作的确认文案仍不够具体；
5. 少数场景存在“结果表述已完成，但实际执行未成功”的风险。

综合评估，当前版本适合在低风险、可回滚、有人审阅的场景下灰度试用；在高风险执行场景全面开放前，需继续完善确认机制、异常处理和执行结果校验能力。

这种结论，才真正适合给产品、研发、管理者做上线参考。

---

十一、小结

AI Agent 怎么测？

可以浓缩成一句话：

不是测它会不会说，而是测它能不能在正确、可控、安全的前提下把事情做完。

所以 Agent 测试至少要覆盖这些层面：

• 是否理解对了任务
• 是否拆解出合理步骤
• 是否选对工具
• 是否正确传递参数
• 是否能处理异常
• 是否有安全边界
• 是否能确认高风险操作
• 是否真的完成任务而不是“假完成”

对测试工程师来说，Agent 测试其实并不陌生。
因为它本质上是把：

• 功能测试
• 接口测试
• 流程测试
• 异常测试
• 安全测试

再叠加一层 AI 的不确定性测试。

这也是为什么 Agent 测试会成为 AI 时代非常重要的一类质量能力。

---

写在最后

很多团队刚开始做 Agent 时，最容易被“演示效果”打动。

因为它看起来真的很像一个会做事的助手。

但测试工程师更应该追问这些问题：

• 它真的理解对任务了吗？
• 它调用的是对的工具吗？
• 它失败时会不会乱来？
• 它有没有越权？
• 它说自己做完了，是真的吗？
• 它的高风险动作，谁来兜底？

这些问题，才真正决定一个 Agent 能不能走出 Demo，进入真实业务。

---

下一篇预告

下一篇继续写：

AI测试怎么建立回归体系：从测试集、评分标准到质量报告

会重点展开：

• AI 测试为什么不能只靠临时提问
• 怎么设计 AI 测试集
• 怎么沉淀缺陷回归集
• 评分标准怎么定
• AI 测试报告怎么写更有说服力