Agent 紧急停止应由运行时控制

AI Agent 出了问题，谁能让它停下来？原文给出的答案是：平台团队必须先造好一个作用于运行进程、能由业务负责人直接操作的停止开关。把「停止」写进提示词，再指定一个负责人，还不够。

作者把这个开关拆成六项工程要求，覆盖运行控制、任务检索、子任务终止、恢复幂等和审计。它值得读的地方，是把「人类随时可以接管」这句承诺，变成了可以在预发布环境里逐项验收的能力。

停止指令为什么不能只放在提示词里

作者提到过一起生产事故：Agent 上下文经过压缩后，停止命令被挤出了上下文窗口。这是一个具体案例，但原文没有给出事故规模、发生频率或更多排查细节。

它指出的问题很直接：如果停止动作还依赖模型读取并服从指令，开关是否有效就受模型当前状态影响。

真正的停止开关，必须从模型之外控制运行中的工作流或进程。

这里的运行时（runtime），就是实际调度和执行 Agent 任务的系统。无论模型正在生成什么，它都应该能暂停或结束执行。

另一个容易遗漏的问题是「找到谁」。业务负责人记得的是「退款 Agent」或「这个客户的全部任务」，运行时保存的却可能只有自动生成的 ID。因此，每次运行都要带上 Agent 名称和业务标识，并支持一次停止所有匹配项。否则，开关虽然存在，负责人凌晨 2 点还是得找工程师查 ID。

暂停、终止、恢复是三件不同的事

原文要求明确区分两个按钮：

• Suspend 暂停当前运行，保留状态，之后可以从同一步恢复。
• Terminate 结束当前运行，而且必须级联终止所有子工作流。

按钮还要说明它对正在执行的工作有什么影响。事故发生时，操作者不该靠猜测判断「停了以后还能不能继续」。

级联终止尤其关键。Agent 可能启动子工作流或并行任务。如果父任务结束了，子任务仍在发送邮件或调用其他服务，停止动作就没有覆盖完整的执行范围。

恢复则有另一层风险。原文提出采用持久化执行（durable execution）：系统记录执行进度，恢复时跳过已经完成的步骤。但停止瞬间正在调用外部 API 的那一步，可能出现结果不确定的情况。

例如，请求已经被支付服务处理，本地却还没记下成功。恢复后重试，就可能重复扣款。因此，作者要求为支付、邮件或其他有外部影响的 API 传入幂等键（idempotency key），让重复请求不会重复产生效果。

能恢复执行，不等于能安全重试外部操作。

自动止损和审计要接入同一套停止能力

手动按钮解决的是「负责人发现问题后怎么办」，自动触发解决的是夜间、周末无人及时操作的问题。

作者列出的触发条件包括支出上限、错误率和投诉阈值。它们应调用负责人使用的同一个停止 API，让自动控制和人工控制共用一套执行逻辑。

每次停止还要留下记录，包括：

• 谁或什么机制触发了停止。
• 停止发生的时间。
• 受影响的运行实例。
• 停止的原因。

这些记录应成为事故复盘的起点。原文要求永久留存，但没有展开存储方式和保留策略。

最后的验收方法很实用：在预发布环境里，让实际业务负责人亲自中途停止一个任务，再恢复它，并分别计时。任何一步需要工程师协助，都说明平台能力还没交付完整。原文没有给出可接受的耗时标准。

我的判断

我认同作者把停止能力放在运行时层面。提示词适合约束正常行为，却无法独立承担进程控制；一个人工接管承诺，至少应该有模型之外的执行入口。

但这篇更像工程检查表。除了上下文压缩导致停止命令丢失的案例，作者没有提供故障率、停止延迟或方案对照数据，不能据此认定某种工作流平台效果更好。

几项要求也都有实现前提。级联终止需要系统掌握父子任务关系；恢复需要可靠的执行记录；幂等键需要下游服务真正支持去重。尤其是终止运行，不能被理解成撤销已经完成的付款或邮件，原文也没有讨论补偿和回滚。

与临时杀进程相比，这套方案补上了业务检索、恢复和审计能力；代价是平台需要维护任务状态与控制接口。是否需要完整落地，要看 Agent 的执行规模和外部操作风险。

能拿来做什么

• 为现有 Agent 运行补充名称、客户等业务标识，让负责人可以按业务对象查找并批量停止任务。
• 检查 Node 或工作流服务中的终止逻辑，确认它覆盖子任务和并行任务，同时把 Suspend、Terminate 的影响写清楚。
• 排查支付、邮件等 API 的重试路径，确认停止后恢复不会重复产生外部效果，并核实下游的幂等支持。
• 安排一次预发布演练，让实际负责人独立完成中途停止和恢复，记录耗时，再检查自动阈值与审计记录是否接通。