9 月的 VS Code 更新（v1.136 至 v1.140）把 Copilot 的重心从“补全下一行”移到了“推进整条工作流”。官方 changelog 的表述很直接：让 agent 驱动的开发从实现一路走到 pull request 合并。这意味着 Agent 不再只是聊天窗口里的助手，而是开始接管可重复任务、会话生命周期和 PR 落地环节。
Automations：把重复任务交给调度器
Agents window 新增的 automations 支持按小时、每天或每周的节奏运行任务，也可以按需手动触发。入口有两种：从模板起步，或直接写自己的 prompt。该功能处于 preview 阶段。
从工程角度看，这解决的是“同一类检查反复手动发起”的问题。比如每日依赖审计、周期性回归提示、固定格式的代码巡检，都可以固化成一条 prompt 加一个调度周期。需要注意的边界是：官方只说明了调度粒度和 prompt 来源，并未承诺任务失败后的重试策略、并发上限或资源隔离方式。因此企业落地时，建议先用只读类任务验证稳定性，再逐步放开写操作。
agent merge：让 Agent 处理合并前的脏活
在活跃会话中启用 agent merge 后，agent 会接手 review 反馈、失败的检查、合并冲突以及 workflow 重跑。该功能同样处于 preview。
这是本次更新里对工作流冲击最大的一项。传统流程中，PR 从提交到合并之间的等待、修冲突、重跑 CI 往往由人来回切换完成；agent merge 把这部分收敛进会话内。但要注意，官方没有说明 agent 在冲突解决时的策略边界，也没有给出自动合并的审批门槛。合理的做法是：在分支保护规则里保留人工 approve 或必需状态检查，把 agent merge 当作“减少往返次数”的工具，而不是绕过评审的捷径。
从会话直接创建 PR
Agents window 支持从 Copilot、Claude 或 Codex 的 agent 会话中打开 pull request 表单，编辑标题和描述，选择 draft 与 merge 选项后创建 PR。这一步把“会话产出”和“仓库变更”之间的手工搬运去掉了。
配套的是会话管理能力：agent 现在可以自行决定创建新 chat 或 session，通过导航链接跳回源 chat，sessions 列表以层级视图展示所有相关会话。PR 合并后会出现 Mark as Done 建议，也可以配置自动清理。这些机制共同指向一个事实：会话数量会随自动化上升，没有层级和清理策略，Agents window 很快会变成噪音。
环境与上下文：Dev Container 与 GitHub 上下文
Agents window 支持从本地或远程文件夹菜单选择 Use Dev Container，用项目配置好的工具和依赖运行 agent 会话，覆盖 SSH、Tunnel 和 WSL 主机。对多语言、依赖复杂的企业仓库来说，这比在宿主机上碰运气更可控。
Chat 侧有两项值得注意：一是 agent 向进行中的 chat 发消息时不再打断当前 turn；二是可以把 GitHub issue 或 PR 通过 Add Context 加入任意 chat，或直接粘贴 URL 到新会话输入框。后者让“从 issue 出发”的工作流少了一次上下文复制。
Workspaces 方面，可以先开一个不带 workspace 的通用 Copilot chat，之后再附加本地文件夹，让对话绑定到具体项目；Codex 会话也可以从 ChatGPT app 接续到 VS Code，无需复制粘贴上下文或文件。
企业落地的配置与迁移建议
第一，把 automations 和 agent merge 都当作 preview 能力对待。官方明确标注了 preview 状态，生产仓库应先在非关键分支或沙箱仓库验证。
第二，为 agent merge 设计护栏。既然 agent 会处理 review 反馈和失败检查，分支保护规则中的必需检查、必需评审和合并队列策略就需要重新审视，避免自动化与保护规则互相打架。
第三，统一会话治理。启用 Mark as Done 建议或自动清理，配合层级会话视图，避免自动化任务产生的会话淹没人工会话。
第四，环境先行。如果团队已有 Dev Container 配置，优先通过 Use Dev Container 启动 agent 会话，减少“本地能跑、agent 跑不了”的差异。
第五，模型与工作流选择上，HydraFusion 可在符合条件时于模型选择器中启用，自动为编码任务挑选模型和工作流，但该功能处于 research preview，不建议作为唯一路径。
整体来看，9 月版本把 Agent 的职责边界从“写代码”扩展到了“调度、会话、合并”。真正的迁移成本不在功能开关，而在团队是否愿意重新定义 PR 合并前后的责任划分。
