Hive——把 Git 变成 AI Agent 的任务总线

一个脚本 + 一个仓库，让多台机器上的 Agent 自己抢活干

多机 AI Agent 协作的常规思路，往往是引入一套调度服务：注册中心、消息队列、中央数据库，外加一套健康检查和故障转移逻辑。这套东西能跑，但维护成本不低，对中小规模场景尤其显得笨重。

Hive（skywalk163/hive） 走了一条完全相反的路：不建调度服务，不引入数据库，不依赖 SSH，把 Git 仓库本身变成任务总线，用 Git 的原子性来解决分布式协调中最棘手的那部分问题。

核心设计：总控写卡，Worker 抢卡，Git 当总线

Hive 的角色分工极其克制：

• 总控（Controller） ：写任务卡、分派、验收。不登录任何 Worker 机器。

• Worker Agent：从仓库拉取任务，原子领取，在独立的 Git worktree 中执行，把结果推回仓库。

• Git 仓库：任务卡、领取信号、执行结果全部以文件形式存在 Git 分支上，本身就是状态机。

领取机制是整个系统最精巧的部分。Worker 要执行一张任务卡，必须 push 一个 claim/T-xxxx 分支来“抢占”。Git push 天然具有原子性——远端只接受第一个成功的 push，后到的会被拒绝。不需要额外的锁服务，抢锁逻辑由 Git 协议本身保证。两个 Worker 同时抢同一张卡，只有一个能赢，输的自动转向下一张。

执行侧，每个任务在一个独立的 Git worktree 中运行，任务之间互不干扰；结果写入 results/T-*.json 并推送到 res/ 分支，总控验收后归档回 main，临时分支删除，审计记录完整保留在 main 上。

Hive 同时覆盖三种执行模式，适配从全自动 CLI Agent 到 GUI Agent 再到人工操作的完整谱系：exec 模式调用外部 Agent 命令；verify 模式只做验收、不产出代码；manual 模式为 GUI 或人工操作准备好 worktree 和任务说明，等待完成后回收结果。

近期关键进展：从“精巧”走向“可扛事”

Hive 当前处于活跃开发中，按任务卡迭代，变更记录在 CHANGELOG.md 中。近期的演进重点，是在保留 Git-as-a-Database 极简架构的前提下，补上分布式协调中不可回避的鲁棒性短板。

项目正在系统性地借鉴 hivecommons/hive 的工程机制，并从中提炼可移植的改进。最直接的三项补丁是：

• 租约持久化：将“谁在什么时间持有哪个任务”写入磁盘（如 task-leases.json），Hub 重启后重新加载，避免因总控进程重启导致所有 claim 分支“冻结”、进行中的任务被误判失效。

• Fencing Token（世代计数器） ：每次任务分配携带单调递增的世代号，Hub 只接受与当前活跃租约精确匹配的恢复请求。僵尸持有者携带过期世代号的恢复会被明确拒绝，防止状态分裂。

• 化身号与宽限期：节点重启后化身号严格递增，自动覆盖过期的“死亡”传闻；Hub 重启后的宽限期内，恢复的租约进入“保留”状态，给正在重连的 Worker 留出缓冲窗口，消除“刚领取就失效”的抖动。

与此同时，Hive 也从 RIP/OSPF 等路由协议中汲取分布式设计原则——例如用“超时即失效”的软状态模型为 claim 分支引入 TTL 租约机制，让总控定期回收过期领取，而不是依赖手动清理。

这些改进的共同指向是：让 Git-as-a-Database 不只是一个巧妙的演示，而是一个在多节点、真实故障场景下仍然可信的任务调度底座。它不需要变成 hivecommons/hive 那样的企业级治理平台，而是要在“极简任务总线”的定位上，把一致性、故障恢复和状态持久化做扎实。

适合谁用

Hive 的目标场景清晰：多台异构机器、多个 AI Agent、一个 Git 仓库就能说清楚协作关系的开发任务。FreeBSD、Linux、Windows 节点可以混合参与，CLI Agent 与 GUI Agent 可以同场调度，不需要为调度层单独维护基础设施。如果你已经在用 Git 管理代码，Hive 相当于让同一个 Git 仓库顺带承担了任务协调的职责——没有额外服务要部署，没有额外状态要备份，审计记录天然可回溯。

项目地址：https://github.com/skywalk163/hive。克隆下来，python3 hive.py init 即可开始。