摘要：微软在 2026 年 9 月 2 日发布 Visual Studio Code 1.136，新增 Agent Merge 预览。它不是替你写完一段代码，而是把已经打开的 Pull Request（PR）交给一个持续运行的收尾循环：处理评审意见、修复必需 CI 检查、解决分支落后或合并冲突，并在符合配置时合并或加入 merge queue。对开发团队来说，变化首先发生在“代码已经提交、但 PR 还没准备好合并”的等待阶段；不过它仍处于预览，开启后会让会话进入 Autopilot 和 Assisted permissions，权限、模型请求消耗和最终复核都必须先看清。
很多团队真正慢下来的地方，不是把第一版代码写出来，而是 PR 提交后的最后几轮：评审者留言、CI 偶发失败、基础分支前进、冲突出现，开发者需要在通知、终端、网页和编辑器之间来回切换。每个问题单独看都不难，叠加起来却会打断正在进行的工作。本文只讨论 1.136 的 Agent Merge：它具体接管哪一段动作，哪些设置决定它会做到什么程度，以及什么时候仍应由人来接管。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
具体发生了什么：Agent Merge 开始盯住 PR 的“最后一公里”
官方发布说明把 Agent Merge 标为 Preview，并明确它会“把 Pull Request 推过终点线”。使用前，先在设置中启用 chat.agentMerge.enabled，再打开一个与 PR 关联的 agent session；在 Agents 窗口标题栏选择 Agent Merge，然后选择 Enable Agent Merge。这不是一个对任意聊天都生效的全局开关，而是绑定到当前会话和它跟踪的 PR。
启用后，代理可处理四类具体阻塞：未解决的 review thread、changes-requested review 以及维护者或 Copilot PR reviewer 的新评论；失败的必需 CI 检查；落后于 base branch 的分支和合并冲突；以及在维护工作完成后的合并或加入 merge queue。官方描述的关键不是“能修一次”，而是它会重复这一过程，直到 PR 达到可合并状态。也就是说，输入不再是“请改这个文件”，而是一个随外部反馈变化的 PR 状态。
一个完整场景：从评审留言走到 merge queue
假设一个后端 PR 已经通过主要功能测试，但 reviewer 留下两条未解决意见，同时一个必需的集成测试因接口变更失败，base branch 还比该分支多了几次提交。传统做法是开发者收到通知后，先在网页读评论，再回编辑器改代码，手动拉取并解决冲突，重跑测试，最后回到 PR 页面判断是否可以合并。这条链路的摩擦不在某一条命令，而在每次外部状态变化都需要人重新恢复上下文。
在 1.136 中，开发者可以从 PR 创建关联 session，选择 Agent Merge，并在配置菜单中勾选希望它处理的阻塞类型，同时决定准备就绪后是只停在可合并状态、自动合并，还是加入 merge queue。代理随后启动 agent turns，针对评论或失败检查修改并同步 PR 分支；必需检查仍在运行时，它会等待，而不是把“尚未完成”误当成成功。检查结束后，它会再次确认 PR 是否满足合并条件，再执行所选的最后动作。
交付结果因此有两个层次：代码和检查结果是代理循环的产物，是否允许它触发合并则是团队策略的产物。对小团队，这可能减少“修完 CI 却忘了回网页”的上下文切换；对有严格审计要求的团队，它也可以先只开启评审意见和失败检查处理，把合并保留给人工或现有审批规则。
为什么它改变的是流程，而不只是多一个按钮
过去的 Coding Agent 更常被理解为“收到一个任务，生成一次改动”；Agent Merge 把任务的边界改成了“观察一个会不断变化的交付对象”。PR 的状态由评论、检查、分支关系和仓库规则共同决定，代理要在每一轮动作后重新读取反馈，才能知道下一步是否仍然必要。这个循环把开发者从重复性的收尾执行者，部分转成阻塞类型与合并策略的配置者。
同一版本还改进了会话组织：相关 chats 会出现在父 session 之下，开发者可以从 sessions list 在相关工作之间切换。它和 Agent Merge 的关系并不是“更多功能拼盘”，而是可追踪性成为持续运行任务的前提——当代理多次处理评论和检查时，团队需要知道哪些对话属于同一项 PR 工作，而不是在一堆孤立聊天中寻找证据。
限制、权限与人需要接管的节点
第一，Agent Merge 仍是 Preview，官方明确提示行为可能变化。第二，开启它会启动 agent turns、修改并同步 PR 分支，并消耗 model requests；会话会切换到 Autopilot 与 Assisted permissions。这个组合意味着“自动运行”不等于“无限权限”，但它确实会让代理持续推进工作，团队应在启用前逐项检查 Agent Merge 的处理范围和合并选项。
第三，自动化的对象是可观察到的阻塞，不是业务正确性本身。一个 CI 变绿，并不能证明修复符合产品意图；一条 review comment 被处理，也不代表架构取舍已经被接受。因此，涉及权限边界、数据迁移、认证逻辑和破坏性变更时，建议先关闭自动合并，只让它处理可重复验证的修复，再由维护者阅读差异和测试输出。官方还说明，若 session 开始跟踪了不同分支或 PR，Agent Merge 会关闭，必须重新启用；这是一项防止任务漂移的保护，但也意味着不能把它当作脱离上下文的后台机器人。
第四，若团队的 CI、评审规则或 merge queue 本身配置不完整，Agent Merge 只能重复暴露这些流程问题，不能替团队定义“准备好合并”的标准。启用前应确认必需检查、分支保护、评审者范围和 merge queue 规则都能被人解释清楚。
结论：先把它当作 PR 收尾助手，而不是自动合并承诺
现在最稳妥的试用方式，是选一个低风险、测试覆盖充分的仓库，先从一个与 PR 关联的 session 开始，只开启处理 review threads 和失败必需检查，不勾选自动合并。记录三件事：它是否能正确恢复 PR 上下文，修复后是否真的重跑并通过了目标检查，以及每轮 agent turn 消耗了多少模型请求。若连续几次试验都能减少人工切换，且团队能接受 Assisted permissions，再把分支更新和冲突处理纳入范围；自动 merge 或 merge queue 应最后评估。
因此，VS Code 1.136 的 Agent Merge 值得关注的地方，不是它宣称“代码可以自己合并”，而是它把 PR 的收尾阶段正式建模成一个可配置、可等待、可重复验证的 agent loop。它可能压缩等待和上下文恢复成本，但不会替代代码所有者对风险、意图和最终交付的判断。
信息来源与事实说明
- Visual Studio Code 1.136 Release Notes：官方发布日期、Agent Merge 功能、设置名、会话绑定和版本状态。
- Use the Agents window (Preview)：Agent Merge 的启用步骤、可处理的阻塞类型、Autopilot/Assisted permissions、等待检查和分支漂移保护。
- 文中关于“减少上下文切换”“先低风险试用”的内容属于编辑分析，不是官方性能承诺；图片均为 VS Code 官方发布页素材，上传至本文 Ghost 图片库后使用。
开发必备：API 全流程管理神器 Apifox
介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。
如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。
值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。
获取专属报价与部署方案
详细的私有化部署系统架构与安全白皮书
针对您公司规模的专属报价单
免费的 1v1 专属产品演示 (Demo) 机会
