一句话看懂：GitHub 允许仓库管理员为 Dependabot 单独指定运行器类型、自定义标签和运行器组，把依赖更新的执行位置从组织级细化到仓库级。对需要访问私有包源或特殊环境的项目来说，这意味着自动化更新终于能跑在正确的基础设施上。
事件核心：发生了什么
2026 年 9 月 29 日，GitHub 在 Changelog 中宣布，仓库管理员现在可以为 Dependabot 的版本更新和安全更新配置运行器。可选设置包括运行器类型、自定义标签（label）以及运行器组（runner group）。此前这类配置只能在组织层级统一设置，现在权限下放到了单个仓库。
如果选择“带标签的运行器”，可以指向自托管运行器，也可以指向规格更大的 GitHub 托管运行器，默认标签为 dependabot。如果选择“标准 GitHub 运行器”，则继续使用 GitHub 默认托管环境。该功能面向 github.com 上的私有仓库和内部仓库开放，公开仓库和 GitHub Enterprise Server 上看不到这些控件。
为什么重要
Dependabot 的核心工作是扫描依赖、生成升级 PR，这个过程本身需要拉取包元数据，有时还要访问私有 registry 或内网制品库。过去组织级统一配置意味着所有仓库共用一个运行环境，要么被迫开大权限，要么让部分仓库的更新任务跑不起来。仓库级配置让权限边界更清晰：需要私网访问的仓库用自托管运行器，普通开源依赖用 GitHub 托管运行器，资源消耗和安全暴露面都能分开管理。
目前公开信息显示，安全配置（security configurations）暂不强制约束 Dependabot 的运行器设置，这意味着仓库管理员仍需手动保证配置符合组织的安全基线。
对用户/开发者/创作者的影响
对使用自托管 CI 的团队，这项改动减少了为 Dependabot 单独维护组织级例外的工作量，可以直接在仓库设置里把更新任务指到已有运行器组。对依赖私有 npm、PyPI 或容器镜像源的团队，带标签的运行器配合自托管环境，能避免因网络隔离导致的更新失败。对普通开源仓库维护者，影响有限——公开仓库看不到这些控件，仍使用默认托管运行器。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是安全配置是否会跟进支持强制 Dependabot 运行器策略，补上当前的管理缺口；二是 GitHub Enterprise Server 何时获得同等能力，企业客户对仓库级控制的诉求通常更强；三是大规格 GitHub 托管运行器与 Dependabot 的组合是否会影响计费方式，这直接关系到团队的 CI 成本核算。
