一个会话管多个仓库：VS Code 1.140 暴露了 Agent 时代的协作难题
编辑器正在从「写代码的地方」变成「编排 Agent 的地方」。VS Code 1.140 的多文件夹会话，解决的是 Agent 落地后冒出的一个真实痛点：一次改动往往横跨多个仓库，而原来的会话模型只认一个工作区。
IT之家报道：微软 9 月 30 日发布 VS Code 1.140 稳定版，重点更新 GitHub Copilot Agent 工作流，新增实验性多文件夹会话——同一 Agent 会话中的聊天可分别绑定不同仓库或 Git worktree，终端、任务、代码变更、Pull Request 与合并状态相互隔离。
这个改动为什么重要
- 它承认了「多仓库」是常态。前后端分仓、SDK 与主应用分仓、基础设施与业务分仓——真实项目很少只有一个仓库。Agent 要在这些仓库之间做联动修改，会话模型就必须支持上下文隔离。
- 隔离是安全设计，不只是整洁。把每个文件夹的终端、任务与变更分开，等于给 Agent 划出权限与状态边界。共用一个终端，就等于让 Agent 在任何仓库里都具备同等执行能力。
- 「远程任务委派」改变了人机分工。把任务派给远程 Agent 后，人的角色从「同步结对」变成「异步验收」。这只有与 CI 门禁、PR 评审配合起来才完整。
但异步委派需要新的护栏
- 验收成本会上升。Agent 单次改动范围越大，人读 diff 的成本越高。分段提交、小 PR 会从「风格偏好」变成「必要约束」。
- 权限要跟着会话走。多文件夹会话必须能表达「这个仓库只读、那个可写」，否则隔离只是界面层面的。
- 可观测性。远程任务跑在别处，日志与中间状态必须能回看，否则失败时无法归因。
对读者的实际影响
- 团队负责人：把「PR 粒度」写进规范。Agent 产出速度上来了，评审能力就是新的瓶颈。
- 开发者：尽快把常用工作区整理成清晰的多文件夹组合。Agent 的上下文质量，取决于你给它的边界是否清楚。
- 平台安全：梳理一遍凭据作用域。会话隔离是编辑器层面的，真正的权限边界仍在密钥与网络策略上。
结论：这次更新看似是工作流细节，实质是编辑器在向「Agent 编排台」演进。它把一个原本属于 CI/CD 的问题——多仓库协同与权限隔离——提前到了开发者的编辑界面里。