很多智能体系统只有在一次请求内跑完时才显得顺畅。一旦任务需要等待审批、外部回调或失败后恢复，问题就不再是提示词，而是工作流设计。
长周期执行要解决三件事：状态放哪、什么时候唤醒、失败后怎么恢复。缺任何一项，系统都会慢慢偏航。
长周期执行会改变设计重点
短时运行还能勉强依赖上下文窗口，长周期不行。系统必须依赖持久状态和明确检查点。
用检查点代替重复推导
检查点不是普通保存点，而是工作流可重新开始的边界。它让系统在暂停后不必重放整段历史。
- 重大规划后建检查点。
- 外部副作用前后建检查点。
- 进入等待或人工审查时建检查点。
把重试和碰运气分开
只有当失败原因表明再次尝试可能成功，重试才有意义。无边界重试只会拖慢恢复并掩盖系统问题。
- 定义哪些失败允许重试。
- 定义最大次数和等待策略。
- 定义最后失败后的升级动作。
唤醒必须由显式条件驱动
工作流不该“等到想起来再继续”。它必须说明在等什么，以及什么事件会恢复执行。
- 人工批准或驳回。
- 外部系统状态更新。
- 计划重试窗口到达。
恢复应该开新分支
恢复动作应该被记录成一个新的决策点，而不是默默覆盖旧历史。这样团队才知道原路径为何失败，以及恢复改了什么。
人工审查本来就是系统的一部分
长周期任务越久，越容易积累不确定性。高影响动作前、连续重试失败后、等待太久时，都应该引入人工检查点。
结语
可靠的长周期执行，核心不是更长上下文，而是更好的工作流。检查点清楚、唤醒明确、恢复可见，系统才真的能长期运行。