首页/实践案例
十天，一百张任务卡，八个 AI 改同一个仓库
这不是我们写给客户看的方案，是我们自己的开发日志。2026-10-23 到 11-01，三个仓库、三台机器、十一个 agent 身份，全部跑在 hive 的同一张任务队列上。下面每个数字都来自仓库里的 tasks/ 与 results/，可以逐条核对。
起点：一个人被拆成六个人用
我们自己就是那个「一人公司」：一个人维护三个仓库（hive、light、lightharness），手上能用的机器是三台——一台 FreeBSD 主机、两台 Windows 虚拟机，另有一台只跑 Gitea 的服务器当任务总线。
改造之前，流程是这样的：一个 AI 列任务，人肉复制粘贴到每台机器。能跑，但有四个漏点，全都真实发生过：
- 分发靠手：复制、确认对方收到、跟踪谁在做，全靠人脑记。
- 状态在聊天里：任务做到哪、失败没有、改了哪些文件，聊天一滚就没了。
- 冲突靠自觉：多个 agent 改同一份 checkout，最后合并靠人肉比对。
- 平台能力没分工：Windows 上没有 CLI agent，只能做验收；写代码必须留给 FreeBSD。
所以我们把任务从聊天窗口里搬出来，搬进 Git。
不再把任务发在聊天窗口里。任务改成仓库里的「任务卡」，代码走分支，结果走 JSON。聊天只用来做决策和评审。 —— 2026-10-22 写下的方案第一句
为什么是 Git，不是数据库
一人公司的运维预算等于零。多一个数据库，就多一个要备份、要升级、会挂掉、挂了没人修的东西。Git 远程仓本来就在，它已经解决了持久化、版本、权限和冲突——只是没人拿它当队列用过。
四条机制，四次事故
不是设计模式推演出来的，是被踩过之后补上的。左边是机制，右边是它挡住的东西。
| 机制 | 怎么实现 | 它挡住的事故 |
|---|---|---|
| 任务卡 | 仓库里一个 Markdown 文件，带 frontmatter：仓库、分支基点、验收命令、可改路径、依赖、重试上限 | 任务只存在于对话里，人一换窗口就丢 |
| 原子领取 | 领卡 = 往 claim/<id> 分支 push 一个租约文件，成功即领到 | 两个 agent 抢同一张卡，做重复功 |
| 独立 worktree | 每张卡一个 task/<id> 分支、一个独立工作目录 | 并行改动互相覆盖，合并时靠人肉比对 |
| 租约 + fencing + 重试上限 | 租约到期自动回收；fencing token 挡掉「过期的人还在写」；重试耗尽转 blocked，不再无限重派 | 机器被杀之后，任务永远卡在「进行中」 |
第四条是实战里补的：纯 Git 模型一开始没有租约状态，一台虚拟机关机，它名下的卡就再没人敢动。补完之后才有「杀进程 → 回收 → 重派 → 依旧只产出一份结果」这个闭环。
十天里，到底是谁在干活
八种 AI 客户端，在同一张队列上领卡。同一个客户端在不同机器上各注册一个身份，所以身份数（11）比客户端数（8）多。
| 工具 | 身份 | 交付 |
|---|---|---|
| WorkBuddy | workbuddy（FreeBSD） | 36 张 |
| DeepSeek Harness | fb88-dsh | 16 张 |
| WorkBuddy | workbuddyai-win | 14 张 |
| 小浣熊 | raccoon-win / raccoon | 9 张 |
| 豆包 | doubao-win | 6 张 |
| DeepSeek | deepseek-win | 5 张 |
| CodeArts | codearts-win | 4 张 |
| DuMate | dumate-win | 2 张 |
| Trae | trae-win | 1 张 |
| 人工验收腿 | fb88-verify | 1 张 |
验收不是自说自话
每张卡在提交前必须跑一遍自己声明的验收命令，输出与退出码一起写进结果 JSON。94 份结果里累计 131 条验收命令，全部退出码 0；93 张 done，1 张失败——失败原因是那台机器没配 light 仓的本地路径，失败也被完整记录，没有「消失的卡」。
这 131 条里 93 条是 pytest，23 条是自己写的 Python 校验脚本，其余是构建与语法检查。它们不是形式化的 smoke test：卡上写什么就真跑什么，跑不过就不许提交。
被杀掉也不会烂尾
机制好不好，要看它怎么应对失败。我们做过一次 20 分钟浸泡：3 个 worker 抢 240 张卡，期间随机 kill -9。
- 240 张卡全部完成，失败 0，缺结果 0
- 杀死 worker 32 次，租约回收重试 7 次，已分派未领取重派 13 次
- 没有出现「一张卡两份结果」，也没有「卡永远卡住」
第二轮换最新代码再压 6 分钟：120 张、杀 9 次、0 失败。
两个夜里真实发生的事
案例最容易写成通稿。这里挑两张卡，把细节摊开——包括它们踩到的坑。
一个 Agent 自己修掉了 P0，还顺手给上游提了三条约束
那天晚上它领到的卡是「光明 CLI 读不到用户传给程序的参数」——light run x.light 甲 乙 直接报 unrecognized arguments。这一条卡死了所有用光明写的命令行工具，包括 hive 自己。
它改了两个 CLI 入口、新增一个运行时模块、补了 8 条 真起子进程的测试，然后把三条「下次别踩」的硬约束写进了报告：不能在某个文件里新开顶层函数（会打破自举率门禁的统计口径）、某个关键字文件是 CRLF 换行（用 LF 写回会改动 1444 行）、还有一个同步脚本只搬函数体不搬 import。这三条现在都写在仓库的 AI 指南里。
另一张卡补的是「派发中间态」
症状很隐蔽：卡被分派出去了，但没人领。dispatched_to 字段没写，回收逻辑只认「已领取」，于是这些卡就那么悬着，看板上既不是 ready 也不是 doing。
修法是两条：分派时同步写时间戳；再加一个「派发 10 分钟未领取就回收」的分支，连续两次派不出去转 blocked，避免一张坏卡被无限重派、刷满日志。验证是 46 条单测 + 83 条相关面回归。
也有一张卡，我们承认没修
有个存储后端在时间戳类型上会直接抛 AttributeError，导致命令行提交全崩。它不在那张卡允许改动的路径里，所以当晚只被记录、未被修复，第二天单独开卡。案例里写这一条，是因为「所有问题都解决了」这句话，通常意味着有人在替你省略细节。
这件事没有免费的部分
如果只讲收益，这套东西会被误当成「装上就自动运转的公司」。实际约束如下，四条都是硬的。
先看清楚再决定要不要学
- 每张卡都必须写得出验收命令。「优化一下体验」这种任务进不了队列——写不出判据，就没有 done 的定义。
- 粒度错了会更慢。卡太细，协调开销超过干活；建议先 3–4 张并行，跑顺了再加。
- Windows 腿会死机。所以它只做 best-effort 验收，不进关键路径；关键路径永远有租约兜底。
- Git 仓库是单点。Gitea 挂了，整个队列停摆。这是拿运维简单换来的，我们认。
- 人仍然要做两件事：拆卡、合并。自动化的是执行和记录，不是判断。
你可以照着跑一遍
这套流程没有绑定我们的机器，也没有绑定我们的业务。最小闭环是三条命令：
git clone https://github.com/skywalk163/hive.git # 国内慢就换镜像：https://gitcode.com/skywalk163/hive.git cd hive && python3 hive.py --dir . init python3 hive.py --dir . task new --title "给首页加一个 404 页面" \ --repo my-site --paths src/ --verify "npm run build" python3 hive.py --dir . dispatch python3 hive.py --dir . work --agent my-laptop
如果想让它记住每次的决策与踩坑，再装一层记忆服务；想让多台机器真正并行，就把同一个仓库 clone 到第二台机器、注册第二个 agent。三者怎么配合，写在 ai.quye.com 上；落到你自己的项目上，见 一人软件开发方案。
轮到你
你手上可能也有两三台闲置机器，和一个永远做不完的清单。
这套东西的意义不是「让 AI 替你上班」，是让你一个人也能同时推进五条线，并且第二天早上知道昨晚发生了什么。