症状:团队要把 Claude Code 放进内网,却不确定代码、提示词和构建任务分别跑在哪里。 最快解法:云端先行;只有网络、工具链或合规要求确实需要自管执行环境时才试点自托管。不要因为“自托管”三个字就采购 Mac;Xcode 任务须先核实 Runner 的 macOS 支持,并在真实流水线中验收。

谁该看:企业 IT 负责人:评估网络边界、数据处理与运维责任。 平台工程负责人:决定托管还是自管 Runner,并核算长期维护投入。 Apple 平台负责人:确认 Xcode、签名与 Mac CI 的执行边界。

**状态核验:**本文最后更新于 **2026 年 9 月 25 日**;截至该日,自托管环境仍处于公开测试。资格与能力状态核对自 [官方公告](https://claude.com/blog/run-claude-code-sessions-on-your-own-compute)和[Claude Code 自托管环境文档](https://code.claude.com/docs/en/self-hosted-environments)。发布前应再次确认测试状态、组织资格和平台支持。

先拆开三种运行方式,再谈采购

云端、自托管和 Remote Control 不是同一类“远程 Mac”。Claude Code 自托管环境把会话执行放到你运营的基础设施;托管方案由服务方提供执行环境;Remote Control 则让你从其他设备继续操作自己机器上、由本人启动的会话。官方文档对会话归属和运行位置的说明指出,Remote Control 会话依赖原机器仍在运行,并归属于启动会话的用户;自托管 Runner 则是团队运营的执行资源。

这一区别直接影响采购判断:Remote Control 不等于团队共享 Runner,也不自动提供 CI 队列、团队隔离和无人值守执行。若任务只是代码分析、编辑或一般测试,先验证托管环境能否访问所需仓库和服务;若必须触达内网服务或预装内部工具,再评估自管执行节点。

Claude Code 自托管环境与云端的主要分野是什么?重点是会话执行位置与运维归属,而不是模型是否在本地运行。自托管时,Runner 在组织运营的主机上执行任务;会话编排和模型推理仍涉及服务方的控制面与 API。

平台工程:先查支持边界,再算运维账

截至本文核验的官方文档,自托管环境处于公开测试,面向 Team 与 Enterprise 组织,默认关闭;启用需要组织所有者操作。文档也明确排除使用 ZDR 的组织,并说明模型推理请求发送至 API,不能据此假定推理数据全在组织内部处理。相关资格和运行限制以本文开头所列的官方公告与自托管文档为准。

但“有自托管 Runner”不等于“目标 macOS 已确认支持”。现有生产部署文档说明了 Runner 镜像、网络出口限制、Git 凭证与编排相关的运维事项;这些内容不能单独证明 macOS 主机或 Xcode 构建受支持。若公开资料没有明确说明你计划使用的主机系统,先向官方确认,不要把兼容性假设写进采购单。

<
决策维度云端托管自托管 Runner判断
执行位置服务方提供的托管环境组织运营的主机与网络内部系统必须直连时,自托管更匹配
环境维护不必自建 Runner 镜像与编排你负责镜像、更新、容量和编排无平台运维人力时优先云端
内网访问需确认托管环境能否满足访问方式会话可从组织网络访问获准资源不要用“内网需求”代替出口规则设计
推理与会话内容按产品数据策略核验提示、响应和工具结果仍会发送至 API;会话记录仍需核验自托管不等于推理数据留在本地
macOS/Xcode需按任务和产品能力另行核验当前资料未据此确认 macOS 或 Xcode 支持未确认前,不以 Mac Runner 立项
**自托管应当在什么条件下进入候选方案?**当内网访问、受控工具链或执行环境治理确实无法由云端满足,并且有团队承担 Runner 运维时,才进入自托管试点。官方建议多数企业优先考虑托管方案;自管团队需要负责镜像构建维护、Runner 更新,以及按需容量模式下的编排器运营。

容量也不是“买几台机器”这么简单。固定模式要求你持续维护预留 Runner;按需模式要有人维护编排器,并验证排队、启动、回收和故障重试。官方资料说明了固定与按需两类运行方式,但没有给出适用于所有组织的成本数字,因此不要用未经核实的节省比例做预算结论。

安全与合规:把数据流画清楚再给绿灯

自托管改变的是执行位置,不是整个数据流。官方说明:仓库检出副本、构建产物、密钥及会话创建或修改的文件留在你提供的基础设施;提示、模型响应和工具结果会发送到 API,会话记录则会被保存,以便继续会话。你需要把“数据在自管主机上处理”与“数据完全不离开组织”分开判断。

建议在安全评审图中标出四段:开发者发起会话、Runner 拉取仓库并执行、工具结果回传 API、产物与密钥存放的位置。然后由安全团队逐项确认会话记录、组织策略、保留设置、日志范围和例外条件;Enterprise 的自定义保留设置及适用范围,应按官方数据保留控制说明核验。

如果组织要求 ZDR,自托管是否能够绕过限制?不能据此推断。官方当前说明自托管环境对启用 ZDR 的组织不可用;而 ZDR 的适用范围也与使用方式、组织资格和协议相关,须核对官方 ZDR 产品适用范围及组织合同。若政策要求推理输入与输出不留存,不要把“代码在自家主机执行”当作替代证明。

Apple 平台:把 Agent 工作与 Xcode 构建拆开验收

Claude Code 可以做代码分析、编辑和通用测试;但需要 macOS、Xcode、模拟器或签名身份的工作属于另一条平台能力链。Apple 文档说明,外部 Agent 可通过 Xcode 提供的 MCP 工具访问项目和执行相关动作;使用前需在 Xcode 中授予权限并配置连接。Apple 外部 Agent 使用 Xcode 工具的说明支持的是 Agent 与 Xcode 工具的集成方式,并不能证明 Claude Code 自托管 Runner 已支持 macOS 主机。

因此,把任务拆成两份验收:一份验证 Claude Code 会话是否能按预期检出代码、运行工具和提交结果;另一份在确认 Runner 平台支持后,验证真实 Mac 上的 Xcode 编译、模拟器测试、签名证书访问与产物上传。Xcode 的 Agent 接口能力和 Runner 主机支持是两个不同的核验项。

官方资料对 macOS Runner 的支持写到了什么程度?仅凭“Runner 可自托管”不能回答“支持”。目前核验到的自托管资料没有足够依据确认目标 macOS Runner 受支持;应向官方核实具体主机与部署方式,并要求明确确认或可复现的端到端验证。

Claude Code 自托管环境能否承载 Xcode 构建?只有当执行节点确实满足 macOS 与 Xcode 环境要求、Runner 平台支持得到确认、签名凭证被隔离且流水线验收通过,才能把它纳入生产方案。Xcode 的 Agent 接口能力和 Runner 主机支持是两个不同的核验项。

IT 与 FinOps:用全生命周期变量替代“买或租”的猜测

不要用未经验证的单价推导“自托管更省”。把相同工作量和服务目标放进同一张成本表,逐项填入采购报价、内部工时和账单数据,再比较月度与年度 TCO。

<
成本项云端托管自托管
会话使用填入组织实际账单或合同报价同样按组织实际 Claude Code 账单填写
执行主机通常不由你采购 Runner 主机填入主机、存储、网络与备份成本
平台运维填入必要的接入和治理工时计入镜像、升级、编排、监控及故障处置工时
闲置容量按实际计费与限额核验计入固定容量闲置或按需扩缩容成本
Mac/Xcode按实际构建路径核价只有平台支持确认后,才计入真实 Mac 资源与签名治理成本
可用公式是:**自托管 TCO=主机与网络+镜像及 Runner 运维+编排与监控+闲置容量+故障处置+Claude Code 使用成本**;云端 TCO 则按合同和实际使用账单,加上必要的接入与治理成本计算。公式里的空项应由采购、平台工程和 FinOps 共同填数,不应以推测价格或“预计节省”替代。

如果你的比较项涉及真实 Mac 构建节点,可以先查看 MACGPU 的 Mac 配置说明,再把可核实的资源与报价填入同一张 TCO 表;这只能帮助核算 Mac 资源,不能替代对 Runner 平台支持的确认。

采购试点:按退出条件决定是否扩大

第一步:登记会话与任务边界

把代码分析、通用测试、访问内部服务和 Xcode 构建分开登记;标明每类任务的仓库、网络依赖、凭证和产物去向,避免用一个“开发环境”需求覆盖不同执行条件。

第二步:由平台工程核验 Runner

核对组织资格、开启方式、Runner 部署模式、镜像更新责任、网络出口和编排器归属。记录官方文档未确认的操作系统、主机类型和限制;这些未决项未关闭前,不采购专用 Mac 作为 Runner。

第三步:让安全团队批准数据流

在试点配置中验证出站访问限制、仓库凭证范围、会话记录与保留策略;不要把宽权限令牌写入共用镜像。官方生产部署文档可作为制定网络出口、主机权限和凭证管理验收项的依据。

第四步:验证真实任务而非登录成功

跑通仓库检出、修改、测试、结果回传、会话恢复和异常退出处理。随后单独验证 Xcode 任务:从 Runner 平台支持确认开始,再测编译、模拟器、签名隔离、产物归档和失败回退。演示登录成功不代表流水线已具备生产可用性。

第五步:按分支决策并指定复核人

  • 若云端满足内网接入、工具链和治理要求,继续用云端,不增加 Runner 运维面。
  • 若这些要求无法满足,且官方确认目标 Runner 平台受支持,再试点自托管。
  • 若任务需要 Xcode,额外要求 macOS 支持确认、签名凭证隔离及端到端构建验收;任一项未通过,构建任务回退到已验证的真实 Mac 流水线。
  • 若组织启用 ZDR,或无法接受会话内容发送至 API,则停止当前自托管方案评估,先让安全与供应商团队确认适用配置。
试点记录应包含责任人、复核日期、故障联系人、回退触发条件和未决风险。资格、产品限制或数据策略发生变化时,重新评审;公开测试期间,不要把当前能力视为长期不变的采购承诺。

如果你现在依赖云端,可能会受内网访问或环境定制边界限制;若自行搭 Runner,则要承担镜像升级、容量编排和故障处置,而 Mac/Xcode 兼容性还需另行确认。更稳妥的做法是先保留云端处理通用任务,只为已经验证必须使用真实 Mac 的 Apple 构建任务准备独立执行节点;需要短期 Mac CI 验证时,可了解 MACGPU 的 Mac 方案,再按实际任务选择资源。若要为长期稳定负载自建硬件,或必须直接接入特定物理设备,租赁未必合适;无论哪种方式,都不要把 Mac 租用误当成自托管 Runner 获得平台支持的证明。