antithesis-k8s-onboarding-assistance – Kubernetes 入门引导辅助 Skill

3周前更新 9 0 0 0

antithesis-k8s-onboarding-assistance 是指导 AI Agent 在 Kubernetes 环境中完成 Antithesis 平台初始接入和配置的 Skill,适合需要部署 Antithesis 测试环境并打通集群连接的工程团队。

Skill 安装

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

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

Skill 调研报告

Skill 详细介绍

antithesishq/antithesis-skills#antithesis-k8s-onboarding-assistance 是 Antithesis 官方 skills 仓库中的一个 Skill,名字可以理解为 antithesis-k8s-onboarding-assistance。它的定位很明确:帮助用户在 Kubernetes 环境中完成 Antithesis 的接入(onboarding)相关辅助工作。

它本身不是一个可以独立运行的程序,也不是一个独立安装的 CLI 工具或服务。它更接近一组面向 AI Agent 的指令 / 工作流说明:当你在支持 Skills 的 Agent 里加载它之后,Agent 在处理 Antithesis 与 Kubernetes 接入相关任务时,会按照这个 Skill 约定的方式组织步骤、检查项和输出。

它主要解决什么问题

  • 把「Antithesis 接入 Kubernetes」这类分散、多步骤的流程整理成 Agent 可以按顺序推进的任务。
  • 减少用户自己从零梳理「先做什么、再做什么、哪些配置属于必需」的成本。
  • 在接入过程中给出结构化的指导,而不是让 Agent 泛泛回答。

它不是什么

  • 不是 Antithesis 平台本身,也不替代 Antithesis 官方文档与控制台。
  • 不是 Kubernetes 发行版,不负责安装或管理集群。
  • 不是通用的 K8s 运维 Skill,它的范围围绕 Antithesis 接入这一目标。

典型任务

  • 梳理在 Kubernetes 上接入 Antithesis 所需的准备项与步骤顺序。
  • 帮助理解接入过程中涉及的概念、配置和流程要点。
  • 在接入出现困惑时,辅助定位应该是哪一类环节没有满足。

适合哪些用户

  • 准备在 Kubernetes 环境里使用 Antithesis 的工程团队。
  • 已经在用 Claude Code 等支持 Skills 的 Agent,希望接入流程更结构化的用户。
  • 需要对接入过程做梳理、记录和复盘的开发者或 SRE。

不适合哪些需求

  • 只是想要一个通用 Kubernetes 教程的用户。
  • 不使用 Antithesis、也不需要接入 Antithesis 的场景。
  • 希望 Skill 直接替你把集群改好、自动完成全部接入的用户——它提供的是辅助与指导,不是自动化改集群的成品工具。

需要说明的是:当前可确认的公开信息主要来自 Antithesis 官方 skills 仓库本身。关于该 Skill 更细的内部步骤、是否覆盖某些特定 K8s 发行版或特定云厂商,目前官方资料未明确说明,具体以该 Skill 当前官方说明为准。

Skill 安全评估

总体判断:这是 Antithesis 官方仓库下的一个接入辅助 Skill,来源可信度较高,性质上偏向指导 / 工作流类,而不是自带危险操作的执行工具。是否安全,主要取决于你的 Agent 在加载它之后被授予了哪些权限。

来源可信度

  • 来自 Antithesis 官方组织仓库 antithesishq,来源相对明确,优于来历不明的第三方同名 Skill。
  • 仍需以你实际获取该 Skill 的渠道为准,避免使用 Fork、镜像或第三方重新发布版本。

与权限有关的主要关注点

  • Shell 权限:接入 Kubernetes 相关任务,Agent 可能会建议或执行 kubectl 一类命令。如果开启自动执行,命令会真实作用于你的集群。这是本 Skill 最需要关注的风险点。
  • 文件写入:接入流程可能涉及生成或修改配置文件(如 YAML、环境相关文件)。请确认 Agent 是否有权写入你的工作目录。
  • 网络访问:接入过程可能需要访问 Antithesis 服务或拉取资料。网络访问本身不是问题,但要注意 Agent 访问的目标是否可信。
  • 凭证:Kubernetes 接入通常涉及 kubeconfig、集群凭证或 Antithesis 的 API Key / Token。这类凭证一旦放进对话或日志,存在泄露风险。

降低风险的建议

  • 如果只需要它帮你梳理接入步骤、生成配置草稿,可以关闭 Agent 自动执行 Shell 的权限,由你手动执行 kubectl 等命令。
  • 不要把生产集群的高权限 kubeconfig 直接交给 Agent。用受限的命名空间或测试集群验证流程,再应用到生产。
  • 不要把长期有效的 API Key、Token 明文粘贴进对话;优先使用短时效凭证,用后及时轮换。
  • 对 Agent 生成并准备执行的命令,先人工审阅,尤其是涉及 apply、delete、权限变更之类的操作。

以上是使用这类接入辅助 Skill 时的一般性风险点。该 Skill 是否存在额外行为,官方资料未明确说明,具体以官方说明和你在本地的实际权限配置为准。

Skill 使用要求

一、Agent / 客户端

  • 该 Skill 来自 Antithesis 官方 skills 仓库,按 Agent Skill 的通用工作方式加载使用。
  • 官方没有提供完整的第三方 Agent 兼容列表。在支持 Skills、自定义 Skill 或类似指令加载机制的 Agent 中通常可以尝试,例如 Claude Code、Codex、Cursor、Trae、OpenClaw、WorkBuddy。
  • 不同 Agent 的 Skill 加载方式与兼容程度可能不同,具体以对应 Agent 当前版本为准。

二、运行环境 / 依赖

项目 要求
Agent 支持 Skills 或自定义 Skill 的客户端
Kubernetes 环境 接入 Antithesis 时需要可用的集群与访问方式
kubectl 接入 K8s 时通常会用到
网络 接入 Antithesis 相关流程时可能需要

Node.js、Python 等是否有硬性版本要求,官方资料未明确说明,不自行推断。

三、权限

  • 文件读取:可选,用于读取你的配置和集群相关文件。
  • 文件写入:可选,用于生成接入所需的配置草稿。
  • Shell:可选,接入 K8s 时可能执行 kubectl 命令;建议按需开启。
  • 网络:可选,取决于接入流程是否需要访问外部服务。

四、账号 / API Key

  • Skill 本身是否需要账号或密钥,官方未明确说明。
  • 但接入的后续流程(Antithesis 平台、Kubernetes 集群)通常需要相应凭证,这部分属于你后续操作的项目的需要,不等同于 Skill 本身的要求。

最小使用条件

  1. 一个支持 Skills 的 Agent。
  2. 一个可访问的 Kubernetes 环境
  3. 基本的 kubectl 使用能力

Skill 安装、使用与卸载教程

一、安装

可以直接复制本页面提供的 Skill 安装指令,粘贴到对应 Agent 或终端执行。

如果你不确定自己的 Agent 该如何安装,可以直接问当前 Agent:

如何安装 antithesishq/antithesis-skills#antithesis-k8s-onboarding-assistance?

如何在 Claude Code 中安装 antithesishq/antithesis-skills#antithesis-k8s-onboarding-assistance?

如何在 Cursor 中安装 antithesishq/antithesis-skills#antithesis-k8s-onboarding-assistance?

让当前 Agent 根据自己的 Skill 加载 / 管理机制指导安装。不同 Agent 的安装位置和方式不同,跟随其自身机制即可。如果该 Skill 有特殊官方安装要求,以官方说明为准。

二、安装后如何使用

安装后,Agent 在处理 Antithesis 与 Kubernetes 接入相关任务时会按该 Skill 的约定工作。你不需要输入特殊命令,直接用自然语言描述需求即可。

适合交给它的任务示例:

使用 antithesis-k8s-onboarding-assistance,帮我在 Kubernetes 上梳理接入 Antithesis 的步骤。

使用 antithesis-k8s-onboarding-assistance,检查我这份 K8s 配置在 Antithesis 接入上还缺什么。

使用 antithesis-k8s-onboarding-assistance,按顺序告诉我接入 Antithesis 需要准备哪些东西。

三、卸载

不同 Agent 的 Skill 安装位置和管理方式可能不同,通常可以:

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

如何卸载 antithesishq/antithesis-skills#antithesis-k8s-onboarding-assistance?

如果没有统一卸载命令,让当前 Agent 根据其自身机制指导移除通常更稳妥。官方是否提供专门的卸载命令,资料未明确说明,不编造。

常见问题

安装后 Agent 没有识别到这个 Skill,怎么办?

先确认 Skill 装在了当前 Agent 实际读取的目录或位置,再确认 Agent 是否需要重启或重新加载 Skill。不同 Agent 机制不同,可直接问当前 Agent 它是否已加载该 Skill。

可以在多个 Agent 里同时安装吗?

通常可以,Skill 是分别装到各 Agent 的。多个 Agent 各自加载互不影响,但要注意在哪个 Agent 里运行,就使用该 Agent 的权限配置。

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

取决于 Agent 的 Skill 管理方式。有的会自动获取最新内容,有的需要重新拉取。不确定时可以直接问当前 Agent 是否需要更新。

这个 Skill 会直接修改我的 Kubernetes 集群吗?

它本身是接入辅助性质的指导 / 工作流,不主动改集群。真正改集群的是 Agent 执行的具体命令(如 kubectl apply)。如果你不想让它自动执行,可以关闭 Agent 的 Shell 自动执行权限,由你手动执行。

可以关闭 Shell 权限使用吗?

可以。关闭后它仍可用于梳理步骤、生成配置草稿和解释接入流程,只是不能替你直接执行命令。

和中国大陆网络环境有关吗?

该 Skill 面向 Antithesis 与 Kubernetes 接入,属于通用海外服务范畴,不是针对中国大陆平台或业务设计的。在中国大陆使用时,是否能顺畅通访问 Antithesis 相关服务,取决于你的实际网络条件。

它和通用的 Kubernetes Skill 有什么区别?

通用 K8s Skill 覆盖面更广,而这个 Skill 聚焦在「把 Antithesis 接入 Kubernetes」这一具体目标上,更偏向特定接入流程的辅助,而不是通用集群运维。

Skill 更新日志

版本列表
无版本号
更新 PR #204 的技能版本
无版本号
更新 PR #204 的变更日志
无版本号
fix: 澄清测试模板不需要驱动程序 (#204) Co-authored-by: Carl Sverre Co-authored-by: Claude Opus 5.5
无版本号
更新 PR #198 的技能版本
无版本号
更新 PR #198 的变更日志
无版本号
feat: 添加 antithesis-feature-workload 技能 (#198)
无版本号
fix: 在 README 中为 antithesis-review-inputs 添加起始提示 (#203)
无版本号
更新 PR #201 的技能版本
无版本号
更新 PR #201 的变更日志
无版本号
feat: 添加 antithesis-review-inputs 技能 (#201) 该技能审查工作负载的输入生成,以评估状态空间探索——即它如何利用随机性将被测系统驱动到多样化的行为区域。
无版本号
更新 PR #200 的技能版本
无版本号
更新 PR #200 的变更日志
无版本号
feat: 添加 antithesis-mutation-testing 技能 (#200) * feat: 添加 antithesis-mutation-testing 技能 验证的是 oracle 而非 SUT:一个每次运行都通过的属性可能是一个永远不会失败的属性。对于每个安全类属性(Always、AlwaysOrUnreachable、Unreachable),该技能注入一个真实的 bug,在 Antithesis 下运行它,并确认目标属性触发——然后将每个幸存者诊断为坏变异体、坏 oracle、坏工作负载或坏属性,并将修复路由到工作负载或研究技能。 工作原理:变异体仅作为补丁存在于用户代码树的临时 git fork 中——工作树永远不会被修改,clean.sh 会验证这一点。每个变异体构建为自己的镜像(在 fork 的 compose 中交换标签),携带一个启动公告以证明部署了正确的构建,以及一个标记以证明有缺陷的代码被执行,并在花费任何运行之前先在本地验证。运行以 --ephemeral 在专用的 --source 下启动,因此故意的失败永远不会进入真实的属性历史。证伪要求标记与目标的反例出现在同一历史中,而不是两次运行范围的计数。 组件: - SKILL.md:先决条件、绿色基线门禁、开场访谈(预算上限、并发、自主性、树写入权限)、范围规则、三个工作流、自审清单 - references/:测试框架机制、变异体设计(三部分补丁)、静态杀伤链验证、扫描 + 判定阶梯 + 归因、证据工件(访谈/状态/历史/报告)、缺失 scratchbook 的目录重建、恢复协议 - assets/mutation-testing/:六个 bash 脚本(fork、sync-patches、select-mutant、build-mutants、verify-mutant、clean)以及一个记录工作目录的 AGENTS.md 另外:triage 在全绿运行中建议该技能,工作负载的迭代文档在绿色运行后指向它,README 记录了用法和成本。 对于审查,承重的部分是判定阶梯和同历史归因规则(sweep-and-verdicts.md)、预算和停止规则(上限、尝试次数上限、无进展停止)、以 fork 的 base_tree 指纹为键的双分支重扫描规则,以及脚本 INTENT/ASSUMES/GUARANTEES 头中的 fork 隔离保证。已针对真实租户进行端到端验证,由三代理小组审查交叉引用和一致性缺陷,并用 make validate 检查。 * 将 mutatable 添加到拼写错误字典,并将 mis-implemented 替换为 incorrectly implemented * 工作负载技能:简化变异测试的解释 Co-authored-by: Carl Sverre * README:澄清变异测试成本 --------- Co-authored-by: Carl Sverre
无版本号
更新 PR #195 的技能版本
无版本号
更新 PR #195 的变更日志
无版本号
feat: 优先使用调用方提供的启动参数而非技能默认值 (#195)
无版本号
更新 README.md 中的安装说明
无版本号
更新 PR #199 的技能版本
无版本号
更新 PR #199 的变更日志
无版本号
澄清 Antithesis 断言不会结束时间线 (#199) 工作负载技能的断言参考中没有提到 SDK 断言是非致命的。根据此文档编写断言的模型可能会从训练中引入断言失败 = 崩溃/中止的假设,导致断言不足或围绕断言调用编写防御性代码。
无版本号
在 README 中添加模型指导部分 (#196) 大多数用户不需要前沿模型来使用这些技能。像 Opus 4.6 这样的中端模型是一个很好的起点,而像 research 这样 token 密集型的技能使成本差异变得有意义。
无版本号
更新 PR #194 的技能版本
无版本号
更新 PR #194 的变更日志
无版本号
fix: reach 声明必须断言前置条件,而不是违规 (#194) * fix: reach 声明必须断言前置条件,而不是违规 遵循 antithesis-workload,一个代理将每个 Sometimes reach 声明写为同一位置 Always 的精确否定。这样的配对不携带任何信息:Sometimes 仅在 Always 失败时触发,而在固定构建上它永远不会触发,Antithesis 将其报告为失败。该代理还将未触发的 reach 声明解读为覆盖缺口,并称两个绿色安全属性是空洞的。 将规则添加到 references/assertions.md,将检查添加到 references/iteration.md 中的 triage 循环,并在 SKILL.md 中添加一个自审项。 fixes #193 Co-Authored-By: Claude * docs: 将 reach 声明指导精简为简化技术英语 Co-Authored-By: Claude * docs: 分别断言前置条件的每一部分 Co-Authored-By: Claude --------- Co-authored-by: Carl Sverre Co-authored-by: Claude
无版本号
更新 PR #191 的技能版本
无版本号
更新 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 插件。这些技能告诉代理优先使用 `podman compose`,而没有任何版本的 snouty 支持它。 compose CLI 和容器引擎是两个独立的选择。这些技能现在说明了这一点,列出了两种受支持的组合,并引导代理使用 `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(代理运行构建的地方)。这消除了两次指针跳转。 删除 snouty 版本注意事项、README.md 中重复的段落,以及重复的“不要使用 podman compose”行。现在一条正面指令承载该规则:运行 `snouty doctor` 并使用它指定的组合进行构建。 引导代理查看 `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,因此代理自己的构建在 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 工具与测试框架所需的 docker-compose 功能不兼容。 Co-Authored-By: Claude --------- Co-authored-by: Carl Sverre Co-authored-by: Claude
无版本号
更新 PR #189 的技能版本
无版本号
更新 PR #189 的变更日志
无版本号
使用 Sometimes 断言验证工作负载可达性 工作负载技能已经教授用于活性和语义状态的 Sometimes 断言,并教授 triage 后的迭代。缺失的是:有意将 Sometimes 断言写为关于工作负载应达到什么的声明,然后将未触发的断言用作工作负载驱动需要改进的证据。 将该实践添加到 assertions.md,将其连接到 iteration.md 中的迭代循环,并在 SKILL.md 中添加一个工作流步骤和自审标准。

暂无评论

none
暂无评论...