CI 只会判对错，判不了对不对得上：GitHub 官方 gh-aw 上手，让 Agent 每天替你巡检仓库

说实话，我对 “AI 自动修 Bug” 这件事早就免疫了。

之前试过的方案，要么甩给我一大坨 diff 让我自己审到凌晨，要么胆子大到直接往主分支推。直到翻到 gh-aw 的设计文档，我愣了三十秒：它默认只读，AI 想写东西只能 “申请”，由另一个独立权限的 job 代劳，产出物一律是草稿 PR。这玩意儿才是我敢在真仓库上开的东西。

一、CI 的盲区：它能判是非，判不了 “对不对得上”

CI 天生只会判是非。测试过没过，lint 报不报错，构建成不成功，全是二值判断。工程里真正磨人的那类问题，它一个都判不了。

文档里写的参数名，代码里两周前就改了，CI 照样绿。重构号称简化了三层抽象，实际只是把复杂度挪了个地方，CI 也绿。新版 API 上线了，README 的示例还挂着老签名，CI 还是绿。

这些都不是对和错，是 “对不对得上”。判这个得理解意图，得跨文件比对，得读懂人类写的那句话。

Continuous AI 说的就是把这类判断变成每次提交都跑一遍的事。你把它当成提交级的文档评审、重构复盘也行，当成随叫随到的 review 搭子也行。它不是替代 CI，是补上 CI 那一层盲区。至于 agent 本身在云上怎么被调度起来，我在 OpenAI Agents API 那篇里拆过，这篇只讲它在真实仓库里怎么落地。

二、Markdown 进去，1904 行 YAML 出来

gh-aw 是 GitHub 官方出的 gh CLI 扩展，MIT 许可，仓库 4800+ stars，当前版本 v0.87.x，处在 public preview。装它就一行：

gh extension install github/gh-aw

思路朴素得有点可爱：工作流用 Markdown 写，正文是给 agent 的自然语言指令，顶部那段 YAML frontmatter 是配置。跑一次 gh aw compile <name>，吐出一份标准 GitHub Actions YAML，落在 .github/workflows/*.lock.yml。

数字很能说明问题。社区里有份公开记录，作者一份 105 行的 Markdown 源文件，编译出来是 1904 行带安全加固的 Actions YAML。这 1904 行让你手写，光 SHA 固定依赖和权限收窄就能写到怀疑人生。

真跑起来时，Copilot、Claude、Codex、Gemini 或者一个叫 Pi 的引擎，作为 agent 在 Actions 里接手。模型够不够聪明不归它管，那是 Cognition SWE-2 这类编码模型的战场。

三、十分钟，跑通第一条 agentic workflow

别想太多，先跑起来。装完扩展，进你自己的仓库走四步。

第一步 gh aw init，每个仓库做一次，把目录结构、.gitignore、.gitattributes 补齐。第二步 gh aw add-wizard githubnext/agentics/docs-updater，把官方预置的文档巡检工作流拉进来。第三步 gh aw compile docs-updater，生成 .lock.yml。第四步提 PR 合并。结果呢？之后每次有 PR 合进主分支，它就会去检查文档和实现有没有脱节。

凭据这块按引擎分开配：

Copilot：需要 copilot-requests: write 权限
Claude：需要 ANTHROPIC_API_KEY
Codex：CODEX_API_KEY 或 OPENAI_API_KEY 都行

Gemini 用 GEMINI_API_KEY。另外记得在 .gitattributes 里加一行 *.lock.yml linguist-generated=true merge=ours，PR 里的 diff 会干净很多，也没人会去 review 机器产物。如果你习惯在本地用 Claude Code，可以把 gh-aw 想成它的托管版本：指令还是你写的，只是执行场搬到了 Actions。

frontmatter 是控制面：触发器、权限、引擎、网络白名单全写在这一段里

四、frontmatter 才是真正的控制面

很多人一上来就闷头写 Markdown 正文。方向反了。

正文只是提示词，frontmatter 才是权力清单。on 决定它什么时候被叫醒，permissions 决定它能碰什么，engine 决定谁来想，network 决定它能访问哪些域名，tools 决定它能调用哪些能力，再加上 max-turns 和 timeout-minutes 给它上缰绳。

改正文一句话是改行为，改 frontmatter 一行是改权力。这两件事的重量完全不一样。network 那一项我建议一开始就写死白名单，别留空。留空等于告诉 agent，外面随便逛。

还有个容易被忽略的东西：Repo Memory。它是挂在 git 上的持久记忆，让 agent 跨多次运行保留上下文，不用每次从零重新认识你的仓库。再叠一个 MCP server，它就能读到仓库外的东西了，比如你们内部的工单系统。

五、safe-outputs：让 AI 只能申请，不能动手

这章是整篇的重点，也是我愿意在真仓库上开它的唯一理由。

agent job 默认只读。官方在它身上套了一整套东西：沙箱执行、网络隔离、输入清洗、SHA 固定依赖、工具白名单、编译时校验、威胁检测。说白了，就是先假设它会出问题，再把爆炸半径圈死。

那它怎么产出东西？答案是 safe-outputs 这道闸。AI 不能直接写仓库，只能在运行结束时提交一份结构化的申请，由另一个权限完全独立的 job 代为落盘。产出类型就五种：create-issue、create-pull-request、add-comment、add-label、noop。可调参数有 max、title-prefix、staged、max-turns、max-ai-credits、timeout-minutes。

关键在于，产出的永远是待审的草稿 PR 或 issue，永远不自动合并。人就坐在最后一道关口上，一次点击决定生死。

Using agentic workflows in your repository requires careful attention to security considerations and careful human supervision, and even then things can still go wrong. Use it with caution, and at your own risk.

这是官方自己在文档里的原话，我原样搬过来。有分析认为，不受约束的 AI agent 正在推高软件缺陷数量。这是分析观点，不是既成事实，但方向我认：沙箱能控制爆炸半径，控制不了代码逻辑本身对不对。人必须留在环里。

五个开箱即用的官方 agentics 场景，产出物统一收进只读沙箱