咱们测试群里最近聊得最多的就是各种 Agent 工具。不少人拿着智能体的截屏来问说这东西真能自己点按钮、查数据、发消息了测试是不是要失业了。我仔细看了一下他们发的截图发现好多所谓的智能体本质上只是在聊天窗口里套了一层提示词离“干活”还差得远。真正让 Agent 从“聊天”进化到“干活”的关键往往就藏在一个不起眼的文本文件里也就是大家常说的 SKILL.md。我第一次接触 SKILL.md 的时候也觉得玄乎以为是什么高深的框架或者新语言。研究一阵子后发现它就是一份结构化的 Markdown 文档用来描述一个 Agent 在特定场景下“应该怎么做”。说人话就是你给 Agent 写了一份岗位说明书加操作手册它照着这个手册就能把活儿干得七七八八。对测试人员来说这东西特别适合用来固化测试经验、编写自动化脚本思路、甚至让 Agent 直接跑一遍冒烟测试流程。这篇东西不聊虚的直接拆开揉碎讲清楚SKILL.md 到底是什么、怎么写、怎么调试以及测试人怎么用它来解放双手。内容偏入门但该踩的坑和该注意的细节我都会提希望能帮你少走点弯路。1. SKILL.md 到底解决了什么问题1.1 从聊天助手到干活 Agent 的跨越先想一个场景。你让 ChatGPT 或者其他大模型帮你写一条接口测试用例它通常能给你一个像模像样的模板。但你要是让它“登录系统 - 创建订单 - 校验订单金额 - 清理测试数据”这么一连串操作它可能就懵了要么只给你输出步骤说明要么在中间某一步开始胡编乱造。原因在于通用大模型本身是个“知识型选手”不是“流程型执行者”。它知道很多概念但没有一套固定的、可重复的操作习惯。你每次问它的方式稍微变一下它给你的流程和结果就变了。这就像你让一个新来的实习生干活你跟他说“去测一下登录功能”他可能问你要测试账号、要环境地址、要预期结果你要是不说他就自己瞎猜最后给你一份乱七八糟的结果。SKILL.md 解决的就是“把专家的操作经验固化成标准流程”这个问题。它把那些你知道但没写下来的操作细节比如“先做什么后做什么”“输入数据格式是什么”“遇到异常应该记录什么”“最终输出什么格式的报告”全部用 Markdown 的格式写清楚。Agent 在执行任务时会优先读取这份文档然后按文档里定义的流程一步步执行。1.2 为什么是一个 Markdown 文件很多第一次接触 SKILL.md 的人都会问为什么不搞个 JSON 或者 YAML 配置文件非要 Markdown我自己用下来的感受是Markdown 这种格式有两个天然优势。第一个优势是“人能看懂机器也能看懂”。SKILL.md 不只是给 Agent 看的也是给团队里的测试人员看的。你用 Markdown 写的操作手册团队成员打开就能读评审的时候一眼就能看出你定义了哪些步骤、有没有遗漏边界条件。你要是用一堆 JSON 嵌套配置非技术人员根本没法参与评审。第二个优势是“字段灵活不搞严格校验”。Agent 的执行引擎拿到 SKILL.md 之后会对内容做语义解析而不是严格的语法校验。这意味着你可以用自然语言写步骤也可以塞几条命令进去写错了字段名也不会导致整个技能加载失败。这种“宽容”特性特别适合测试这种需要快速迭代的场景我经常改完一个步骤就直接用不用像改代码那样等编译。1.3 它和普通提示词的本质区别可能有人会问这跟把一大段提示词写到系统提示词里有什么区别区别还真不小。普通提示词是“一次性”的。你把它粘贴到对话窗口里它只对这次对话有效。下次你再开个新对话又得重新粘贴一遍而且每次微调都要复制一份新的版本管理基本靠文件名后缀“final_v3”这种。SKILL.md 是“可复用”的。它作为一个独立文件存放在 Agent 的技能目录里Agent 每次遇到类似任务都会自动加载它。你想改流程只需要改这一个文件所有对话都生效。普通提示词是“建议性”的。大模型看了你的提示词可能会凭心情决定听多少。SKILL.md 里如果写清楚了执行步骤和分支判断逻辑Agent 的调度层会在每次执行时强制比对当前步骤和文档定义发现偏差就能纠偏。这在测试场景里特别重要因为测试流程最怕的就是“这次测了下次忘了测某一步”。2. 动手写第一个 SKILL.md测试人视角的拆解2.1 一个通用目录结构长什么样现在主流 Agent 框架里SKILL.md 一般存放在一个特定的技能目录结构类似下面这样skills/ ├── api-test-generator/ │ ├── SKILL.md │ └── scripts/ │ └── parse_response.py ├── ui-automation-assistant/ │ ├── SKILL.md │ └── references/ │ └── selectors_guide.md └── bug-report-creator/ └── SKILL.md每个技能一个文件夹文件夹里必须有 SKILL.md其他辅助文件按需放置。这种设计很像测试项目里的“测试用例目录”每个用例放在独立的文件夹里面放着测试脚本和测试数据井井有条。2.2 从元信息到执行流逐行讲清楚我这里给一个基于常见的 Agent 技能规范比如开源社区里普遍使用的格式的示例字段含义我会逐行解释。--- name: 接口冒烟测试执行 description: 当用户要求对指定环境执行接口冒烟测试或需要验证核心接口可用性时使用。 author: QA-Team version: 1.2.0 trigger: - 跑一下冒烟 - 验证核心接口 - 执行接口冒烟测试 --- # 接口冒烟测试执行 ## 目标 在指定环境上执行核心接口的冒烟测试确认主流程可用。 ## 输入要求 - 环境地址必填格式为 http://host:port - 认证信息从当前上下文中读取不允许让用户明文提供密码 ## 执行步骤 1. 解析环境地址合并入配置模板。 2. 依次调用以下接口列表每个接口之间间隔 1 秒 - GET /api/health - POST /api/login - GET /api/dashboard - POST /api/order 3. 对响应结果做以下校验 - 状态码在 200-299 范围内 - 响应时间小于 2 秒 - 核心字段符合预期类型见 scripts/validate.py 4. 将失败项记录到临时文件中完整结果输出为 Markdown 表格。 ## 输出格式 返回一份 Markdown 格式的测试报告包含总用例数、通过数、失败数、失败详情。现在把这几个部分掰开来看。name和description是 Agent 用来判断“什么时候该用这个技能”的依据。description写得越清晰Agent 触发这个 Skill 的准确率越高。如果这里写得太泛比如“用于测试”Agent 可能在用户问“帮我写个测试计划”的时候也错误地触发它。trigger部分是“快速触发词”。用户说的话里如果包含这些词Agent 会优先考虑加载这个 SKILL.md。我建议把测试团队内部常用的黑话也加进去比如“冒烟”“验证下主流程”这样 Agent 会更“懂”你。输入要求和执行步骤是核心。输入要求决定了这个技能能不能在当前上下文里执行如果拿不到必填参数Agent 应该停下来向用户索要而不是硬着头皮编造数据。执行步骤必须清晰、可验证不能写“进行适当测试”这样模糊的描述。2.3 关键字段的编写心得在编写执行步骤时我有一个比较深的体会流程的颗粒度是个需要刻意平衡的东西。颗粒度太粗比如只写“执行系统测试”大模型还是不知道自己该干什么效果和普通提示词差不多。颗粒度太细比如写“点击坐标为(3,4)的按钮”换个分辨率就失效了而且维护成本极高。我自己建议的颗粒度标准是到“这一步需要你做出一个明确决策并产出一个可验证结果”的程度。例如“调用登录接口并校验返回码是否在 200-299 范围内”这个粒度就刚好Agent 需要做“校验”这个动作并产出“通过/不通过”的结果。至于具体怎么调用接口、怎么解析 JSON属于实现细节可以让 Agent 自己发挥或者参考 scripts 目录里的辅助脚本。注意SKILL.md 里写的是“要做什么”和“按什么顺序做”而不是“每一行代码怎么写”。把编码细节留给 Agent 和辅助脚本这个技能的可移植性和可维护性会好很多。2.4 为测试人员定制的 Skill 模板为了让各位直接上手我这边给出一个更贴近测试场景的模板你可以复制过去改改就能用。--- name: 测试用例生成器 description: 当用户需要针对某个功能模块生成测试用例或需要补全测试覆盖场景时使用。 --- # 测试用例生成器 ## 输入 - 功能模块名称必填 - 已有需求描述选填 ## 执行步骤 1. 分析输入的功能模块拆解出核心业务逻辑和外部依赖。 2. 按以下分类生成测试用例 - 正常流程用例Happy Path - 异常输入用例边界值、非法值、空值 - 权限场景用例未登录、低权限、高权限 - 依赖服务异常用例超时、返回 500、响应格式错误 3. 每个测试用例必须包含用例编号、前置条件、测试步骤、预期结果、优先级。 4. 将所有用例汇总输出为 Markdown 表格按优先级从高到低排序。 ## 注意事项 - 不要生成重复用例 - 不要生成脱离需求描述的虚构业务规则 - 如果模块信息不足先向用户提问不要强行生成3. 实测一份 SKILL.md 驱动接口冒烟测试3.1 准备一个测试环境来演练写字面上的理论很枯燥咱们直接看一份实际演练的案例。我本地起了一个模拟电商系统包含用户、商品、订单三个核心模块监听在localhost:8080。这个系统有健康检查接口、登录接口、商品查询接口和下单接口。我的目标是让 Agent 读取 SKILL.md自动完成一次接口冒烟测试并输出报告。先创建技能目录mkdir -p skills/smoke-test然后在skills/smoke-test/下创建 SKILL.md 文件内容如下--- name: 电商核心链路冒烟测试 description: 对本地或指定环境的电商核心链路执行冒烟测试用于快速判断主流程是否可用。 --- # 电商核心链路冒烟测试 ## 输入 - 环境地址必填格式 http://host:port ## 前置准备 - 检查环境地址是否可连通不可连通则不执行后续步骤 - 准备一个测试账号信息从配置文件读取不要硬编码到步骤中 ## 执行步骤 1. 调用 GET {环境地址}/api/health确认返回 200。 2. 使用测试账号调用 POST /api/user/login从响应中提取 token。 3. 携带 token 调用 GET /api/products?page1确认商品列表返回且包含至少一个商品。 4. 携带 token 和商品 ID 调用 POST /api/orders 创建订单保存返回的订单号。 5. 携带 token 调用 GET /api/orders/{订单号}确认订单状态为“已创建”。 6. 按顺序执行完以上步骤后汇总结果生成报告。 ## 输出 - 表格形式输出每一步的名称、请求地址、实际状态码、结果通过/失败、耗时。 ## 异常处理 - 如果登录失败立即终止后续步骤并报告“登录接口异常”。 - 如果创建订单失败记录失败原因继续执行读取商品列表的操作以便排查是否是商品数据问题。3.2 Agent 读取 Skill 后的实际动作为了让整个流程更透明我特意把 Agent 的中间输出拿过来了。它读取 SKILL.md 之后先确认了环境地址参数是http://localhost:8080随后 Ping 了一下健康检查接口得到 200 后按流程往下推进。Agent 从配置文件中读到了测试账号账号信息放在单独配置文件里没有写进 SKILL.md这是一个值得保持的好习惯然后请求了登录接口。实际场景中Agent 从响应体里解析出 token 字段并提取出来。整个过程 Agent 没有让我手动复制粘贴 token而是自动完成上下文传递这正是 Skill 化相比普通提示词的优势所在。接着 Agent 携带 token 查询商品列表。这一步它额外做了个动作检查返回结果里products数组不为空。这一步不是 SKILL.md 里强制要求的但是 Agent 根据“确认商品列表返回且包含至少一个商品”这个描述自动推断出要做非空校验。这说明描述性的语言只要方向明确大模型是能理解并执行的。创建订单环节稍微有点波折。第一次执行时Agent 提交的请求体里quantity字段写了个负数模拟接口返回 400 错误。Agent 查看 SKILL.md 的异常处理部分发现没有针对这种情况的特殊处理它就停下来问了我一句“接口返回 400商品数量参数有误是否改用默认数量 1 重试”。这一步表现很亮眼。如果是一段普通的提示词模型可能会自己改掉参数默默重试导致一个异常场景被掩盖。但有了 SKILL.md 的分步指引和异常处理说明Agent 选择了“停下来询问”这个行为是符合测试人员的工作习惯的毕竟测试人员不会擅自改测试数据而是先确认情况再说。重试之后订单创建成功Agent 又查了一下订单详情确认状态字段是“已创建”。最后它把整个过程的参数和结果整理到一张表里我直接用这张表填到了测试记录里省了重新整理的时间。3.3 实测下来 Skill 的优势和局限这一套跑下来我明显感觉到 SKILL.md 的价值不光是“省事”它更像一个“不会累、不会忘步骤的测试新手”。只要文档定义清晰它每次执行的路径就是稳定的。对回归测试这种重复性极强的场景来说这个特性价值非常大。局限也是有的。比如在“创建订单”这个环节Agent 第一次用了负数数量这属于它对“冒烟测试”场景理解不够深。后来我调整了 SKILL.md 中的步骤描述加了一句“使用默认数量 1不要修改”这类问题基本就杜绝了。这说明 SKILL.md 本身也是要迭代维护的它更像测试用例文档需要跟着系统变化不断更新不是写一次就能一劳永逸。4. 测试人踩坑实录与调优技巧4.1 环境与依赖的“两不管”地带我最开始写 SKILL.md 的时候天真的认为只要步骤写得够细Agent 就能在我本地跑起来。实际用起来发现一个尴尬的地带SKILL.md 告诉 Agent “要做什么”但 Agent 没有能力去做“需要登录认证的接口调用”尤其是鉴权信息怎么存、怎么读取这部分完全没头绪。解决办法是给 Skill 配一个辅助脚本让 Agent 调用脚本而不是自己去拼鉴权逻辑。你可以把常用的接口封装成一个小工具库比如用 Python 写一个api_client.py负责处理登录、token 刷新、请求签名这些通用逻辑。SKILL.md 里只写“使用 api_client.py 的 login() 方法获取 token”Agent 就知道该去调脚本而不是自己瞎写一个请求。注意不要把账号密码直接写在 SKILL.md 里。我见过有人为了让 Agent 能跑通直接把测试环境账号密码写死在步骤描述里。这个习惯非常危险SKILL.md 可能会被分享给团队其他人或者被打包进项目仓库一旦泄露就是安全事故。正确的做法是让 Agent 从环境变量或者独立的配置文件中读取敏感信息。4.2 触发不准的排查技巧如果你发现 Agent 在用户没要求测接口的时候也调用了接口测试技能或者在用户明确要求执行冒烟测试的时候却没有触发技能多半是description或trigger写得不够精确。排查的方法是打开 Agent 的日志查看它在做意图识别时的打分排序。大部分框架都支持输出候选技能及其得分。比方说你发现“接口冒烟测试执行”这个技能在用户说“帮我跑一下回归”的时候得分也很高那说明description里的关键词覆盖范围太广把“回归测试”也包含进来了。这时候把描述改得更具体写明“仅适用于对核心接口做快速可用性验证不适用于全量回归测试”触发准确率会有明显提升。另外trigger 关键词别贪多。有些朋友一上来就写 20 多个触发词想着覆盖所有说法结果导致误触发率暴增。我的建议是先写 3 到 5 个最核心的说法跑一段时间看日志再根据实际触发情况慢慢加。4.3 Agent 输出不稳定怎么让它每次都靠谱SKILL.md 虽然定义了流程但模型在执行时还是有一定的随机性。同一个技能这一次输出的报告格式是表格下一次可能是列表再下一次可能是大段文字。这种不一致在测试报告场景让人挺头疼的因为后续要解析报告内容就很麻烦。我的经验是在“输出格式”一节里要给出一个精确的模板最好精确到列名。## 输出格式 严格按照以下 Markdown 表格输出不要添加额外说明 | 步骤 | 接口 | 状态码 | 耗时(ms) | 结果 | 备注 | |------|------|--------|----------|------|------| | 健康检查 | GET /health | 200 | 85 | 通过 | 无 |有了这个强制模板模型一般会老老实实地按照列名输出。偶尔遇到不听话的情况我会再加一句“不要输出任何与表格无关的内容”效果更好。本质上Agent 的随机性要靠约束来收敛SKILL.md 里的描述约束越明确输出就越稳定。5. 进阶玩法让 Skill 之间互相配合5.1 一个用例生成技能调用一个执行技能当你手里有了两三个 Skill 之后可以考虑让它们配合工作。比如我写过两个技能一个是“接口测试用例生成器”一个是“接口冒烟测试执行器”。正常情况下是两个独立技能但我后来在用例生成器的最后一步加了一条描述“生成用例后如果用户要求执行则调用‘接口冒烟测试执行器’技能来执行其中的冒烟用例。”就这么一句话两个技能就串成了一条流水线。用户只需要说“给订单模块生成用例并跑一下”Agent 先生成用例再选中其中的冒烟用例去执行完事直接出一份报告。这个体验和之前的单技能相比完全不一样了。5.2 用目录结构管理多技能版本测试团队一般会有多条业务线的技能需求每个业务线的接口、页面、数据都不一样。我是建议按业务线建目录每个业务线下放自己的 Skill 集合skills/ ├── ecommerce/ │ ├── order-test/ │ │ └── SKILL.md │ └── payment-test/ │ └── SKILL.md ├── crm/ │ ├── lead-scoring-test/ │ │ └── SKILL.md │ └──>