先说句实在话等这个 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 补全然后是对话式 CopilotCopilot 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”标签页。如果你找不到这两个入口打开命令面板CtrlShiftP 或 CmdShiftP输入“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-61 确实代表周一这么写没问题。容易错的是把* * * * *直接抄过来当测试结果任务每秒都在后台跑把扩展宿主卡到崩溃。我踩过的一个坑是笔记本休眠导致的漏执行。VS Code 在系统休眠期间醒不来等恢复后调度器会补执行一次错过的任务吗实测结果是大部分情况下不会补执行。如果你的自动化任务是那种必须当天完成的比如日报生成建议在触发器里显式加一个catchUp: true这样恢复后会补齐漏掉的任务。4.3 权限弹窗过多或者 Agent 操作被误拦approval设为always之后每个任务执行前都会弹窗如果你一上午要跑十几个小任务确实影响心情。我的建议是分阶段放开权限阶段approval 设置适用场景实验期always第一次跑观察 Agent 行为稳定期onWrite只读为主偶尔写固定文件信任期never任务结果可验证、写权限严格受限权限被误拦这件事也常发生。比如 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 面板一条条发指令的日子了。
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 补全然后是对话式 CopilotCopilot 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”标签页。如果你找不到这两个入口打开命令面板CtrlShiftP 或 CmdShiftP输入“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-61 确实代表周一这么写没问题。容易错的是把* * * * *直接抄过来当测试结果任务每秒都在后台跑把扩展宿主卡到崩溃。我踩过的一个坑是笔记本休眠导致的漏执行。VS Code 在系统休眠期间醒不来等恢复后调度器会补执行一次错过的任务吗实测结果是大部分情况下不会补执行。如果你的自动化任务是那种必须当天完成的比如日报生成建议在触发器里显式加一个catchUp: true这样恢复后会补齐漏掉的任务。4.3 权限弹窗过多或者 Agent 操作被误拦approval设为always之后每个任务执行前都会弹窗如果你一上午要跑十几个小任务确实影响心情。我的建议是分阶段放开权限阶段approval 设置适用场景实验期always第一次跑观察 Agent 行为稳定期onWrite只读为主偶尔写固定文件信任期never任务结果可验证、写权限严格受限权限被误拦这件事也常发生。比如 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 面板一条条发指令的日子了。