VS Code 1.137 Agent Automations预览：让Copilot按计划自动执行开发任务

先说句实在话：等这个 1.137 稳定版，我盼了好几周。VS Code 从 1.136 开始在 AI 功能上明显提速，1.137 一出来最吸引我的不是那些常规的编辑器优化，而是 Agent Automations 预览。这东西一句话解释就是——你给 Copilot Agent 布置一个“到点自动干活的周期任务”，它会在后台自己跑起来，不用你选中代码、敲回车、等回复那一整套流程。

过去大半年，我身边几乎每个写 TypeScript 和 Python 的同事都在试 Claude Code、Codex 这类外部 Agent，大家最大的抱怨就是“集成深度不够”。VS Code 这次把 Agent Automations 放进稳定版预览，算是对这类需求的正面对话：不用离开编辑器，不用手动把代码上下文复制到终端里，直接在开发环境里定义触发条件和任务内容，让 Agent 按计划干活。这篇文章适合三类人：已经在用 GitHub Copilot 的开发者、关注 Agent 编程工具选型的技术负责人、以及所有对 VS Code 插件生态和自动化工作流感兴趣的玩家。我会把功能原理、配置细节、权限边界、实际踩坑一次说透，尽量让你看完就能自己动手配一个可用的自动化任务。

1. 从 1.136 到 1.137：这次更新到底改了什么

先说版本背景。VS Code 的月度发布节奏一直很稳定，1.137 属于常规迭代，但功能包里的 Agent Automations 预览不是小打小闹。按官方 release notes 的说法，这是 Copilot Agent 从“交互式对话工具”进化成“可编排的自动化执行器”的关键一步。

1.1 Agent Automations 到底是什么

名字起得有点绕，拆开看其实很直白。Agent 指的是 VS Code 内嵌的 GitHub Copilot Agent，它能读取你当前的工作区文件、编辑器上下文，也能调用终端命令和代码操作；Automations 是指给它加了一层“调度器”，让这些 Agent 能力不再依赖你手动发起对话，而是按照预设的规则自动触发。

触发规则目前主要有两类。第一类是定时触发，比如“每天 9 点扫描仓库里所有 TODO 注释并生成待办清单”；第二类是事件触发，比如“文件保存后自动跑一遍 ESLint 修复”“Pull Request 合并后自动更新 CHANGELOG”。这种设计思路其实和 CI/CD 里的 cron job 很像，只不过跑任务的执行环境从远端服务器换成了你本地 VS Code 进程。

这是过去几年的产品演进趋势：先是代码补全（Tab 补全），然后是对话式 Copilot（Copilot Chat），再然后是 Agent 模式（可以自主多步骤操作），现在到了 Automations 阶段——让 Agent 在无人值守的场景下干活。所以 1.137 的意义，不只是多了一个预览开关，而是把“AI 辅助编程”推进到了“AI 自主执行例行任务”的阶段。

1.2 这次与之前版本的关键差异点

如果你从 1.135 直接跳到 1.137，能感受到的变化不止 Automations 一项。但 Automations 这个功能在架构上和以前最大的不同，是引入了“任务定义文件”的概念。

以前你用 Copilot 干活，交互是即时性的：打开 Chat 面板，输入“解释这段代码”，它回答完就结束，没有持久化的任务状态。Agent Automations 不一样，它要求你至少配置一个任务描述，包括触发条件、目标文件或目录、要执行的指令、以及运行时的权限范围。这些配置会存在工作区的.vscode/automations.json（或者类似命名的文件）里，随项目走，团队成员可以共享同一套自动化规则。

另一个差异点是对多模型接入的态度更开放。1.137 扩展了模型适配层，除了默认的 GPT 系列，还允许通过模型供应商扩展点接入其他模型服务。网上很多人问“vs code codex 如何接入 deepseek”或者“vs code 外接 codex api”，本质上就是看中 VS Code 的扩展机制，想自定义模型后端。这次 Automations 的接口设计也考虑到了这一点，把“任务定义”和“底层模型调用”解耦，理论上不同模型都能跑同一套任务定义，只是执行效果会有差异。

2. Agent Automations 核心机制拆解

预览功能看着新鲜，但你得搞清楚它背后是怎么工作的，才能在正式项目里放心用。这一节我把触发机制、权限模型、运行隔离这三个关键点拆开讲。

2.1 触发方式与调度逻辑

Automations 的调度器跑在 VS Code 的扩展宿主进程里。定时触发用的是类似 cron 的表达式，不过在配置格式上做了简化，意图是让非运维背景的开发者也能看得懂。比如：

{ "name": "每日代码健康检查", "trigger": { "type": "schedule", "cron": "0 9 * * *" }, "instruction": "扫描当前工作区，找出所有标记了 FIXME 的地方，按严重程度分组输出到 NOTES.md", "target": "workspace", "approval": "never" }

这个配置的意思是：每个工作日早上 9 点，让 Agent 扫描整个工作区，找出 FIXME 注释，整理成报告写到 NOTES.md 里。approval字段很关键，never表示完全不用人工确认，适合低风险任务；onWrite表示只有写文件时才要弹窗确认；always则意味着每次执行前都要你点头。

事件触发的实现稍微复杂一点。VS Code 本身有大量事件源，比如文件保存、文件变更、终端命令执行、Debug 会话启动等。Agent Automations 目前优先开放了文件事件和 Git 事件两类。我在配置里用的比较顺手的是“postSave”事件——保存文件后自动格式化并补全测试骨架。

这里有一个容易忽略的点：调度器不是常驻系统服务，而是在 VS Code 进程活着的时候才有效。如果你关了编辑器，定时任务不会在后台偷偷执行，这既是限制也是安全设计。想要真正离开编辑器也能跑，得配合 GitHub Actions 或者本地 cron 拉起code --command来实现，后面实操部分会讲。

2.2 权限模型与安全边界

把自动化任务交给 AI 执行，最让人不放心的就是“它会不会把仓库改坏”。幸好 1.137 在这个问题上没有含糊，延续了 VS Code 的 Workspace Trust 体系，又在它之上加了 Agent 专属授权层。

我拿实际场景解释一下。假设你配了一个“保存后自动修复 import 顺序”的任务，Agent 要执行的操作分三类：

• 读取类操作：读文件、搜索符号、查看 Git 状态，这些默认放行，不需要权限。
• 写入类操作：修改文件内容、创建新文件，必须匹配你授权的路径范围。
• 命令类操作：在终端里执行命令，这类风险最高，默认全部拦截，除非你在配置里显式声明允许哪些命令。

这三类权限在配置里清晰分开。我推荐大家刚开始做实验的时候，把命令类操作权限保持默认的“询问”状态，你可以在弹窗里观察 Agent 到底想执行什么命令，逐渐摸清它的行为模式再放宽限制。实际遇到的情况是，Agent 有时候会自作主张运行npm install来“修复”依赖问题，这种操作如果没有设置allowedCommands，会被直接拦下来。

2.3 我最看好的三个落地场景

配置过几十个自动化任务之后，我发现真正值得用的不是那些花哨的功能，而是日常重复性高、规则明确的场景。这里列三个我目前已经在用的：

第一个是“每日 issue 扫描和归类”。在多人协作仓库里，AGENTS 机器人或者 Copilot 生成的 issue 经常散落各处。我配置了一个定时任务，每天早上把@agent标记的 issue、评论、以及代码里的TODO(agent)注释汇总到一个文件里，团队早会直接看这个文件就能同步进度。

第二个是“分支合并前的自动清理”。因为 Agent 有能力读取 diff 和检查文件列表，我让它在我创建 pull request 之前自动做三件事：确认没有调试残留（比如console.log、debugger）、检查锁文件是否更新、在 CHANGELOG 里追加本次改动描述。这些在过去靠 pre-commit hook 也能实现，但写 hook 的成本和维护成本明显更高，用自然语言描述给 Agent 效率反而更高。

第三个是“依赖安全提醒”。这个不是安全扫描器，而是智能筛选器。系统会执行npm audit这类命令，但真正的问题是输出信息噪音太大。Agent 可以读取 audit 结果之后，自动判断哪些漏洞影响到了当前项目的调用链，然后只把真正要紧的报给你。这个能力已经超出简单的定时任务范畴了，靠的是 Agent 对项目代码的理解。

3. 实操：三步跑通你自己的第一个 Automations

理论说太多容易飘，下面直接上手。我按从零到一的顺序写，你照着操作就行。

3.1 升级到 1.137 并开启预览功能

第一步，确认版本号。打开 VS Code，在“帮助”菜单里选“检查更新”，升级到 1.137 或更高版本。注意 Automations 目前是预览功能，默认关闭，你要打开设置面板搜索agent.automations.enabled，手动开启。

还有一个前提条件：你的 GitHub Copilot 订阅要包含 Agent 模式访问权。目前这个能力并不是所有 Copilot 套餐都默认包含，如果你用的是个人免费额度或者旧版 Business 方案，可能看不到 Automations 配置入口。我在测试时发现登录状态也会影响功能可见性，建议先重启一次 VS Code 再检查设置项，有时候改了配置不重启，扩展宿主不会重新加载。

配置完成后，左侧活动栏应该会多出一个“Automations”图标，或者在你打开 Copilot Chat 面板时多出一个“Automations”标签页。如果你找不到这两个入口，打开命令面板（Ctrl+Shift+P 或 Cmd+Shift+P），输入“Automations: Open Dashboard”手动打开。

3.2 写一个最小可用的自动化任务

我建议第一个任务别整太复杂的，以“每天下午 6 点自动整理当天改过的文件列表”练手最合适。因为只读不写，即便配置出错也不会损坏文件。

在项目根目录下创建.vscode/automations.json，内容如下：

{ "version": 1, "automations": [ { "name": "傍晚工作日志", "trigger": { "type": "schedule", "cron": "0 18 * * *" }, "instruction": "列出今天修改过的所有源文件，按目录分组，用简洁的摘要写进 LOG.md。只读操作，不要修改其他文件。", "target": "workspace", "approval": "onWrite", "permissions": { "write": ["LOG.md"] } } ] }

保存文件后，VS Code 会自动识别并显示在 Automations 面板里。你可以点右边的“Run now”按钮测试一次，不用等到下午 6 点。执行过程中，面板会显示 Agent 的思维链和调用记录，第一次跑的时候别急着关，观察它到底读了多少文件、在哪一步被卡住。

这里有三个参数值得我说一下：

• cron: 标准五段式表达式，依次表示分、时、日、月、星期。0 18 * * *是每天 18:00。
• approval: 我设置在onWrite，也就是写文件前需要确认，防止 Agent 脑抽把 LOG.md 写到别的目录。
• permissions.write: 限制 Agent 的写权限只在 LOG.md 一个文件上。项目里如果还有 Agent 生成的临时文件，应该在write数组里明确列出来。

3.3 把 Automations 和 Git 事件结合起来

定时任务只是开始，事件触发才是 Automations 的进阶玩法。我用一个实际项目中的例子：每次git push成功后自动更新版本号描述文件。

在.vscode/automations.json里增加第二个任务：

{ "name": "push 后更新版本描述", "trigger": { "type": "event", "event": "postPush" }, "instruction": "对比最近两次提交的差异，提取新增功能和修复内容，用中文重写 CHANGELOG.md 的本节内容，保持原有格式。", "target": "workspace", "approval": "always", "permissions": { "write": ["CHANGELOG.md"] } }

事件类型postPush执行时机是 git push 成功之后。这里有个基本逻辑需要留意：任务是在 VS Code 进程里执行的，如果你用命令行工具git push而 VS Code 没有检测到这个操作，任务可能不会触发。所以用这个功能时，我建议在 VS Code 内置终端里完成 push 操作，触发成功率会高很多。

事件触发任务的approval我建议设成always。这不是因为我多疑，而是因为事件触发往往发生在你意想不到的时刻，比如开完会回来发现 Agent 已经把 CHANGELOG 改成了一堆垃圾描述。设为always可以让你在合并这些改动之前亲眼确认一遍。

3.4 结合热词里的真实需求补充一下

搜“vs code 配置 c++环境”和“vs code flutter android 项目报错:unable to find suitable visual studio toolc”这类词的朋友，应该都经历过在 VS Code 里调工具链的痛苦。Automations 在这类场景里能帮上忙吗？我的看法是，能帮一部分，但别指望它自动修好所有环境问题。

比如 C++ 环境配置，VS Code 的 C/C++ 扩展本身已经能通过c_cpp_properties.json配置编译器路径和头文件路径。我在一个新项目里配 Automations 的时候，会让 Agent 读取当前工作区的compile_commands.json，自动检查 tasks.json 里的编译命令是否和它匹配。这种检查任务耗时很短，定时跑完全没问题。

至于 flutter android 项目报错 “unable to find suitable visual studio toolc”，这实际上是 Windows 上缺 C++ 工具链的典型错误。Agent 能帮你判断缺少的是 MSVC 还是 Build Tools，然后给你命令去安装。但它不能直接替你完成图形化的 Visual Studio Installer 操作，因为那超出了 VS Code 进程的能力边界。所以这类问题上，Automations 适合做“诊断报告生成”，不适合做“一键修复”。

4. 常见问题与排查技巧实录

预览版嘛，各种小毛病肯定少不了。这一节我把我自己遇到的和社区里高频出现的问题整理成表格，方便你排查。

4.1 预览版功能入口消失或没效果

我遇到最多的情况是开启agent.automations.enabled之后，界面上没有出现 Automations 面板。排查步骤是：先确认版本号是否真的到了 1.137（有些自动更新策略会延迟），然后在命令面板里输入 “Automations: Reload” 强制重载，最后检查 Copilot 登录状态是不是过期了。

如果你用的是公司的代理网络，还要注意扩展宿主是否被防火墙挡了。Automations 面板加载失败时，控制台通常会报类似 “WebSocket connection failed” 的日志，这个提示通常和网络策略有关。

4.2 定时任务没有按预期触发

定时任务不触发，十有八九是 cron 表达式写错了。比如你以为0 9 * * 1是“每周一早上 9 点”，实际上星期字段的取值是 0-6，1 确实代表周一，这么写没问题。容易错的是把* * * * *直接抄过来当测试，结果任务每秒都在后台跑，把扩展宿主卡到崩溃。

我踩过的一个坑是笔记本休眠导致的漏执行。VS Code 在系统休眠期间醒不来，等恢复后调度器会补执行一次错过的任务吗？实测结果是：大部分情况下不会补执行。如果你的自动化任务是那种必须当天完成的（比如日报生成），建议在触发器里显式加一个"catchUp": true，这样恢复后会补齐漏掉的任务。

4.3 权限弹窗过多或者 Agent 操作被误拦

approval设为always之后，每个任务执行前都会弹窗，如果你一上午要跑十几个小任务，确实影响心情。我的建议是分阶段放开权限：

权限被误拦这件事也常发生。比如 Agent 要读取某个 node_modules 里的配置文件，被 Workspace Trust 判定为可疑操作然后拦截。这时候不要直接关掉信任校验，更好的做法是精确授权：

"permissions": { "read": ["src/**", "package.json", "pnpm-lock.yaml"], "write": ["CHANGELOG.md"], "commands": ["npm run build"] }

路径支持 glob 通配符，你把需要访问的目录写清楚，Agent 就不用每次都被拦。这里切记不要把read设成**，否则 Agent 会尝试读取.env之类包含密钥的文件，虽然它不会主动打印密钥，但一旦日志泄露风险也大。

4.4 性能问题和内存占用

Agent 跑自动化任务时，会加载工作区索引和模型上下文，内存占用比普通编辑会话高很多。我在一个庞大的 monorepo 里跑定时扫描任务时，VS Code 进程内存飙到 2GB+。后来做了两个优化：

第一，把target从workspace改成具体子目录，比如packages/core/src，减少索引范围。第二，在任务 instruction 里明确限制文件遍历深度，例如写“只读取 src 目录下的 *.ts 文件，忽略 node_modules 和 dist”。

如果发现扩展宿主一直占用 CPU，多半是 Agent 在后台反复重试某个失败操作。打开输出面板看 Agent 日志，找到最后重试的是哪个操作，针对性地把对应的命令权限加上，或者把任务的触发时间隔拉长，基本能解决。

5. 热词背后：为什么大家盯着 Agent 接入不放

最近搜 VS Code 相关技术帖，满屏都是“vs code codex 如何接入 deepseek”“vs code 安装 claude code”“vs code 外接 codex api”这类问题。我觉得这波热度不单是追新，背后其实是几个真实的开发痛点。

5.1 多模型接入的真实需求

很多开发者手上有不止一个 AI 编程账号。Claude Code 在代码理解和长上下文表现上更符合一部分人胃口，Codex 在终端工具调用上更激进，DeepSeek 在中文场景和成本上有优势。问题是这些工具大多是独立 CLI 或插件，切来切去非常麻烦。

VS Code 的 Agent Automations 设计上把模型执行层抽象掉了，理论上支持按任务粒度指定模型。比如我可以让“日常重构”任务用默认 Copilot 模型，让“生成测试用例”任务走自定义的本地模型端点。这个能力对多模型切换用户来说很有价值，因为不用再为了某个模型单独装一套插件和配置。

但我要泼一点冷水：目前 1.137 的模型扩展接口还没完全开放给第三方，Automations 默认绑定的还是 Copilot 模型。如果你在自定义配置里强行改 endpoint，大概率会收到“model not supported”的错误。想体验多模型，建议关注后续版本对 OpenAI-compatible API 的支持程度，GitHub 官方最近连续几个版本都在做模型兼容层，这方向是明确的，但别急着在生产环境依赖它。

5.2 和外部 Agent 工具的分工

那 Agent Automations 出来后，像 Claude Code 这类外部工具是不是就没用了？我的实际体会是，两者定位不同。外部 Agent 适合那种“临时拉起来跑一次大任务”的场景，比如“给我重构这个模块，并把所有调用点都改掉”，这种任务复杂度高、持续时间长，放在独立 CLI 里执行体验更好。Automations 适合“固定时间、固定规则、长期重复”的场景，比如每天扫描、每次提交前格式化、每周统计仓库健康度。

这两种工具可以配合使用。我现在的工作流是：Automations 负责周期性和事件驱动的例行公事，Claude Code 负责需要深度推理的一次性大改。两边的配置互不干扰，Automations 执行完任务后写出的文件，如果我看着不满意，随时丢给 Claude Code 再做一次 review。

5.3 我对 Automations 后续演进的几个判断

第一，任务定义文件会越来越像 CI 配置。目前automations.json还不够成熟，字段命名和语义理解成本偏高。等后面的版本稳定了，应该会出现类似 GitHub Actions 那样的 marketplace，直接拉一个现成的自动化任务模板过来用，改一改参数就能适配自己的项目。甚至社区很可能会把这个配置文件变成可分享的链接，点一下就能导入。

第二，事件触发类型会大幅扩充。现在主要是文件事件和 Git 事件，以后大概率支持终端事件、调试事件、甚至是 Copilot 对话本身作为触发源。比如，当你和 Copilot 讨论完一个 issue 后，Automations 自动生成一个“尝试修复”的任务，这在设计上是很自然的一步。

第三，执行环境不一定局限在本地。长期看，VS Code 官方大概率会提供云端执行后端，让自动化任务在 CI 环境或者专用的 runner 上执行。那样的话，“VS Code 关了任务就不跑了”这个限制就能被打破，Automations 才真正具备生产级定时任务的可靠性。

6. 几个实测后的小建议

最后聊点使用体会吧。我折腾 Agent Automations 这一周，最大的感受是：它强不强，很大程度上取决于你给它设定的边界。如果你肯花半小时把任务定义文件写清楚，把权限范围卡好，它真的能变成帮你省大量时间的队友；如果你只是随手配了个“每天扫描仓库”又没限定范围，它跑起来会比你想象中更啰嗦——一会儿改这个、一会儿问那个，最后你还得一个个检查它改了什么，反而更累。

我的建议是分阶段引入。先在个人项目或者不重要的 side project 上配一两个只读任务，跑几天观察日志，慢慢加写操作和命令操作，等完全摸清了行为模式再上团队项目。automations.json是跟着仓库走的，如果你一上来就在共享工程里放一个权限很宽的任务，影响的是整个团队所有使用者的开发环境，那时候再改就麻烦了。

另外一定记得，Automations 是预览功能，API 和行为都可能在下个版本调整。别把太核心的流程寄托在它上面，同时留意 GitHub 官方 release notes，每次版本更新都要重新看一遍自己配过的任务是否还正常触发。我就在一次自动更新后发现定时任务全部静默失效了，查了半天才发现是配置格式升级导致旧字段被废弃。养成了“升级后立刻手动 Run 一次所有任务”的习惯，能帮你少踩很多这种暗坑。

这个功能我是真心推荐你抽一个下午时间试试。不一定要配复杂的自动化，哪怕就让它每天帮你整理一下 TODO 列表，也能直观感受到“Agent 自己跑任务”和“你叫 Agent 跑任务”之间的体验差异。等到你适应了这种工作方式，你可能就再也回不去手动打开 Chat 面板一条条发指令的日子了。