如果说传统软件测试是在验证：

那么 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 ↓是否需要查询订单？ ↓是否需要身份验证？ ↓是否满足退款条件？ ↓是否调用退款工具？ ↓退款成功后是否再次确认？

这里至少出现了四类新的测试问题：

1. 决策是否正确？
2. 工具选择是否正确？
3. 参数传递是否正确？
4. 执行路径是否存在异常？

所以：

三、Agent测试的第一层：任务是否完成？

最基础的测试仍然是：

最终任务是否完成。

例如：

测试目标：

预期：

订单状态：已支付

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"]

用户说：

正确行为应该是：

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) == 1assert 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↓ ↓REFUNDHUMAN↓ 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 -> ENDSTART -> QUERY -> CHECK -> HUMAN -> END

这时候，测试平台就可以自动发现：

当前Agent模型至少存在两条执行路径。

进一步可以计算：

• 路径覆盖率
• 节点覆盖率
• 工具覆盖率
• 异常路径覆盖率

九、Agent测试最容易忽略的问题：死循环

这是传统接口测试和 Agent 测试之间一个非常明显的区别。

例如：

查询订单 ↓查询失败 ↓重新查询 ↓查询失败 ↓重新查询 ↓查询失败 ↓……

如果没有限制：

Agent可能一直执行。

因此，测试系统应该监控：

MAX_STEPS = 10if 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 测试平台，仅仅统计：

“回答正确率”

是不够的。

建议至少建立以下指标。

这意味着：

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"]

这段测试本质上要确认的是：当调用 query_order 工具时人为模拟出一个 500 错误，agent 在执行“查询订单10001”这条指令后，返回状态是否会落在 "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 测试真正的难点，并不是“怎么调用一个大模型”。

而是：

这可能正是未来 AI 质量工程最值得研究的方向之一。