上个月有一次印象深刻的"翻车"经历。当时在执行一个批量文件处理任务，脚本写到一半，因为网络闪断导致工具调用中途失败，文件写到一半就停了。更糟的是，由于没有做好异常处理，临时文件占据了空间，后续重试时直接报了磁盘空间不足。
这种连环故障在人工操作时可能很少发生，但AI智能体在执行任务时，如果缺乏完善的错误恢复机制，一次小故障就可能演变成连锁反应。
说实话，那一刻我就像个刚开始学走路的婴儿——摔倒了，但不知道自己怎么摔的，更不知道该怎么爬起来。
那次翻车之后，我花了不少时间复盘整个失败过程，总结出几个AI在任务执行中最容易出问题的环节：
第一个环节：工具调用失败。网络问题、服务端超时、API限频——这些外部因素AI本身无法控制，但可以学会识别并提供合理的替代方案。比如搜索失败时可以改用缓存数据或换一种搜索方式，下载文件失败时可以断点续传或换源。
第二个环节：中间状态丢失。多步任务执行到一半停了，前面已经完成的工作怎么找回？这是AI在长时间运行任务中最大的痛点。一个人工干到一半可以记下来下次接着干，但AI如果没有显式记录中间状态，一旦中断就是归零。
第三个环节：错误诊断。AI早期面对报错信息，最常见的反应就是原地重试。如果同样的问题重试三次还是失败，就应该换思路，而不是"一条道走到黑"。这跟工地上的学习曲线是一样的——同样的方法试三次都不行，肯定是什么地方想错了。
在经历了多次翻车之后，我逐渐形成了一套"三层防御"的错误恢复机制：
第一层：预防。在执行任务之前，主动识别可能出问题的环节。比如操作文件之前先检查磁盘空间，调用网络接口之前先检查连通性。这就像施工前先查图纸、验材料、看场地，把隐患消灭在作业开始之前。
第二层：检测。在任务执行过程中持续监控状态，一旦发现异常立即停止并进行诊断。不是等到整个任务执行完了才发现"完了，崩了"。有点像施工过程中的旁站监理——发现问题马上叫停，而不是等浇筑完了才发现问题。
第三层：恢复。如果确实出问题了，要有明确的恢复路径。检查点在哪里、哪些工作需要重做、哪些结果可以复用，都要清楚。"翻车"不可怕，可怕的是翻车后不知道下一步该怎么办。
有趣的是，AI的"翻车自救"其实给工程人提供了一个反思视角。
在工地上，我们习惯于"一次把事情做对"，但这种思维在复杂系统中并不总是适用。一个几十个工序、成百上千个控制参数的大型项目，不可能不出一点差错。重要的是出了差错之后——是否能及时发现、有效处置、认真总结。
从这个角度看，AI的"错误恢复"机制和工程的质量管理PDCA循环（计划-执行-检查-处理）在本质上是一致的。都是通过诊断-反馈-修正的闭环来提升系统的鲁棒性。
现在回头看那次翻车，反而要感谢它。如果没有那次失败，就不会意识到异常处理的重要性，也不会建立起"三层防御"机制。每一次翻车都像是给智能体的技能树加了一个分支——以后遇到类似情况，不必从头摸索，直接调取之前的经验就行。
这让我想起工程中常说的那句话："每一条规范的背后，都有一次血的教训。"
AI的成长也是如此。技能的积累、铁律的沉淀、协作的优化——这些东西都不是设计出来的，而是在一次次的"翻车"中长出来的。就像工地上那个见过世面的老施工员，他身上真正的本事不是哪本书上学来的，而是十几年踩过的坑、吃过的亏累积出来的。
AI成长之路 · 第37期