GitHub将workflow artifact定义为工作流一次运行中产生的文件或文件集合，它使资料在任务结束后仍可保存，也能交给同一工作流的其他任务。[1] 这里被保存的是某个任务产生的资料。一个文件在任务工作区里叫什么，与它作为工件交接时叫什么，需要沿着官方示例分别阅读。
《Store and share data with workflow artifacts》的三任务例，给出了一个可以核对的数字过程。job_1先计算三加七，将十保存到math-homework.txt，再以homework_pre这个工件名上传该文件。job_2取得homework_pre，读取文件中的值，乘以九，又把结果保存回math-homework.txt。job_3取得后续工件并将最终结果写入日志。整个算式是三加七的和再乘九，结果为九十。[2]
第二个任务继续使用同一个文件名，却没有沿用同一个工件名。教程明确说，v4中的工件被视为不可变，因此第二次给出的名称是homework_final。[2] 在这个例子里，math-homework.txt作为工作区文件，其内容从十被覆盖为九十；homework_pre和homework_final则分别标记交接中的两个工件。文件内容发生覆盖与工件不可变并不相互否定，因为两句话所指的对象不同。
这个差别也使中间结果与最终结果的去向可读。job_2读取的是前一个任务的homework_pre，job_3读取的是job_2的homework_final。若说明只剩下“大家都用了math-homework.txt”，就无法表达第三个任务究竟接续哪一份结果。两个具名工件把交接阶段留在名称中，而不是要求读者仅凭相同文件路径猜测其内容已经到了哪一步。[2]
任务的先后还由示例的依赖关系交代。教程用needs让job_1、job_2、job_3依次运行，并说明依赖前一任务工件的任务，必须等待前一任务成功完成。[2] 因而，文件与工件名称之外，还有结果何时具备被后续任务使用条件的问题。这里的等待条件属于教程流程本身，不是看到一个文件名就已经证明任何真实项目完成了运行。
工件名称也不等于文件数量。教程允许一个工件包含单个文件、多个文件或目录；未提供名称时，默认名为artifact。对于一次运行的全部工件，文档所述的下载结果会按每个工件的名称分别建立目录。[2] 这使工件名除了区分上述计算阶段，还能组织一组文件：一个工件可以包含不止一个路径，而多个工件也不会仅因内部文件同名，就在说明里失去各自身份。
保存的期限又属于另一项资料属性。教程说，单个工件可以有自己的保留期，但不能超过仓库、组织或企业设置的上限。[2] 概念页则明确，删除一次工作流运行时，与该运行关联的全部工件也会从存储中删除。[1] 前者限制一项工件可保留多久，后者把关联工件的存续联系到运行记录；工件不可变的定义没有独自保证它会一直存在。
本篇解释GitHub.com文档中明确采用v4工件的示例，没有执行工作流、上传下载文件或配置保留期限；网页首次发布日期未知。十与九十均为官方算式中的数值，不是本项目运行所得。
资料：[1] https://docs.github.com/en/actions/concepts/workflows-and-actions/workflow-artifacts
[2] https://docs.github.com/en/actions/tutorials/store-and-share-data
信息来源
本文基于上述公开资料整理，未使用来源页面的图片、视频或嵌入媒体。