这个提示词用来做什么

agent 要跑十几分钟、中间还会调支付或发消息，你担心它在重试时把同一件事做两遍。注入超时、重复回调与中途失败等场景，检查副作用是否被重复执行，并补上幂等保护。说明流程步骤与副作用即可，可指定允许演练的环境。

提示词全文

我要给一个长时间运行的 agent 流程做一次故障演练，目标是找出「重试或恢复时会被重复执行的副作用」。请你按下面的方式帮我设计并分析，不要泛泛谈可靠性。

## 输入
流程：{它每一步做什么、总共要多久}
外部副作用：{例如调用支付、发通知、写库、发邮件}
运行方式：{自建进程 / 工作流引擎 / 云函数}

## 输出
1）关键点清单：把流程里「一旦重复执行就会造成真实损失」的步骤单独列出来，并说明损失是什么（重复扣款 / 重复通知 / 脏数据）。
2）注入方案：为每个关键点设计一个最小破坏的故障——在第几步之后杀掉进程、在第几步把网络断开、在第几步让下游返回超时但实际已成功；每个方案写清注入位置、预期现象，以及恢复后该看什么。
3）判定标准：给定恢复后的观测数据，怎么判断它是「安全重放」还是「重复执行」——给出具体的日志字段或数据比对方法。
4）修复建议：按代价从低到高给出改法（幂等键 / 去重表 / 状态落盘 / 人工确认），并指出每个改法在你们这套运行方式下是否可行。
5）最后给一个结论：如果只能先做一件事，应该修哪个关键点，为什么。

注意：不要假设「框架会自动保证一次」，把每一次重试都当成可能重复来检查。

怎么用

  1. 把上面的提示词全文复制到对话窗口或工作流里。
  2. 把花括号占位符（如 {任务描述}）替换成你自己的内容。
  3. 条目越具体，产出越稳定；不需要的条目可以直接删掉。

输出示例

它会先把「重复扣款」和「重复发通知」分开处理——前者要求幂等键，后者往往只是体验问题，优先级不同。第 3 步给出的判定方法通常最有价值：很多人做了演练，却没有事先定义「怎么算重复」。

基本信息

  • 分类：工程
  • 标签：故障注入 · 幂等 · 重试 · 副作用 · 可恢复性
  • 收录日期：2026-10-05

同类提示词