登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  业界新闻

VS Code 的Copilot新交互怎样连接本地与云端代理任务

来源:17golang原创

时间:2026-10-31 04:49:19 167浏览 收藏

这次 VS Code 的 Copilot 更新,重点不是再增加一个聊天入口,而是把“任务在哪里运行、从哪里继续、谁能控制”这三件事拆开了。GitHub 在 2026 年 10 月 28 日的公告中说明:云端代理可以从 Agents window 启动,并在 VS Code、Copilot app、GitHub Mobile、github.com 或 Copilot CLI 继续同一个会话;本机任务则由新的 Agent Host 脱离单个 VS Code 窗口继续运行。

官方地址:https://code.visualstudio.com/

公告地址:https://github.blog/changelog/2026-10-28-github-copilot-in-vs-code-universe-releases/

要点速览
  • 云端代理适合不依赖本地工作区的后台任务,关闭笔记本不会停止云端执行。
  • 本机或远程 Agent Host 仍依赖对应机器、工具链和权限;远程机器与 Agent Host 必须保持运行。
  • 手机控制、本地电脑操作、连接器和自定义市场等能力要单独看预览、实验和组织策略边界。

先把“云端”和“本地”分成两条任务链

公告里最容易被混在一起的是 cloud agent 和 Agent Host。前者把工作交给 GitHub 基础设施,适合可以在云端检出代码、安装依赖并完成修改的任务;后者让代理在自己的电脑或远程机器上持续工作,适合依赖内网服务、专用工具链或本地凭据的任务。

VS Code Copilot 云端代理与本地 Agent Host 的执行位置和会话连接关系说明图
图1:执行位置说明图,区分云端基础设施、本机 Agent Host、远程 Agent Host 与不同控制端之间的关系;这是原创说明图,不是软件截图。
任务条件更适合的执行位置必须先确认
后台改代码、可在云端准备依赖云端代理仓库访问、分支策略、结果审查
依赖本地服务或桌面工具本机 Agent Host本机权限、审批和电脑休眠策略
需要内网、GPU 或固定构建环境远程 Agent HostSSH/Dev Tunnel、远程机器与 Agent Host 持续运行

云端会话的价值在于“换客户端不断线”

这次交互的变化可以按同一个 session 来理解:早上从 VS Code 的 Agents window 启动云端会话,离开电脑后在 GitHub Mobile 查看进度,回到桌面再由 VS Code 或 Copilot CLI 接着处理。公告还提到,从 Slack 或 Microsoft Teams 私信启动的会话,也可以在这些客户端继续。

这并不等于所有本地状态都会自动搬到云端。企业试用时仍要先确认仓库是否能被云端工作环境访问、依赖是否能从允许的源安装,以及代理提交的修改是否必须经过分支保护和人工审查。会话连续性解决的是“从哪里继续”,不替代代码权限和变更审批。

本机 Agent Host 解决的是窗口关闭后的持续运行

本机模式的关键组件是 Agent Host。它把 Copilot 会话从某一个 VS Code 窗口中隔离出来,因此关闭项目文件夹或窗口后,任务仍可以在后台继续。若使用 Remote SSH 或 Dev Tunnels,代理还可以在另一台机器上运行;但公告明确要求远程机器和它的 Agent Host 保持运行,断开本地连接不等于远程环境已经退出。

# 只在需要从 GitHub Mobile 控制本机代理时启用 Agent Host
code agent host --github-environment

# 这里的检查重点是运行位置和生命周期,不是重新创建一个会话
# 机器、Agent Host 与项目依赖必须在允许的维护窗口内保持可用

如果任务需要访问本地数据库、内网服务或桌面应用,本机模式通常比云端更自然;但可达性也意味着风险面更大。建议把“允许访问哪些目录、能否运行终端命令、是否需要每次审批”写进组织策略,而不是交给使用者临时判断。

VS Code Agent Host 将会话与编辑器窗口分离并连接本机或远程机器的关系示意图
图2:会话持续性结构图,展示编辑器窗口、Agent Host、项目依赖和移动控制端的静态边界;这是原创说明图,不是运行截图。

企业试用前要单独检查权限、插件和实验能力

公告同时提到插件控制、Marketplace、Copilot connectors 和 computer use。它们不能被当成同一种“开关”:插件市场可以由组织策略要求或阻止指定插件,仓库里的 .github/copilot/settings.json 更接近默认值,贡献者仍可能关闭;连接器可以把 Slack、Notion 或 Microsoft Learn 的上下文带入会话,但公告标注为 preview;computer use 需要在设置中启用,且每个应用都需要批准,组织也可以通过策略禁用,当前属于 experimental。

  • 身份:记录会话由哪个账号、组织和仓库权限启动。
  • 执行:记录任务落在云端、本机还是远程 Agent Host,避免把本地内网能力误当成云端能力。
  • 扩展:先列出允许的插件市场、连接器和默认插件,再决定是否开放预览能力。
  • 人工控制:涉及桌面应用、写文件、终端或外部服务时保留审批点,尤其是 computer use。

上线前用一张清单收住连续性带来的复杂度

可以把第一次试用限制在一个非生产仓库和一个明确的任务类型,按下面顺序复查:

  1. 确认仓库分支保护、密钥注入和依赖源对执行位置可用。
  2. 启动一个可回滚的任务,记录 session、执行位置、操作者和审批人。
  3. 分别测试关闭 VS Code 窗口、断开 SSH 或切换到 GitHub Mobile 后能否继续,以及哪些状态不会继续。
  4. 把生成的提交、日志、工具调用和人工批准结果放回正常审查链路。
  5. 对 preview 或 experimental 能力设置明确的组织开关和退出方案。

这样看,这次更新真正带来的不是“代理替你完成一切”,而是同一项工作可以在云端、本机、远程机器和移动端之间重新分配。分配前先确定数据边界和审批边界,连续性才会变成生产效率,而不是新的追踪盲区。

常见问题

关闭笔记本后,所有 Copilot 任务都会继续吗?

不会。公告明确描述的是云端代理在 GitHub 基础设施上继续运行;本机或远程 Agent Host 仍依赖对应机器和主机进程保持运行。

手机控制本机代理需要什么条件?

公告给出的入口是 code agent host --github-environment,并要求本机和 Agent Host 保持运行;具体账号权限和组织策略还要按所在环境确认。

Copilot connectors 和 computer use 是默认生产能力吗?

不能这样理解。公告把 connectors 标为 preview,把 computer use 标为 experimental;试用前应由组织管理员确认是否开放,并保留人工批准和回退方式。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>