Copilot 会话一键续到 VS Code

截至 2026 年 10 月 19 日，GitHub 已支持把 GitHub Copilot App 中的 Agent 会话继续到 VS Code，无需重新描述任务，也不必手动搬运 Agent 已经修改的代码。开发者可以先在独立桌面应用里让 Agent 分析仓库、制定计划和执行改动，再进入 VS Code 接手审查、调试与提交。

**Copilot 会话续接是指同一个 Agent 任务可以从 Copilot App 转入 VS Code，并继续使用原有对话记录、工作上下文和本地代码状态。**它不是把一段聊天文本复制进编辑器，而是让 VS Code 识别此前创建的受支持会话，并在同一条任务链上继续工作。

这项能力看起来只是少了一次复制粘贴，实际解决的却是 Coding Agent 最让人烦躁的问题之一：切换界面之后，模型突然“失忆”。过去从独立 Agent 工具回到 IDE，开发者往往要重新解释目标、指出涉及的文件，再检查磁盘上的改动是否和聊天里的计划一致；现在，这些步骤可以压缩为一次会话续接。

这次打通的不是聊天记录，而是 Agent 的工作现场

**Agent 工作上下文是模型完成当前任务时使用的会话历史、仓库信息、工具执行结果、任务计划和改动状态的集合。**普通聊天记录只告诉你“说过什么”，而工作上下文还要回答“看过哪些文件、执行过什么操作、任务进行到哪一步、磁盘上留下了哪些结果”。

GitHub 在官方介绍中明确强调，续接过程不会丢掉 conversation、code changes 或 working context。换句话说，开发者在 Copilot App 中要求 Agent 修复一个鉴权问题后，进入 VS Code 时不需要重新发送“请打开 auth middleware，再检查 token refresh 逻辑”这样的提示词；编辑器可以沿用原会话继续检查差异、运行测试或追问实现细节。

**代码改动能够保留的关键原因，是这些受支持会话操作的是本地工作区，而不只是云端聊天窗口中的临时代码片段。**只要 VS Code 打开的仍是对应仓库，Agent 已写入工作树的文件不会因为界面切换而消失，Git 也会继续把它们识别为未提交改动。

这项设计比“导出聊天记录”更有价值。导出文本只能恢复语言层面的背景，却无法可靠还原终端命令、工具调用、文件差异和任务进度；会话续接则试图保存完整任务轨迹，让 IDE 成为前一个 Agent 界面的延伸。

Copilot harness 是这次体验统一的底层

**Copilot harness 是 GitHub 用来统一 Agent 行为、工具使用和会话体验的运行框架。**根据 VS Code 官方文档的描述，这套框架建立在 GitHub Copilot SDK 之上，用于让 VS Code、GitHub Copilot CLI 和 GitHub Copilot App 获得更一致的任务执行方式。

统一 harness 的意义在于，用户不必再为每个入口学习一套完全不同的 Agent 逻辑。Copilot App 适合把任务单独展开，VS Code Chat 适合边写边问，Agents 窗口适合管理任务，CLI 则更适合终端驱动的操作；这些界面负责不同阶段，但底层会话可以在受支持的范围内被重新发现和继续。

| 入口 | 更适合的场景 | 可继续的会话 | 主要优势 | |---|---|---|---| | GitHub Copilot App | 独立处理复杂任务、减少编辑器干扰 | App 创建的受支持本地会话 | 任务视图更集中，适合先规划再执行 | | VS Code Chat view | 打开项目后边编码边交互 | 当前实时会话及受支持会话 | 对照源码、终端、测试和调试器最直接 | | VS Code Agents window | 浏览和管理多个 Agent 任务 | 可发现 App、CLI 等入口创建的受支持会话 | 更接近 Agent 任务控制台 | | GitHub Copilot CLI | 终端优先的仓库操作 | 可与 VS Code 继续的受支持 CLI 会话 | 适合脚本、Shell 和远程开发习惯 | | GitHub.com 或移动端远程控制 | 离开当前开发机后查看长任务 | 需要单独启用的 CLI 远程实验能力 | 可以监控和引导仍在运行的 CLI 会话 |

这里的关键词是“受支持会话”。它不意味着任意历史聊天、任意第三方 Agent 或任何一台设备上的任务都能自动出现在 VS Code，也不等于 GitHub 已经完成全产品、全设备的 Copilot Chat 同步。

实战：把 Copilot App 任务带进 VS Code

**最稳妥的操作方式，是先确认 App 和 VS Code 指向同一个本地仓库，再发起续接。**如果两个入口打开的是不同克隆目录，即使仓库远程地址相同，工作树里的未提交改动也不会凭空跨目录复制。

第一步：在 Copilot App 中建立可验证的任务边界

**清晰的任务边界能让续接后的检查成本显著降低。**例如，不要只让 Agent“优化登录模块”，而应要求它完成一个可以验收的工作单元：定位 refresh token 竞争条件、修改实现、补充回归测试，并列出尚未解决的问题。

在切换之前，建议让 Agent 总结一次当前状态，至少包括：

• 已修改哪些文件；
• 已运行哪些测试或静态检查；
• 哪些命令成功，哪些命令失败；
• 当前是否仍有后台任务；
• 下一步最适合在 VS Code 中完成什么。

这份总结不是为了替代会话续接，而是作为人工检查点。Agent 会话保留得再完整，也不应代替版本控制和开发者验收。

第二步：从会话入口打开 VS Code

**Copilot App 的会话菜单提供了继续或打开到 VS Code 的入口。**不同操作系统、发布批次和界面语言下，按钮文案可能显示为“Open in VS Code”或含义相近的“Continue in VS Code”，但目标都是调用 VS Code 并加载对应会话。

如果没有从 App 直接跳转，也可以先在 VS Code 中打开对应项目，再进入 Chat view 或 Agents window，查找 Copilot App 创建的受支持本地会话。VS Code 官方说明特别提到，Agents 窗口可以发现并继续来自 GitHub Copilot App 或 GitHub Copilot CLI 的受支持会话。

此时应重点确认三件事：

1. VS Code 登录的是预期的 GitHub 账户；
2. 当前工作区是 Agent 实际操作过的仓库目录；
3. Copilot 扩展与 VS Code 已更新到支持该能力的版本。

第三步：先验证 Git 状态，再继续让 Agent 工作

**续接成功后的第一件事应该是核对工作树，而不是马上发送下一条指令。**对话显示正常，只能证明会话被找到；Git 差异与测试结果才决定代码是否真的处于预期状态。

可以在 VS Code 集成终端中执行：

git status --short
git diff --stat
git diff

这三个命令分别用于检查改动文件、变更规模和具体差异。假设 Copilot App 表示自己修改了 4 个文件，而 git status --short 只显示 2 个，就不应继续让 Agent扩大改动范围，而应先排查是否打开了错误目录、部分文件尚未写入，或者改动已被其他进程覆盖。

**VS Code 的 Source Control 面板适合逐文件审查，Chat 中的 diff 则适合结合 Agent 解释理解改动理由。**2026 年的 Copilot 更新已经把代码差异更直接地呈现在聊天线程中，但开发者仍应以真实工作树和 Git diff 为准。

第四步：利用 VS Code 完成调试、测试和人工修改

**进入 VS Code 后，Agent 会话的价值在于能立刻使用编辑器级工具完成最后一公里。**开发者可以打开断点、查看类型错误、运行测试、使用集成终端，或者直接人工修改 Agent 刚刚生成的实现。

一个合理的续接提示可以是：“基于当前会话继续，先解释 tokenManager.ts 的修改为什么能避免并发刷新，再运行相关测试；不要修改其他模块。”这条指令不必重复完整需求，而是利用已保留的上下文约束下一步动作。

测试命令应根据项目实际情况执行，例如：

npm test
npm run lint
npm run typecheck

这些命令只是常见示例，不代表 Copilot 会自动判断所有项目的正确验证流程。对于大型 monorepo，更建议先运行受影响包的定向测试，再决定是否执行完整测试套件。

第五步：在提交前建立新的人工检查点

**会话连续不等于代码正确，提交前仍要完成独立审查。**至少需要检查 Agent 是否扩大了修改范围、是否引入新的依赖、是否改写配置文件，以及测试是否真的覆盖了原始缺陷。

推荐在提交前再次执行：

git diff --check
git status --short

git diff --check 可以发现部分空白字符错误，git status --short 则能避免把日志、构建产物或本地配置误加入提交。涉及数据库迁移、权限策略、密钥处理和部署配置时，还应安排人工专项审查，不能只依赖 Copilot 的会话记忆。

哪些内容能保留，哪些内容不要想当然

**目前最可靠的理解是：GitHub 打通了受支持本地会话在 Copilot App 与 VS Code 之间的继续能力。**它改善的是同一开发环境中的界面切换，不应被宣传成无限制的跨设备、跨 IDE、跨仓库同步。

| 内容 | 续接后的预期状态 | 需要注意的边界 | |---|---|---| | 对话历史 | 保留在同一受支持会话中 | 不代表所有旧聊天都会自动迁移 | | Agent 任务上下文 | 可继续使用 | 上下文仍可能受模型窗口、压缩和会话实现影响 | | 本地代码改动 | 在同一工作树中保留 | 换电脑或换克隆目录不会自动复制未提交文件 | | 工具执行轨迹 | 可作为会话的一部分继续参考 | 外部进程、临时环境和已退出终端未必能恢复 | | 测试结果 | 可保留相关记录 | 环境变化后应重新运行，不能把旧结果视为持续有效 | | 当前 Git 分支 | 由本地仓库决定 | 切错分支会造成上下文与代码状态不一致 | | 跨设备聊天同步 | 不是本功能的核心承诺 | 社区仍在持续提出完整跨设备同步需求 | | 第三方 Agent 会话 | 默认不适用 | 必须属于 GitHub 明确支持的会话类型 |

“上下文不中断”也不应理解为模型拥有完美记忆。长会话仍可能经过摘要或压缩，模型对早期细节的关注度也可能下降；真正不会丢的是可恢复的会话链路和本地文件，而不是保证模型永远准确记住每一条隐含约束。

它和 Copilot CLI 远程控制不是一回事

**Copilot App 续接 VS Code 是本地工作流切换，Copilot CLI remote 则是对运行中终端会话的远程监控与引导。**GitHub 在 2026 年 5 月公布的 VS Code 4 月更新中，为 CLI 会话加入了实验性的跨设备控制能力。

CLI 远程能力需要在设置中启用：

github.copilot.chat.cli.remote.enabled

随后在支持的 CLI 会话中执行：

/remote on

启用后，开发者可以从 GitHub.com 或移动端监控、引导仍在运行的 Copilot CLI 会话。这个功能更接近“人离开电脑，但任务还在跑”；App 到 VS Code 的续接则更接近“任务还在这台电脑上，只是换一个更适合审查代码的界面”。

两者共同说明 GitHub 正在把 Copilot 从 IDE 插件改造成多入口 Agent 系统，但目前仍有明显边界。社区在 GitHub Discussion #175114 中提出的目标更进一步：让 Visual Studio、VS Code、GitHub.dev 和 GitHub Mobile 共享完整聊天历史，并提供后台任务完成通知；截至本文时间，这种覆盖所有入口的无缝同步仍不能与本次本地续接能力画等号。

遇到会话找不到，可以按这个顺序排查

**多数续接问题首先来自账户、目录和版本不一致，而不是模型本身。**建议按以下顺序检查，避免一上来就重装整个开发环境：

1. 确认 Copilot App 与 VS Code 使用同一个 GitHub 账户；
2. 确认 VS Code 打开的路径就是 App 会话对应的本地仓库；
3. 更新 VS Code 与 GitHub Copilot 扩展，并重启编辑器；
4. 打开 Chat view 或 Agents window，确认不是只在普通历史聊天列表中查找；
5. 检查仓库是否被移动、重命名或重新克隆；
6. 检查当前分支和 worktree 是否与创建会话时一致；
7. 在 VS Code 的 Output 面板选择 GitHub Copilot，查看扩展错误；
8. 最后再考虑退出账户、重新授权或清理扩展状态。

**企业账户还需要考虑组织策略是否限制 Agent 功能。**GitHub Copilot Business 或 Enterprise 环境可能由管理员控制模型、Agent 模式及相关预览能力，因此个人账户可见的入口不一定会同时出现在企业工作区。

社区曾报告 Agent mode 长时间停留在“Working...”状态，排查时也通常需要查看 VS Code Output 中的 GitHub Copilot 日志。不过，删除 .git 目录之类的激进操作不适合作为常规修复方案；它会破坏仓库元数据，还可能让会话与代码状态进一步脱节。

这项功能真正改变的是任务交接成本

**Copilot App 到 VS Code 的会话续接，是一项比新模型跑分更务实的工程体验升级。**开发者不缺一个可以聊天的窗口，真正稀缺的是让 Agent 在不同界面之间仍能认得任务、文件和进度的能力。

它最适合三类任务：第一类是 Agent 已经在 App 中完成大部分实现，需要回到 IDE 做精细审查；第二类是长时间代码分析，需要在独立界面减少干扰，再进入 VS Code 调试；第三类是多人或多任务并行时，希望在 Agents 窗口统一管理会话。

它暂时不适合被当作三件事：不能替代 Git 分支和提交，不能保证任意设备上的未提交改动自动同步，也不能证明 Agent 生成的代码已经通过安全与质量审查。

**我们的判断是，这次更新把 Copilot 向“持续工作的 AI 队友”推进了一步，但距离真正无感的跨设备 Agent 仍有距离。**本地会话能够从独立 App 进入 VS Code，已经解决了最常见的任务断层；下一阶段更难的问题，是如何在桌面、浏览器、移动端和远程开发机之间同步权限、环境与运行状态，同时又不把敏感代码和终端控制暴露给错误设备。

对于现在就要使用的开发者，最佳实践很简单：让 Copilot App 负责展开任务，让 VS Code 负责审查和收尾，让 Git 负责提供最终可信的状态记录。会话可以连续，责任边界不能模糊。

参考来源

• GitHub Community：Persistent Copilot Chat and Agent Interaction Across Devices —— 社区关于 Copilot 跨设备聊天、移动端访问和后台任务通知的功能建议，可用于区分现有本地续接与更完整的跨设备同步。
• microsoft/vscode-docs —— VS Code 官方文档源码仓库，包含 Copilot、Agent、Chat 与相关开发工作流说明。
• doggy8088/github-copilot-configs —— 社区整理的 GitHub Copilot 与 Agent 模式配置资料，适合排查功能开关及实验性设置。