antithesis-launch – 自动化启动测试配置 Skill

3周前更新 7 0 0 0

antithesis-launch 是用于对接 Antithesis 平台的 Skill,帮助 AI Agent 在确定性模拟环境中启动测试运行并验证软件行为,适合需要在受控条件下排查并发与分布式系统缺陷的测试场景。

Skill 安装

多 Agent 安装
npx skills add https://github.com/antithesishq/antithesis-skills --skill antithesis-launch

使用 npx skills 快速安装,支持将 Skill 添加到多个兼容的 AI Agent。

Skill 调研报告

Skill 详细介绍

antithesishq/antithesis-skills#antithesis-launch 是 Antithesis 官方 skills 仓库中的一个 Skill,名称可以识别为 antithesis-launch。它的定位围绕 Antithesis 平台的启动与运行流程展开,帮助 AI Agent 在用户提出与 Antithesis 测试相关需求时,按照 Antithesis 期望的方式组织配置、命令或操作步骤。

需要说清楚的是:

– 它不是独立运行的软件,也不是 Antithesis 平台本身。
– 它本身不会替你执行确定性测试,也不会替代 Antithesis 的后端服务。
– 它更像是一份面向 Agent 的指令 / 工作流封装,让 Agent 在处理 Antithesis 相关任务时更贴近官方推荐做法。
– Skill 提供的是“操作指引与任务编排能力”,真正的测试执行、结果收集和判定仍然依赖 Antithesis 平台与配套的运行环境。

典型使用场景

– 需要把一个项目接入 Antithesis 进行确定性模拟测试,希望 Agent 协助梳理启动步骤。
– 已经使用 Antithesis,希望 Agent 帮助生成或校验启动配置、运行参数。
– 希望在 CI / 自动化流程中通过 Agent 触发 Antithesis 相关启动动作。
– 需要把 Antithesis 启动流程标准化,减少手动操作带来的偏差。

适合的用户

– 已经在用或准备使用 Antithesis 做确定性测试的团队。
– 希望通过 AI Agent 减少 Antithesis 接入与启动过程中重复操作的工程人员。
– 需要把 Antithesis 启动步骤沉淀为可复用流程的团队。

不适合的需求

– 只是想找一个通用测试框架,和 Antithesis 无关。
– 期望 Skill 自身就能完成测试、无需 Antithesis 平台。
– 完全不了解 Antithesis、也不打算使用它的用户。

由于当前可确认的公开资料有限,具体支持哪些子任务、需要哪些参数、支持哪些语言或运行环境,请以 Antithesis 官方仓库中该 Skill 的当前说明为准。

Skill 安全评估

总体判断:来自 Antithesis 官方组织仓库(antithesishq),来源可信度相对较高;但它涉及测试启动流程,通常会与运行环境、命令执行和可能的凭证配合,属于需要关注权限边界的 Skill,而不是“纯文本提示词、零风险”类型。

需要重点关注的几类风险:

– Shell 与进程执行:启动 Antithesis 通常涉及运行命令或脚本。如果 Agent 被授予自动执行 Shell 的权限,Skill 触发时可能会直接执行命令。建议对不熟悉的项目,先关闭 Agent 的自动执行权限,由用户手动复核并执行命令。
– 网络访问:Antithesis 作为平台服务,接入与启动过程通常需要访问网络。这属于正常用途,但意味着 Skill 运行过程中可能存在对外通信。
– 凭证 / Token:如果 Antithesis 的接入依赖 API Key、Token 或类似凭证,这些凭证一旦被写入仓库、日志或配置文件,存在泄露风险。建议使用环境变量或专用密钥管理方式,不要把凭证硬编码进代码或提交到版本控制。
– 配置与文件改动:Skill 可能引导 Agent 修改项目内的配置、CI 文件或启动脚本。执行前建议在独立分支或副本上进行,避免直接影响主分支。
– 注入类风险:如果 Skill 会读取外部输入(配置、仓库内容、用户描述)并据此生成命令,存在被恶意内容影响的风险。执行前对生成的命令保持人工确认习惯,可以降低这类风险。

降低风险的实操建议:

1. 只在明确要用 Antithesis 的项目中启用该 Skill。
2. 限制 Agent 的自动 Shell 执行权限,关键命令由人工确认。
3. 检查 Antithesis 相关凭证的存放方式,避免明文提交。
4. 优先在非生产分支、非生产环境试用,确认流程无副作用后再接入正式环境。

不要因为 Skill 来自官方仓库就默认“绝对安全”。官方来源降低的是供应链与来源可信度风险,不代表运行时权限风险自动消失。

Skill 使用要求

一、Agent / 客户端

该 Skill 位于 Antithesis 官方 skills 仓库,本身面向支持 Skills 或类似指令加载机制的 AI Agent。官方没有提供完整的第三方 Agent 兼容列表,因此:

– 在支持 Skills 的环境中可以优先尝试。
– Claude Code、Codex、Cursor、Trae、OpenClaw、WorkBuddy 等主流 Agent,如果支持自定义 Skill 或指令加载,通常可以尝试安装使用;不同 Agent 的加载方式和贴合程度不同,具体以对应 Agent 当前版本为准。
– 没有官方依据表明它“完美适配”某个特定 Agent,遇到差异以官方仓库说明为准。

二、运行环境 / 依赖

具体依赖以官方说明为准。通常此类“启动 Antithesis”类 Skill 会与下列环境相关:

| 项目 | 要求 |
|—|—|
| Agent | 支持 Skill / 自定义指令加载的 Agent |
| Antithesis | 需要可用的 Antithesis 平台接入(账号 / 项目) |
| 网络 | 通常需要,用于访问 Antithesis 服务 |
| Shell / 脚本执行 | 取决于具体启动方式,可能涉及 |
| Git | 如果流程涉及代码仓库,通常需要 |

官方当前没有明确统一的 Node.js / Python 版本要求说明,请不要自行假定版本。以项目实际接入方式为准。

三、权限

– 文件读取:通常需要,用于读取项目配置。
– 文件写入:可能,用于生成或修改配置 / 启动脚本。
– Shell:可能,用于执行启动命令。
– 网络:通常需要。
– GitHub / 仓库访问:如果流程涉及代码仓库,可能需要。

以上以“可能 / 通常”标注的项,请结合自己的实际使用场景确认,非全部为硬性必需。

四、账号 / API Key

需要区分两件事:

– Skill 本身:是否强制要求账号或凭证,以官方说明为准。
– 你使用 Antithesis 的过程中:通常需要 Antithesis 账号,并可能需要 API Key / Token 之类凭证。

具体凭证名称、配置方式、环境变量名,请以 Antithesis 官方文档和该 Skill 当前说明为准,本文不做编造。

最小使用条件

1. 一个支持 Skill / 自定义指令加载的 Agent。
2. 一个可用的 Antithesis 平台接入。
3. 一个你想要用 Antithesis 进行测试的项目。
4. 根据启动方式,可能需要可用的网络与 Shell 执行环境。

Skill 安装、使用与卸载教程

一、安装

LemonAIKit 的 Skill 详情页已经提供了该 Skill 的安装指令。最直接的方式是:

1. 复制本页面提供的 Skill 安装指令。
2. 粘贴到你的 Agent 或终端执行。

如果不清楚自己的 Agent 该怎么装,可以直接问当前 Agent:

如何安装 antithesishq/antithesis-skills#antithesis-launch?

如何在 Claude Code 中安装 antithesishq/antithesis-skills#antithesis-launch?

如何在 Codex 中安装 antithesishq/antithesis-skills#antithesis-launch?

如何在 Cursor 中安装 antithesishq/antithesis-skills#antithesis-launch?

让当前 Agent 根据它自己的 Skill 加载 / 管理机制指导安装。如果官方对该 Skill 存在额外安装要求,请以官方仓库说明为准;本文不重复页面已经提供的完整安装命令。

二、安装后如何使用

安装后,当你的任务和 Antithesis 启动 / 接入相关时,Agent 会更倾向使用该 Skill 的流程。适合交给它的任务包括:梳理 Antithesis 启动步骤、整理启动配置、生成启动命令草稿、协助接入流程。

使用示例:

使用 antithesis-launch,帮我把这个项目接入 Antithesis 并整理出启动步骤。

使用 antithesis-launch,检查我现在的 Antithesis 启动配置有没有问题。

使用 antithesis-launch,帮我梳理在 CI 里触发 Antithesis 启动需要做哪些准备。

向 Agent 描述需求时,尽量说明:项目类型、你想让 Antithesis 测什么、当前已有配置和环境,Agent 才能给出更贴合的输出。关键命令建议先人工确认再执行。

三、卸载

不同 Agent 的 Skill 安装位置和管理方式可能不同。稳妥做法:

– 使用对应 Agent / Skill 管理器提供的删除方式移除该 Skill。
– 或直接询问当前 Agent:

如何卸载 antithesishq/antithesis-skills#antithesis-launch?

如果官方明确提供统一卸载命令,以官方为准;没有统一命令时,让 Agent 按自身管理机制移除即可,不必手动清理陌生目录。

常见问题

1. 这个 Skill 能自己跑 Antithesis 测试吗?

不能。它负责的是启动 / 接入流程的指令与编排,真正的测试执行依赖 Antithesis 平台与配套环境。把它当作“流程助手”,而不是测试引擎。

2. 可以同时安装到多个 Agent 吗?

一般可以。Skill 通常按 Agent 各自的管理目录存放,多个 Agent 可以各自安装。注意不同 Agent 加载方式不同,作者可能只针对部分 Agent 做了优化,行为可能有差异。

3. Skill 更新后需要重新安装吗?

取决于你的 Agent 如何管理 Skill:如果它支持从仓库更新,重新同步即可;如果是固定拷贝到本地,需要重新获取最新版本。具体以 Agent 的 Skill 管理方式为准。

4. 安装后 Agent 没识别到 Skill,怎么办?

先确认三件事:安装路径是否是当前 Agent 读取 Skill 的目录;Agent 是否需要重启或重新加载;Skill 名称 / 目录结构是否与官方一致。仍不行就询问当前 Agent:“为什么没有加载 antithesishq/antithesis-skills#antithesis-launch?”

5. 中国大陆使用有没有网络限制?

Antithesis 平台本身在境外,实际访问情况取决于网络环境。安装 Skill 本身可能通过 GitHub 完成,也可能受网络影响。如果访问受阻,需要在网络层面自行解决,Skill 本身不改变这一点。

6. 它会自动修改我的项目吗?

取决于 Agent 权限配置。如果授予了自动写入 / 执行权限,Skill 相关流程可能改动配置或脚本。建议在独立分支试用,关键改动人工确认。

7. 可以关闭 Shell 权限吗?

可以。你可以让 Agent 只生成命令和步骤,由你手动执行。这样会损失一部分自动化便利,但能显著降低误执行风险,适合初次接入或不熟悉的项目。

Skill 更新日志

版本列表
无版本号
为 PR #204 更新技能版本
无版本号
为 PR #198 更新技能版本
无版本号
为 PR #201 更新技能版本
无版本号
为 PR #200 更新技能版本
无版本号
为 PR #195 更新技能版本
无版本号
feat: 优先使用调用方提供的启动参数而非技能默认值 (#195)
无版本号
为 PR #199 更新技能版本
无版本号
为 PR #194 更新技能版本
无版本号
为 PR #191 更新技能版本
无版本号
fix: 将 podman compose 指南替换为 Docker Compose v2 (#191) * fix: 将 podman compose 指南替换为 Docker Compose v2 Antithesis 针对 podman 运行独立的 docker-compose 二进制文件。它 从不运行 `podman compose`。snouty 以相同方式驱动 Docker Compose v2: 独立 `docker-compose` 二进制文件,或来自 snouty 0.7.0 的 `docker compose` CLI 插件。技能曾告诉 agent 优先使用 `podman compose`,而没有任何版本的 snouty 支持它。 compose CLI 和容器引擎是两个独立的选择。技能现在这样说明, 列出两种受支持的组合,并指引 agent 使用 `snouty doctor` 读取 snouty 在此机器上选择的组合。 snouty 从不构建镜像,也从不拉取镜像,因此构建必须落在 snouty 选择的引擎的镜像存储中。setup 和 launch 技能现在包含两种引擎的构建命令,包括使 podman 支持独立二进制文件的 DOCKER_HOST 接线,以及用于在同时装有 podman 的机器上进行 docker 构建的 SNOUTY_CONTAINER_ENGINE 覆盖。 PREREQUISITES.md 从两个平台部分中删除了 `podman-compose`。在 Debian 上,`docker-compose-v2` 包仅提供 CLI 插件,因此 podman 组合改为下载独立二进制文件。 Co-Authored-By: Claude * docs: 审查后收紧 compose 指南 将构建指南从 docker-compose.md(该文件涵盖编写 yaml)移到 submit-and-test.md,agent 在该文件中运行构建。 这消除了两次指针跳转。 删除 snouty 版本注意事项、README.md 中重复的段落, 以及重复的“不要使用 podman compose”行。现在一条正面 指令承载该规则:运行 `snouty doctor` 并使用它指定的组合进行构建。 指引 agent 查看 `snouty doctor` 检查项,而不是其解析后的 设置。检查项打印 `Container runtime: docker detected`,而 设置行打印 `auto-detect`。 在 launch 技能和 README 中恢复 `docker compose build` 作为可运行命令, 并将 PREREQUISITES.md 中的 `snouty doctor` 步骤移到 安装 snouty 之后。 Co-Authored-By: Claude * 更新 SKILL.md 以提供更清晰的前置条件说明 澄清了运行 'snouty doctor' 的说明,并删除了前置条件中的冗余内容。 * docs: 每个文件只说明一次 compose CLI 选择 技能在每个命令处都重复“或 `docker-compose`”。来自 `snouty doctor` 的一次 观察即可为整个运行确定 CLI,因此 每个文件现在只说明一次,然后直接写 `docker compose`。 Co-Authored-By: Claude * docs: 删除脆弱的 podman socket 单行命令 Compose 默认使用 Docker 守护进程 socket,因此 agent 自己的构建 在 podman 机器上需要 DOCKER_HOST。snouty 为其自己的 compose 调用设置它,而不是为构建设置。 不过,macOS 命令不应被直接交给用户。podman 从当前 TMPDIR 推导 socket 路径,而 socket 是在 `podman machine start` 时绑定到该 TMPDIR 下的,因此 `podman machine inspect` 可能报告 一个不存在的路径。snouty 正是出于这个原因探测同级位置。改为说明该要求以及 macOS 陷阱。 Co-Authored-By: Claude * docs: podman 需要启动其 API socket 在全新的 podman 4.9.3 安装上验证。`podman info` 报告一个 socket 路径,而 `RemoteSocket.Exists` 为 false,并且 `snouty doctor` 仍然 打印 "Container runtime: podman detected"。将 DOCKER_HOST 导出到 该路径会给 compose 一个失效的 socket。 将检查项和 `systemctl --user enable --now podman.socket` 修复 添加到构建指南和 podman 安装步骤中。 Co-Authored-By: Claude * docs: 在 podman 引擎上使用 `podman compose` 构建 `podman compose` 是包装器,不是 `podman-compose`。它针对 podman 的 API socket 执行 Docker Compose v2 二进制文件,因此它自行完成 DOCKER_HOST 接线,镜像会落入 podman 的存储。已在 podman 4.9.3 上使用独立二进制文件和 CLI 插件作为提供程序验证。 用它替换手动 DOCKER_HOST 导出,并删除 `podman compose` 不是替代方案的声明。socket 检查保留:当 podman 未监听时,无论哪种方式构建都会失败并显示 "Cannot connect to the Docker daemon"。 snouty 仍然需要 PATH 中的独立 `docker-compose`。在只有 podman 而没有 `docker` CLI 的情况下,`snouty doctor` 会报告 "no usable Docker Compose", 而 `podman compose` 可以工作。 Co-Authored-By: Claude * docs: 构建前检查 podman compose 提供程序 podman 从 ["docker-compose", "podman-compose"] 解析其 compose 提供程序,并回退到 podman-compose Python 工具,该工具 不是 Docker Compose。`podman compose version` 会指出运行的是哪一个: 对于 Compose v2 提供程序,stdout 输出 "Docker Compose version ...", 对于回退项输出 "podman-compose version ..."。已在 podman 4.9.3 上验证两者。 用该命令替换 stderr 提供程序行建议,并与 socket 检查并列。 Co-Authored-By: Claude * docs: 应用 PR 191 的审查建议 从安装步骤中删除 podman socket 检查和 `snouty doctor` 行, 将 `systemctl --user enable --now podman.socket` 保留在 安装命令本身中。将 podman 构建提升为 launch 技能中的顶级要点, 并缩短引擎覆盖子要点。说明 `podman-compose` Python 工具与 harness 所需的 docker-compose 功能不兼容。 Co-Authored-By: Claude --------- Co-authored-by: Carl Sverre Co-authored-by: Claude
无版本号
为 PR #189 更新技能版本
无版本号
为 PR #188 更新技能版本
无版本号
为 PR #184 更新技能版本
无版本号
chore: 为 PR #182 回填 changelog 条目和技能版本号提升 (#183) * 为 PR #182 更新 changelog 回填:PR #182 合并时没有 changelog 标签,因此 pr-merge-changelog 工作流短路,未添加任何条目。 通过运行 `.ci-scripts/changelog.py add-entry` 并传入 `find_merged_pr.py` 本会生成的条目文本复现。 Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_018gQyXJukB6xdZzEieUvMTu * 为 PR #182 更新技能版本 回填:同样的短路跳过了版本号提升。通过 运行 `.ci-scripts/update_skill_versions.py update --sha 5b6aeb5` 复现, 使用工作流本会传入的 #182 合并提交 SHA。 Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_018gQyXJukB6xdZzEieUvMTu --------- Co-authored-by: Carl Sverre Co-authored-by: Claude Opus 5 (1M context)
无版本号
为 PR #180 更新技能版本
无版本号
为 PR #179 更新技能版本
无版本号
为 PR #178 更新技能版本
无版本号
为 PR #177 更新技能版本
无版本号
为 PR #176 更新技能版本
无版本号
为 PR #169 更新技能版本
无版本号
为 PR #165 更新技能版本
无版本号
为 PR #162 更新技能版本
无版本号
为 PR #168 更新技能版本
无版本号
为 PR #161 更新技能版本
无版本号
为 PR #167 更新技能版本
无版本号
为 PR #164 更新技能版本
无版本号
为 PR #160 更新技能版本
无版本号
为 PR #158 更新技能版本
无版本号
为 PR #157 更新技能版本
无版本号
为 PR #155 更新技能版本

暂无评论

none
暂无评论...