VS Code让AI智能体定时干活

VS Code 1.137 上线：AI 智能体开始按时“上班”

微软于 9 月 10 日发布 Visual Studio Code 1.137，最值得关注的变化是预览版 Automations：开发者现在可以让 AI 智能体按小时、每日或每周自动执行任务，而不必每次都手动打开聊天窗口、重新输入提示词。

**Automations 是 VS Code 内置的智能体任务调度功能，用于按照预设提示词和时间计划，重复运行代码分析、仓库检查及项目维护任务。**它支持 Manual、Hourly、Daily 和 Weekly 四种调度方式，适合追踪代码变更、分类 Issue、查找潜在 Bug、生成项目摘要等周期性工作。

这次更新的重要性不在于“又多了一个定时器”，而在于 VS Code 正在改变 AI 编程助手的工作方式：过去的 Copilot 更像坐在副驾驶位置上的即时助手，只有开发者提出问题时才开始工作；Automations 则试图让智能体在固定时间主动检查项目，并持续产出结果。

Automations 支持四种调度方式

**VS Code 1.137 的自动化任务可以手动运行，也可以按照小时、日期或星期循环执行。**其中，每日和每周计划按照用户设备的本地时区运行，开发者可以指定执行时间；每周计划还可以指定星期几。

| 调度方式 | 执行规则 | 典型使用场景 | |---|---|---| | Manual | 仅在用户选择“Run now”时执行 | 调试提示词、临时审查代码 | | Hourly | 每小时运行一次 | 追踪高频提交、检查持续变化的分支 | | Daily | 每天在指定时间运行 | 生成日报、汇总仓库变化、扫描待办事项 | | Weekly | 每周在指定日期和时间运行 | 周度技术债检查、依赖审查、项目状态总结 |

用户需要在 Agents 窗口中启用 chat.automations.enabled 设置，随后从侧边栏进入 Automations。微软提供了追踪变更、分类 Issue 和查找 Bug 等模板，用户也可以自行填写任务名称、提示词、执行范围、预期输出和调度计划。

**Automations 目前仍处于预览阶段，并且正在分批推送。**该功能在 VS Code Stable 稳定版中默认关闭，在 Insiders 版本中默认开启；即使升级到 1.137，不同用户看到功能的时间也可能不同。如果侧边栏没有出现 Automations，首先需要确认相关设置是否已经启用。

一个更实际的使用方式，是先以 Manual 模式检查首次运行结果，确认智能体读取了正确的项目、没有修改不该修改的文件，再切换到 Hourly、Daily 或 Weekly。微软官方文档同样建议先检查第一次执行，再编辑自动化任务并启用计划。

它不是简单的 cron，也还不能替代 CI

**Automations 与传统 cron 定时任务的区别，是开发者描述“目标”，智能体自行决定完成目标所需的步骤。**传统脚本要求人提前写清每一条命令，例如拉取日志、筛选错误、拼接报告；智能体自动化则可以接收“总结过去一天的仓库变化，并指出可能影响兼容性的修改”这类自然语言任务，再结合工作区文件、Git 信息和可用工具完成分析。

这种差异让 Automations 更适合处理边界模糊、输入持续变化的工作。例如，“每天检查新提交中是否出现缺少测试的公共接口变更”很难只靠一条固定命令解决，因为智能体需要理解代码结构、提交差异和测试覆盖关系。对中大型项目而言，这类任务往往正是代码审查中最耗时间、又最容易被忽略的部分。

但 Automations 现阶段也不应被视为 GitHub Actions、Jenkins 或其他 CI/CD 系统的替代品。CI 的优势是执行环境可复现、规则确定、失败条件清晰，并且能够在无人值守的服务器上持续运行；VS Code Automations 的核心仍是本地 Agents 工作流，需要可用的智能体和相应运行环境。

换句话说，CI 负责回答“构建是否通过、测试是否成功”，Automations 更适合回答“这些变化意味着什么、哪里值得人重点检查”。前者是确定性流水线，后者是带有推理能力、但输出可能波动的智能分析任务。

| 能力 | VS Code Automations | 传统 cron | CI/CD 流水线 | |---|---|---|---| | 任务描述方式 | 自然语言提示词 | 固定脚本或命令 | 配置文件、脚本及工作流 | | 是否具备代码语义理解 | 是，取决于所选智能体与上下文 | 通常不具备 | 通常依赖外部扫描工具 | | 调度粒度 | 手动、每小时、每日、每周 | 通常可细化到分钟 | 事件触发或定时触发 | | 输出确定性 | 较低，同一任务可能产生不同表达 | 高 | 高 | | 适合自动部署 | 现阶段不建议 | 可以，但风险较高 | 最适合 | | 适合生成仓库摘要 | 适合 | 需要自行编写完整逻辑 | 需要接入额外工具 | | 运行定位 | 编辑器内的智能体工作流 | 操作系统任务调度 | 服务器或云端流水线 |

**Automations 当前最大的价值，是把智能体放到 CI 之前或之后，而不是把 CI 替换掉。**它可以在提交进入正式流水线前发现疑点，也可以在测试完成后解释失败原因、整理变更摘要。真正决定构建能否合并和发布的硬门槛，仍应该由测试、类型检查、静态分析和权限规则控制。

定时智能体有用，但权限边界必须收紧

**定时执行意味着 AI 智能体可以在开发者没有实时盯着屏幕时读取文件、运行工具并产生修改，因此权限控制比普通聊天更重要。**一条看似无害的“查找并修复 Bug”提示词，实际执行范围可能非常宽：智能体可能编辑多个文件、运行测试、更新依赖，甚至尝试清理它认为无用的内容。

团队在启用自动化任务时，至少应该遵循三条原则：

1. **优先只读，再逐步开放写入。**仓库摘要、变更追踪和 Issue 分类适合先行试用，自动修改生产代码则应该更谨慎。
2. **限定项目和输出范围。**提示词中应明确允许访问的目录、需要忽略的文件，以及结果应写入报告还是直接修改代码。
3. **保留人工审查和确定性验证。**智能体生成的补丁必须经过差异审查、自动测试和静态检查，不能因为任务是定时执行就默认可信。

对于多人团队，另一个问题是成本和噪声。一个每小时运行的任务每天最多触发 24 次；如果 10 个仓库分别配置 3 个小时级任务，一天理论上会产生 720 次执行。即使单次任务并不昂贵，重复读取大型代码库、生成相似摘要，也可能带来不必要的模型消耗和大量低价值通知。

因此，Hourly 更适合变化频繁、需要快速反馈的活跃仓库；技术债总结、依赖审查和文档一致性检查通常采用 Daily 或 Weekly 就足够。调度频率越高不代表自动化效果越好，任务是否有明确增量输入，才是判断频率的关键。

Voice Mode 允许开发者随时打断智能体

**Voice Mode 是 VS Code 1.137 中处于实验阶段的语音智能体交互模式，允许开发者通过语音下达任务、追问状态，并在智能体运行过程中打断或重定向。**用户启用 agents.voice.enabled 后，可以点击聊天输入框中的 Voice Mode 按钮开始使用。

这一功能与普通的语音转文字并不完全相同。Voice Mode 能够感知当前会话状态，回答正在运行的任务、所选模型和已附加文件等问题；当智能体走错方向时，用户还可以通过按键通话方式中断响应，直接补充新的限制条件。

语音模式真正有价值的场景，不是用嘴巴代替键盘写一长段需求，而是在智能体执行长任务时进行低成本干预。例如，智能体正在重构认证模块，开发者可以直接补充“不要修改公共接口”“先保留旧版兼容层”，不用等待整项任务结束后再回滚大量修改。

不过，语音交互仍然存在术语识别、文件名歧义和环境噪声问题。对于数据库迁移、权限规则、依赖版本等要求精确的任务，最终约束最好仍以文字形式确认。企业管理员也可以通过关闭 Copilot 预览功能来禁用这项实验能力。

快速聊天终于可以中途接入工作区

**快速聊天转工作区功能允许用户先进行不绑定项目的讨论，再在需要代码上下文时附加本地文件夹，并保留原有对话继续执行。**转换完成后，聊天标题、历史消息和当前请求都会保留，智能体在工作区准备完成后继续访问项目文件。

这个改动解决了 AI 编程产品中一个常见的上下文断层。过去，开发者可能先问“这个缓存策略是否合理”，讨论到具体实现时才发现需要让模型读取项目；如果重新打开工作区聊天，往往还要复述背景。现在，用户可以从通用讨论自然过渡到具体项目，不必重建会话上下文。

该功能目前仅适用于 Copilot 框架，意味着它还不是所有 VS Code 智能体扩展都能直接复用的通用能力。对微软而言，这也体现出 VS Code 的策略：一边开放 AI 扩展接口，一边让 Copilot 在 Agents 窗口、工作区上下文和任务编排层占据更深的位置。

Agents 窗口直接查看 GitHub Issue 和 PR

**VS Code 1.137 的 GitHub 集成允许开发者在 Agents 窗口内查看 Issue 和 Pull Request 详情，即使当前没有打开对应仓库。**用户需要在默认配置文件中安装 GitHub Pull Requests 扩展，并开启对应的实验能力。

这一变化让“处理 GitHub 问题”从网页跳转变成智能体上下文的一部分。开发者可以先查看 Issue 描述、讨论和关联信息，再让智能体寻找相关代码；处理 PR 时，也可以围绕变更内容继续追问，而不必频繁切换浏览器、编辑器和聊天窗口。

它对维护多个开源项目或跨仓库组件的开发者尤其有用。Agents 窗口本身面向跨项目智能体会话，不要求每个任务都先打开一个完整工作区；GitHub Issue 与 PR 接入之后，它更像一个面向代码任务的统一收件箱。

宠物互动是彩蛋，Automations 才是主线

**VS Code 1.137 还加入了宠物互动及征名相关内容，但这更接近社区彩蛋，而不是本次更新的生产力核心。**真正值得开发团队评估的是 Automations、Voice Mode、工作区转换和 GitHub 集成，因为这四项能力共同指向同一个方向：VS Code 正从“带 AI 的代码编辑器”转向“管理多个智能体任务的工作台”。

微软近年来不断把智能体能力下沉到编辑器内部，包括跨文件修改、运行命令、读取编译错误、调用集成浏览器以及处理 GitHub 任务。Automations 补上的一块拼图是时间维度——智能体不再只由一次点击触发，也可以成为周期性的软件维护流程。

这次更新最值得关注的，不是定时，而是持续委派

**VS Code 1.137 首次让普通开发者能够在编辑器里低门槛配置周期性智能体任务，这比单纯提升补全速度更可能改变日常开发流程。**代码补全优化的是“写一行代码需要多久”，而定时智能体优化的是“哪些事情根本不必由人反复做”。

短期看，Automations 最适合低风险、可审查、重复度高的任务，包括每日变更摘要、Issue 初步分类、Bug 线索搜索、文档与代码一致性检查。对于自动重构、依赖升级和生产配置修改，开发者仍应设置严格边界，并把最终决策留给人工和确定性流水线。

从产品竞争角度看，微软的优势不是单次智能体能力一定强于所有 AI IDE，而是 VS Code 已经拥有成熟的扩展生态、GitHub 工作流和庞大用户基础。把调度能力直接放进 Agents 窗口，可以让自动化任务连接本地项目、编辑器诊断、扩展工具和 GitHub 上下文，这种整合深度比单独增加一个聊天按钮更难复制。

Automations 目前仍是预览功能，调度粒度也只有小时、每日和每周，距离复杂的条件触发、团队级集中管理、云端常驻执行还有明显距离。但方向已经很清楚：AI 编程工具的下一轮竞争，不再只是“谁回答得更好”，而是“谁能在正确的时间、拿到正确的上下文，并在可控权限内持续把事情做完”。

参考来源

• IT之家：微软 VS Code 1.137 发布，为宠物征名、按小时/日/周调度 AI 智能体任务：介绍 VS Code 1.137 的 Automations、Voice Mode、GitHub 集成及宠物互动等主要更新。