会用WorkBuddy生成用例，和懂Agent测试，是两件事

一个很常见的应届生场景：打开WorkBuddy，输入一段需求描述，几十秒后生成一屏测试用例，复制、粘贴、交作业。操作很熟练，产出也不算少。

但如果面试官接着问一句——“你觉得WorkBuddy是怎么把这条用例生成出来的？它调用了哪些工具？哪一步如果失败了，它会怎么兜底？”——空气往往会安静下来。

不是你不会用产品。是你只用到了产品的最外层。

2026年测试岗分层的真正分界线，不在“会不会用某个AI产品”。行业里已经有人说得很直白：真正值得测试工程师学习的，不是WorkBuddy或任何一个具体产品，而是它背后的 Agent + MCP/Tool + 测试框架 + 业务系统这套结构。会用WorkBuddy生成用例，和懂Agent测试，是两件不同层面的事。

你让它生成用例，它到底做了什么？

大多数人看到的是“输入需求 → 输出用例”。但中间发生的事，比这个界面复杂得多。

WorkBuddy的官方拆解里有一句话很关键：模型是一个无状态的函数。一次模型调用可以写成：输出 = 模型（系统提示词 + 工具 + 会话历史 + 其他上下文 + 用户指令）。模型本身不保存记忆，对话的连续性、工作进度，全部由产品侧维护状态再注入。

这意味着什么？意味着你看到的“生成用例”这个结果，不是模型一个人完成的。它背后至少叠了四层：模型生成调用请求 → Agent 校验参数、检查权限、执行工具 → 把执行结果作为 tool result 放回上下文 → 模型基于新的上下文决定下一步。

如果你让WorkBuddy去读一份腾讯文档里的需求再生成用例，它需要先通过连接器打通腾讯文档；如果你让它根据会议纪要提取测试点，它要先加载腾讯会议连接器，把字稿拉进来，才能开始“生成”。你看到的“一键生成”，实际是一条工具调用链在支撑。

而这条链，才是Agent测试真正要看的对象。

真正拉开差距的动作：把一次工具调用拆成“决策—执行—观察—反馈”

对应届生来说，不需要一上来就会写复杂的Agent代码。你需要的是一种拆解意识：把WorkBuddy的一次操作，还原成一条可观察、可追问的链路。

以“驱动浏览器做UI验证”为例。你看到的是它打开了页面、做了断言、截了图。拆开看：

决策层：Agent根据当前任务，决定“下一步应该调用浏览器工具，而不是去查数据库”。这个判断依赖的是系统提示词、可用工具列表和当前上下文。如果决策错了，后面全是白费。

执行层：Agent校验参数（URL、选择器、操作类型），检查权限（这个工具在当前状态下是否允许被调用），然后执行。这里的一个核心测试点是：参数校验和权限边界是不是真的生效了，而不是假设它们“应该”生效。

观察层：工具返回了结果——页面加载成功或失败、元素找到了或没找到。这个结果被放回上下文，成为下一轮决策的输入。这里要问的是：如果工具返回了一个异常结果，Agent能不能正确识别，而不是把异常当成正常继续往下走。

反馈层：模型基于观察结果决定“继续下一步”还是“重试”还是“终止”。大厂面试里已经有人在问这个了：Agent调用工具失败，重试和兜底机制是什么。同一个工具连续失败怎么办？Agent陷入循环调用怎么办？这些问题的答案，不在“生成用例”的层面，在工具调用失败后的行为层面。

WorkBuddy桌面级、过程可见的特点，恰恰给了应届生一个不需要生产环境就能练这件事的机会。你看得见它调了哪些工具、哪些步骤可以被打断、哪些输出明显需要人工兜底。这种“把黑盒打开看一眼”的习惯，比多生成100条用例值钱得多。

一个Skill和一段Prompt的区别，就是“临时判断”和“可评测规则”的区别

这是另一个分水岭，而且对应届生极其友好——因为它不需要你会写后端，只需要你理解什么叫把规则做成可验证的东西。

WorkBuddy的官方材料里有一句定义得很清楚：Prompt = 任务，Skill = 做法。Prompt只影响这一次对话；Skill是把一类任务的做法，永久地装进Agent的身体里。更关键的是，Skill是文件，所以它可以Git管理、版本回滚、团队共享、A/B测试、自动评测、持续更新。

用测试的语言翻译一下：Prompt是你每次临时口头交代的测试步骤，Skill是你沉淀下来的、可以被反复验证的测试标准。

一个具体的应届生练习：你把“测试用例质量评审”的五项标准写成SKILL.md——需求可追溯、边界覆盖、前置条件、操作步骤、预期结果可验证——让Agent按照这个固定规则去检查已有用例。然后，你反过来评测这个Skill本身：故意埋入“只测8位和20位、不测7位和21位”的边界漏洞，看它的召回率怎么样、精确率怎么样。

这个循环——“封装规则 → 验证规则是否有效 → 迭代规则”——就是测试工程化最朴素的原型。你在面试里讲“我写了一个用例质检Skill，并用20条已知缺陷用例测了它的检出率”，远比讲“我熟悉WorkBuddy”有分量。因为前者证明的是一种可迁移的工程判断力，后者只证明你会点按钮。

Harness层，才是Agent测试真正的主战场

如果只记一个概念，对应届生来说，应该是Harness。

WorkBuddy团队自己的总结是：Agent能否稳定完成任务，不只取决于模型强弱，还取决于它如何被引导、上下文如何组织、工具和权限如何接入、结果如何验证，以及Harness如何把一次次不确定的模型输出，转化为更稳定、可控的执行过程。Harness不是某个工具，是包裹在模型外面的那层工程环境——编排循环、工具调用、状态、超时、重试、审计和终止条件，都属于它。

为什么这对测试人重要？因为传统测试的断言对象是“输出”，Agent测试的断言对象扩展到了“状态迁移路径”和“控制面行为” 。一个Agent的输出可能是“合理”的，但它中间跳过了必要步骤、调用了不该调用的工具、在失败时无限重试而没有熔断——这些问题在只看最终结果的测试里完全不可见。

大厂面试已经在系统性地考这些东西了。2026年字节“测试开发工程师-开发者AI”岗位的JD里，硬性要求出现了“对AI Agent有深入理解和实践经验”；面试官会指着架构图问：“Agent在这里调用工具失败，你的重试和兜底机制是什么？”。Harness工程、Agent异常处理、模型幻觉测试，正在成为一线团队筛选候选人的真实门槛——“不会建测试Agent，就难进一线团队”。

而WorkBuddy恰好提供了一个低门槛的观察窗口。你不需要自己从零搭一个Harness才能理解它。你只需要在做每一次操作时多问三句话：它现在在执行哪一步？这一步如果被打断，应该从哪里恢复？这一步的输出，什么情况下需要人来确认而不是自动放行？ 这三句话，就是Harness视角的起点。

应届生现在可以做的，不是“学更多工具”

2026年测试岗的数据已经很直白了：手工测试岗位需求同比下降47%，AI测试岗位需求同比激增455%。分层的本质不是“AI取代人”，而是价值在从“执行”向“定义和验证”迁移。

对应届生来说，最危险的状态不是“不会”，而是停在“会用” 。会用WorkBuddy生成用例，和会用Excel拉一张表，在能力结构上没有本质区别——都是工具操作。真正让你进入另一层的，是你能不能做到这三件事：

第一，拆开一次调用。 选一个你常用的WorkBuddy功能，把它的“决策—执行—观察—反馈”链路写下来，标出至少一个可能失败的点和一个需要人工兜底的点。

第二，封装一条规则。 把你写用例时脑子里那套“什么样的用例算合格”的判断，写成一份Skill，然后设计一个小评测集去验证它到底有没有用。

第三，追问一个“如果”。 如果工具超时了会怎样？如果模型给出了一个看起来合理但实际越权的操作会怎样？如果同一个步骤被重复执行了三次，系统怎么发现？——这些“如果”，就是Agent测试的入口。

你不需要在半年内变成一个能搭复杂Agent系统的工程师。但你需要从现在开始，把每一次对AI产品的使用，变成一次对Agent行为的观察。工具会换，产品会迭代，但“把一次不确定的输出拆解成可验证的链路”这个能力，不会过时。

而这，恰恰是“只会写用例”最值得被替换掉的部分——不是用例本身没用了，是你值得站在比用例更高的那一层。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。