你以为 GitHub Actions 只能跑脚本？今天 AI Agent 把这件事彻底接管了

写完了三年 CI 流水线，每次遇到「这个 flaky test 为什么只在周二挂」「谁来分一下这堆 issue」「文档又和代码对不上了」这类问题，都只能等人肉介入——2026 年 8 月 31 日 GitHub 把这件事用一套新架构彻底接管了：GitHub Agentic Workflows。

它解决的是什么问题

传统 CI/CD 流水线擅长做确定性任务：构建镜像、跑测试、部署产物。这些你写好一次，它就跑一万次不会错。

但现实工程里有大量任务是非确定性的，需要读上下文、做判断：

• 新 issue 来了，该不该加 bug 标签、该分给谁？
• CI 失败了，怎么判断是依赖版本问题还是代码本身的问题？
• 一次大的重构合并了，相关的 README 和 API 文档谁来同步更新？

这些事情以前只能人肉处理。Agentic Workflows 做的事情，就是把这层「判断能力」接到 GitHub Actions 里——用 AI Agent 来做，而且是在你现有的 Actions 基础设施上跑，不引入新的运行时。

怎么跑起来的：两行命令，从 Markdown 到 Action

整个流程分两步：

第一步：写 Markdown
在 .github/workflows/ 目录下新建一个 .md 文件，用自然语言描述这个 Agent 要做什么。

---
name: CI Doctor
on:
  workflow_run:
    types: [completed]
    workflows: ["CI"]

engine: claude
outputs:
  - type: issue-comment
    triggers:
      - issue-open
---

当 CI 运行失败时，读取失败的日志，判断失败原因，
并在相关 issue 下留言给出修复建议。

第二步：编译并运行

gh extension install github/gh-aw    # 安装 CLI 扩展
gh aw compile                      # 把 .md 编译成 .lock.yml

编译出来的 .lock.yml 就是一个标准 GitHub Actions workflow 文件，直接在 Actions 里跑，不需要任何新基础设施。

支持哪些引擎

Agentic Workflows 不绑定某一家的模型。frontmatter 里指定 engine 字段：

Copilot 用户开箱即用；换引擎只需要改一行配置，workflow 其他部分不变。

安全模型：为什么它不会把你的仓库搞乱

这是整个功能设计里最用心的部分。GitHub 在技术预览阶段花了四个月做安全架构，而不是急着上线功能。

核心原则就一条：Agent 做判断，可信步骤执行写操作。

具体拆解：

默认只读。 Agent 拿到的权限是仓库只读，除非你在 frontmatter 里显式声明它需要哪些写操作。

Safe Outputs 模式。 Agent 想创建 issue、留评论、开 PR？不是直接写，而是声明「我要写一个 issue-comment」，系统校验这个输出的类型和内容，确认安全后才执行。Agent 不能自己决定往仓库里写什么。

隔离执行。 Agent 运行在 GitHub Actions 的沙盒环境里，网络隔离，依赖 SHA 固定，不能自己下载额外的工具。

权限不上传。 Secrets 不进 Agent 运行时，写操作全走下游隔离任务，Agent 碰不到你的凭证。

不可提权。 Agent 不能给自己升级权限，不能修改 Actions 配置，不能绕过 review gate。

这套模型的逻辑是：即使 Agent「想」做坏事，它的权限边界已经物理隔绝了操作能力。

怎么计费

成本分两部分：

• GitHub Actions 计算分钟： 标准 Actions 价格，$0.002/分钟（2026 年 1 月基准）
• LLM 推理费用： 按选择的引擎走对应提供商的 API 计费

GitHub 引入了 AIC（AI Credits）作为跨引擎的统一预算单位：1 AIC = $0.01。可以在 frontmatter 里设 max-ai-credits 限制单次运行的 AI 花费上限，默认上限是 1000 AIC（$10）。

简单任务（如读一条 issue、贴标签、留评论）实际 token 消耗很低，跑一次几分钱。复杂的代码审查或文档更新任务，大概 $0.05–$0.20 每次。

查看用量用 GitHub CLI：

gh aw logs          # 看最近运行记录含 token 用量和 AIC 估算
gh aw audit RUN-ID  # 查单次运行的详细费用

适合哪些场景

不是所有事情都值得交给 Agent。官方给了几个经过验证的预制 workflow：

Issue Triage： 新 issue 打开，Agent 读标题和正文，自动贴标签、分类、判断严重程度、分给合适的 reviewer。

CI Doctor： CI 失败时，Agent 读日志，判断是依赖版本问题、测试本身问题还是代码逻辑问题，在相关 issue 下留言并建议修复方向。

Daily Repo Status： 定时跑，Agent 扫描仓库的健康度——待处理 PR 数量、open issue 趋势、测试覆盖率变化——生成一条状态 issue。

Doc Sync： PR 合并后，Agent 检查改过的文件和对应文档是否同步，漏了就开个 PR 把文档补上。

Compliance Check： 检测代码是否违反团队政策（比如某个 API 的使用权限），违规则上报。

三步上手

第一步： 确保你的仓库开启了 GitHub Copilot 订阅，安装 CLI 扩展：

gh extension install github/gh-aw

第二步： 从一个预制 workflow 开始，不用自己写 Markdown：

gh aw add-wizard githubnext/agentics/ci-doctor

这个命令会交互式引导你选引擎、配 secrets、生成 workflow 文件。

第三步： 跑第一次，看日志，调整 frontmatter 里的 outputs 声明，让 Agent 逐步获得你需要它拥有的写操作权限。

从安装到跑出第一个结果，实测大约十分钟。

一个判断标准：这件事值得交给 Agent 吗

不是所有维护任务都适合自动化。一个简单的判断标准是：

如果这件事你愿意让一个认真但没有经验的新人去做，给他阅读权限但不给写权限，让他每次行动前必须汇报——那这件事就适合丢给 Agentic Workflows。

判断力要求高、写操作边界清晰的场景，是它的最佳落点。