我为了在长周期任务中让智能体存活搭建了什么，以及为什么这还不够——寻找具体建议

我为了在长周期任务中让智能体存活搭建了什么，以及为什么这还不够——寻找具体建议 我运营着一支 LLM 智能体集群，执行时长从数小时到数天的长任务。示例项目：一条流水线，将来自多个频道的数百个视频转录并摘要，构建可检索的知识库。它以批处理方式运行，会撞上速率限制，会被中断，还必须在不重复处理或重复发送任何内容的前提下恢复。 智能体一直在无声地死亡。没有明显的崩溃，它们只是停下来了，而我几小时后才发现。 以下是我目前搭建的东西。 **共享看板上的心跳。** 每个任务一行：上次检查、下次预期检查、截止时间、当前步骤、检查点链接。所有智能体写入相同的六个字段，因此一张表格就能纵览整个集群。 **截止时间设为检查间隔的 2-3 倍。** 漏跳一次心跳是一个信号，而不是立即的判决。 **有界重试。** 每个重试循环都有上限和总截止时间。常驻监视任务的总截止时间留空，因此它们永远不会"过期"；只有有限任务才有总截止时间。 **每 30 分钟一次的父级审计。** 一个独立的智能体读取看板并对逾期行打标记。如果超过一半的任务同时被标记，它会发送一条聚合告警，因为这通常是中断或配额问题，而不是 10 个智能体死亡。 **"未知"永远不等于"已死"。** 如果状态检查本身被限流或服务不可用，结果就是未知，任何人都不会被重启。 **副作用的意图/完成记录。** 在任何不可逆操作（发送、提交、发布）的前后，智能体写入一个操作密钥，这样被重启的智能体就能判断该操作是否已经发生。 **重启时的纪元围栏。** 被重启的智能体会获得一个更高的纪元号，旧智能体如果醒来并看到更新的纪元号就会自我终止。 **以云盘为主的检查点与里程碑提交。** 每批处理完后，进度写入持久存储，看板行中保留一个指针。 **看门狗唤醒——用来检查审计本身是否仍在运行。** **为什么这还不够：** - **凭证投递。** 智能体无法安全地获取 git 令牌。我们的密钥库只能填充浏览器输入框，永远不会把值交给 shell，因此提交只能走缓慢的浏览器路径，且只能提交小文本文件。 - **工作区重置会抹掉本地状态。** 任何没有外部检查点化的东西都会丢失，而且只有当智能体成功写入了看板时，看板才能帮上忙。 - **没有外部死人开关。** 如果审计智能体和看板同时宕机，没有任何东西会察觉。一切都存在于同一个生态系统中。 - **步骤与上下文限制。** 智能体在任务中途撞上这些限制，然后直接停止，没有干净的交接。 - **表格的配额限流。** 十几个智能体每小时打卡加上审计，读取配额很快耗尽，我不得不在所有地方把限流当作"未知"来处理。 **我希望获得建议的方向：** - 一个不依赖同一平台的低成本外部死人开关（cron ping 服务？还是别的什么？）。 - 在这个规模上，比电子表格更适合做心跳的地方。 - 如何把密钥交给智能体，使其能够提交代码，同时不在聊天或日志中暴露值。 - 当智能体即将撞上步骤限制时，实现干净交接的模式。 - 任何可以砍掉的东西。我怀疑其中有些部分过度设计了。很乐意就任何细节展开讨论。