VS Code 1.137 带来了一项很容易被低估的能力：Agent Automations 进入 Public Preview。开发者可以把一个带有 Prompt、工作区、模型和权限配置的 Agent 任务保存下来，手动运行，也可以按小时、每天或每周自动运行。
它适合处理“重复但需要判断”的工作，例如汇总最近的代码变化、整理 Issue、寻找潜在缺陷或检查文档。关键变化不是多了一个定时器，而是定时器会再次启动一个拥有文件读取、命令执行甚至修改权限的 Agent 会话。只要任务进入无人值守状态，Prompt 质量就不再是唯一问题，工作区、权限、运行主机、幂等性和用量预算都需要一起设计。
Agent Automations 具体能做什么
VS Code 官方更新说明把 Automations 定义为重复运行的 Agent 任务。打开 Agents window 后，侧边栏会出现 Automations 入口；可以从模板开始，也可以自己填写任务名称、Prompt 和调度计划。
目前的调度方式包括：
| 调度方式 | 适合的工作 |
|---|---|
| Manual | 先验证 Prompt 和首次运行结果 |
| Hourly | 需要较短反馈周期的仓库巡检或状态汇总 |
| Daily | 每日变更摘要、Issue 初筛、文档检查 |
| Weekly | 周报、依赖观察、长期问题盘点 |
| On demand | 不改变计划，临时手动触发一次 |
这项功能仍在 Preview，并且会逐步向用户开放。需要先启用 chat.automations.enabled 设置，然后在 Agents window 中进入 Automations。预览状态意味着设置入口、运行行为和可用 Agent 可能继续变化，不适合在没有回滚方案的情况下作为关键生产流程的唯一依赖。
它不是普通的 Cron
传统 Cron 通常只负责在某个时间启动脚本，脚本的权限和执行环境由服务器固定提供。Agent Automation 的配置对象更丰富：它会保存 Prompt、目标工作区、所选 Agent、模型和 Session configuration，还可能包含权限选项和 Git worktree 设置。
一次运行大致可以看成下面这条链路：
1 | 调度时间到达 |
VS Code 文档明确提醒，Automation 可以按照所选 Agent 的权限读取文件、运行命令和进行修改。保存 Automation 不会绕过组织策略，也不能保证未来每次运行都不需要审批。换句话说，调度计划只是“何时启动”，不是“自动获得一切权限”。
运行环境决定它会不会真的按时执行
本地 Automation 有一个与云端定时任务不同的前提：运行它的机器和 Agent 必须可用。官方文档说明，Agent Host-backed 的计划需要 Agent Host 进程保持运行；其他计划则需要 VS Code 窗口保持运行。关闭应用或让机器睡眠后，不能假设任务仍会像服务器上的 Cron 一样正常执行。
另外还有几个容易被忽略的调度行为：
- 每日和每周计划使用本地时区；
- 中断后，错过的计划可能触发一次 catch-up，但不保证每次错过的执行都被补回；
- 同一个 Automation 一次只运行一个会话，不会因为计划重叠而并行启动多个相同任务；
- 每次执行都会消耗所选 Agent 和模型对应的使用额度。
因此，开发团队在设计计划时要先回答两个问题：这台机器是否真的会在目标时间在线，以及漏跑一次任务会不会影响业务。如果任务具有生产影响，就应该准备一个有稳定运行时的替代方案，而不是把本地 VS Code 当成高可用调度器。
第一次不要直接设置成每天运行
官方文档建议先把 Schedule 设为 Manual，检查首次运行结果后，再改成 Hourly、Daily 或 Weekly。这个顺序非常重要，因为 Agent 的错误往往不是“任务没启动”，而是任务启动后理解错范围、调用了不合适的命令，或者生成了没人会消费的输出。
可以先用一个只读、范围明确的任务做验证：
1 | 汇总当前仓库最近 24 小时的提交和 Pull Request。 |
首次运行重点检查四件事：
- Agent 是否打开了预期的工作区。
- 读取范围是否超出了任务需要。
- 输出是否带有可核对的提交、Issue 或文件引用。
- 任务失败、无数据和权限不足时，结果是否清楚表达了状态。
只有当这四点都稳定后，才适合加入周期计划。
Prompt 要写成可重复执行的任务
一次性对话可以依赖上下文，定时 Automation 则不能假设上一次会话的记忆还在。Prompt 最好明确写出输入范围、输出格式、禁止操作和失败处理。
1 | 任务：生成过去 24 小时的仓库变更摘要。 |
其中“重复运行”尤其重要。周期任务可能因为手动触发、catch-up 或重复计划而多次运行。输出文件应使用稳定的日期键或写入独立目录，避免每次执行都追加一份重复内容；如果任务会写文件，最好先读取当前状态，再根据差异决定是否修改。
工作区、权限和隔离怎么选
VS Code Automations 创建表单允许选择目标工作区，也允许选择 No workspace。一个实用的选择规则是：
| 任务类型 | 建议配置 |
|---|---|
| 只做资料汇总或一般问答 | No workspace，或只读工作区 |
| 读取仓库并生成报告 | 指定工作区，限制写入权限 |
| 自动修复代码 | 使用独立 Git worktree，要求测试和人工审查 |
| 需要发布或改动线上资源 | 不要直接交给无人值守 Automation |
如果所选 Agent 支持，Git 工作区可以选择 New Worktree 和基准分支。这样任务产生的修改不会直接落在开发者当前分支上，尤其适合自动修复、批量重构和文档更新。
“有独立 worktree”不代表风险自动消失。Agent 仍可能运行命令、读取环境变量或访问网络，因此要同时收紧权限级别，并检查组织策略和审批规则。对于包含密钥、客户数据或内部配置的仓库，不要因为任务只是“整理 Issue”就默认开放完整文件和网络访问。
适合优先自动化的三类工作
变更摘要和交接信息
每天汇总过去一段时间的提交、Pull Request 和 Issue，输出面向开发者的变更摘要。这类任务结果容易人工核对，失败时也不会直接改变系统状态。
Issue 初筛
让 Agent 按既定标签和模板检查新 Issue，提取复现步骤、影响范围和缺失信息。自动化只负责整理和提出问题，不要在没有人工确认时自动关闭 Issue 或修改优先级。
文档和工程卫生检查
周期检查过期链接、缺失变更记录、重复配置或明显的文档漂移。第一阶段只生成报告，确认误报率后，再考虑让 Agent 在 worktree 中提交修改。
相反，自动发布、删除数据、修改生产配置、轮换凭据和直接合并代码，都不适合一开始交给本地预览功能承担。它们需要更明确的身份、审批、审计和恢复机制。
如何验收一个 Automation
可以用一周的试运行建立最小验收表：
- 计划是否在预期时区触发；
- 机器休眠或 VS Code 关闭后，任务如何表现；
- 运行失败时是否产生明确的错误记录；
- 输出是否重复、遗漏或引用过期信息；
- Agent 是否执行了 Prompt 之外的命令；
- 任务每次运行的模型、时间和使用量是否可追踪；
- 产生代码修改时，是否留在 worktree 而不是当前工作分支。
这些问题比“Prompt 写得像不像人话”更能决定周期任务是否值得长期保留。对于真正重要的任务，还应把结果发送到已有的监控、Issue 或审批流程，而不是只留在某个本地 VS Code 窗口里。
结语
VS Code 1.137 的 Agent Automations 让开发者可以把一些重复的工程工作交给周期运行的 Agent，小时、天、周三种调度粒度覆盖了从频繁巡检到周报整理的常见场景。它最有价值的地方，是把 Prompt、工作区、模型和权限配置放在同一个可重复运行的任务里。
但它仍然是 Preview 功能，也依赖本地运行环境。更重要的是，每次自动运行都可能拥有真实的文件和命令权限。先用 Manual 验证，再使用最小权限、独立 worktree 和明确的输出约束，最后才设置周期计划，才能让 Agent Automations 成为工程流程的一部分，而不是一个会在夜里悄悄改文件的黑盒定时器。