摘要：2026 年 9 月 28 日，GitHub 把自托管运行器的最低版本强制日期提前：完整强制执行从 9 月 29 日开始，取代此前公布的时间。低于 2.329.0 的运行器无法注册或重新注册；已注册但低于运行版本下限的运行器会停止执行作业，即使它此前注册成功过。影响范围仅限 GitHub Enterprise Cloud，Enterprise Server 不受影响；带数据驻留的 Cloud 实例早在 7 月 31 日就已开始强制。官方同时给出了一个可以提前自查的 REST API。
这条公告最容易被误读的地方，是它说的不是一个门槛，而是两个。第一个门槛管注册：低于 2.329.0 版本的运行器无法注册，也无法重新注册。第二个门槛管作业执行：官方提到执行作业需要更高的最低版本，而已注册但低于这条线的运行器会停止执行作业——发布说明里特意补了一句，即便它此前已经成功注册过。
「已经注册过」这个限定词是整条公告里最需要留意的部分。它意味着一个运行器不会因为你什么都没做就继续可用；注册状态不构成豁免。如果你的自托管机群是分批建设的，很可能会出现「新机器都合规、老机器还在跑」的混合状态。
还有一个时间差值得单独指出：带数据驻留的 Cloud 实例已经在这条线之外。下面把日期、范围和自查手段分开讲。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
发生了什么：两个门槛，一个提前的日期
按公告，这项变更于 2026 年 9 月 28 日发出，完整强制执行从次日 9 月 29 日开始，取代此前公布的时间。公告没有在正文里重述旧日期，只说新时间「取代此前宣布的日期」，所以如果你是按旧日期排的升级计划，需要直接按 9 月 29 日重排。
范围被写得很清楚：只影响 GitHub Enterprise Cloud。GitHub Enterprise Server 不受影响。这一条对同时运维两种形态的团队很重要——同一条内部通报不能直接发给所有环境。
第三个事实是时间差：GitHub Enterprise Cloud with Data Residency 的强制已经于 2026 年 7 月 31 日开始。也就是说，如果你的实例带数据驻留，这不是一个「还有一天」的问题，而是一个「已经在执行」的问题。
公告给出的建议是直白的：在 9 月 29 日之前升级。升级指引放在自托管运行器文档里。
一个具体场景：机群里那批「还能跑」的旧运行器
设想一个企业团队的 CI 机群：20 台自托管运行器，分三批采购。最早那批装的是两年前的 runner 版本，一直工作正常；后两批是新机器，版本早就过了 2.329.0。团队没有升级第一批的理由——它们没坏，构建成功率也正常。
9 月 29 日之后，第一批机器会进入两种不同的失败模式。版本低于 2.329.0 的那部分，连注册都过不去，表现为「机器还在，但接不上」；版本高于 2.329.0 但仍低于运行版本下限的那部分，能注册，但会停止执行作业。这两种故障的报错位置不同，值班的人如果不清楚门槛的划分方式，很容易误判成网络问题或权限问题。
同一件事在 Data Residency 实例上已经发生过一轮。7 月 31 日开始强制的实例，团队多半已经踩过一次这两种失败模式，那次的排查经验可以直接复用。
为什么这会改变工作流
第一个变化是机群管理从「按需维护」变成了「按版本清单维护」。过去自托管运行器的版本是运维细节，只要机器能用就没人过问；现在版本本身变成了一条会被强制执行的边界。这意味着机群清单里需要新增一列：每个运行器的当前版本，以及它对应的注册与运行弃用日期。
第二个变化是升级动作的节奏。整批升级自托管运行器不是无风险操作，通常要排窗口、要避开发布日。公告只提前了一天，对已经把本周排满的团队来说，真实的做法很可能是先处理版本低于 2.329.0 的那批（因为它们连注册都保不住），再把仍在运行的旧版本排进下一个窗口。
第三个变化来自官方给的工具：新增的运行器版本弃用 REST API 可以查询任意版本的注册弃用日期与运行弃用日期。它的意义不在于这次，而在于把「下一个截止日期是什么时候」变成可以自动告警的值。机群规模一大，靠人读 Changelog 排期是不可靠的。
限制、边界与人应该在哪儿接手
公告没有在正文里给出运行版本下限的具体数字。它只写了注册门槛是 2.329.0，并把运行门槛描述为「更高的最低版本」，具体数值需要去自托管运行器文档里核对。这是一个必须自己查清的参数，不能从这条公告里推断。
第二个边界是范围判断。GitHub Enterprise Server 不受影响，但如果你同时有 Cloud 与 Server 两套环境，运维通报必须分开发，否则会引发不必要的升级动作。
第三个边界在升级本身：公告提供的是截止日期和查询 API，不是升级路径。不同操作系统与架构的运行器升级方式不同，需要各自的方案。人的接管点在这里——把版本清点、日期换算和升级窗口排期交给流程，而不是留给值班的人临时判断。
还有一点需要说明：这次公告本身被标记为 Retired 类目，也就是说它是对既有政策的时间调整，而不是一项新政策。如果你此前完全不知道这项强制存在，那么真正需要补的功课是去读最初发布的那条公告，而不是只读这一条。
如何自查与升级
第一步是清点：列出所有自托管运行器的当前版本，按是否低于 2.329.0 分成两组。低于这个数字的，在 9 月 29 日之后会失去注册与重新注册能力，优先级最高。
第二步是查运行下限：到自托管运行器文档里核对执行作业所需的最低版本，再对照清点结果，找出「版本已过 2.329.0 但低于运行下限」的那批——它们能注册，但会停作业。
第三步是接上告警：调用运行器版本弃用的 REST API，读取各版本的注册弃用日期与运行弃用日期，给临近期限的机群做自动提醒，避免下一条同类公告再靠人工发现。
如果你的实例带数据驻留，先确认当前状态——这条线从 2026 年 7 月 31 日起已经在执行。
信息来源
- GitHub Changelog：Self-hosted runner version enforcement date has moved（2026-09-28，Retired）— https://github.blog/changelog/2026-09-28-self-hosted-runner-version-enforcement-date-has-moved/
- GitHub Docs：Managing self-hosted runners（升级指引与最低版本要求）
- GitHub Docs：REST API endpoints for runner version deprecations（注册与运行弃用日期）
HiFox ：将 Agent 变成真正的队友
另外，我们也在思考，AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。
👉 立即体验 Hifox：https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。