技能介绍

在 Kubernetes 上用 Argo Workflows 编排计算任务时，YAML 模板的数量会随着 DAG 复杂度快速增加。一次脚本改动、一次复制粘贴改参数，都可能引入语法错误、DAG 依赖成环、引用了不存在的构件，或者上游步骤输出与下游步骤输入的类型对不上。这些问题往往要等到 argo submit 甚至运行到某个 Pod 失败之后才暴露，排查代价通常比编写阶段大得多。

核心能力与工作方式

这个技能把校验放在提交运行之前完成，主要走两条通道：

命令行模式：使用 argo CLI，适合本地开发时直接对模板文件跑 argo lint 或 argo lint --strict，改动保存后几秒内就能得到反馈。
API 模式：通过 Argo Server REST API 发起校验请求，适合嵌入 CI/CD 流水线，在 MR 阶段拦住明显不合法的 workflow。

它会重点检查三类容易漏掉的问题：

DAG 依赖循环：当 A 依赖 B、B 又（直接或间接）依赖 A 时，workflow 永远不会进入运行态，靠肉眼读模板很容易忽略。
无效的构件引用：步骤里引用了并未声明的 artifacts、arguments.artifacts 或 outputs.artifacts，这类问题在提交时可能被推迟到运行时才报错。
参数类型不匹配：上游 outputs.parameters 声明的是 string，下游却当作 int 使用；或者 default 值与 schema 里的 type 不一致。

除了问题检测，它还会做模板的语法与结构验证，保证文件能被 Argo 正确解析。整个流程是静态的，不会触发任何容器部署，也不会消耗集群资源。

适用边界与注意点

前置条件：运行环境需要能访问 argo CLI 与 Argo Server 的 API 端点，CI 场景下通常需要相应命名空间的 get/list 权限。
校验不是编译：它不会真正执行 DAG，因此无法发现运行期才出现的问题，例如镜像拉不下来、when 条件实际值与预期不符。
建议跑在提交前：将 argo lint 放在本地钩子或流水线入口，可以显著减少无效提交进入共享仓库的概率。
容器化与亲和性规则仍靠人工确认：调度相关的 nodeSelector、tolerations、affinity 以及 Hera/Juno 等 SDK 生成的模板结构，需要结合集群实际情况再核对一遍。