如何让 3 个 AI 编码 Agent 7×24 小时不间断运行

最近 Hacker News 上有一位开发者分享了他连续 3 天运行 3 个 AI 编码 Agent 的经验（6 分 / 3 条评论），虽然分数不高，但内容非常有实操价值。他用 Claude Code、Codex CLI 和 OpenCode 三个 Agent 同时工作，配合 Beads 任务队列、本地模型降成本、Telegram 远程监控——实现了接近 7×24 的自动化编码流水线。

本文将把他的 9 条实操经验重组为 7 步实战指南，让你也能搭建自己的多 Agent 编码集群。

Step 1：启用 Headless 模式

要让编码 Agent 能脚本化运行，第一步是启用无头（headless）模式。三种主流工具的命令略有不同：

Headless 模式下 Agent 不会启动交互式 REPL，而是直接执行你传入的指令后退出。这是整个自动化流水线的基础。

claude -p "Scan this repo for hardcoded API keys and output a JSON report"

Step 2：搭建 Ask Human 通道

Headless 模式下，Agent 无法像交互式会话那样直接问你。如果 Agent 在深夜遇到需要人工确认的决策，它会卡住直到你醒来。

解决方案是实现一个 ask_human 的 MCP 工具。这位开发者开源了自己的实现：

git clone https://github.com/sermakarevich/claude.git

工作原理：Agent 调用 ask_human 工具时，消息会发送到一个外部通道（Telegram），你可以在手机上回复。Agent 收到回复后继续执行，不会阻塞整个流水线。

💡 关键经验：这个 ask_human 通道是解决”Agent 夜间空转”的核心。原作者的实测数据：3 个 Agent 并发运行时，如果有 1 个 Agent 卡在等待人工输入，GPU 利用率会降到 30% 以下。有了 ask_human 通道后，GPU 能保持在 100% 利用率。

Step 3：部署 Beads 任务队列

多 Agent 协作的核心问题：谁来分配任务？如何防止多个 Agent 抢同一个任务？

原作者使用了 Beads——一个轻量级分布式图式 Issue Tracker，底层由 Dolt（Git 风格的 SQL 数据库）驱动。Beads 的核心能力：

• 有向无环图（DAG）任务依赖：任务 B 可以在任务 A 完成后自动启动
• 原子性认领：每个任务只能被一个 Worker 认领，防止重复执行
• 状态追踪：TODO → InProgress → Done / Failed
• 优先级和层级：支持任务层级和优先级排序

dolt sql -q "INSERT INTO tasks (title, status, priority, depends_on) VALUES ('Implement login page', 'TODO', 1, NULL)"

Beads 的角色类似 CI/CD 中的队列系统（如 Sidekiq 或 Celery），但专门为 AI Agent 设计——它的输出格式是纯 Markdown，Agent 可以直接读取和理解任务上下文。

Step 4：实现 Worker Artifacts（可恢复的工作产物）

当每个 Worker 开始执行任务时，它需要知道：我从哪里开始？做到哪一步了？如果重启了怎么恢复？

解决方案是为每个任务创建独立的 Artifact 目录：

beads-task-42/
├── plan.md            # 执行计划
├── status.md          # 当前进度
├── knowledge.md       # 过程中发现的知识
├── events.jsonl       # 事件日志
└── stderr.log         # 错误输出

Worker 启动时，其 System Prompt 会指示它：

1. 检查 Artifact 目录是否存在
2. 如果存在，读取 plan.md 和 status.md，从断点继续
3. 如果不存在，创建全新的计划文件并开始执行

mkdir -p /workspace/artifacts/beads-task-42

这种设计让 Agent 具备了”崩溃恢复”能力——即使 Worker 进程因 OOM 或其他原因退出，新启动的 Worker 也能捡起未完成的任务继续干。

Step 5：用 Git Worktree 隔离 Worker

当多个 Agent 同时修改代码库时，隔离是最关键的设计决策。原作者的方案不是传统分支，而是 Git Worktree：

git worktree add ../worker-1 feature/login
git worktree add ../worker-2 feature/api
git worktree add ../worker-3 feature/tests

工作流：

1. Worker 在它的 worktree 中实现功能
2. 下一个自动触发的 Worker 验证任务是否完成，运行测试
3. 验证通过后，合并 worktree 到主分支
4. 关闭 Beads 中的对应 ticket
5. 如果发现问题，创建一个 Fix 任务塞回队列

⚠️ 注意：Git worktree 之间共享同一个 Git 对象存储，但工作目录完全隔离。这意味着 Worker A 的改动不会影响 Worker B 的进行中工作。你只需要在合并时处理冲突即可。

Step 6：优化成本——用本地模型做苦力

连续运行 3 个 Claude Code Agent 的成本非常惊人。原作者实测：即使切换到 Sonnet 4.6，Claude 的 $200 订阅额度在 30 分钟内就会被烧完。而 API Token 的价格是订阅价格的 40 倍——更不可持续。

他的解决方案是分层模型架构：

配置示例（Ollama + Qwen3.6:36B）：

ollama pull qwen3.6:36b

ollama run qwen3.6:36b

原作者的经验是：即使 Qwen 3.6:36B 比云模型慢，而且 Ollama 一次只处理一个请求，但3 个 Worker 并发运行时 GPU 利用率能保持在 100%——因为如果一个 Worker 在等人工回复，另一个 Worker 可以继续使用 GPU。

成本对比：

Step 7：接入 Telegram 远程监控

当 Agent 在夜间无人值守时，你需要一个能随时查看进度的通道。原作者的方案是 Telegram Bot：

Telegram 的具体用途：接收 Agent 的提问并直接回复、查看所有任务的当前状态、手动创建新任务。UI 界面则提供实时看板，展示任务队列、Worker 活动和成本统计。

架构总览：7×24 编码流水线

把以上 7 步组合起来，系统架构如下：

编排器（Orchestrator）
  ├── 无限循环：检查 Beads 任务队列
  ├── 空闲 Worker 认领任务
  └── 触发新 Worker
        │
Worker 1 ─── Git Worktree A ─── 本地模型 (Qwen)
Worker 2 ─── Git Worktree B ─── 本地模型 (Qwen)  ─── Telegram 通知
Worker 3 ─── Git Worktree C ─── 本地模型 (Qwen)
        │
验证 Worker ─── 合并 Worktree → 关闭 Task → 创建 Fix Task

原作者使用的工具链覆盖了 Claude Code、Codex CLI 和 OpenCode，实现了”coder agnostic”——不依赖单一模型提供商。每个 Worker 用不同的编码工具，通过 Beads 和 Git Worktree 隔离协作。

总结

运行多 Agent 编码集群不再只是理论。这位开发者的实践表明，配合合理的架构设计（任务队列 + 工作隔离 + 人工通道），就能实现接近 7×24 的自动化编码流水线。

三个关键 takeaways：

1. 成本控制是第一优先级——没有分层模型架构，任何多 Agent 方案在经济上都无法持续
2. 隔离比协作更重要——Git Worktree + 独立 Artifact 目录是防止 Agent 互相干扰的基础
3. 人工通道不可或缺——ask_human 是避免 Agent 空转的关键设计

参考来源：HN 用户 sermakarevich 的 Show HN 帖子（objectID: 48520757），GitHub 仓库 sermakarevich/fleet