结论：VS Code 1.146 已弃用 Local harness，官方计划于 2027 年 2 月移除；你应在移除前迁到 Copilot harness。本周先盘点并备份自定义项，再用一个可重复任务验证新会话、远程工作区和项目命令，别把“新会话默认使用 Copilot”误当成“旧配置已迁完”。(VS Code 1.146 发布说明)
这篇适合仍使用 Local harness、需要处理旧会话或自定义工具的 VS Code Agent 用户。
通过 Remote SSH 在远程 Mac 工作的工程师，还要确认 Agent Host 实际连接的工作区和命令环境。
负责团队推广的管理员，应先核对策略、权限和沙箱，再扩大切换范围。
最后更新于 2026 年 11 月 12 日；核实依据为 VS Code 1.146 发布说明及官方迁移、远程开发与策略文档。
弃用时间与迁移窗口
VS Code 1.146 Stable 于 2026 年 11 月 11 日发布，并将 Local harness 标记为弃用；官方写明它计划在 2027 年 2 月移除。官方也说明 Copilot harness 自 VS Code 1.143 起已是新会话默认选项。也就是说，你要尽早处理依赖 Local 的工作流，但不用仅因看到弃用提示就假定每个旧会话都必须立即重建。
判断迁移是否完成，至少要分清四件事：harness 决定 Agent 如何组织模型、工具和审批；模型是会话使用的推理模型；执行位置决定文件和命令在哪台机器上运行；Agent Host 则负责运行会话。改模型不等于换 harness，选 Copilot harness 也不会自动把代码搬到云端。(VS Code 的 Agent harness 概念说明)
| 决策维度 | 继续使用 Local harness | 迁到 Copilot harness |
|---|---|---|
| 适用情况 | 仅用于移除前暂时保留尚未验证的旧流程 | 新建会话与已完成兼容核验的日常工作 |
| 运行方式 | 会话与 VS Code 编辑器窗口紧密关联 | 会话由 Agent Host 运行，可从受支持界面继续访问 |
| 自定义项 | 沿用旧会话已有配置，但不应期待获得新功能 | 按目标 harness 的格式逐项检查和配置 |
| 主要风险 | 官方说明旧 harness 功能冻结，未来将被移除 | 工具、权限、MCP、Hooks 等支持方式可能不同 |
官方明确指出，Local harness 在移除前处于功能冻结状态，Copilot harness 才是后续功能重点；但选择 Copilot 并不意味着旧配置全部自动兼容。
迁移前盘点：自定义配置不会自动迁移
选择 Copilot harness 只是为新会话选择运行框架，不是把提示文件、个人 Agent、指令、Hooks、MCP 服务器和凭据逐项转换。迁移指南建议先选一个原本可稳定复现的小任务，记录项目、必需工具、要执行的命令、审批过程和预期结果，作为新旧工作流的对照基线。(Local 到 Copilot harness 官方迁移指南)
你可以先按下面的清单盘点：
- 提示文件、个人 Agent 与指令：记录存放位置、项目或个人作用范围，以及是否依赖编辑器配置。迁移后再确认 Copilot harness 能否从相应位置读取。
- Hooks：备份配置和调用脚本，注明触发事件、输入输出、启用或禁用状态。Hooks 没有简单的“复制即迁好”保证，应按照目标格式重新核验。
- MCP：记录服务器启动命令、环境变量、认证方式和实际使用的工具。配置格式与凭据传递方式可能不同；尤其不要把秘密占位符替换成共享文件中的明文凭据。
- 工具和终端：列出扩展提供的工具、Shell 初始化依赖、环境变量与项目命令。某些扩展工具需要对应编辑器窗口保持连接。
- 权限和团队策略：记录谁批准命令、哪些操作被限制，以及沙箱是否生效；这些行为应在目标执行主机上验证，而非只看设置界面。
MCP 配置需要按 Copilot harness 支持的目标位置检查，旧编辑器管理配置并不必然会被新 harness 直接读取；Hooks 也要核对事件、脚本参数和执行环境。(VS Code MCP 配置说明)
⚠️ 备份不只是把设置文件复制一份。把关联脚本、MCP 凭据的存放方式和启用状态也记下来；迁移完成并通过项目验收前，保留可回退的原件。
新会话试迁与 Copilot harness 确认
先在新会话的 Session Target 中明确选择 Copilot，再核对账户是否有可用模型和必需工具。创建后，查看会话标题中的 harness 标记，或在 Agents 窗口查看输入框提示、会话列表信息；不要仅凭模型名称判断 harness，因为同一类模型可以在不同 harness 下使用。
然后用先前记录的基线任务复跑一次。把代码改动、终端命令、工具调用、审批提示和最终测试结果逐项与旧流程比较；如果某一步发生变化，先定位是工具缺失、配置格式、权限策略，还是 Shell 环境不同，不要立刻用更宽松的权限掩盖差异。
推荐按这个顺序试迁：
- 新建会话，在 Session Target 选择 Copilot，并确认显示的会话 harness。
- 选定与基线相同的仓库、分支和执行位置，避免把工作区变化误判为 harness 差异。
- 启用已核验的工具与 MCP 服务器，逐个确认其工具调用能够成功。
- 要求 Agent 执行同一组项目命令，记录审批行为、错误输出和文件变更。
- 使用项目自己的测试或构建命令验收，并保留差异与未解决项。
如果要延续旧 Local 会话，可通过官方交接路径把会话历史和上下文带到 Copilot 会话；交接后要确认历史、草稿、工作区和权限。它不是双向切换，且新旧 harness 的可用模型、工具和权限可能不同。(官方迁移指南中的会话交接说明)
Remote SSH 工作区与 Agent Host 验收
Remote SSH 编辑器连接成功，不代表 Agent 已在预期主机上执行，也不代表项目命令具备所需依赖。对远程 Mac 工作流，你要分别确认编辑器当前连接的远程主机、Agent Host 所在环境、打开的仓库路径，以及终端实际使用的 Shell。VS Code 的远程开发文档说明，Remote SSH 会在远程主机上打开工作区；Agent Host 文档则指出，工作区编辑和命令使用 Agent Host 所在环境的工具与依赖。(Remote SSH 远程开发文档；Agent Host 概念说明)
可用一个真实项目作为场景案例：例如，Agent 修改远程 Mac 上的应用代码后，需要运行项目已有的 macOS 构建或测试命令。不要只看会话启动成功；检查工作目录、分支、依赖版本与命令输出，再确认构建或测试结果。若命令找不到、环境变量缺失或权限被拒绝，应先判断是远程主机配置还是 harness 设置问题。
远程验收时重点检查：
- 仓库与路径：确认 Agent 修改的是 Remote SSH 窗口中打开的目标仓库，而非本地同名目录。
- 命令环境：在远程终端核对 Shell、路径和项目依赖，再让 Agent 运行同一条基线命令。
- Agent Host：确认会话位于预期主机。客户端配置不一定会传到远端；远程会话所需的用户配置和依赖可能必须在运行环境内准备。
- 工具可用性：检查扩展提供的工具是否因编辑器未连接而不可用，并单独验证 MCP 服务器的认证与调用。
- 最终结果：以项目自己的构建、测试或打包输出为通过标准，而不是以远程连接成功或 Agent 返回“已完成”为准。
Copilot 会话可在编辑器与 Agents 窗口间继续，但 Agent Host 必须仍在运行；由编辑器提供的工具也可能要求编辑器保持连接。
远程会话的配置边界容易被忽略：本机上能用的凭据、Shell 初始化和 MCP 设置，不一定在远程 Agent Host 所在环境可见。先在目标主机核实，再判断是否需要迁移配置。
团队推广与策略核验
个人任务通过后，再选择能代表团队实际情况的项目验证，而不是直接全员切换。至少覆盖不同的仓库配置、MCP 与 Hooks 使用方式，以及需要受控命令或沙箱的执行场景；记录管理员策略实际下发到哪个环境，并在远程主机检查有效策略。官方企业设置文档建议通过策略诊断核实策略值及来源，也提醒在远程主机和容器中确认实际生效的沙箱策略。(VS Code 企业 AI 设置管理文档)
推广前可以对照这份优缺点清单：
- ✅ 分批推广：先让代表性项目的维护者完成验收，再扩大到其他仓库；出现阻塞时，团队仍能定位到具体配置或策略。
- ✅ 权限先于便利：分别验证命令审批、工具权限与沙箱边界，不要把“命令能跑”当作“命令在正确边界内运行”。
- ❌ 不要只改默认值：偏好 Copilot 的默认设置不等于禁止 Local，也不等于所有团队策略已部署。
- ❌ 不要保留重复活动配置：迁移后检查旧配置和新配置是否同时触发，避免 Hook 或工具重复执行。
- ⚠️ 不要把旧会话当作已迁移流程：确认需要延续的历史、草稿和工作区可用，并标记仍无法替代的 Local 依赖。
企业策略可以影响可用 harness、权限和沙箱行为；如果你负责团队设置，应在扩大推广前检查策略来源与实际效果。迁移指南和企业管理文档也应随着 VS Code 官方更新复核，特别是移除节点、兼容说明或策略行为发生变化时。
如果你的项目主要运行跨平台代码，本机或现有 CI 环境未必需要额外的 Mac；但当工作流依赖 macOS 工具链、需要持续在线的执行主机时，Windows/Linux 环境会受操作系统与工具链限制，临时搭建也增加维护和权限核验成本。先完成迁移验收，再按任务是否确实需要 macOS 决定执行位置；你可以先参考远程 Mac 方案对比，若需要临时或按周期使用持续在线的 macOS 环境，再了解 VpsHold 远程 Mac 使用方式。若你已经有稳定且合规的 Mac 执行节点，就没有必要为了迁移 harness 而额外租用。