多智能体任务的“检查点”设计：失败后不必从头再来

在多智能体流程里，我遇到过一个很典型的失败：五个 Agent 已经跑完前三步，第四步调用外部接口超时，整个任务被判定失败。重新跑一遍不是不能做，而是前面已经花掉的时间、Token 和外部调用全部作废。更麻烦的是，有些步骤带有副作用，比如已经发出的通知、已经写入的草稿，重复执行还会造成重复结果。这篇文章想讨论一个朴素但有效的办法：给任务加检查点。

检查点不是日志，也不是简单的进度条。它的核心是：在每个不可逆或者代价较高的步骤之后，把恢复任务所需的最小状态写下来。至少包括三样东西：已经完成到哪一步、这一步产出的关键结果、以及下一步需要哪些输入。只要这三样齐全，恢复时就可以直接从断点继续，而不用重新推理前面已经确定的内容。

设计检查点时，我会坚持三个原则。第一，检查点要小。只存恢复必需的信息，不要把整个对话历史原样复制，否则恢复本身就变成新的负担。第二，检查点要可验证。写入时顺手记一个步骤指纹或版本号，恢复时先核对，避免用旧状态去跑新流程。第三，检查点要分层。任务级检查点记录整体进度，步骤级检查点记录单步的输入输出，出现问题时可以只回滚一步，而不是整个任务。

一个最小实现并不复杂。可以用一张简单的状态表：任务编号、当前步骤、步骤产物摘要、更新时间。每个步骤结束时先写检查点，再进入下一步；恢复时先读最近一个完整的检查点，再校验输入是否仍然有效。

恢复流程也要当成正常路径来设计，而不是事后补丁。建议固定三个动作：先确认断点是否仍然有效，再只重跑断点之后的步骤，最后把恢复过程本身也记下来。这样即使恢复过程中再次失败，下一次仍有据可查。

检查点不是万能的。对于幂等性差、外部状态不可控的步骤，恢复前必须先确认副作用是否可以安全重放；不能确认时，宁可停下来等人工判断，也不要自动继续。总结一下：多智能体任务越长，检查点越重要。它不解决模型能力问题，但能把一次失败的代价从“全部重来”降到“从断点继续”，这在日常跑任务时，往往就是能不能按时交付的区别。