GitHub Copilot 在 CLI、App 和 SDK 中同步上线了 Dynamic workflows（动态工作流）。官方将其定位为：用代码定义编排，以获得复杂多 Agent 工作所需的可靠性与可观测性。该能力目前处于公开预览阶段，所有 Copilot 计划均可使用。
它解决什么问题
普通对话模式适合快速问答和简单改动。但当任务需要明确阶段、检查点或边界时，仅靠一次提示很难保证每次执行路径一致。Dynamic workflows 的核心思路是把「流程」从自然语言提示中抽离出来，写成程序：哪些步骤自动执行、何时引入 Agent、如何消费 Agent 结果，全部由代码决定。Agent 只负责需要分析或判断的部分。
官方给出的典型场景是服务事故调查：先收集日志与遥测数据，再分配独立 Agent 分析不同系统，最后把它们的结构化发现合并成时间线与根因报告。关键在于「同样的步骤每次都会运行」，流程本身是可复现的。
与 /fleet 的区别
官方明确区分了两者：/fleet 是 Copilot 把工作委派给子 Agent 并并行协调；而 Dynamic workflow 执行的是代码中定义的流程。前者偏「Copilot 自主调度」，后者偏「开发者显式编排」。这一区别决定了适用边界——需要稳定、可审计、可复用的流程时，代码编排更合适。
能力清单
根据官方说明，Dynamic workflows 可以：
- 运行命令、使用工具或调用其他服务；
- 把目标拆成任务，并行执行相互独立的任务；
- 在阶段之间传递结构化结果；
- 让子 Agent 互相验证彼此的发现；
- 在客户端支持时向用户请求输入；
- 在检查点暂停，供你审阅结果后恢复。
工作流程序本身运行在 GitHub Copilot 扩展内，因此可以访问 Copilot 的扩展性 API。这意味着它不是一个孤立的脚本，而是能接入 Copilot 既有扩展体系。
适合的场景
官方列出的候选场景包括：
- 发布检查：让一个 Agent 评估失败项，暂停等待你审阅后再继续。
- 并行审查 PR 中大量变更文件。
- 用代码找出已合并 PR 中未解决的评审意见，再让两个模型判断这些意见是否仍然成立，只有两者一致时才报告。
- 在大代码库中跨多个目录扫描某种模式，例如缺失的测试或即将移除 API 的使用点。
- 先研究变更、基于发现规划实现，再执行改动。
- 启动耗时或成本较高的长任务，并允许中途暂停、稍后恢复。
反过来，官方也给出边界：如果只是要一个快速答案或简单改动，标准聊天模式的普通提示通常就够了。
如何开始
- 在 GitHub Copilot App 中，Dynamic workflows 始终可用，无需额外设置。
- 在最新版 Copilot CLI 中，需要通过
--experimental命令行选项启动，或在交互会话中使用/experimental on开启实验性功能。更新 CLI 可运行/update。 - 可以让 Copilot 为你常用的流程创建工作流；官方文档提供了创建步骤。
- 想知道已有哪些工作流，可以直接问「What dynamic workflows are available?」。
- 反馈可通过 CLI 中的
/feedback提交。
工程视角的几点判断
以下为工程分析，非官方事实。
第一，把编排写成代码，最大的收益是可观测性与可测试性。流程的每一步是显式的，失败点、重试边界、并行度都可以被审查，而不是隐藏在模型的一次推理里。
第二，检查点与人工介入是长任务的关键设计。官方支持暂停审阅后恢复，这让高成本运行不必一次性赌到底，适合接入 CI 或发布门禁。
第三，子 Agent 互验加「两者一致才报告」的模式，本质上是用冗余判断降低误报。对评审意见清理、代码库扫描这类噪声敏感的任务，这种结构比单 Agent 更可控。
第四，注意当前状态是公开预览且可能变化，CLI 还需显式开启实验性功能。在生产流水线中采用时，建议先用于只读或可回滚的环节，例如扫描、审查、报告生成，再逐步扩展到会修改代码的步骤。
总体来看，Dynamic workflows 把 Copilot 从「对话式助手」推向「可编排的执行引擎」。对需要把 AI 编程能力沉淀为可复用自动化流水线的团队，这是一个值得评估的新原语。