Azure Pipelines Apple Silicon：2026 托管还是自托管？

最后更新于 2026 年 8 月 20 日，状态核实自 Microsoft Azure Pipelines 官方文档与 Apple Xcode 27 Release Notes。

Azure Pipelines Apple Silicon 公开预览目前每种规格最多允许 8 个 Standard 与 8 个 XLarge Agent 排队运行。这个限制足以支持短时验证和有限峰值扩容，但不适合把生产发布全部押在仍处预览阶段的托管池上。最快的解法是：生产签名保留独立自托管 Mac 基线，Pull Request、Beta 测试和突发队列交给托管资源，形成双池混合架构。（Microsoft 关于 GitHub-hosted Agents 的说明）

这篇文章适合使用 Azure Pipelines 构建和发布 iOS 应用、正在为 Xcode 27 规划 Apple Silicon 容量的研发效能负责人。
如果还需要处理签名凭证、内部网络、数据驻留或采购预算，下面的场景分流比单纯比较“哪台机器更快”更有参考价值。

先按任务决定 Agent 池，而不是先选供应方式

Xcode 27 Beta 已确认只能安装并运行在 Apple Silicon Mac 上，并要求 macOS Tahoe 26.4 或更高版本。它不等于正式版支持承诺，也不代表所有现有 Intel 流水线都必须立即迁移；但如果团队计划采用 Xcode 27，Intel Agent 已经不能继续作为唯一长期基线。Apple 的 Xcode 27 Release Notes

工作负载场景	推荐资源	是否适合直接进入生产	首要验证证据
Pull Request、非可信分支、一次性构建	GitHub-hosted Agents 的 Apple Silicon 托管池	✅ 适合测试	隔离性、失败清理、队列等待
日常开发 CI、Beta 兼容测试	托管池为主，必要时回退自托管 Mac	⚠️ 需观察预览稳定性	构建成功率、镜像变更、平均排队
App Store 生产签名与发布	独立自托管 Mac 池	✅ 更适合	Keychain、证书撤销、审计日志、恢复时间
私有制品库、内部 API、受限出口	有网络隔离的自托管 Mac	✅ 通常更合适	DNS、白名单、私有端点连通性
发布高峰、临时并发增加	自托管固定容量 + 托管弹性容量	✅ 推荐混合	队列长度、峰值时段、重跑率
需要固定依赖缓存和专用账号	专用自托管 Mac	✅ 更适合	缓存命中、权限边界、环境漂移

需要特别区分 3 类资源：传统 Microsoft-hosted Agents 使用 Azure Pipelines 池；GitHub-hosted Agents for Azure Pipelines 是新的按分钟计费池；self-hosted Agents 则运行在企业或企业指定的 Mac 基础设施上。当前 Apple Silicon 预览资源位于 GitHub-hosted Agents 池，不应把它与传统 Microsoft-hosted macOS 镜像或此前暂停的 macOS 15 ARM64 预览混为一谈。Microsoft 的 Agent 类型说明

对于 App Store 发布，建议先保留独立自托管基线，至少等正式可用状态、镜像范围、运行地域和账单规则都能在企业环境中核实时，再决定是否扩大托管比例。预览资源可以参与生产发布试点，但不宜成为唯一发布出口。

第一种场景：短时验证与非可信代码，优先使用隔离托管环境

Pull Request、外部贡献分支和一次性 Beta 兼容测试的共同特点，是任务短、环境变化快，而且代码本身不应接触生产签名资产。托管 Agent 每次为任务提供新环境，构建完成后不保留上一条任务的工作目录，这比把外部代码直接放进持久自托管 Mac 更容易控制残留风险。Azure Pipelines 安全建议

这类任务建议采用以下路由原则：

PR 验证只允许读取公开依赖和测试凭证，不注入发布证书。
外部 Fork 构建不进入企业内网，不访问私有制品库和内部 API。
Beta 构建使用临时签名配置，构建产物上传到隔离存储。
失败重跑仍使用同类托管镜像，避免把临时状态带入生产节点。
托管池的镜像标签必须固定，不要在 YAML 中长期使用无法审计变化的模糊标签。

需要核查的并不是 Azure DevOps 组织页面显示的地区，而是实际 Agent 的运行地域、镜像标签、可用性和网络能力。Microsoft 文档说明，不同托管 macOS 资源的运行地域和网络限制不能简单由组织所在地区推断；传统 Microsoft-hosted macOS Agent 还可能始终运行在美国，这对数据驻留要求较高的企业尤其重要。Microsoft-hosted Agent 的地域与网络说明

第二种场景：生产签名必须建立独立的自托管基线

生产发布流水线与普通测试任务的差别，不在于是否执行了 xcodebuild，而在于它会触碰长期有效的凭证、固定的发布账号和真实用户可下载的产物。

自托管 Mac 的优势是可以冻结 Xcode、依赖包、证书、Provisioning Profile 和 Keychain 结构；但这并不是“配置完成后就不用管”。Azure 官方提醒，自托管 Agent 本质上会执行从外部下载的代码，运行身份、Agent 文件夹、Pipeline 定义和 Agent Pool 权限都必须纳入威胁模型。macOS 自托管 Agent 文档

生产签名池至少应做到：

使用专用非 root 系统账号运行 Agent，不授予日常 sudo 权限。
将签名节点与普通测试节点分开，不能共用高权限 Agent Pool。
Keychain 只在签名任务中解锁，任务结束后清理临时密钥和导出文件。
发布账号、证书和 Provisioning Profile 分离管理，设置撤销与轮换流程。
关闭来自外部 Fork 的自动生产发布路径。
为 Agent 主机准备远程重启、磁盘清理、账号撤销和整机重装流程。

面对 Xcode 27 的 Apple Silicon 要求，团队应如何分配托管与自托管资源？
如果只是检查编译兼容性，先用 Apple Silicon 托管 Agent；如果需要稳定签名、固定缓存、内部依赖或审计取证，则使用自托管 Mac。Xcode 27 目前仍应按 Beta 状态管理，正式版支持范围、镜像标签和流水线兼容性都要在发布前重新核实，而不能把 Beta 的运行要求直接当作长期 SLA。

VNCMac 的远程 Mac 方案适合用来建立一台隔离的 Apple Silicon 自托管 Agent 试点机：先把签名任务限制在专用池，再观察真实构建日志，而不是直接替换全部生产节点。若企业还在比较硬件采购与远程使用，可以先查看 Mac 远程使用方案，再根据固定容量和维护责任决定下一步。

第三种场景：内部网络和数据驻留要求决定能不能用托管池

企业 iOS 构建通常不只依赖代码仓库，还可能需要访问私有 CocoaPods 镜像、内部 API、私有制品库、漏洞扫描服务或企业 Key Vault。此时，“流水线在 Azure DevOps 中”不代表托管 Agent 自动具备访问这些资源的能力。

Microsoft 文档明确指出，Microsoft-hosted Agent 不能通过 ExpressRoute 或 VPN 直接连接企业网络；访问私有 Key Vault 等内部资源时，官方建议使用 self-hosted Agent 或其他能够进入目标网络的执行资源。Microsoft-hosted Agent 的网络限制

可以按下面的边界判断：

只访问公网仓库和公开依赖：托管 Agent 可以进入试点范围。
访问固定出口白名单：先确认托管资源的 IP 范围是否稳定、是否需要持续更新。
访问私有端点或内部 DNS：优先使用具备网络可达性的自托管 Mac。
源代码或构建产物受地域限制：必须取得实际运行地域证据，不能根据组织区域猜测。
需要内网横向访问：即使自托管，也要把 Agent 放进隔离网段，只开放必要目标。

⚠️ 经验提醒：不要把“能从 Agent 访问 Azure DevOps”误认为“能访问企业内部服务”。前者只证明控制平面连通，后者还涉及路由、DNS、出口、防火墙和数据驻留。

自托管 Mac 更适合哪些 iOS 构建任务？
它更适合生产签名、私有依赖拉取、固定版本回归、需要持久缓存的高频构建，以及必须连接内部服务的流水线。对于不可信 PR 和外部代码，自托管 Mac 反而需要更严格的网络隔离，不能因为它“在企业网络里”就默认更安全。

第四种场景：发布高峰采用固定基线加托管弹性

企业通常同时面对两种相反需求：生产发布希望环境固定，发布高峰又希望快速增加并发。单独使用托管池，容易受预览容量、镜像变化和按分钟费用影响；单独购买大量自托管 Mac，则会承担非高峰时段的闲置容量和维护工作。

因此，混合池的核心不是把两类 Agent 随机混用，而是按任务属性分流：

stages:
- stage: Verify
  jobs:
  - job: PullRequestBuild
    pool:
      name: GitHub-hosted Agents
      vmImage: macos-26-arm64

- stage: Release
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  jobs:
  - job: SignedRelease
    pool:
      name: ios-production-self-hosted
      demands:
      - xcode.signing == true

上面的结构只是路由示例。实际部署还应在模板层限制哪些项目可以使用生产池，并通过分支保护、环境审批和服务连接权限阻止普通测试任务误用签名节点。

成本变量	托管 Apple Silicon Agent	自托管 Mac	混合池
计算费用	按有效运行分钟计费，预览规则可能变化	按设备租赁或采购、维护周期承担	只把峰值和短任务交给托管
并发能力	受预览规格和队列限制	由固定设备数量决定	基线容量加弹性容量
空闲成本	通常较低，但每次运行需重新准备环境	非高峰仍需承担设备成本	通过固定基线控制关键发布
缓存	每次任务重新准备，缓存策略受镜像限制	可维护持久缓存	生产缓存留在自托管，测试使用托管
网络	通常不能直接进入企业私网	可放入受控网络	按任务拆分网络边界
运维责任	镜像和主机由平台维护	证书、Agent、系统、磁盘和恢复由团队负责	责任按池拆分
失败重跑成本	需要重新计入运行分钟和准备时间	主要消耗设备时间与运维时间	根据任务优先级选择池

企业做 Mac Agent TCO 分析时，不要只拿托管 Agent 的分钟单价和 Mac 设备月租做比较，至少要记录以下变量：

月度 TCO = 有效构建分钟成本 + 并发容量成本 + 闲置容量成本 + 环境维护工时 + 失败重跑成本 + 网络与存储成本。

托管方案还要记录镜像准备、依赖下载、缓存恢复、队列等待和重跑分钟；自托管方案则要记录证书轮换、系统升级、磁盘清理、远程恢复、备用节点和人员工时。GitHub-hosted Agents 的计费、资源规格与预览规则应以发布时的官方价格页面和企业账单为准，不能使用未核实的静态报价。官方 GitHub-hosted Agents 计费说明

第五步：用真实试点数据决定采购、租赁还是继续托管

建议用一条非生产流水线完成 2 个阶段的试点，而不是直接切换正式发布。

第一步：锁定可复现的构建样本

选择最近一个月中具有代表性的 iOS 项目，保留依赖文件、Xcode 版本、测试目标、签名模式和产物上传步骤。至少准备普通 Debug、Release、模拟器测试和真实签名 4 类任务。

第二步：建立 3 个 Agent Pool

分别创建托管 Apple Silicon 池、隔离的自托管 Mac 池和生产签名池。不要让生产签名池承担 PR 构建，也不要让外部代码进入拥有内部网络访问权的自托管节点。

第三步：固定 YAML 路由和镜像标签

将 pool、vmImage、Xcode 版本和依赖缓存策略写进模板，避免某个项目开发者通过局部 YAML 修改绕过审批。对托管资源记录实际可用区域、镜像版本、任务启动时间和队列变化。

第四步：记录 6 类证据

每次构建至少保存：

构建是否成功，以及失败原因；
排队时间与实际执行时间；
Xcode、macOS、Swift 和依赖版本；
签名资产是否只出现在指定节点；
内部网络访问是否符合白名单；
失败后能否远程重启、清理或恢复 Agent。

第五步：计算有效分钟，而不是只看总分钟

将依赖安装、缓存恢复、签名准备、构建、测试、产物上传分别计时。对于失败重跑，单独记录是代码失败、镜像变化、网络超时，还是 Agent 状态问题。

第六步：设置重新评估节点

Xcode 27 正式发布、Apple Silicon 托管 Agent 转为 GA、预览暂停、镜像标签调整、支持地区变化或价格变化时，都应重新执行兼容性和成本核算。本文不采信未经官方确认的正式发布日期、SLA 或性能提升数字。

试点结束后，可以按以下准入条件做决定：

继续扩大托管：非签名任务成功率稳定，网络和数据驻留满足要求，队列不会影响交付窗口。
采购或租赁自托管 Mac：生产签名、私有网络或固定缓存是刚性要求，且维护工时可被团队承受。
采用混合池：生产与网络受限任务需要固定基线，PR 和发布高峰又存在明显波动。
暂缓迁移：Xcode 27 兼容性尚未稳定，托管 Agent 可用区域或账单条件无法证明，或者签名隔离无法通过安全评审。

如果团队决定先做自托管试点，可以把一台隔离的远程 Apple Silicon Mac 接入专用 Agent Pool，随后根据构建和队列记录调整固定容量。与一次性采购相比，远程租赁的优势是减少前期设备占用和异地运维，但长期稳定高负载、需要本地物理接口或必须完全掌控硬件生命周期的团队，仍可能更适合自购设备。VNCMac 可作为这类试点的远程 Mac 资源入口；若需要比较不同地区的可用主机，可以查看 Mac 主机采购与使用选项。

最终判断不是“托管一定便宜”或“自托管一定安全”。托管 Agent 解决的是临时容量和环境隔离，自托管 Mac 解决的是签名、网络、缓存和恢复控制；对多数需要 Xcode 27 的企业 iOS 团队，生产自托管基线加托管弹性容量仍是 2026 年更稳妥的起点。先从一台隔离的 VNCMac Apple Silicon Mac 开始，收集真实流水线数据，再决定固定容量与弹性容量的比例。