GitHub 于 2026 年 10 月 1 日宣布 Dynamic Workflows 在 GitHub Copilot CLI、Copilot app 和 Copilot SDK 公开预览。这项能力让用户以代码定义一个可复用的代理流程，把多个自动化步骤、工具调用和一个或多个 agent 组合起来；流程可以是顺序执行、并行执行，或两者混合。
GitHub 的说明把 Dynamic Workflow 和单次指令或 /fleet 区分开来。/fleet 着重把工作分派给多个 agent，而 Dynamic Workflow 则描述整个有明确阶段的程序：每个阶段可以调用命令、工具或服务，把结构化结果传给下一阶段，也可以在中途要求用户输入、等待人工批准，或让一个 subagent 验证另一个 subagent 的结果。这让代理协作更接近一个可阅读、可测试和可重复执行的流程定义。
实际上，这种结构适合有清晰入口、步骤和完成条件的工作。例如事故资料整理可以先收集 log，再并行分析不同服务，最后由另一个 agent 汇总和检查；版本发布检查可以把测试、依赖、变更摘要和人工批准放在同一条流程；代码审查或大型 codebase sweep 也可以把工作拆成多个可观察的阶段。对于需要长时间执行的研究、计划及修改任务，检查点和结构化交接尤其重要。
Dynamic Workflows 的价值不只是让 agent 数量增加，而是让「怎样协作」成为可管理的程序资产。流程可以固定允许的工具、输入格式、重试或停止条件，并把结果留在明确的阶段边界。这有助于降低每次重新描述流程的成本，也让团队有机会比较不同版本的工作流，而不是只比较一次对话的最后答案。
不过，公开预览仍然不代表每种任务都适合自动化。流程越长、工具越多，越需要处理权限、错误恢复、部分完成、重复执行和敏感数据传递。团队应先在低风险及可重设的工作中验证，为每个阶段设置可检查的输出，并在付款、删除、发布或修改生产环境前保留人工批准。GitHub 也指出 CLI 的使用需要开启实验性功能，而 Copilot app 的界面则可直接使用预览能力；具体功能和限制仍可能变化。
这次更新显示 agent 工程正由「叫几个代理同时做事」走向「把一条代理程序写清楚」。对于企业而言，最值得先建立的不是最复杂的多代理系统，而是几条有明确输入、输出、验证及责任边界的可复用流程，再逐步加入并行化和更高程度的委派。
