本地电脑一关，Agent 任务就停在半路，重新打开 VS Code 后还找不到完整上下文。
最快解法：把 Agent Host 部署在靠近代码仓库和 Xcode 工具链的独立云端 Mac 上，通过 SSH 或开发隧道连接，并为每个任务创建隔离工作树；但会话持久化不等于执行环境已经安全隔离。

这篇教程适合谁，以及你要先接受的边界

如果你是需要让 GitHub Copilot、Claude 或 Codex 在 Xcode 项目中执行长任务的 iOS、macOS 开发者，这篇内容适合你。
如果你负责集中管理多个远程 Agent 会话、工作树、凭据和弹性容量，也可以直接按后面的验收条件执行。

最后更新于 2026 年 9 月 3 日，功能状态与部署路径核实自 VS Code 官方架构、远程连接、AI 设置、MCP 与 Apple Xcode 文档。

先区分 5 个对象：Agent Host 负责保存会话、运行 Agent harness，并在远程工作区执行文件修改与命令；Agent harness 决定 Copilot、Claude 或 Codex 如何运行；模型提供方负责推理服务；VS Code 是客户端；云端 Mac 才是真正执行 xcodebuild、脚本、浏览器和 MCP 工具的环境。

官方架构说明确认，Agent Host 可以作为本地进程或远程独立服务运行，客户端通过 Agent Host Protocol，也就是 AHP，连接会话；远程运行时，文件编辑和命令执行发生在远程机器上。AHP 仍处于持续开发阶段，所以不要把预览功能当成企业级稳定承诺。可先查看 VS Code Agent Host 架构说明。

你还需要先判断是否真的要云端 Mac：

  • 只运行跨平台脚本、后端测试或文档任务：Linux 或本地环境可能更简单。
  • 需要 Xcode、Simulator、xcodebuild、签名工具或 macOS 专属测试：云端 Mac 才有明确价值。
  • 需要物理 iPhone、USB 调试或本地钥匙串交互：普通远程 Mac 不一定能满足，必须先确认硬件接入与人工操作路径。
  • 需要长期满负载、多团队共享同一环境：共享主机的权限、磁盘和构建缓存会成为隐性成本，任务级独占环境通常更容易审计。

先做职责和风险分界：持久会话不是沙箱

Agent Host 解决的是“客户端关闭后会话还能不能继续”的问题，不自动解决以下 3 类风险。

第一，代码修改可能直接落在会话文件夹或工作树中。你需要查看差异后再提交、合并或丢弃，而不能假定所有改动都会先停留在待批准区。会话的启动、接管和清理方式，应以 VS Code 会话管理文档 为准。

第二，客户端提供的工具不一定在客户端断开后继续可用。浏览器工具或扩展贡献的工具可能路由回提供它们的客户端；如果客户端退出，Agent Host 仍可能继续运行，但某些工具调用无法完成。

第三，远程 Mac 上的凭据、SSH 密钥、Apple 签名证书和环境变量都可能被 Agent 触及。因此上线前要写清楚 4 件事：代码目录、允许调用的工具、凭据范围、任务结束后的清理责任。对于高权限操作，保留人工批准，不要为了减少中断而直接启用“跳过所有权限检查”的模式；VS Code 的 AI 设置参考 也将部分权限与 Claude Agent 标记为实验性或仅适合隔离环境。

⚠️ 经验：如果你无法回答“这个 Agent 能读哪些目录、能执行哪些命令、异常退出后谁撤销凭据”，就不要把远程 Agent Host 当作生产入口。

第一小时连接：SSH 还是开发隧道更适合云端 Mac？

两条路径都能让 Agents window 连接远程 Agent Host，但运维责任不同。先选团队长期能管理的一条，不要把临时测试连接直接当成生产入口。

决策维度 SSH 开发隧道
网络入口 远程 Mac 需要可通过 SSH 访问 远程 Mac 主动建立出站隧道，通常不需要开放入站端口
身份验证 SSH 用户、密钥、跳板机和主机策略 需要经过身份验证的账户与隧道
适合场景 平台团队已有主机目录、密钥轮换和审计体系 远程 Mac 位于受限网络，或需要从浏览器快速接管
主要风险 暴露 SSH 入口、密钥过期、用户权限过宽 匿名隧道可能让获得地址的人启动 Agent 会话
回退方式 检查 SSH、进程和本地端口转发 关闭隧道并改用受控 SSH
本文评分 4.5 / 5 4 / 5

通过 SSH 时，Agents window 会在远程机器上自动安装并启动 VS Code CLI，前提是远程 Mac 已可访问 SSH；具体流程见 远程 Agent 会话文档。通过开发隧道时，必须要求身份验证，不能使用匿名访问，否则持有隧道地址的人可能启动带有你凭据的 Agent 会话。 Remote Tunnels 安全文档 对认证、出站连接和加密方式有进一步说明。

在远程 Mac 上准备基础环境：

mkdir -p ~/agent-host
cd ~/agent-host

git clone <你的仓库地址> workspace
cd workspace

git status
xcode-select -p
xcodebuild -version

然后确认 Xcode 是当前开发者目录。Apple 的 Xcode 命令行工具参考 说明，xcodebuild、simctl 和 devicectl 等工具随 Xcode 提供，调用前必须安装 Xcode 并设置活动开发者目录。

如果使用独立 Agent Host，按照当前官方文档运行：

code agent host

该命令默认在本机启动服务，并使用连接令牌保护访问；如果采用开发隧道，再使用对应的 --tunnel 选项。启动后保存 4 项证据：VS Code 版本、启动命令、连接主体、首次连通时间。若命令不存在或设置项名称不同，停止部署并重新核对当前稳定版文档，不要凭旧教程猜测参数。

首个任务：用隔离工作树验证 Agent Host 云端 Mac 部署

不要一上来让 Agent 重构整个应用。先从一个可逆的小任务开始，例如新增一个单元测试、修复一个明确的编译错误，或者调整一个不涉及签名与发布的 Swift 文件。

建议按下面 5 步执行：

  1. 为任务创建独立分支和工作树，目录名包含任务编号，避免多个 Agent 同时写入同一目录。
  2. 在 VS Code 的 Agents window 中选择目标工作区，再明确选择 Copilot、Claude 或 Codex harness。
  3. 记录账号、模型入口和权限模式；不要假设 3 个 harness 的工具、上下文处理和批准机制完全一致。
  4. 让 Agent 只执行一个小修改，并要求它输出修改文件、执行命令和测试结果。
  5. 检查 git diff、测试日志、生成制品和工作树状态，再决定提交、丢弃或恢复。

多个并行任务不要共享同一个工作树。一个任务负责修复测试，另一个任务负责界面改动时，应分别创建工作树；否则即使会话上下文彼此独立，文件系统变更仍可能互相覆盖。你可以进一步阅读 Git worktree 隔离并行 Agent 任务的方法，把“会话独立”和“代码目录独立”分开验收。

Agent Host 支持多个客户端观察和控制同一会话；同一会话中的多个聊天可以共享工作区和工作树，但它们的对话历史仍然独立。这里要注意，多窗口接管解决的是会话访问问题，不是并发写入冲突问题。

关闭本地电脑后会继续吗？多窗口接管如何验收？

只关闭本地电脑或编辑器窗口，不能单独证明部署成功。你要把 3 种故障分开测试：客户端网络断开、远程 Mac 重启、Agent Host 进程退出。

先让一个代表性任务进入执行状态，例如运行测试并生成结果文件，然后关闭本地 VS Code 窗口。等待任务进入一个容易识别的阶段，再从第二个 VS Code 窗口或受支持的浏览器入口重新连接，核对：

  • 会话状态是否仍为运行中、已完成或等待确认；
  • 终端输出是否连续，是否能看到断线前后的时间点；
  • 变更文件和差异是否与远程工作树一致；
  • 待确认的命令是否仍需要人工批准；
  • 原客户端和新客户端是否显示同一个会话，而不是复制出新任务。

Agent Host 的设计是让主机成为会话事实来源；客户端重连后可以重新获取状态。这解释了为什么多个 VS Code 窗口可以接管同一会话，但不代表每个客户端贡献的浏览器、扩展或交互式工具都能在断线后继续。

停止条件很明确：如果客户端关闭后远程进程停止、重连后变更集不一致，或者确认请求丢失，就先回退到短任务模式，不要继续扩大并发量。若只是 SSH 断开而主机仍运行，修复连接配置即可；若主机进程退出，则需要检查启动方式、日志和远程 Mac 的重启策略。

Xcode 与 MCP：能调用不等于能交付

远程 Agent Host 可以靠近 Xcode 工具链执行命令，但“代码生成成功”不能替代项目交付验收。至少执行一次构建、一次测试，并保存结果文件或日志。

例如：

xcodebuild \
  -workspace Example.xcworkspace \
  -scheme Example \
  -destination 'platform=iOS Simulator,name=iPhone 16' \
  test

具体工作区、scheme 和 Simulator 名称必须替换为你的项目值。Apple 的 运行测试与解读结果文档 说明，xcodebuild test 可以生成 .xcresults 结果包，其中可包含测试结果、代码覆盖率和日志。

MCP 要单独验收。Agent Host 原生读取工作区 .mcp.json 和用户级 ~/.copilot/mcp-config.json；它不会直接读取 .vscode/mcp.json，但 VS Code 可以转发部分配置。需要交互式输入的服务器，例如依赖 ${input:...} 的配置，可能无法在远程独立会话中正常工作。具体边界见 MCP 配置参考。

因此，MCP 验收至少包括：

  • 服务器是否在远程 Mac 上安装，而不是只安装在本地电脑；
  • 工作区路径是否指向当前工作树；
  • 所需环境变量是否通过受控凭据注入；
  • 浏览器工具在客户端断开后是否仍可用；
  • 高权限命令是否保留人工确认；
  • MCP 服务器异常退出后，Agent 是否会错误地重复执行副作用操作。

第一周的运行基线：决定共享池还是独占 Mac

完成首次连接后，不要只记录“能运行”。连续保存以下指标：任务运行时长、工具调用次数、失败重试、人工接管次数、工作树数量、构建峰值、磁盘增长和异常恢复时间。

你可以按 3 个结果做分流：

  • 继续试点：任务能在客户端断开后续跑，重连后状态一致，代码差异可复核，Xcode 构建和测试结果可保存。
  • 限制任务范围：会话能续跑，但部分浏览器、MCP 或签名工具依赖客户端，暂时只允许低风险修改和测试任务。
  • 暂缓扩大：远程 Mac 重启后无法恢复、工作树互相污染、凭据无法撤销，或 Agent Host 退出后没有可追踪日志。

如果你还在估算并行任务数量，可以先阅读 AI Coding 长任务的云端 Mac 容量估算，再结合构建峰值决定共享环境还是任务级独占环境。需要比较租赁与自购路径时，可查看 MacPull 的 Mac 购买方案说明；临时试点或短周期验收则适合先参考 MacPull 的租赁方案页面。

当前方案与 MacPull 方案：什么时候值得切换？

如果你现在依赖本地 Mac 跑长任务，常见缺点是电脑关机后进程停止、单台设备难以承载多个隔离工作树，以及团队成员无法从不同客户端统一接管会话。若改用普通云主机，又会遇到 Xcode、Simulator、签名工具和 macOS 专属测试无法直接复现的问题。

把 Agent Host 放到独立云端 Mac 上，能同时保留 macOS 工具链和远程会话能力，尤其适合临时测试环境、跨时区长任务和需要多窗口接管的 AI Coding 团队。你完成最小会话、断线续跑、工作树隔离与 Xcode 交付验收后，再根据任务时长、并行工作树数量和构建峰值选择共享池或任务级独立环境；如果只是长期稳定满负载，或者必须依赖物理设备接口，自购 Mac 可能更合适。