如果你看到“Claude Code 自托管环境”，最需要先纠正的不是安装步骤，而是一个边界：它自托管的是执行层，不是 Claude 模型。
Claude Code self-hosted environments 把 cloud session 中实际跑命令、检出仓库、生成构建产物和保存会话工作目录的地方，放到你控制的机器或容器里。与此同时，控制面、会话排队与编排、模型推理，以及用于跨端恢复的会话 transcript，仍由 Anthropic 承担。提示词、模型响应和工具结果仍会发往 api.anthropic.com。
因此，它不是“Claude 完全本地化”，也不是离线运行方案。它更接近一种清晰的执行位置重分配：让 Agent 在能接触内部网络、内部 Git 凭据和企业工具的地方执行；让 Anthropic 继续运行服务端控制与模型部分。
先分清：普通本地会话、本地模型与自托管环境不是一回事
普通 Claude Code 终端或 IDE 会话原本就在开发者机器上运行。你打开本地仓库、运行测试，代码和 shell 进程就在自己的设备上；这与 cloud session 的远端执行模式不同。
Claude Code self-hosted environments 针对的是 Claude Code cloud sessions：原本由 Anthropic 托管执行环境的 web、mobile 或 desktop 会话，现在可以调度到组织自己的 Runner 上。它也不同于本地模型、第三方 Claude-compatible backend 或“把 API 改到自建 gateway”：模型推理仍走 Anthropic API，不能改由 Bedrock、Google、Microsoft Foundry 或自建 LLM gateway 提供。
还要把它与两项相邻能力拆开：Remote Control 是用网页界面控制自己机器上的 Claude Code 会话；Claude Platform Managed Agents 的 self-hosted sandboxes 则属于另一套平台产品与文档。它们都涉及“代码在哪里执行”，但并不等于 Claude Code self-hosted environments 的 Runner 架构，不能把设置、保留策略或安全承诺互相搬用。
为什么要把执行层搬进自己的基础设施
很多团队并不希望一个 cloud session 在公共网络可达性、内部服务访问、Git 凭据和构建依赖上受限。自托管 Runner 可以放在私有网络、特定 VPC、开发容器或已有的构建环境里：仓库 checkout、构建产物、会话创建的文件、密钥和对内部服务的调用留在这条自有基础设施边界内。
但“文件留在这里”不等于“信息从不离开这里”。Claude 必须看到任务输入与工具执行结果，才能决定下一步。因此 prompts、responses 和 tool results 仍会发送到 Anthropic；一次会话的 transcript 也仍由 Anthropic 存储，以支持 web、mobile 和 desktop 之间的恢复。准确的采购或合规问题不是“是否全本地”，而是：哪些文件、命令结果和上下文会成为模型请求的一部分，组织是否接受这条数据流。
Environment、Runner 与 Session：三个对象各管什么
可以用三个对象理解这个功能。
- Environment 是组织为 cloud session 准备的可调度执行环境。自托管类型需要由 Team 或 Enterprise 管理员启用，功能处于公测且默认关闭；启用了 ZDR 的组织不支持它。
- Runner 是安装在自有机器或 Linux 容器中的进程。它注册到一个 Environment，取得工作后在本地创建工作目录、检出仓库并启动 Claude Code 执行进程。
- Session 是用户从 Claude Code cloud surface 发起的一次任务。调度服务把它排队并交给符合条件的 Runner；运行中的文件与进程在 Runner 一侧，会话的服务端编排与 transcript 不在 Runner 上。
图：Runner 主动从自有网络发起出站轮询；执行位置改变，但控制面、推理和 transcript 的归属没有一起迁移。
一次 cloud session 的真实生命周期
用户先在 Claude Code 的云端入口创建 session，并选择已配置的自托管 Environment。Anthropic 的控制面负责建立会话、排队和调度；Runner 不等待 Anthropic 反向连入企业网络，而是主动发起出站连接并轮询可领取的工作。
领取到 session 后，Runner 在自己的主机或容器里准备工作区：按当前支持的 GitHub 仓库来源检出代码，执行需要的环境配置，并运行 Claude Code。模型要求读文件、运行命令或写入产物时，这些实际操作发生在 Runner 所在基础设施；工具结果再回到 Anthropic，使模型能继续推理。
这个方向很重要。企业网络不需要向 Anthropic 暴露一个入站端口，但仍必须允许 Runner 访问所需的 Anthropic 服务端点，并自行管理网络出口、代理、证书、Runner 身份、磁盘、清理、容量与故障处理。自托管减少的是执行面的托管依赖，不是运维责任。
一个更实用的决策问题：你要控制的到底是哪一层？
很多讨论从“数据是否在本地”开始，最后把五个不同问题混成一个。更实用的做法是逐层作答：
- 执行位置：谁的机器运行 shell、编译器、测试和文件系统？self-hosted Runner 可以回答这一层。
- 网络可达性：执行进程能否访问只在内网、VPC 或受控代理后面的服务？这由你的 Runner 网络策略回答。
- 身份与凭据：谁发放 Git、包仓库、测试系统或部署目标的权限？这是组织的密钥和最小权限设计，不能由 Environment 名称代替。
- 模型上下文：哪些命令输出、文件片段、错误日志或工具结果会在执行过程中发给模型？这是任务设计与调用行为需要评估的边界。
- 服务端保留与恢复：会话怎样排队、如何跨端继续、transcript 在哪里存放？这些仍属于 Anthropic 承担的服务层。
这五个答案可以同时为真：文件系统在企业网络、内部服务只能由 Runner 访问、密钥只放在自有基础设施，但某些工具结果仍会进入模型上下文，而 session transcript 仍由 Anthropic 保存。把它们压缩成一句“数据不出网”会让安全评审失去可执行性；把它们拆开，才知道该找平台团队、身份团队还是采购与合规团队确认。
对开发团队而言，这个拆分还有一个直接收益：它避免把“我们已经能跑起来”误当成“我们已经完成风险评估”。Runner 成功领取任务，只证明网络、注册和基础执行路径可用；它不自动验证每一个内部服务权限是否合适、每一份命令输出是否应该成为模型上下文，或所有成员是否都应能 dispatch 到这类环境。上线验收应把这些判断保留为显式检查项，而不是从一条成功日志里推断出来。
换句话说，技术连通性是部署起点，不是数据边界与权限治理的结论。
Claude Code 自托管环境的数据边界
下面这张表不是“哪些数据绝不离开”的承诺，而是对执行、控制和存储责任的拆分。具体文件会不会进入 prompt 或 tool result，仍由任务、Claude 的调用路径与组织配置决定。
| 对象 | 运行或存储位置 | 运营责任 |
|---|---|---|
| 执行进程与文件 | 用户基础设施 | 用户 |
| 控制面与队列 | Anthropic | Anthropic |
| 模型推理 | Anthropic API | Anthropic |
| 会话 transcript | Anthropic | Anthropic |
| Git 凭据与内部服务 | 用户基础设施 | 用户 |
这也改变了安全讨论的重点。你需要审计 Runner 能读取什么仓库、能拿到哪些凭据、可以访问哪些内部服务、日志与构建产物留多久；同时要根据 Anthropic 的数据边界审阅 prompt、response、tool result 与 transcript 的处理。仅仅把 Runner 放进 VPC，并不能自动证明“源码绝不会出现在 Anthropic 请求上下文中”。
Fixed runner 与 on-demand fleet：不是同一类容量模型
文档把固定 Runner 与按需 fleet 作为不同的部署选择。固定 Runner 适合已有稳定机器、专用容器或需要长期保持准备状态的团队；on-demand fleet 更适合由自己的编排系统在任务到来时拉起短生命周期执行资源。两者都把执行资源的供给、隔离与成本交给组织，而不是免费获得一个额外的推理层。
还要特别注意 Runner 的分配语义：一个 Runner 在首次接单后会锁定一个用户；capacity 表示这个用户可并发的 session 数，不表示多名用户可以混跑同一 Runner。容量规划因而要按用户与会话并发来做，而不是只看“有多少台机器”。
Windows 也不是 Runner host 的直接选项；需要通过 Linux 容器来承载。无论选固定机器还是 fleet，组织仍须承担主机、容器镜像、修补、监控、磁盘清理与事故响应成本；Claude Code 使用量仍计入组织额度。自托管未必更便宜，它只是把成本结构从 Anthropic 托管执行资源转成了自己的基础设施与运维工作。
当前资格、入口与路由限制
该功能面向 Team 与 Enterprise，处于公测并且默认关闭；管理员需要先创建并启用 Environment。任何组织成员目前都可以向组织环境 dispatch，并没有逐 Environment 的 dispatch ACL。对安全负责人来说，这意味着“谁可向哪一个内部执行环境发起任务”仍是一个需要在组织流程中补齐的治理问题。
当前仓库来源为 GitHub；一些 Claude Code 的入口暂时不能路由到自托管环境，包括 Claude Tag、Claude Security 与 Code Review 等部分能力。不要因为 Runner 已经连通，就假设所有调用路径都会经过它。
版本信息也要写准。自托管环境由 Claude Code 2.1.224 引入；截至 2026-08-10，官方 changelog 已列出 2.1.227。前者是功能引入版本，不是“当前最新版”。部署或排障时应以组织实际安装的版本和当日 changelog 为准，而不是把首次出现的版本号当作长期标签。
安全责任从哪里增加，而不是消失
Anthropic 不需要主动入站企业网络，降低了暴露一个入站服务的需求；但 Runner 变成了新的高权限执行面。它能看到 Git token、内部包 registry、构建缓存、测试数据库或部署凭据时，最小权限和隔离策略必须由组织设计。
另一个常见误区是把 Environment 当成天然的人员隔离边界。当前没有逐 Environment 的 dispatch ACL，任何组织成员都可以向组织环境 dispatch。因此，环境名称本身不是“只有某团队可使用”的访问控制。把一套能接触高敏系统的 Runner 放进组织里之前，应先判断组织成员能否触发任务、Runner 是否会根据任务取得高权限凭据，以及是否需要以更细粒度的身份、网络分段或独立组织流程来补足这层治理。
建议至少把这几项写进上线前的操作约束：
- 为 Runner 使用专门的服务身份、最小范围 Git 凭据和可轮换密钥；不要复用某位开发者的全权限 token。
- 为每种 Environment 定义网络出口、可访问的内部服务与依赖源，并记录变更责任人。
- 让 checkout、构建产物、临时文件和 session 工作区有明确的清理与保留策略。
- 按用户锁定和
capacity的实际语义规划并发，避免把一个 Runner 误当多租户资源池。 - 在真实仓库以最小权限任务试跑：确认所需服务可达、机密不会被无意写入日志，并把失败路径纳入值班流程。
如果团队同时维护跨客户端的开发辅助能力，类似 Agent Plugins 1.0 的可移植打包边界也值得单独处理：插件包的发现结构可以标准化，Runner 的身份、密钥、网络与执行策略仍是运行环境自己的契约。
谁应该使用，谁更适合别的方案
适合评估 self-hosted environments 的团队，通常已经有明确的 cloud session 工作流，但需要它访问仅在企业网络可达的服务、使用组织控制的构建镜像或保留本地执行文件。前提是团队愿意承担 Runner 供应、监控、容量和安全隔离。
如果工作主要发生在开发者自己的终端或 IDE，本地 Claude Code 已经让执行留在设备上，并不需要再为 cloud session 部署 Runner。若目标只是从网页控制一台已有机器，先评估 Remote Control；若硬性要求模型推理、提示词与工具结果都不能离开本地边界，则这项功能不满足需求，应另行评估本地模型或符合组织数据要求的架构，而不是把 self-hosted Runner 当作同义词。
部署前检查清单
- 组织是 Team 或 Enterprise，且没有启用 ZDR；管理员已明确启用该公测能力。
- 目标是 Claude Code cloud sessions，而不是替代本地 terminal/IDE 或部署本地模型。
- GitHub 仓库接入、Runner 主机或 Linux 容器、网络出口和
api.anthropic.com连通性已经由安全与平台团队确认。 - Runner 使用独立身份，Git 凭据、内部服务权限和日志保留范围已经最小化。
- 团队理解 prompts、responses、tool results 与 transcript 仍会由 Anthropic 处理，不把 VPC 当作“所有数据不出网”的证明。
- 已按首次用户锁定与
capacity的并发含义设计资源池，并准备固定 Runner 或 on-demand fleet 的运维方案。 - 已列出不能路由到该环境的入口；上线验收只覆盖当前支持的 GitHub 与 cloud-session 路径。
验证边界与官方来源
本文依据 Anthropic 的发布公告和 Claude Code 官方 self-hosted environments 文档撰写；截至 2026-08-11，本文没有创建 Team/Enterprise Environment、注册 Runner、接入内部 GitHub 或运行任何 production session。它不是 Team/Enterprise 实测报告，也不证明某个组织的网络隔离、权限边界或合规结论。
最终结论很简单：Claude Code self-hosted environments 让你决定 Agent 在哪里执行，不让你接管 Anthropic 的模型、控制面或 transcript。 如果这个边界正好解决了内部执行与服务可达性问题，它值得评估；如果你需要完全离线或零外发推理，则应该从别的技术路线开始。