GitHub Copilot 推出动态工作流：用代码编排多智能体任务

动态工作流是什么？一句话说清身份

2026年10月1日，GitHub 开发并发布了 GitHub Copilot 的动态工作流功能。它目前是公开预览的闭源服务，能在 Copilot CLI、GitHub Copilot 应用和 GitHub Copilot SDK 中使用。简单说，它让你用代码写出一套多智能体协作流程，像给机器人小队画一张分工图，让它们按步骤干活、互相检查、还能中途停下来等你确认。

这个功能面向所有 Copilot 计划开放，但官方明确标注为公开预览，意味着功能可能随时调整。它不是一个新的独立产品，而是 GitHub Copilot 这个母产品新增的一项核心能力。

为什么需要它？普通聊天不够用的时候

平时你用 Copilot 聊天，就像问一个聪明的朋友一个问题，他直接给你答案。但如果任务很复杂，比如要同时检查几十个文件、让不同机器人分析不同系统、还要把结果拼成一份报告，普通聊天就容易乱。动态工作流就是为这种复杂任务准备的。

原文举了一个例子：调查服务故障时，你可以让工作流先收集日志和遥测数据，再派多个独立智能体分别分析不同系统，最后把它们的结构化发现合并成时间线和根因报告。每次运行都走同样的步骤，结果更可靠，也更容易观察哪里出了问题。

它和 /fleet 有什么不同？

原文专门对比了 /fleet。在 /fleet 里，Copilot 自己决定怎么把工作分给子智能体，并协调它们并行干活。而动态工作流是你用代码定义好整个流程，Copilot 按你写的程序执行。一个像是让队长自由发挥，一个像是你提前写好剧本让演员照演。

这个区别很重要：当你需要固定流程、明确检查点、或者想让多个智能体互相验证时，动态工作流更合适。如果你只是想要一个快速答案或简单修改，原文建议直接用普通聊天模式就够了。

它能做哪些具体事情？

原文列出了动态工作流的能力：运行命令、使用工具、调用其他服务；把目标拆成任务并并行执行独立任务；把结构化结果从一个阶段传到下一个阶段；让子智能体互相验证发现；在客户端支持时向你请求输入；在检查点暂停，让你审查结果后再继续。

适合的场景包括：发布前检查，让一个智能体评估失败原因，暂停等你确认再继续；并行审查拉取请求中大量改动的文件；用代码找出已合并拉取请求中未解决的评论，再让两个模型判断评论是否仍然重要，只有两者都同意才报告；在大代码库中同时搜索某个模式；研究一个改动、规划实现、然后执行；启动一个可能耗时较长的运行，中途暂停稍后继续。

怎么开始用？操作路径很简单

在 GitHub Copilot 应用中，动态工作流始终可用，无需任何设置。在最新版 Copilot CLI 中，你需要启用实验性功能：运行 CLI 时加上 –experimental 命令行选项，或者在交互会话中使用 /experimental on。更新 Copilot CLI 可以运行 /update。

你可以让 Copilot 为你创建一个常用流程的工作流，也可以问“有哪些动态工作流可用？”来查看已有的工作流。在 Copilot CLI 中可以用 /feedback 分享反馈。原文还提到，Copilot 内置了编写指导，你可以自己写工作流，也可以让 Copilot 完全帮你写。

有哪些限制和需要注意的地方？

首先，动态工作流目前是公开预览，官方明确说“可能会有变化”，所以不要把它当作永久稳定的功能来依赖。其次，它需要写在 GitHub Copilot 扩展里，这意味着你需要对扩展机制有一定了解，或者让 Copilot 帮你生成。

另外，原文没有说明动态工作流的具体定价、是否会在未来转为正式稳定版、各平台功能是否完全一致、支持哪些编程语言编写工作流、SDK 的具体版本要求，以及公开预览的结束时间。这些信息目前都是官方未说明的状态。

适合谁用？什么时候不该用？

动态工作流适合需要重复执行复杂流程的开发者，比如发布检查、大规模代码审查、跨目录搜索、多步骤研究加实现。如果你经常做同一套多步骤操作，或者任务需要明确阶段、检查和限制，它就很合适。

但如果你只是想要一个快速答案或简单修改，原文明确建议用普通聊天模式。动态工作流不是用来替代日常聊天的，而是用来处理那些需要可靠性、可观察性和多智能体协作的复杂任务。把它想成给机器人小队写剧本，而不是每次问路。