写了三年 GitHub Actions，每次接新需求都要翻文档——今天发现它彻底变了，用 Markdown 写工作流

写了三年 GitHub Actions，每次接新需求第一件事就是去翻文档——那套 YAML 语法写着写着就变成配置游戏，真正想做的事反而埋在一堆 runs-on 和 steps 里。今天发现 GitHub 悄悄把这个彻底变了：用 Markdown 写工作流，AI 帮你编译成 Actions 运行，连 Copilot CLI 都不需要另装插件。

这件事的账全算清楚了。

GitHub Agentic Workflows 是什么

今年 2 月 GitHub 把它放进技术预览，本质是把写什么和怎么跑彻底分开。传统做法是你写 YAML 描述 CI/CD 流水线——哪台机器跑、跑什么命令、先决条件是什么。Agentic Workflows 换了个思路：你用自然语言描述需求，AI 编码 agent 理解你的仓库上下文、自己做决策、自己执行，写 Markdown 文件就行。

一个最小例子长这样：

on:
issues:
types: [opened]
permissions:
read-all
safe-outputs:
add-comment:

Issue Clarifier
Analyze the current issue and ask for additional details if the issue is unclear.

顶部的 — 是 frontmatter，控制触发时机和权限；下面那堆是人话，告诉 AI 遇到新 issue 的时候该干什么。gh aw compile 把这套 Markdown 编译成 .lock.yml——GitHub Actions 真正跑的那个 YAML 文件。

编译这一步很重要：它不是跑 Markdown，是把 Markdown 变成一个加固过的 Actions 流水线，加了安全验证、权限校验，输出是一个你能审计的标准 YAML。

为什么这件事值得认真看

三个原因。

第一个是安全模型。Agentic Workflows 默认只读，写操作全靠 safe-outputs 白名单——你说只能加评论，那 AI 真的就只能加评论，写不了别的东西。实际执行时 AI 运行在沙箱容器里，网络隔离、依赖固定版本、写操作全经过威胁检测。这套设计比直接给 AI token 写仓库要靠谱得多。

第二个是跨 engine。不绑定 Claude Code 还是 Codex 还是 Gemini——同一条自然语言指令，编译后换成任何 agent 都能跑。这个解耦让团队可以在不重写工作流的前提下试不同的 AI 工具。

第三个是它本质上是一套用 AI 编程 CI/CD 的框架。你描述意图，AI 写工作流，生成的 YAML 你审核，你合并——AI 接管的是怎么实现，人保留的是做什么和最终审批权。

实际能用在哪

根据官方和社区的案例，目前最成熟的几个场景：

CI 失败根因分析：AI 自动调查失败的构建，定位到具体哪个 step、哪个文件、哪个 commit，生成诊断报告。传统做法是你自己看日志，现在你睡一觉醒来它已经把结论发到 issue 了。

Issue 自动分类：新 issue 进来，AI 读内容、读仓库历史、打标签、分配给对应的人。相当于一个 24 小时在线的 Triage Bot。

文档同步：代码改了，AI 自动检测变更的实体，检查文档是否需要更新，生成 PR 更新文档。

每周状态报告：定时跑，扫描这个星期的新 PR、issue、构建状态，生成一个汇总发给团队。

这些场景有个共同点：规则明确但执行重复，用 YAML 写每次都要配一堆条件判断，用自然语言描述反而清晰。

怎么跑起来

需要三样东西：GitHub Actions 已启用、GitHub CLI 装好且认证过、一个支持的 AI agent（Claude Code、Codex、Gemini CLI、Copilot CLI 任选）。装好 gh aw 扩展之后：

gh extension install github/gh-aw
gh aw init

然后进到你想要的 agent 里，调用 agentic-workflows skill 说你要干什么：

/agentic-workflows create a pr reviewer that ensures changes are adequately tested

AI 会生成一个 Markdown 文件，编译成 .lock.yml，让你审核。审核完确认没问题，commit 就跑起来了。

值得注意的边界

Agentic Workflows 目前还在公开预览，API 和行为随时可能变。它的定位是研究演示，不是成熟产品——但核心设计已经稳定，跑在标准 GitHub Actions 上，编译出来的 YAML 你是能完全审计的。

还有一层局限：它解决的是仓库级自动化这个场景，也就是 issue、PR、构建、文档这些。应用层的业务逻辑部署、跨服务编排这些不在它的射程内。GitHub 自己也说，复杂流水线仍然需要 YAML，Agentic Workflows 是补充不是替代。

下一步是什么

如果你管一个需要长期维护的仓库，试试从最简单的场景入手——比如新 issue 进来自动打标签、新 PR 自动检查有没有测试覆盖。这两个场景规则清晰、立竿见影，跑顺了之后再扩到文档同步和 CI 诊断。

GitHub 官方在 Peli 的 Agent Factory 里收录了 50+ 个现成 workflow，可以直接 fork 改。

总结一句话：GitHub 把 CI/CD 的编程模型从 YAML 配置升级到了自然语言描述加 AI 编译执行，这件事对前端团队的工程化意义在于——以前自动化什么和怎么自动化是两套知识，现在你只需要想清楚要什么，剩下的交给 agent。

下一步：装 gh aw，跑 gh aw init，用一个真实场景试试。