Agent 测试实战系列 · 第 1 篇
阅读对象：测试工程师 / QA / SDET ｜ 预计阅读：12 分钟
本篇目标：搞懂 Agent 是什么、它凭什么"测不准"，以及你该往哪儿使劲。

---

先说一个真实得扎心的故事。

某团队做了一个客服 Agent。内部测试准确率 90 多分，Demo 演示行云流水，老板看完很满意，拍板：上线！

结果上线一周，客服工单直接炸了。用户截图满群飞：“这 AI 是智障吧”“问它退换货，它给我推荐新品”。

团队回去一查评测分数——还是 90 多分。

分数没变，产品却已经翻车了。

问题出在哪？不是模型不行，而是：他们压根没有一套方法，去判断这个 Agent 到底行不行。而这句话，大概率也会戳中屏幕前的你——因为传统的测试方法论，在 Agent 面前，正在批量失效。

接下来的几周，我会用一个系列，手把手带你建立"Agent 测试"的完整能力栈：从原理认知、黑盒判定框架，到评测体系搭建、CI 落地、生产质量与安全对抗，最后还有面试实战。今天是第 1 篇，先把地基打牢。

一、先别慌：Agent 到底是什么？

很多测试同学一听"AI Agent"就觉得是算法团队的事。错了。Agent 已经是你测的系统的一部分，甚至是核心部分——就像当年你测接口、测微服务一样，现在你迟早要测 Agent。

那 Agent 到底是什么？

一句话版本：Agent 是一个能自己"想"和"做"的软件系统——你给它一个目标，它自己拆解任务、调用工具、观察结果、修正动作，直到把目标完成。

它和大模型的区别在于：大模型是"你说一句、它回一句"的对话机器；Agent 是"你布置任务、它自主执行"的数字员工。

拆开看，一个典型 Agent 有四个核心部件：

• 大脑（LLM）：负责推理与决策，是 Agent 的智力来源；
• 规划（Planning）：把"帮我订明天去上海的机票"这种大目标，拆成"查航班→比价格→下单→确认"一串子任务；
• 工具（Tools）：Agent 的手和脚——调用 API、搜索网页、读写数据库、操作浏览器；
• 记忆（Memory）：短期记忆（本轮对话上下文）和长期记忆（历史经验、用户偏好）。

图1｜Agent 的自主工作循环：目标进来，闭环出去

注意看图 1 的循环：感知目标 → 规划拆解 → 调用工具 → 观察反馈 → 更新记忆，然后进入下一轮，直到任务完成。每一轮决策都经过大模型，这意味着：同样的任务，它每次"走的路"都可能不一样。

这正是 Agent 与传统软件最本质的区别，也是所有测试难题的根源。

二、一次任务 = 一条"轨迹"，而不是一行结果

传统测试里，我们测的是"输入 → 输出"。Agent 世界里，这个模型彻底不够用了。

给你看个经典例子（业内流传甚广）：让 Agent 完成"帮我订明天北京到上海的航班"。

同样是成功，它可以走出三种完全不同的路径：

• 路径 A：查航班 → 选最便宜 → 下单 → 成功（3 步，干净利落）
• 路径 B：查航班 → 按时间过滤 → 挑选 → 下单 → 成功（4 步，有冗余）
• 路径 C：查航班 → 接口报错 → 自动重试 → 下单 → 成功（有重试，说明工具不稳定）

问题来了：如果只测"最终有没有订上"，三条路径全部通过，得分一模一样。

但路径 C 的用户体验是灾难——重试意味着延迟翻倍，失败率被"最终成功"四个字掩盖了。只有看完整执行过程，才能发现这些差异。

这个过程，就是 Agent 领域的核心概念：轨迹（Trajectory）——Agent 从接收任务到交付结果之间，每一步决策、每一次工具调用、每一个中间结果的完整记录。

记住这个词。它比"输出结果"重要十倍。本系列后面讲评测体系、讲生产监控，全都绕不开它。

把这两个概念（工作循环、轨迹）装进脑子，我们就可以回答那个灵魂问题了。

三、为什么你会的测试方法，正在失灵？

先看一张对比图，把传统系统（包括普通接口和 Web 应用）和 Agent 摊开比一比。

图2｜为什么"老办法"失灵：确定性 vs 不确定性

从上到下，五个维度，逐一拆解：

1. 输出从"可复现"变成"随机"

传统接口：同一入参，同一输出。断言写"等于 200"“包含某某字段”，跑一万遍都一样。

Agent 呢？同一个问题，今天答对，明天可能就给你整出新花样——大模型天生带随机性，即使温度设成 0，不同版本、不同区域的推理结果也可能波动。

后果：字符串级断言全面失效。你断言"回答里包含’退货政策链接’“，模型换个说法你就误报；你断言"不包含 XX”，模型今天没提，明天可能就提了。

2. 路径从"固定代码"变成"现场生成"

传统系统：代码路径写死了，分支覆盖跑一跑，覆盖率一算，心里有底。

Agent：每一步走哪条路，是模型现场"想"出来的。一千次执行，可能有一千种排列组合。穷举？不存在的。

后果：基于"覆盖代码路径"的测试设计方法，在 Agent 的决策层上基本失效——你覆盖不了"模型的思维路径"。

3. 判定从"布尔对错"变成"目标达成 + 过程质量"

传统断言是二值的：对，或者错。

Agent 的"对"有无数种写法。同一个指令，回"好的，已为您下单"和回"订单已提交，订单号 12345"都算完成，但后者信息更完整、更可信。

后果：你要判定的东西变多了——不只是"结果对不对"，还有"过程合不合理"（该调工具时调没调？有没有多余调用？）、“信息可不可信”（是不是忠于工具返回？还是编的？）。

4. 环境从"可控"变成"即输入"

传统测试里，依赖都可以 Mock——数据库、第三方 API，全换测试桩，环境干干净净。

Agent 的世界里，外部环境本身就是它推理的输入：工具返回什么、API 通不通、数据脏不脏，都会直接影响 Agent 的行为。你 Mock 掉一切，测的就不是 Agent 了；你不 Mock，测试结果又不可复现。

后果：测试环境的设计变成一门新学问——哪些层可以替身、哪些层必须真实，需要精心权衡（这个坑，系列第 4 篇专门填）。

5. 风险从"代码约束"变成"自主行动"

普通软件再复杂，权限在架构层就锁死了：没有数据库权限，代码写得再野也删不了库。

Agent 不一样——它被授予了真实工具：能调 API、能写数据库、能发邮件、甚至能执行部署脚本。权限给了它，约束就只剩"提示词里的一句叮嘱"。

后果：测试必须新增一个传统 QA 几乎不碰的维度——安全与合规：它会不会被提示注入骗走？会不会把敏感信息泄露给用户？用户嘴上说"我已授权"，它会不会就真去执行高风险操作？

小结：不是测试没用，是"测什么"变了

传统测试的关注点是"验代码"——代码按不按设计跑。Agent 测试的关注点变成了三件事：

验行为 + 验目标 + 验边界。

这不是测试的末日，而是测试的范式转移。而每一次范式转移，都是旧技能贬值、新技能升值的时候——问题是，你站在哪一边。

四、危与机：这轮洗牌，测开反而站上了牌桌

先看两组被业内广泛引用的数据（Gartner 2026 年报告，经中文社区转述）：

• 缺乏系统化评测体系的 Agent 项目，上线后故障率是成熟项目的 4.2 倍；
• 到 2027 年，40% 的 Agentic AI 项目会被直接砍掉。

翻译成人话：Agent 项目正在大规模上线，也正在大规模翻车。而翻车最狠的，恰恰是那些"没有专业质量保障能力"的团队。

Anthropic 工程团队在《Demystifying evals for AI agents》里也说得直白：他们见过太多 90% benchmark 分数、却照样在生产环境翻车的团队。Benchmark 与生产之间的鸿沟，从来不是模型能力问题，而是评测方法论问题。

那么问题来了：谁能把 Agent 的"行不行"科学地说清楚？——这正是测试工程师的看家本领，换了个战场而已：

你的老技能	迁移后的新技能
设计测试用例	设计评测集与场景库
写断言	设计判定标准（结果 + 过程 + 安全）
搭测试环境	设计可控的 Agent 环境（替身 / 录制 / 沙箱）
线上监控告警	生产轨迹采样、回放与回归
自动化与 CI	把评测嵌入 CI/CD 流水线

事实上，市面上已经出现"AI 质量保障工程师""Agent 测试开发工程师"这类岗位，要求正好落在上表右列。这不是贩卖焦虑——需求端真的在变，而且变得很快。

五、你要补的课，我已经排好了

学习最怕东一榔头西一棒子。这个系列就是一条层层递进的完整路线，从"看得懂"到"测得动"再到"守得住"：

图3｜七站路线：认知 → 入门 → 进阶 → 实战 → 深入 → 生产 → 面试

• 第 2 篇｜黑盒五维判定框架：结果正确性、数据可信性、行为合理性、安全合规性、稳定与终止性。先学会"怎么判对错"，再谈工具和平台。
• 第 3 篇｜从 0 搭建评测体系（Eval）：三层评估架构（决策层 / 任务层 / 生产层）、评测集怎么造、LLM-as-Judge 怎么用、为什么"只测端到端成功率"远远不够。
• 第 4 篇｜分层测试落地：单元 → 集成 → E2E → CI；StubLLM 与 VCR 录制回放；为什么"全 Mock"有时比"不 Mock"更危险。
• 第 5 篇｜轨迹与数据：benchmark 的用法与坑（AgentBench、τ-bench、BFCL……）、轨迹级评估、评测数据工程。
• 第 6 篇｜生产质量与安全：监控采样、回放回归、提示注入攻防、失败兜底与治理。
• 番外篇｜面试实战："你会怎么测一个 AI Agent？"高分回答框架 + 高频追问。

每一篇都会配图、配清单、配可以直接抄的模板，目标是让你读完就能在项目里用起来。

六、名词速查：测试工程师的 Agent 词典

后面几篇会高频使用这些词，先混个脸熟：

• Agent（智能体）：能自主规划、调用工具、完成目标的 AI 系统，本系列主角；
• LLM（大语言模型）：Agent 的"大脑"，负责推理与生成，本身不做工具调用；
• 轨迹（Trajectory）：Agent 从接任务到交付之间每一步决策与工具调用的完整记录，是 Agent 测试的核心观测对象；
• Eval（评测）：给 AI 系统一个输入、对其输出应用评分逻辑的测试过程，可自动化、可重复；
• LLM-as-Judge（大模型当裁判）：用另一个大模型给 Agent 的行为打分，常用于主观维度评估；
• Benchmark（基准测试集）：标准化评测集，如 AgentBench、τ-bench，适合横向对比，但不能完全代表生产表现；
• Prompt Injection（提示注入）：通过输入内容诱导 Agent 越权或执行恶意指令，是 Agent 安全测试的头号敌人；
• StubLLM / Mock：用可控的模型替身或假响应代替真实模型，让测试确定、快速、不烧钱；
• LLM-as-a-Judge 陷阱：裁判模型本身可能偏心、偏懒，需要定期用人工标注校准。

读完这篇，你可以用三句话自测：

1. 我能说清 Agent 和大模型的区别吗？（区别在于"自主执行"四个字）
2. 我能解释"为什么字符串断言在 Agent 上会失效"吗？（非确定性 + 多种正确写法）
3. 我能说出 Agent 测试的三个新关注点吗？（验行为 + 验目标 + 验边界）

答不上来的，回头再看一遍对应的章节；全答上来的，恭喜，第 2 篇的判定框架你学起来会非常快。

写在最后

回到开头那个客服 Agent。它的问题从来不是"模型不够聪明"，而是团队拿"测模型"的思路去测 Agent——看几个 case、跑几个 demo、打个分，就敢上线。

Agent 时代，测试的门槛不是在变低，而是在变高。

高在你要理解一种全新的系统形态；高在你要把"质量"从结果层面推进到过程层面；高在你要对"不可控"建立一套可控的工程方法。

但门槛高，恰恰意味着护城河深。当别人还在用传统思路硬测 Agent 的时候，你已经能体系化地回答"它到底行不行"——这就是你未来三年的核心竞争力。

下一篇，我们上手第一件武器：黑盒视角下的五维判定框架——不碰一行源码，也能把 Agent 测出个所以然。

觉得有用，点个赞 + 在看，转发给同样在转型路上焦虑的测试朋友。评论区聊聊：你们团队的 Agent，现在是怎么测的？踩过哪些坑？我会在后续文章里针对性拆解。

🎬 一个小彩蛋：常有读者问"有没有能直接看的实操演示"——我把《AI 在测试领域应用的探索》整理出来了，里面是 AI 辅助用例设计、缺陷分析的真实项目演示，正好是这篇文章的"实战篇"。资料已经打包好了，在公众号对话框回复「agent」即可自动获取，随时回复随时领。

---

📌 系列预告：第 2 篇《别再把 Agent 当接口测：黑盒五维判定框架》——下一篇见。