一个人的 AI 工作流，停止条件要写在开始之前

一个人跑 AI 工作流，最危险的时刻通常不是第一次失败，而是失败以后系统还在继续。它换一种说法、再调一次工具、再生成一版，看起来一直有动作，实际上可能没有增加任何新证据。时间、调用额度和错误影响就在这种“还差一次”的循环里被放大。

我更在意的不是工作流能连续跑多久，而是它能不能在不确定时停在一个可恢复的位置。停止条件应该在开始前写好，而不是出事后临时决定。

停止不是失败，是把判断权拿回来

OpenAI 的 Agent 指南把两类人工介入触发器说得很直接：超过失败阈值，以及即将执行敏感、不可逆或高风险动作。NIST 的 AI 风险管理框架也要求运行中的系统具备监控、人工覆盖、事件响应和恢复机制。它们共同指向一个很朴素的设计：自动化可以自己往前走，但不能自己决定什么时候值得继续冒险。

社区讨论里经常出现循环调用、反复修正和越改越乱的个案。这些只能算实践信号，不能证明所有 Agent 都会失控。不过它足以提醒一个人经营业务的人：不要把“模型还愿意继续”误当成“这次重试有价值”。

先写下三类停止条件

• 失败次数到上限：同一个动作连续失败，且新一轮没有带来新的错误信息，就停止。具体是一两次还是更多，取决于任务成本；关键是上限由工作流计数，不交给模型自己感觉。
• 结果没有实质变化：连续两版只是换措辞、换顺序，验收项仍然不通过，就停止。继续生成不是进展，只有新的证据或新的可检查结果才算。
• 下一步会扩大后果：发送、付款、删除、覆盖、公开发布或改动账号权限前，直接交回人工。即使前面全部成功，高风险动作也不靠累计信心自动放行。

Google Cloud 的重试文档给了一个很实用的工程边界：没有退避地重试、无条件重试非幂等操作，以及重试本来就不会自行恢复的错误，都会让问题更严重。放到个人 AI 工作流里，可以翻成一句话：只有错误可能短暂恢复、动作可以安全重复，而且每次尝试都有上限时，重试才有意义。

停下来时，至少留下四样东西

• 已经完成到哪一步，以及最后一次可用结果在哪里。
• 最后一次失败的原始原因，不让后续摘要把它改写成猜测。
• 本轮试过哪些动作，哪些动作明确没有效果。
• 恢复需要谁确认、从哪一步继续，以及什么结果才算通过。

这样做的价值不是让错误报告更漂亮，而是避免下一次从头猜。停止点保存的是工作状态，也是你继续、回退或放弃这条路径时的决定材料。

恢复也要有验收，不是点一下“再来”

我们用本地示例数据复现了一次内容发布任务的异常恢复。页面没有把“重新开始”当成结果，而是依次检查准备环境、任务状态、AI 伙伴和最终结果；四步完成后，仍然把“问题修复了吗”留给人确认。这个顺序很重要：技术动作完成，只能说明恢复流程跑完了，不能替你判断业务结果是否可用。

如果你准备把一件重复工作交给 AI，先在任务卡上补三行：最多重试几次，什么变化才算进展，哪一步必须停下来叫你。工作数据默认留在本机；仅你主动接入的渠道与模型调用按任务所需出网。先让失败可控，自动化才有资格长期运行。