GitHub Copilot 上线 Dynamic Workflows：把多智能体流程写成代码

发生了什么

10 月 1 日的 GitHub Changelog 带来一个值得细品的新能力：Dynamic Workflows（动态工作流），同时登陆 Copilot CLI、Copilot app 和 Copilot SDK，进入 public preview。它允许你把一个多智能体协作过程写成代码，让 Copilot 每次都按完全相同的步骤执行，而不是每次都从零开始重新提示一个 agent。

官方给的例子是故障排查：工作流先拉日志和监控数据，把不同系统分给几个独立的 agent 并行分析，再把它们的结构化结论合并成时间线和根因报告。同样的步骤，每次故障都跑同一套——而不是每次都来一场即兴调查。

它到底是什么：程序，不是提示词

Dynamic workflow 本质上是一个程序，定义"任务如何被完成"。它把自动化步骤和一个或多个 agent 的工作混在一起：哪些步骤串行、哪些并行、什么时候让 agent 上场、结果怎么用——全部写在代码里，agent 只负责需要分析与判断的部分。

技术上，它住在一个 GitHub Copilot extension 里面，因此天然拥有 extension 的全部扩展 API。它能做的事情包括：跑命令、调工具、调外部服务；把目标拆成任务并行执行；在阶段之间传递结构化结果；让 subagent 互相校验对方的结论；在客户端支持的情况下向人要输入；在检查点暂停，等人看完结果再手动恢复。

GitHub 特意把它和已有的 /fleet 命令划清界限：/fleet 是 Copilot 自己临场决定如何拆分、协调 subagent；dynamic workflow 跑的是开发者（或者被提示过的 Copilot）提前写死在代码里的流程。一个是"临场发挥"，一个是"照本宣科"——两者互补，不互相取代。

官方推荐的使用场景

Changelog 里列了一批"好候选"：跑发布检查，让一个 agent 评估失败，然后暂停等人 review 结论再继续；并行 review 一个 PR 里的大量变更文件；用代码找出已合并 PR 上未解决的评论，再让两个模型判断这些评论是否还成立——只有两者一致才上报；对大代码库做模式横扫（缺测试、要删的 API 用法）；研究→规划→实施的一条龙；以及启动一次又长又贵、可能想中途暂停的任务。

注意官方的另一句提醒：简单问题、简单改动，普通聊天模式就够了。Dynamic workflow 是给"可复用的流程"和"需要明确阶段、检查点、限制"的任务准备的——杀鸡别用牛刀。

上手门槛被刻意压低了：你可以自己写，也可以让 Copilot 帮你写——就像 extension 一样，Copilot 内置了 authoring guidance，能教你，也能直接替你生成一个完整的工作流。CLI 侧需要开 experimental（--experimental 或 /experimental on），app 侧开箱即用，所有 Copilot 套餐都可用。

为什么这事比看起来大

先说趋势：这是"流程即代码"正式进入 AI agent 世界。过去一年，agent 的能力曲线是"越来越能干"；现在的曲线是"越来越可重复"。当 agent 开始承担生产流程（发布检查、事故响应、代码审查），"每次临场发挥"就从优点变成了风险——同样的输入应该得到同样的过程。Dynamic workflow 把"怎么做"从 prompt 里抽出来，变成可版本管理、可 review、可测试的代码，这是工程化的必经之路。

再说对 vibe coder 的直接价值：你那些反复用的"咒语清单"，现在有了更好的归宿。每次上线前都要让 agent 查一遍的事项、每次重构前都要跑的分析套路、每周一次的依赖健康检查——以前它们是收藏夹里的 prompt，现在可以变成一个 workflow：固定步骤、并行加速、中间结果结构化、关键节点停下来等你点头。vibe coding 的瓶颈正在从"agent 会不会做"变成"流程靠不靠谱"，而这正是 dynamic workflow 要解决的问题。

还有一个细节值得玩味：GitHub 让 workflow 住在 extension 里。这意味着你的工作流自动继承了 Copilot 的生态——MCP 工具、私有数据源、企业策略，全部可用。它不是又一个孤岛，而是一块拼进现有版图的砖。

冷静的部分：public preview，官方明说"可能变化"。现在就把核心生产流程全押上去还太早，但拿一条非关键流程（比如每周依赖扫描）先试点，成本很低，收益是提前摸清这套范式。等它 GA 的那天，你已经是会写 workflow 的人了。