Agent Skills 开放标准来了：AI Agent 终于有了“可复用技能包”

导读过去一年很多人都在聊 Agent。会写代码的 Agent、会操作浏览器的 Agent、会调用工具的 Agent、会自动执行任务的 Agent听起来都很强。但真正落地时问题也很明显同一个任务每次都要重新解释一遍流程。 同一套经验不同 Agent 之间很难复用。 同一个项目换个工具、换个模型之前沉淀的规则就失效了。 一个团队内部积累的操作规范、测试流程、排查经验很难变成 Agent 稳定可调用的能力。所以Agent 真正缺的可能不是更大的模型而是一套能把“经验”封装起来的标准。这也是 Agent Skills 这个开放标准值得关注的原因。Agent Skills 是一个轻量级、通用、模型无关的 AI Agent 技能开放格式。它的核心不是再造一个复杂框架而是用一个简单的目录和一个SKILL.md文件把某类任务的流程、规则、脚本、模板和参考资料封装成一个可复用的技能包。官方规范中一个 Skill 至少包含SKILL.md并可选包含scripts/、references/、assets/等目录。(Agent Skills[1])对于测试开发、自动化测试、AI 测试平台、企业内部 Agent 落地来说这件事非常关键。因为它意味着 我们可以把测试用例评审、接口自动化生成、日志分析、故障排查、报告生成、RAG 测评、UI 自动化脚本规范逐步封装成 Agent 可以稳定调用的技能。这可能是 Agent 从“聪明的聊天助手”走向“可靠的工程协作者”的关键一步。目录为什么 Agent 需要 Skill 标准Agent Skills 到底解决了什么问题一个 Skill 的标准结构是什么SKILL.md 为什么是整个标准的核心渐进式披露Agent Skills 最重要的设计Agent Skills 和 MCP 有什么区别测试开发团队可以怎么用 Agent Skills一个测试用例审核 Skill 应该怎么设计Agent Skills 的最佳实践真正落地前必须注意的风险一、为什么 Agent 需要 Skill 标准很多团队在使用 AI Agent 时最开始都会经历一个阶段感觉什么都能做。 写代码可以生成测试用例可以分析日志可以写报告也可以。但用久了之后问题就来了。你会发现 Agent 的表现非常依赖上下文。你告诉它“按照我们公司的测试规范写用例”它可能并不知道规范是什么。 你告诉它“按照我们项目接口风格生成 Pytest 脚本”它可能不知道你们的断言规范、目录结构和公共方法。 你让它“帮我审核测试用例”它可能只会泛泛地说覆盖率不足、边界值不足而不是按照你们真实评审会的标准逐条检查。这就是 Agent 落地最大的矛盾模型越来越强但组织内部的经验没有被结构化封装。过去我们靠人传人。 师傅带徒弟组长讲规范评审会上反复纠正。到了 Agent 时代这些经验不能只停留在人的脑子里而应该沉淀成 Agent 可读取、可执行、可复用的技能。Agent Skills 解决的就是这个问题。它不是教模型变聪明而是把“怎么做某类任务”变成标准化资产。二、Agent Skills 到底解决了什么问题Agent Skills 可以理解为给 AI Agent 使用的“技能说明书 工具包 参考资料 执行脚本”。它重点解决四类问题。1. 可复用性以前你每次都要在 Prompt 里写请按照以下规则生成测试用例…… 请参考以下接口规范…… 请输出 Markdown 表格…… 请不要遗漏边界值、异常流、权限控制……这些内容一旦变成 Skill就不需要每次重复输入。Agent 只要识别到任务匹配就可以加载对应 Skill。例如用户说“帮我审核一下这份测试用例。” Agent 自动触发test-case-reviewSkill。 然后按照固定标准检查字段完整性、步骤连贯性、边界覆盖、异常流、预期结果、可执行性。这就把一次性的 Prompt变成了可长期复用的能力模块。2. 可分享性一个好的测试用例审核 Skill不应该只在一个人的电脑里有用。它应该可以被团队共享。 可以进入代码仓库。 可以版本管理。 可以评审。 可以迭代。 可以在多个 Agent 工具之间迁移。Agent Skills 采用纯文本文件组织非常适合 Git 管理。官方也强调Skills 可以把专业知识、流程和团队上下文打包成可版本控制、按需加载的目录。(Agent Skills[2])这对企业内部非常重要。因为很多 AI 落地失败不是因为模型不强而是因为企业内部知识没有被工程化管理。3. 上下文效率Agent 最大的成本之一是上下文。如果每个任务都把所有规范、所有文档、所有工具说明一次性塞进去模型很快就会被大量无关信息淹没。Agent Skills 的核心设计是“渐进式披露”。也就是先加载最少的信息用来判断要不要触发技能。 触发后再加载主要操作说明。 真正需要时再读取更详细的参考资料、模板或脚本。官方文档把这个过程分成 Discovery、Activation、Execution 三个阶段启动时只加载名称和描述任务匹配后加载完整SKILL.md执行时再按需使用脚本、模板和参考文件。(Agent Skills[3])这非常符合真实工程场景。因为一个成熟团队可能会有几十个甚至上百个技能但每次任务只需要其中一两个。4. 执行可靠性只靠自然语言 PromptAgent 很容易“理解对了但执行偏了”。比如你让它生成接口自动化脚本它可能每次目录结构不同、断言方式不同、命名风格不同。如果 Skill 里明确写好使用 Pytest 请求层统一走api_client.py断言必须包含状态码、业务码、核心字段 测试数据放在data/禁止在用例中硬编码 Token 生成后必须运行格式检查和单测Agent 的执行稳定性就会明显提高。这就是 Skill 的价值不是让 Agent 自由发挥而是让 Agent 在清晰边界内工作。三、一个 Skill 的标准结构是什么按照 Agent Skills 的规范一个技能本质上就是一个目录。典型结构如下test-case-review/ ├── SKILL.md ├── scripts/ │ └── validate_cases.py ├── references/ │ ├── review-rules.md │ └── boundary-checklist.md ├── assets/ │ └── output-template.md其中只有SKILL.md是必需的。其他目录都是可选的。1. SKILL.md这是技能的入口文件。它包含两部分第一部分是 YAML 前置元数据。 第二部分是 Markdown 指令主体。Agent 会先读取元数据判断这个 Skill 是否适合当前任务。任务匹配后再读取 Markdown 主体按照里面的步骤执行。2. scripts/这个目录用于存放可执行脚本。例如测试用例格式校验脚本 接口文档解析脚本 日志清洗脚本 性能数据统计脚本 Markdown 报告生成脚本 Excel 转换脚本当一个任务里有固定、重复、容易出错的处理逻辑时就不应该每次都让 Agent 现场写代码。更好的方式是把脚本沉淀到scripts/中让 Agent 直接调用。3. references/这个目录用于存放详细参考资料。例如测试用例评审规则 接口错误码说明 数据库表结构说明 业务状态机说明 质量准入标准 团队代码规范 发布流程说明这些内容不一定每次都需要加载。只有当 Agent 遇到相关问题时再按需读取。这就是渐进式披露的核心思想。4. assets/这个目录用于放模板、示例、图片、配置文件等静态资源。例如测试报告模板 缺陷分析模板 用例评审输出模板 性能压测报告模板 接口自动化项目模板 数据清洗配置模板对于输出格式要求很强的任务assets/非常有用。因为“给模板”通常比“用语言描述格式”更稳定。四、SKILL.md 为什么是整个标准的核心SKILL.md是 Agent Skills 的灵魂。一个技能能不能被正确触发主要看description。 一个技能能不能稳定执行主要看 Markdown 指令主体。 一个技能能不能长期维护主要看它是否足够清晰、克制、可验证。一个典型的SKILL.md可以这样写--- name: test-case-review description: Use this skill when reviewing software test cases, checking case completeness, boundary coverage, step consistency, expected results, exception scenarios, and execution feasibility. Use it when the user asks to review, optimize, audit, improve, or validate test cases, even if they do not explicitly mention test case review. license: MIT compatibility: Python 3.10, Markdown input, optional Excel parsing metadata: author: QA Team version: 1.0 --- # Test Case Review Skill ## When to use Use this skill when the user provides test cases and wants review, optimization, scoring, rewriting, or coverage analysis. ## Workflow 1. Identify the business module and test objective. 2. Check whether each case has clear preconditions, steps, data, and expected results. 3. Review normal flow, exception flow, boundary values, permissions, data consistency, and concurrency scenarios. 4. Mark vague, duplicated, unexecutable, or low-value cases. 5. Output review comments and optimized examples. ## Output format | Case ID | Problem | Risk | Suggestion | Optimized Version | |---|---|---|---|---| ## Gotchas - Do not only give general advice. - Do not ignore expected results. - Do not treat UI interaction steps as business verification points. - Do not add unrealistic scenarios that cannot be executed.这个文件看起来并不复杂但它解决了三个关键问题什么时候用。 怎么执行。 输出成什么样。这就是 Agent Skill 和普通 Prompt 最大的区别。普通 Prompt 是一次性的。 Skill 是可沉淀、可复用、可验证的。五、渐进式披露Agent Skills 最重要的设计Agent Skills 最值得关注的设计不是目录结构而是渐进式披露。简单说就是不要一开始把所有信息都塞给模型。而是分层加载。第一层元数据层只加载name和description。这部分非常短通常只有几十到一百多个 token。作用只有一个判断当前任务是否需要这个技能。例如name: api-test-generator description:UsethisskillwhengeneratingAPItestcasesorPytestautomationscriptsfromSwagger,OpenAPI,Postmancollections,orinterfacedocumentation.Agent 看到用户说“帮我根据 Swagger 生成接口自动化用例。”就能判断这个 Skill 可能有用。第二层指令层当 Skill 被激活后Agent 才读取完整的SKILL.md。这里可以包含任务目标 执行步骤 输入输出要求 异常处理 注意事项 示例 验证方式官方建议将主要说明控制在合理范围内并把详细资料放到references/中。规范中也明确建议SKILL.md主体保持在 500 行以内详细参考材料拆到独立文件。(Agent Skills[4])这非常重要。因为 Skill 不是文档仓库。它应该像一个“任务操作手册”而不是一本百科全书。第三层资源层只有在需要时Agent 才加载脚本 模板 详细规范 示例文件 错误码说明 项目配置例如用户只是让 Agent 粗略评审测试用例就不需要加载完整企业级测试规范。但如果用户问“这个预期结果为什么不合格”Agent 就可以读取references/review-rules.md。如果用户要求“帮我生成最终评审报告。”Agent 再读取assets/review-report-template.md。这样做的好处是上下文更省。 触发更精准。 执行更稳定。 维护也更清晰。六、Agent Skills 和 MCP 有什么区别很多人看到 Agent Skills第一反应是这和 MCP 有什么区别这个问题非常关键。简单理解MCP 更像是 Agent 连接外部工具和数据源的协议。 Agent Skills 更像是 Agent 执行某类任务的方法包。MCP 解决的是“能调用什么”。 Skills 解决的是“怎么把事情做好”。举个例子。如果你希望 Agent 能访问数据库、调用浏览器、读取 GitHub、操作 Jira那么 MCP 很合适。但如果你希望 Agent 知道查询用户表时必须过滤软删除数据 生成测试报告必须包含风险等级 接口自动化脚本必须复用公司封装的请求方法 缺陷分析必须先看日志再看链路追踪 生产数据库只允许只读查询这些就更适合放在 Skill 里。两者不是替代关系而是互补关系。一个成熟的 Agent 工程体系大概率会是MCP 负责连接工具。 Skills 负责封装流程。 RAG 负责补充知识。 Agent 负责理解目标、规划步骤和执行任务。可以用一张图理解用户任务 ↓ Agent 理解意图 ↓ 匹配 Skill ↓ 读取任务流程 / 规则 / 模板 ↓ 通过 MCP 调用工具 ↓ 执行脚本 / 查询数据 / 生成结果 ↓ 验证输出 ↓ 返回结果所以MCP 让 Agent 有手有脚。 Agent Skills 让 Agent 知道应该怎么干活。七、测试开发团队可以怎么用 Agent Skills对于测试开发团队来说Agent Skills 的价值非常直接。因为测试团队有大量标准化、流程化、可复用的工作。这些工作过去靠文档、培训、评审和经验传递。现在可以逐步沉淀成 Skill。1. 测试用例生成 Skill适用场景根据需求文档生成测试点 根据 PRD 生成测试用例 根据页面截图生成 UI 测试点 根据用户故事补充异常流 根据状态机补全业务路径Skill 中可以定义用例字段标准 功能流分析方法 边界值设计规则 异常场景清单 权限场景清单 输出模板 评审检查项2. 测试用例审核 Skill适用场景审核已有测试用例 检查用例是否可执行 检查预期结果是否明确 检查是否遗漏边界值 检查异常流和权限场景 检查用例是否重复或低价值这类 Skill 很适合测试团队内部推广。因为测试用例评审是高频任务而且不同组长的评审标准经常不一致。把评审经验沉淀成 Skill可以大幅提升团队一致性。3. 接口自动化生成 Skill适用场景根据 Swagger 生成接口用例 根据 OpenAPI 生成 Pytest 脚本 根据接口文档补充断言 生成请求参数组合 生成异常参数测试 生成接口自动化项目结构Skill 中可以明确目录结构 命名规范 公共请求方法 认证方式 断言标准 数据驱动格式 失败重试策略 报告生成方式4. UI 自动化生成 Skill适用场景根据页面结构生成 Playwright 脚本 根据业务流程生成 Selenium 脚本 根据页面元素生成 POM 对象 补充等待策略和断言 优化定位器稳定性Skill 中可以写清楚优先使用哪类定位方式 禁止使用脆弱 XPath 如何处理异步加载 如何封装 Page Object 如何设计断言 如何处理失败截图和日志5. 缺陷分析 Skill适用场景分析 Bug 根因 整理缺陷复盘 根据日志判断问题链路 从错误堆栈提取关键信息 输出开发可读的缺陷描述Skill 中可以定义先看现象再看影响范围 先确认环境再确认数据 先定位入口再定位调用链 输出必须包含复现步骤、实际结果、期望结果、影响范围、初步判断 禁止直接给结论必须标明证据来源6. 性能测试分析 Skill适用场景分析压测结果 定位吞吐瓶颈 分析响应时间分布 识别错误率变化 生成性能测试报告 给出容量评估建议Skill 中可以封装TPS、RT、P95、P99、错误率分析方法 应用、数据库、中间件、网络层排查路径 压测数据清洗脚本 报告模板 容量预估模型7. AI 系统测评 Skill适用场景测评大模型输出质量 测评 RAG 问答准确性 测评智能体任务完成率 测评多模态识别效果 分析幻觉、拒答、鲁棒性、安全性这对 AI 测试开发尤其重要。因为 AI 系统测试不是简单点点页面而是要围绕准确性、一致性、鲁棒性、可解释性、延迟、成本、安全边界等指标做系统评估。这些规则非常适合 Skill 化。八、一个测试用例审核 Skill 应该怎么设计如果我们要给测试团队做一个test-case-reviewSkill可以按下面这个思路设计。1. description 要写准很多 Skill 失败不是因为指令写得不好而是因为 description 写得太差。比如description: Review test cases.这个描述太弱了。Agent 很难判断什么时候该触发。更好的写法是description: Usethisskillwhenreviewing,auditing,scoring,optimizing,orrewritingsoftwaretestcases.Checkcompleteness,stepconsistency,inputdata,expectedresults,boundaryvalues,exceptionflows,permissions,dataconsistency,concurrencyrisks,andexecutionfeasibility.Useitwhenevertheuserprovidestestcasesandasksforrevieworimprovement,eveniftheydonotexplicitlysaytest case review.这个描述包含三类信息技能做什么。 什么时候使用。 哪些间接表达也要触发。这比简单写“审核测试用例”可靠得多。2. 指令主体要像评审清单测试用例审核不是让 Agent 自由点评而是要让它按照固定维度检查。可以设计成这样## Review Checklist - [ ] 是否有明确测试目标 - [ ] 是否有前置条件 - [ ] 是否有测试数据 - [ ] 操作步骤是否连续 - [ ] 预期结果是否可验证 - [ ] 是否覆盖正常流 - [ ] 是否覆盖异常流 - [ ] 是否覆盖边界值 - [ ] 是否覆盖权限场景 - [ ] 是否覆盖数据一致性 - [ ] 是否存在重复用例 - [ ] 是否存在无法执行的用例 - [ ] 是否存在描述模糊的步骤清单比长篇描述更适合 Agent 执行。因为它能降低遗漏概率。3. 一定要写 GotchasGotchas是 Skill 里最值钱的部分。因为它记录的是 Agent 最容易犯错的地方。例如## Gotchas - 不要只给“覆盖不足”这类泛泛建议必须指出具体缺失场景。 - 不要把“页面展示正确”当成唯一预期结果必须补充业务状态、数据变化或接口返回。 - 不要只检查正常流程必须检查异常流、边界值和权限控制。 - 不要生成无法执行的用例例如依赖不存在的数据或无法构造的状态。 - 不要忽略并发、重复提交、幂等性和数据一致性问题。 - 如果用例步骤跳跃必须指出缺失步骤。 - 如果预期结果不可观察必须要求补充可验证依据。这部分比“请认真审核”有用得多。因为它把经验里的坑直接写出来了。4. 输出格式必须固定输出格式越明确结果越稳定。例如## Output Format ### 总体结论 - 完整性评分 - 可执行性评分 - 风险覆盖评分 - 主要问题 ### 详细评审 | 用例编号 | 问题类型 | 当前问题 | 风险影响 | 修改建议 | 优化示例 | |---|---|---|---|---|---| ### 遗漏场景补充 | 场景类型 | 建议补充用例 | 设计原因 | |---|---|---| ### 最终建议 用 3-5 条总结该用例集下一步如何优化。这样输出之后测试组长可以直接拿去评审测试同学也能按表修改。5. 验证循环要写进去一个好的 Skill 不应该只让 Agent 生成结果还要让 Agent 自查。例如## Validation Before final response: 1. Check whether every issue has a specific case reference. 2. Check whether every suggestion is executable. 3. Check whether expected results are observable. 4. Check whether missing scenarios are relevant to the business. 5. Remove generic advice that does not help improve the test cases.这一步非常关键。因为很多 Agent 输出看起来很完整但实际充满套话。验证循环就是为了逼它从“写得像”变成“真的有用”。九、Agent Skills 的最佳实践想把 Skill 写好不能只靠感觉。下面这几条是比较适合工程团队落地的原则。1. 不要让 Skill 变成百科文档Skill 不是知识库。不要把所有资料都塞进SKILL.md。SKILL.md应该只放什么时候用 怎么做 注意什么 输出什么 如何验证详细资料放到references/。模板放到assets/。脚本放到scripts/。这样 Skill 才能保持轻量。2. 只写 Agent 不知道的内容很多人写 Skill 时喜欢解释大量通用知识。比如“测试用例是软件测试中的重要资产。” “接口测试用于验证系统接口是否符合预期。” “性能测试可以发现系统瓶颈。”这些内容对 Agent 没有太大价值。Skill 里应该写的是你们团队的字段规范。 你们项目的断言要求。 你们业务的特殊状态。 你们评审时最常见的问题。 你们平台的目录结构。 你们内部工具的调用方式。 你们不允许出现的错误。Skill 的价值不是常识而是经验密度。3. 粒度要像函数一样一个 Skill 不要太大也不要太小。太小的问题是一个任务需要连续触发多个 SkillAgent 容易混乱。太大的问题是触发不精准执行步骤太长结果变得不可控。比较好的粒度是一个 Skill 解决一类明确任务。例如test-case-review审核测试用例api-test-generator生成接口自动化用例performance-report-analysis分析性能测试报告bug-root-cause-analysis分析缺陷根因rag-evaluation评估 RAG 系统效果这就像写函数。一个函数只做一件相对完整的事。4. 优先写流程不要只写结论不好的 Skill 是这样写的“生成高质量测试用例。”好的 Skill 是这样写的先识别业务对象。 再拆分主流程。 再补充异常流。 再设计边界值。 再检查权限。 再补充数据一致性。 最后按模板输出。Agent 需要的不是口号而是路径。尤其在测试开发场景里过程比结果更重要。因为测试设计本身就是一套方法论。5. 脆弱任务必须写死步骤有些任务容错率低必须写得非常明确。比如数据库迁移 生产环境变更 批量删除数据 自动发送邮件 修改 CI/CD 配置 执行压测任务 发布前质量门禁这类 Skill 不能写得太开放。应该明确先生成计划 必须二次确认 必须备份 必须 dry-run 必须限制范围 必须记录日志 必须验证结果 禁止自动执行高风险操作越脆弱的任务指令越要具体。6. 高频逻辑要沉淀成脚本如果你发现 Agent 每次都在重复写同一段代码就应该把它变成脚本。例如解析 Excel 用例 检查用例字段缺失 统计接口覆盖率 生成 Markdown 报告 清洗 JMeter 结果 分析慢 SQL 解析错误日志 检查 OpenAPI 字段让 Agent 每次临时写脚本稳定性一定不如调用一个经过验证的脚本。所以成熟 Skill 的结构应该是自然语言负责判断和编排。 脚本负责稳定执行。 模板负责规范输出。 参考资料负责补充细节。这才是工程化。十、真正落地前必须注意的风险Agent Skills 虽然很有价值但不能只看好处。因为 Skill 本身也会带来新的风险。尤其是当 Skill 可以执行脚本、调用工具、访问文件或操作外部系统时它就不再只是“提示词”而是具备了真实执行能力。近期已有研究开始关注 Agent Skills 的安全问题包括技能生命周期、权限边界、恶意技能检测、社区技能风险等方向。相关论文指出Agent Skills 的风险不仅来自代码也可能来自SKILL.md中的自然语言指令、权限设计和分发机制。(arXiv[5])企业落地时至少要注意五件事。1. 不要随便安装陌生 Skill第三方 Skill 可能包含恶意脚本、隐蔽指令或过度权限要求。安装之前要检查它会读取哪些文件 它会调用哪些工具 它是否联网 它是否执行 Shell 命令 它是否请求敏感权限 它的脚本是否可读 它的来源是否可信Agent Skill 本质上是一种可执行能力包。不能像复制普通 Prompt 一样随便复制。2. 高风险 Skill 要做权限隔离例如数据库操作 Skill 邮件发送 Skill 代码提交 Skill 云资源操作 Skill 生产环境运维 Skill 批量文件修改 Skill这些必须限制权限。建议做到只读优先 最小权限 沙箱运行 关键操作二次确认 操作前生成计划 操作后生成审计记录3. Skill 要做版本管理不要让团队成员各写各的 Skill。否则很快就会出现同名 Skill 行为不同 旧版本规则还在使用 不同项目标准冲突 输出模板不一致 脚本没人维护建议把 Skill 放进 Git 仓库。每次修改走 Review。这和维护测试框架、自动化平台、公共组件是一样的。4. Skill 要有评估集一个 Skill 写完后不是能触发就算成功。要设计一组测试问题来验证它。比如test-case-reviewSkill可以准备 20 个查询10 个应该触发。 10 个不应该触发。应该触发的例子“帮我看看这批用例有没有问题。” “这些测试点覆盖完整吗” “帮我优化一下登录模块测试用例。” “评审一下这份 Excel 里的用例。” “预期结果是不是写得太简单了”不应该触发的例子“帮我解释什么是测试用例。” “帮我写一篇测试用例教程。” “测试用例和测试计划有什么区别” “帮我做一个测试岗位学习路线。” “测试用例管理工具有哪些”这样才能判断 description 是否写得准确。5. 不要把 Skill 当万能药Skill 解决的是“经验封装”和“流程复用”。但它不能替代业务理解 工程判断 权限治理 数据质量 工具稳定性 组织流程 质量文化如果底层流程本身混乱Skill 只会把混乱自动化。所以企业做 Agent Skills第一步不是写文件而是梳理流程。先把人的最佳实践说清楚再把它变成 Skill。十一、写在最后Agent Skills 这个标准真正有意思的地方在于它把 Agent 能力建设从“调 Prompt”推进到了“建资产”。Prompt 是临时表达。 Skill 是长期能力。Prompt 更像一次对话。 Skill 更像一个模块。Prompt 依赖个人经验。 Skill 可以团队共享。Prompt 很难评审。 Skill 可以版本管理。Prompt 很难复用。 Skill 可以跨工具迁移。对测试开发团队来说这件事尤其值得重视。因为测试工作天然包含大量流程、规范、模板、检查项和经验。测试用例怎么设计。 接口自动化怎么生成。 UI 自动化怎么封装。 性能报告怎么分析。 缺陷根因怎么定位。 AI 系统怎么测评。 发布质量怎么把关。这些都可以逐步 Skill 化。未来一个优秀测试团队的核心资产可能不只是自动化框架、测试平台和用例库还会包括一套稳定、可复用、可审计的 Agent Skills。到那个时候AI Agent 才不只是一个会聊天的助手而是一个真正理解团队流程、遵守工程规范、能稳定交付结果的数字化协作者。真正的 Agent 工程化可能就是从一个SKILL.md开始的。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。