摘要：2026 年 9 月 24 日，GitHub 调整了 Actions 中过期 artifact 的呈现方式。运行摘要页的 artifact 列表不再显示它们，REST API 的「列出仓库 artifact」与「获取单个 artifact」两个端点也不再返回它们。此前这些条目的底层文件已经从存储中删除，却仍带着 Expired 标签留在列表里。GitHub 明确说明：保留期设置与计费都不受影响，产物记录仍可在该次运行的日志中找到。
「这个 artifact 到底还在不在？」这个问题在过去几个月里，让不少人的 CI 排障多绕了一个弯。运行摘要页的列表里明明躺着一个带 Expired 标签的产物，API 也照样把它返回给你，但实际上存储里那份文件早就被清掉了。列表说存在，存储说没有，而账单又说不清。
9 月 24 日，GitHub 把这个不一致收掉了：过期 artifact 不再出现在 UI 里，也不再由 REST API 返回。这次改动很小，但会影响到所有用 API 枚举产物的脚本和平台工具。下面说清楚它到底改了哪三处、没改哪两处，以及你的自动化里哪一行需要跟着动。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
发生了什么：三个表面不再返回过期 artifact
按 GitHub Changelog 的描述，改动的范围被限定在「怎么显示」这一层。具体是三个表面：第一，工作流运行摘要页上的 artifact 列表；第二，REST API 中「列出仓库 artifact」（list artifacts for a repository）这个端点；第三，「获取单个 artifact」（get an artifact）这个端点。这三处从此都不再出现已经过期的条目。
变更之前的形态是：artifact 过期、底层文件已从存储删除，但列表里仍然留着它，并打上一个 Expired 标签。GitHub 在公告里直接点出了这个标签造成的困惑——有用户因此不确定自己是否还在为一份已经不存在的产物付存储费。
同时被明确划在改动之外的，是保留期设置与计费。公告原文说这次「只改变过期 artifact 的显示方式」，不影响 artifact retention 设置，也不影响计费。也就是说，一个 artifact 什么时候过期、过期后是否还占额度，规则完全没有变化；变的只是它还露不露面。
一个具体场景：按名字下载产物的部署脚本
设想一条典型的流水线：构建 job 上传一个名为 app-bundle 的 artifact，几小时或几天后，部署 job 通过 API 先列出某次运行的全部产物，按名字找到 app-bundle，拿到它的下载地址，再解压发布。
在过去，如果这次运行的 artifact 已经过期，列表接口依然会返回 app-bundle 这个条目——名字在、大小在、标签是 Expired。脚本会认为「产物存在」，于是继续下一步，直到真正去下载时才拿到失败，报错信息还可能指向下载环节而不是「产物已过期」这个真实原因。
改动之后，同一个脚本会在列表这一步就拿到空结果。它需要自己判断「列不到」到底是过期、是本次运行压根没上传、还是名字拼错。好处是失败点前移、语义变干净；代价是原本靠「列到名字」当作存在性检查的写法，现在会静默地走进另一条分支。
为什么这会改变工作流
受影响最明显的不是人手点界面的场景，而是把 API 当数据源的工具。任何做「产物清单」「交付留痕」「存储用量盘点」的平台层脚本，过去都能拿到一份包含过期条目的列表，现在这份列表会变短。如果这些脚本把条目数量当作指标上报，指标会突然下降——不是因为产物少了，而是因为看不见了。
另一个变化在排障路径上。公告给出的替代方案很明确：如果需要知道某次运行产出过什么，可以回到该次运行的日志里找。这等于把「产物记录」的权威来源从 artifact 列表挪回了日志。对习惯了看列表的人，这是一个需要重新建立的肌肉记忆；对已经把日志归档的团队，则几乎无感。
从平台设计的角度看，这次修复的是一类常见的一致性缺陷：一个索引层保留了元数据，而底层对象已经不存在。GitHub 选择的解法是让索引层跟着对象一起消失，而不是给条目加更多状态说明。这个方向对使用方更友好，但也意味着「曾经存在过」这个信息不再由 artifact 接口承载。
限制、边界与人应该在哪儿接手
第一，这次改动不提供任何兼容开关或宽限期提示。它不是一个需要在设置里开启的预览功能，而是直接生效的行为变更，因此在变更前后跑同一段脚本，可能得到不同结果。
第二，日志并不是 artifact 的等价替代品。日志能告诉你这次运行上传了什么名字、多大体积，但它不提供重新下载那份产物。如果业务上需要长期保留产物用于回溯发布或合规取证，就必须依赖 artifact 保留期设置、把产物转存到自己的对象存储，而不是指望列表接口。
第三，这件事提醒了一个更普遍的判断点：「接口返回了条目」和「资源可用」是两件事。凡是把列表结果当作可用性依据的自动化，都值得检查一遍。人的接管点在这里很明确——把「产物缺失」从下载阶段的报错，前移成流水线里一条有明确文案的失败分支，让值班的人一眼看懂是过期还是没上传。
如何自查与调整
可以在一个已有过期 artifact 的仓库上做一次对照验证：调用列出仓库 artifact 的接口，确认过期条目不再出现；再对同一次运行的日志确认产物名称仍可追溯。随后检查自有脚本中所有基于产物列表的判断分支，把「列表为空」拆成过期、未上传、名字不匹配三种情况分别处理，并把需要长期留存的产物改为在构建成功时同步转存。
信息来源
- GitHub Changelog：Expired GitHub Actions artifacts no longer shown in UI and API（2026-09-24）— https://github.blog/changelog/2026-09-24-expired-github-actions-artifacts-no-longer-shown-in-ui-and-api
- GitHub Docs：REST API — Actions artifacts（list artifacts for a repository / get an artifact）
- GitHub Docs：Storing and sharing data from a workflow（artifact 保留期设置）
HiFox ：将 Agent 变成真正的队友
另外，我们也在思考，AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。
👉 立即体验 Hifox：https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。