github/gh-aw

解决什么问题

仓库里总有一类活不适合写死脚本：issue 分诊、PR 审查、排查 CI 失败、维护文档。手工做太累，给 LLM 直接配一个有写权限的 token 又太危险。gh-aw 把这类智能体步骤变成可编译的产物：用 Markdown 写任务、YAML frontmatter 写触发器和权限，编译成标准的 GitHub Actions 工作流。

有什么不同

常见做法是在 CI 里塞一段临时脚本或自定义 action，提示词、触发条件和权限散落各处，没人校验。这里 Markdown 是唯一信源，gh aw compile 生成锁定文件，智能体任务默认只读并在沙箱中运行；写操作先进入 safe outputs，再由独立 job 以收窄的权限执行。相比通用智能体框架，它牺牲通用性换取和 Actions 触发器、权限模型的紧密结合，代价是被绑在 GitHub 上。引擎可替换（README 列出 Copilot、Claude Code、Codex、Gemini、Pi），这一点比自建方案省事。

适合谁

适合活跃开源仓库的维护者，以及以 GitHub 为中心的研发平台团队，尤其是已经熟悉 Actions YAML、希望智能体步骤像代码一样被 review 的人。不适合需要在 GitHub 之外跑智能体的场景，也不适合只想要确定性检查的团队——README 明确说它是 CI 的补充而非替代。排斥在 CI 中调用 LLM、或要求完全离线运行的团队应直接跳过。

上手成本

入口是 CLI 扩展（gh extension install github/gh-aw），需要 gh 和可用的 AI 引擎账号，也会消耗 Actions 分钟数。部署前必须逐项检查权限、工具、网络访问和生成的 .lock.yml。许可证为 MIT。项目年轻，README 自己披露了影响 >= 0.83.3, < 0.85.4 的安全公告、相关版本被抢先下架，说明安全面是真实存在的，锁定版本很重要。README 对架构讲得很细，但对运维上限和失败模式着墨不多。

点评

GitHub 官方项目，创建约 14 个月积累约 5400 star，近一个月 +304，上过一次日榜——势头可观，但榜单记录太稀疏，不足以证明已进入稳定轨道。设计思路（只读智能体、校验后的安全输出、独立收窄权限写 job）是对路的，Markdown 编译成工作流也让智能体逻辑可评审。早期就出现安全公告，提醒你这是个年轻且安全敏感的工具。值得在低风险仓库做试点，但在锁定版本、仔细审查权限之前，不宜全仓推广。