介绍 gh-aw-fleet

我在几个月前开始使用 GitHub 智能体工作流：这是一种小型的 Claude/Copilot 智能体，运行在你的持续集成环境中，用于代码审查、每日文档更新、恶意代码扫描以及拉取请求修复。你使用 Markdown 编写它们，它们会被编译为 GitHub Actions，并由一个人工智能智能体在每次运行时执行具体工作。

在让最初几个代码仓库运行起来后，我遇到了一个问题：我究竟该如何追踪每个仓库中部署的内容？是什么版本？使用了什么配置概要？发生了哪些偏离？

因此，我构建了一个工具。

它是什么

gh-aw-fleet 是一个用于 GitHub 智能体工作流的声明式集群管理器。一个 fleet.json 文件声明了你的代码仓库以及它们应使用的“配置概要”；命令行界面负责协调（deploy、sync、upgrade、add），默认情况下所有操作均为空运行。它是围绕 gh aw、gh 和 git 的一个轻量级编排器，而非分支版本。

它绝不会重写工作流的 Markdown 文件。它只回答一个问题（谁在何时从哪个配置概要获得什么工作流），并将实际的文件操作分派给 gh aw。任何涉及代码仓库的操作都会在那里创建一个拉取请求。没有任何操作会强制推送或直接提交到 main 分支。

# 检查整个集群的偏离情况，无需克隆，只读模式
gh-aw-fleet status

# 使代码仓库与其声明的配置概要保持一致（先空运行，然后创建拉取请求）
gh-aw-fleet sync acme/widgets --apply

空运行检查机制是我最依赖的部分。deploy、sync 和 upgrade 命令会准确打印出它们将要执行的操作，在你添加 --apply 参数之前不会更改任何内容。当你同时处理十几个代码仓库时，“先展示给我看”这一特性决定了一个工具是值得信赖，还是需要你时刻看护。

出乎意料的部分

基于使用量的 Copilot 计费将于 2026 年 6 月 1 日生效。每个部署的工作流都会按计量费率消耗积分，而针对单个代码仓库的工具（gh aw、Actions 用户界面）无法跨集群查看，因此无法告诉你积分用在了哪里。

事实证明，用于声明哪些代码仓库使用哪些工作流的同一个 fleet.json 文件，正是归因这些消耗的自然场所：可以按代码仓库、按配置概要或按成本中心进行归因。一个 consumption（消耗）汇总功能正在开发中。我原本是去解决偏离追踪问题，结果却带回了云财务运营问题。

自发布以来的更新

v0.1.0 版本于 4 月 21 日发布，包含了核心的协调循环。现在是 v0.2.0 版本，两者之间的差距主要在于让用户在更多代码仓库上信任该工具：

status / 偏离检测：无需克隆任何内容即可查看整个集群中哪些部分不符合预期，并以此作为持续集成任务的门禁条件。
JSON 输出 + 结构化日志：读取命令支持 -o json 选项，底层使用 zerolog，因此你可以将结果管道传输到 jq 或聚合器中。
可恢复的部署：可以从提交或推送门禁处恢复未完成的部署，而无需重新开始。
第一层安全扫描器：在任何内容发布之前检查密钥和结构规则。
observability-plus 配置概要 + HTTP 402 计费诊断：为上述计费故事奠定早期基础。
HuJSON 配置：允许在 fleet.json 中使用注释和尾随逗号，以便你可以在设置固定版本的旁边记录为什么要这样设置。

当前状态

v0.2.0，仍处于 1.0 之前版本：命令行标志和

免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。