Agent Skills 到底是什么？测试开发必须搞懂的下一代 AI 能力单元

最近跟几个做测试开发的朋友聊天，发现一个挺有意思的现象：大家都在用 Claude Code、Cursor 这类工具辅助写测试，但用着用着就发现不对劲。

有人说他的 Agent 跑个登录测试，在登录页卡了二十分钟——验证码图片识别不了，等了三秒就以为登录失败，直接 abort。还有人让 Agent 从 Jira 拉 bug 列表去验证，生成的代码看起来挺完整，跑起来才发现它不知道 Jira 的字段映射规则，不知道测试环境的数据库密码存在哪个密钥服务里，更不知道验证失败后该在评论里@谁。

问题出在哪？不是模型不够聪明。是它压根不知道你团队怎么干活。

Prompt 为什么不够用了

我们过去用 AI 做测试，基本套路就是写一段系统提示词：“你是资深测试工程师，请按照以下步骤执行回归测试……”然后期待它自己搞定一切。

这个思路有一个根本性缺陷：LLM 是语言模型，不是操作系统的内核。它可以告诉你“应该先登录再查询”，但面对动态验证码、偶尔超时的 API、需要滑动解锁的按钮，纯文本推理能力完全不够用。

Prompt 是说明书，告诉 Agent “拧开螺丝”。但真实任务执行，需要的是知道螺丝刀在哪个抽屉、顺时针拧几圈、遇到滑丝怎么处理——这些确定性操作流程，Prompt 给不了。

Skill 到底是什么

Anthropic 在 2025 年 10 月推出、12 月正式开放为行业标准的 Agent Skills，解决的就是这个问题。

形式上，一个 Skill 就是一个结构化文件夹。核心是一个叫 SKILL.md 的文件，包含了 YAML 元数据（技能名称、描述）和 Markdown 格式的执行指令。除此之外，还可以包含 scripts/ 目录存放可执行脚本、references/ 存放领域知识文档、assets/ 存放模板和静态资源。

但别被“文件夹”这个形式骗了。Skill 的本质是把一系列原子操作封装成一个能力单元，对外暴露清晰的输入输出，对内包含确定性的执行逻辑、错误处理、重试机制、日志上报。

举个例子。同样是让 Agent 做接口测试，没有 Skill 的时候，你每次都要在 Prompt 里写“先调登录接口拿 token，再调业务接口，断言 code=0，data 不能为空……”写一百遍也还是那一百遍。有了 Skill 之后，“接口测试”就是一个可复用的能力单元，Agent 需要时自动加载，不需要时只占约 100 个 token 的元数据空间。

Skills 和 MCP 到底什么关系

这是被问得最多的一个问题。

简单说：MCP 是连接器，Skills 是方法论。MCP 负责让 Agent 能够连接外部工具和数据源——Git 仓库、接口文档、测试平台、数据库、CI/CD 系统。它解决的是“能不能做”的问题。Skills 负责告诉 Agent 怎么组合这些工具、遵循什么流程——先做什么后做什么、遇到异常怎么处理、输出什么格式的报告。它解决的是“怎么做才对”的问题。

用一个厨房的比喻：MCP 是厨房里的刀具、炉灶、烤箱，Skills 是菜谱。你给一个学徒全套厨具，他可能切伤手指；但给他一份详细的菜谱，他就能做出一道像样的菜。

测试开发场景里怎么用

说几个具体的。

接口测试用例生成。 我们内部跑通了一套方案，核心思路是“拆解”。不让 LLM 一次性生成整个测试文件，而是把任务拆成三个独立 Skill：参数构造 Skill 负责根据参数类型和约束生成合法测试数据；依赖链处理 Skill 负责分析接口前置条件，自动生成获取 token 等 setup 代码；断言生成 Skill 根据响应 schema 和业务规则，生成状态码断言、字段存在性断言、值范围断言。每个 Skill 职责单一，通过编排器组合调用。

回归测试。 Google 为 Gemini API 准备了一套 Skill，用 117 条 Prompt 搭建评测集，对比“没有 Skill”和“启用 Skill”时模型生成的代码。测试点被拆成四个可判定的断言：Agent 有没有激活正确的 Skill？Skill 是否引用了当前版本的权威文档？生成的代码有没有调用废弃接口？工具调用能不能解释代码的来源。

SDK 版本检查。 这个场景很多人踩过坑。AI 编程助手拿着过期文档，把已经废弃的 SDK 写得非常像真的，代码能跑，但用的是旧接口。Skill 的做法是把 API 能力、当前 SDK 版本、示例代码和官方文档来源打包在一起。测试断言里明确写“must_use: [stream, error_handling]”和“must_not_use: [legacy_generate_content]”。版本错了，测试直接暴露。

一个 Skill 该长什么样

拆完企业级 Skills 库之后，有个挺关键的发现：脚本是为“人按步骤执行”设计的，Skill 是为“Agent 按意图调度”设计的。这两个物种不一样。

一个能跑稳的 Skill，至少要在三个层面做对：

注册发现层。 不只是写一段 description 就完了。Agent 做任务规划时，靠的是语义匹配加能力标签筛选。实践中有效的做法是三层筛选：领域标签（接口测试/UI验证/数据校验）、意图描述（用“是什么+解决什么问题+适用场景+不适用场景”四段式写）、前置指纹（声明执行前置条件，比如“需要登录态 Token 已缓存”）。尤其是“不适用场景”这一项，直接决定 Agent 会不会滥用你的 Skill。

能力抽象层。 输入 Schema 要用 JSON Schema 做硬约束，别靠自然语言描述参数。Agent 对结构化约束的遵循程度远高于自然语言。能写枚举就写枚举，别让 Agent 自由发挥。

副作用管理层。 声明 allowed-tools 限制技能只能访问特定工具。日志分析技能不该有权访问数据库删除工具。这不是可选项，是安全底线。

最后说几句

字节 2026 年春招的测试开发岗位，JD 里悄悄多了一行：“对 AI Agent 有深入理解和实践经验”。阿里通义实验室的技术专家岗，明确要求掌握 Skill 封装和工程化落地能力。

这不只是招聘词的堆砌。手工测试岗位需求在降，全栈测开需求在涨，“熟悉 MCP 协议”“具备 Skill 封装能力”正在从加分项变成硬性门槛。

对测试开发来说，Skill 的核心价值不在于“让 AI 帮你写脚本”，而在于把你脑子里那些值钱的测试经验——接口参数该怎么构造、断言该怎么设计、失败后该怎么判断——从“人的经验”变成“可调用的工程能力”。

这件事，越早开始越好。