GUIDE / 工程

一个人怎么带一支 Agent 舰队：心跳、指纹与失败闭环

相关：多机 Agent 掉线排查手册：七步定位　·　AI 小团队怎么开周会才不浪费时间　·　任务舰队　·　打开在线看板

多机多 Agent 的真实故障不是「跑得慢」，而是「悄悄失败还报告成功」。三个机制让失败无处藏身。

一、真正的故障长什么样

一个人带一支 Agent 舰队时，最常见的三种事故：

1. 静默失败：脚本报错退出，但没有人看日志。三天后你发现该生成的东西没有生成。
2. 身份覆盖：两台机器用了同一个名字，后上报的状态覆盖了前一台，于是「看起来都在线」。
3. 假完成：任务被标记为完成，但产出为空或只有占位符。审核的人看了一眼标题就过了。

这三种事故的共同点：系统在说「一切正常」，而事实不是。所以设计的起点不是「提高成功率」，而是「让失败无法伪装」。

二、机制一：心跳，但要带指纹

朴素的心跳只证明「有个进程还活着」。它挡不住上面第 2 种事故。

所以心跳必须携带身份指纹：机器 ID、部署指纹、版本号。三者组合才能确认「这是那台机器，跑的是那个版本」。任何一项不匹配，都应该报警而不是静默接受。

heartbeat {
  machine_id:   "mac-mini-02",
  fingerprint:  "sha256:9f2c…",   // 由硬件 + 部署路径 + 密钥派生
  version:      "1.0.3",
  task_id:      "TP-0913",
  ts:           "2026-10-29T07:12:41+08:00"
}

指纹的价值在于不可伪造的连续性：改名容易，改指纹难。这让「同名覆盖」这类最难查的错变成一条报警。

三、机制二：失败闭环，而不是失败通知

大多数系统的做法是「失败了发个通知」。这不够，因为通知会被忽略。

闭环要求三件事：

• 原因必填：任务失败必须写下原因分类（依赖缺失 / 超时 / 逻辑错误 / 外部接口），不能空着；
• 责任人必填：谁负责处理，不写部门；
• 复核必做：重试成功后，要标记「这是第几次尝试、前几次为什么失败」。

这三件事让失败从「一次性事件」变成「可统计的数据」。跑一个月，你就能看出哪一类失败占大头——这比任何事后复盘都准。

四、机制三：阻塞升级，而不是等人发现

任务是会卡住的。卡住的原因通常不是技术，而是「等一个只有某个人能做的决定」。

所以需要一个升级链：

阻塞 > 4h  → 提醒责任人
阻塞 > 12h → 提醒负责人（跨部门）
阻塞 > 24h → 进创始人审批队列（带等待时长）

关键在最后一级：它必须出现在老板每天都会看的那一屏上，而不是发一条他永远不看的消息。

五、一个人怎么带

有了上面三个机制，一个人带舰队才可行。日常只有三个动作：

1. 早上看一屏：在线几台、卡住几个、待批几个。90 秒。
2. 处理队列：只处理升级到你的，不主动巡检。
3. 每周看一次统计：失败分类 Top3、阻塞时长分布、掉线次数。据此改流程，而不是改人。

这套方法的本质是：把人从「巡检」里解放出来，只保留「决策」。巡检是机器该做的事，决策才是人的价值。

六、最小实现

不需要复杂的编排框架。一个目录、一个 JSON 文件、一个定时任务就够：

fleet/
  machines.json     # 名册 + 指纹 + 版本
  heartbeat/        # 每台机器写一个文件，带时间戳
  audit/            # 失败记录，含原因与责任人
  escalate.json     # 升级链配置

先把这三个机制跑起来，再考虑要不要引入更重的框架。大多数团队的问题不是框架不够强，而是没有人对「失败必须留痕」这件事负责。

---