如果说传统软件测试是在验证：
“程序有没有按照设计好的流程执行？”
那么 AI Agent 测试需要回答一个更加复杂的问题：
“一个可以自主规划、调用工具并动态调整执行路径的系统，应该怎么测试？”
这是 AI 应用进入企业之后，测试工程师面临的一个新问题。
传统自动化测试通常是：
输入
↓
固定流程
↓
固定接口
↓
预期结果
而 Agent 更像：
用户目标
↓
Agent理解任务
↓
制定计划
↓
选择工具
↓
执行工具
↓
观察结果
↓
重新规划
↓
继续执行
↓
最终结果
同一个用户需求，Agent 可能走出完全不同的执行路径。
因此，测试 Agent 不能只验证最终答案。
执行过程本身，也必须成为测试对象。
一、什么是 AI Agent？
目前很多 AI 应用都可以调用大模型，但“调用大模型”并不等于 Agent。
一个典型 Agent 通常包含几个核心部分：
用户目标
↓
┌───────────┐
│ Agent │
│ 推理/规划 │
└─────┬─────┘
↓
┌─────────────┐
│ Tool选择/调用 │
└──────┬──────┘
↓
┌────────────┼────────────┐
↓ ↓ ↓
搜索工具 数据库工具 API工具
│ │ │
└────────────┼────────────┘
↓
执行结果
↓
Agent观察
↓
重新规划
例如：
用户说：
“帮我查一下订单，如果符合退款条件就提交退款。”
Agent可能执行：
查询订单
↓
判断订单状态
↓
判断退款条件
↓
调用退款接口
↓
确认退款结果
↓
返回用户
注意：
这里已经不是简单的接口调用。
Agent实际上在做：
感知 → 决策 → 行动 → 观察 → 再决策。
这也是 Agent 测试和传统接口测试最大的区别。
二、为什么传统测试方法不够用了？
假设传统接口：
POST /refund
输入：
{
"order_id": "10001"
}
预期：
{
"code": 200
}
测试非常直接：
response = refund(order_id)
assert response["code"] == 200
但是如果由 Agent 决定什么时候调用退款接口：
测试就变成了：
用户请求
↓
Agent
↓
是否需要查询订单？
↓
是否需要身份验证？
↓
是否满足退款条件？
↓
是否调用退款工具？
↓
退款成功后是否再次确认？
这里至少出现了四类新的测试问题：
- 决策是否正确？
- 工具选择是否正确？
- 参数传递是否正确？
- 执行路径是否存在异常？
所以：
Agent 测试不能只测“结果”，还要测“行为”。
三、Agent测试的第一层：任务是否完成？
最基础的测试仍然是：
最终任务是否完成。
例如：
测试目标：
查询订单10001的状态。
预期：
订单状态：已支付
Agent返回：
订单10001目前处于已支付状态。
这属于：
Task Success（任务成功率）
可以把测试抽象成：
def test_order_query(agent):
result = agent.run(
"查询订单10001的状态"
)
assert "已支付" in result
但这种测试还不够。
因为 Agent 可能“碰巧”给出了正确答案。
例如：
Agent根本没有调用订单查询工具，而是自己猜了一个答案。
最终结果可能看起来正确。
但是从质量角度：
这是一个严重问题。
所以需要继续向下测试。
四、第二层：测试Agent是否选择了正确的工具
假设系统提供三个工具：
tools = [
"query_order",
"refund_order",
"search_knowledge"
]
用户说：
“查询订单10001的状态。”
正确行为应该是：
query_order
而不是：
refund_order
或者：
search_knowledge
因此，我们可以记录 Agent 的 Tool Call。
例如：
trace = agent.run(
"查询订单10001的状态"
)
print(trace.tool_calls)
期望：
[
{
"tool": "query_order",
"args": {
"order_id": "10001"
}
}
]
测试：
assert len(trace.tool_calls) == 1
assert trace.tool_calls[0]["tool"] \
== "query_order"
这就从：
结果测试
升级成：
行为测试。
五、第三层：工具参数是否正确？
选择正确工具还不够。
Agent可能：
工具选对了。
参数却错了。
例如：
正确：
{
"order_id": "10001"
}
Agent却传：
{
"order_id": "10010"
}
最终：
查询到了错误订单。
因此需要对 Tool Call 做参数校验。
例如：
call = trace.tool_calls[0]
assert call["tool"] == "query_order"
assert call["args"]["order_id"] == "10001"
对于企业级 Agent，这一点尤其重要。
因为 Agent 调用的工具可能包括：
- 数据库查询
- CRM操作
- 支付系统
- 工单系统
- 代码执行
- 文件操作
如果参数错误：
可能造成真实业务风险。
六、第四层：测试Agent执行路径
Agent最大的特点之一：
执行路径不是固定的。
例如：
用户请求
↓
查询订单
↓
判断订单状态
/ \
正常 异常
↓ ↓
退款 转人工
测试人员需要考虑：
路径A：
查询 → 判断 → 退款
路径B：
查询 → 判断 → 转人工
路径C：
查询失败 → 重试 → 查询成功 → 退款
路径D：
查询失败 → 重试 → 仍失败 → 转人工
如果只写一个测试：
test_refund_success()
很可能只覆盖了路径A。
这就是 Agent 测试中非常典型的：
路径覆盖不足。
七、用图模型理解Agent执行路径
可以把 Agent 的执行过程抽象成一个有向图：
START
↓
QUERY_ORDER
↓
CHECK_STATUS
/ \
/ \
ELIGIBLE INELIGIBLE
↓ ↓
REFUND HUMAN
↓
END
每一个节点：
代表一个状态或者动作。
每一条边：
代表一次状态转移。
于是：
Agent测试就可以转换成一个图搜索问题。
八、用DFS自动探索Agent路径
例如：
graph = {
"START": ["QUERY"],
"QUERY": ["CHECK"],
"CHECK": ["REFUND", "HUMAN"],
"REFUND": ["END"],
"HUMAN": ["END"]
}
我们可以使用 DFS：
def dfs(node, path, graph):
path = path + [node]
if node == "END":
return [path]
results = []
for next_node in graph[node]:
results.extend(
dfs(
next_node,
path,
graph
)
)
return results
执行：
paths = dfs(
"START",
[],
graph
)
for path in paths:
print(" -> ".join(path))
得到：
START -> QUERY -> CHECK -> REFUND -> END
START -> QUERY -> CHECK -> HUMAN -> END
这时候，测试平台就可以自动发现：
当前Agent模型至少存在两条执行路径。
进一步可以计算：
- 路径覆盖率
- 节点覆盖率
- 工具覆盖率
- 异常路径覆盖率
九、Agent测试最容易忽略的问题：死循环
这是传统接口测试和 Agent 测试之间一个非常明显的区别。
例如：
查询订单
↓
查询失败
↓
重新查询
↓
查询失败
↓
重新查询
↓
查询失败
↓
……
如果没有限制：
Agent可能一直执行。
因此，测试系统应该监控：
MAX_STEPS = 10
if trace.step_count > MAX_STEPS:
raise AssertionError(
"Agent可能存在循环执行问题"
)
更进一步，可以检测：
状态是否重复。
例如：
visited = set()
for step in trace.steps:
state = (
step.tool,
str(step.args)
)
if state in visited:
print("发现重复执行状态")
visited.add(state)
这样可以帮助发现：
- 重复调用
- 无效重试
- Agent死循环
十、Agent测试还需要关注“越权调用”
这是企业真正落地 Agent 后非常重要的一类测试。
假设一个 Agent 拥有：
查询订单
退款
修改地址
删除订单
用户输入：
“帮我查询订单。”
正常情况下：
只应该调用：
query_order
如果 Agent因为错误推理：
调用：
delete_order
这就不是普通Bug了。
而属于：
高风险Agent行为。
因此测试中需要建立：
allowed_tools = {
"查询订单": ["query_order"],
"退款": [
"query_order",
"refund_order"
]
}
然后验证：
for call in trace.tool_calls:
assert call["tool"] \
in allowed_tools["查询订单"]
这类测试可以逐渐发展为：
Agent权限与安全测试。
十一、Agent测试应该建立哪些核心指标？
如果企业准备建设 Agent 测试平台，仅仅统计：
“回答正确率”
是不够的。
建议至少建立以下指标。
| 指标 | 关注点 |
|---|---|
| Task Success Rate | 任务最终是否完成 |
| Tool Selection Accuracy | 工具选择是否正确 |
| Tool Argument Accuracy | 工具参数是否正确 |
| Path Coverage | 执行路径覆盖程度 |
| Step Efficiency | 完成任务需要多少步骤 |
| Loop Rate | 是否存在循环执行 |
| Failure Recovery | 工具失败后能否恢复 |
| Safety Violation | 是否存在越权行为 |
| Latency | 完成任务耗时 |
| Cost | Token/API调用成本 |
这意味着：
Agent测试已经逐渐从传统的：
功能测试
发展成：
行为 + 性能 + 安全 + 成本 + 可靠性测试。
十二、工具失败以后，Agent能不能恢复？
这是一个非常值得测试的场景。
例如：
Agent
↓
调用订单查询
↓
API 500
此时优秀的 Agent 应该：
发现工具失败
↓
判断是否可以重试
↓
重试
↓
仍然失败
↓
切换备用方案 / 转人工
而不是：
API失败
↓
继续调用同一个接口
↓
继续失败
↓
无限重试
因此可以设计：
def test_tool_failure_recovery(agent):
mock_tool_error(
"query_order",
status_code=500
)
result = agent.run(
"查询订单10001"
)
assert result.status \
in ["fallback", "human", "failed"]
这个测试实际上是在验证：
Agent的故障恢复能力。
十三、Agent测试和传统自动化测试最大的区别
可以简单总结：
传统自动化测试
输入
↓
固定流程
↓
接口
↓
断言
而：
Agent测试
用户目标
↓
Agent规划
↓
工具选择
↓
参数生成
↓
工具执行
↓
状态观察
↓
重新规划
↓
最终结果
所以 Agent 测试不能完全照搬 Selenium、接口自动化的思路。
测试对象已经从：
静态系统
变成：
动态决策系统。
十四、测试工程师应该如何建立Agent测试体系？
一个比较完整的 Agent 测试体系，可以拆成五层：
┌────────────────────────────┐
│ 业务结果测试 │
│ Task Success / Accuracy │
├────────────────────────────┤
│ Agent行为测试 │
│ Tool / Path / State / Loop │
├────────────────────────────┤
│ 模型能力测试 │
│ Reasoning / Hallucination │
├────────────────────────────┤
│ 安全与权限测试 │
│ Tool Permission / Data │
├────────────────────────────┤
│ 基础设施测试 │
│ API / DB / MQ / Network │
└────────────────────────────┘
这时候，传统测试工程师的能力仍然有价值。
因为：
接口测试、自动化测试、Mock、性能测试、日志分析等基础能力并没有消失。
只是：
测试对象发生了变化。
十五、AI质量工程师真正需要测试的是什么？
如果把传统测试和 Agent 测试放在一起，会发现一个很有意思的变化。
传统软件：
程序按照规则执行。
AI Agent：
系统根据目标进行决策。
因此未来质量工程师需要回答的问题也发生了变化：
不是只问：
“结果对不对？”
而是进一步问：
“为什么做这个决策？”
“为什么调用这个工具？”
“为什么走这条路径？”
“失败以后能不能恢复？”
“有没有执行不应该执行的操作？”
“同样的任务，多次执行是否稳定？”
这些问题构成了 Agent Quality Engineering 的核心。
结语
AI Agent正在让软件从：
按照程序执行
逐渐走向：
根据目标自主执行。
这对开发是一次架构变化。
对测试同样是一场变化。
过去我们验证：
输入 → 输出
现在需要验证：
目标
↓
决策
↓
行动
↓
观察
↓
再决策
↓
结果
因此，Agent 测试真正的难点，并不是“怎么调用一个大模型”。
而是：
如何建立一套能够观察、度量和约束 Agent 行为的质量工程体系。
这可能正是未来 AI 质量工程最值得研究的方向之一。
