GitHub 官方文档列出的自托管 Runner 网络连接要求包括最低 70 kbps 的上传和下载速度，并要求主机能通过 HTTPS 的 443 端口访问相关服务；这只是通信门槛，不代表构建速度、安全合规或科研结果有效。(自托管 Runner 官方参考) 结论：项目必须在 macOS 上构建或测试，而且团队有人负责主机维护时，自托管 Runner 才值得部署。先用隔离仓库验证注册、执行和清理流程，不要把它直接用于不受信任的 PR 工作流。
开发 macOS 科研应用的研究生：需要把本地构建或测试接入 GitHub Actions。 课题组开发者：工作流依赖自定义工具，或需要持续可用的 macOS 环境。 高校 IT 与实验室管理员：需要评估仓库访问范围、凭证权限和日常维护责任。
部署前先判断是否需要 macOS Runner
远程 Mac 可以承担 GitHub Actions 的 macOS 工作流，但主机必须能够运行 Runner 程序并与 GitHub Actions 通信，项目所需工具也必须能在该环境中使用。即使连接成功，数据访问、网络边界和机构安全审批仍需单独核实；Runner 在线状态不能代替这些审查。
先检查项目是否真的依赖 macOS：目标应用需要在 macOS 环境构建、测试，或工作流依赖只能在该环境中使用的工具。如果现有 GitHub-hosted Runner 已能满足任务，就没有必要仅为使用远程 Mac 而迁移；多一台自托管主机，也意味着团队要承担更新、故障排查、磁盘清理和权限管理。
| 方案 | 环境与维护责任 | 适合的情况 | 主要限制 |
|---|---|---|---|
| GitHub-hosted Runner | 使用托管环境，团队不负责维护一台常驻 Runner 主机 | 现有环境能提供项目需要的系统和工具 | 需确认托管环境是否满足项目要求 |
| 实验室自托管 Mac | 团队配置工具，并负责主机、网络和日常维护 | 实验室已有获批 Mac，且有人负责运行 | 共享排期、主机状态和交接责任要明确 |
| 远程 Mac 自托管 Runner | 团队负责 Runner 与工作流；主机的具体环境取决于实际交付 | 项目需要持续可用的 macOS 环境，且远程访问符合数据规则 | 有网络依赖，仍需核实主机能力及机构政策 |
| 不部署 macOS Runner | 继续使用现有 Linux、Windows 或其他 CI 环境 | 项目并不要求在 macOS 上执行 | 不能据此验证 macOS 专属构建或行为 |
注册前先限定仓库、代码与凭证范围
先准备专用测试仓库或可恢复的项目副本，列出工作流会执行的脚本、安装的依赖、访问的数据和所需凭证。标记哪些内容属于受限研究数据，并确认数据是否允许存放或处理在实验室外的主机上；如果需要机构审批，先完成审批再安装 Runner。
注册位置会影响任务可用范围。建议先限定在单个测试仓库；只有确实需要共享时，再评估组织级 Runner 及其访问策略。GitHub 官方添加说明涵盖了不同范围的 Runner 注册流程，操作时应以仓库或组织设置页当时生成的指令为准。(添加自托管 Runner 的官方步骤)
远程 Mac 是否能承担 macOS CI 作业？ 可以，但要确认它能访问工作流所需的服务、安装项目依赖，并按课题组的数据规则处理代码和文件。远程连接本身不能证明数据驻留、访问控制或网络设置符合高校政策；这些问题需要你和负责审批的人员逐项确认。
来自 fork 的 PR 应如何处理？ 如果提交的代码不受信任，不要把它直接派发到可接触凭证、项目文件或内部资源的自托管主机。GitHub 的安全说明提醒，自托管环境可能受到不受信任工作流的持久影响；任务结束不意味着主机已自动恢复干净。(GitHub Actions 安全使用建议)
同时检查 GITHUB_TOKEN 和仓库密钥的使用范围，只授予工作流完成任务所需的权限。权限设置可以降低不必要的访问，但不能替代主机隔离，也不能代替机构安全审批。(设置 GITHUB_TOKEN 身份验证的官方教程)
注意：Runner 任务可能接触主机上已有的文件和网络资源。除凭证外，也要把临时文件、缓存、测试数据和失败日志纳入清理与审查流程。
在 macOS 主机上注册并设置恢复路径
注册时不要复制来源不明的安装命令。进入仓库或组织的 Actions Runner 设置页，选择添加自托管 Runner，并根据页面指引选定系统和架构；随后在 Mac 上下载 Runner 程序、解压并运行配置步骤。配置时记录 Runner 名称、标签及所属范围，并按页面要求处理注册令牌，不要将其写进工作流或提交到代码库。(GitHub 官方 Runner 添加说明)
建议按以下顺序操作：
- 建立可恢复的测试范围。 使用专用测试仓库或可恢复副本，先确认工作流不会读取敏感材料。
- 核对主机条件。 按当前官方文档确认 macOS 版本、处理器架构和网络要求，并检查项目依赖是否能安装。
- 选定注册范围。 从单仓库开始；需要共享时，再由管理员评估组织级 Runner 与可访问仓库范围。不要借用他人凭证绕过权限流程。
- 按设置页指令注册。 记录名称、标签和注册位置，确认主机能连接 GitHub Actions。
- 配置工作流路由。 使用
runs-on指定与 Runner 实际标签相符的条件。Runner 在线不代表标签一定匹配；路由条件也不证明主机上的软件版本或工具状态正确。(工作流语法与 Runner 选择规则) - 准备重启与移除流程。 若需要主机重启后自动恢复，依据 GitHub 的 macOS 服务配置说明设置服务，并记录如何查看状态、停止服务和移除 Runner。(macOS Runner 服务配置官方说明)
用最小科研工作流分层验收
先提交不含敏感数据、结果容易核对的工作流，再逐步加入项目构建与测试命令。下面的示例只用于核验执行环境，不会验证科研软件功能，也不能证明分析结果有效：
name: macOS runner smoke test
on:
workflow_dispatch:
jobs:
verify:
runs-on: [self-hosted, macOS]
steps:
- name: Check runner environment
run: |
sw_vers
uname -mruns-on 中的标签必须和 Runner 配置相匹配；如果设置了其他自定义标签或 Runner 组，应按实际配置调整。上述系统命令用于记录 macOS 版本和处理器架构，不是对应用构建或科研计算结果的验收。GitHub 的工作流语法文档说明了作业如何按 Runner 标签进行选择。([工作流语法与 Runner 选择规则](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax))
验收记录要区分几个层次：
- 路由：作业是否匹配了预期 Runner，日志是否能确认执行位置。
- 环境：macOS 版本、处理器架构和关键工具版本是否符合项目基线。
- 项目：构建与测试命令是否执行，日志和产物是否可检查。
- 科研结果：分析结果是否按学科方法复核，数据处理是否符合项目要求。
- 清理：临时文件、缓存、测试数据和凭证是否按约定处理。
根据隔离检查结果决定正式接入
正式仓库接入之前，逐项记录结论和负责人：
- 工作流是否限定在获准的仓库和事件范围内？
- 不受信任的提交是否不会进入能访问内部资源的自托管主机？
- 令牌和密钥是否只授予任务所需权限？
- 主机上的项目文件、缓存和临时数据是否能够检查与清理？
- 主机重启后是否有明确的恢复办法，Runner 故障时由谁处置？
- 数据使用和执行环境是否完成所需的机构审查？
只有在主机隔离、仓库权限和清理流程都经过检查后，才考虑正式运行构建任务。需要由外部贡献者提交代码的项目，应先为不受信任的代码设计隔离执行路径，而不是直接放宽 Runner 的仓库访问范围或密钥权限。
建立长期维护基线再决定是否扩展
每次 macOS、开发工具、Runner 配置或仓库权限变化后，更新环境记录：包括系统信息、关键依赖的安装方式、Runner 标签、工作流触发范围、维护负责人和最近一次验收结果。作业排队时，先核对 Runner 是否在线、标签与组是否匹配，以及工作流是否有权使用该 Runner；不要只看主机进程就断定调度正常。
还要明确日志保留和清理方式。失败日志可能包含文件路径、环境变量或研究数据线索，分享给课题组成员之前先检查内容；缓存则应按项目要求处理，避免一个任务留下的状态影响之后的结果。服务配置和状态管理按官方 macOS 说明维护，不要把未经记录的手工修改当作长期运行方案。
如果你目前依赖实验室的 Linux 或 Windows 主机，它们不能直接替代需要在 macOS 上执行的构建；共享 Mac 可能受排期和环境交接影响；自行购置设备则需要你承担采购与维护。对只需偶尔验证兼容性的项目，先利用现有 CI 或实验室资源更合适；若项目确实需要持续可用的 macOS 主机，可以先查看 MACGPU 远程 Mac 环境入口，核实具体系统、访问方式和数据规则后，再决定是否接入 Runner。远程方案仍依赖网络，也不自动满足机构安全政策；需要物理接口或长期重负载且已有合适预算时，自购设备可能更合适。若你还要评估自有 Mac 的选型，可参考 Mac 机型选购指南。