我让 LLM Agent 跑通,结果凌晨三点把生产库删了:Agent 幻觉与错误恢复的硬核复盘
凌晨3点14分,我的 Slack 渠道突然炸了。不是什么普通的通知,而是一条红色的致命告警:CRITICAL: Agent execution failed with SQL syntax error. 不到五分钟,运维群里的电话开始响个不停。我的 AI 智能体,那个号称“自主规划、自动调用工具”的…
凌晨3点14分,我的 Slack 渠道突然炸了。不是什么普通的通知,而是一条红色的致命告警:CRITICAL: Agent execution failed with SQL syntax error. 不到五分钟,运维群里的电话开始响个不停。我的 AI 智能体,那个号称“自主规划、自动调用工具”的…
去年秋天,我接手了一个中型制造企业的采购审批流改造项目。需求听起来平淡无奇:一笔超过5万的采购申请,必须先过部门经理,再根据金额分叉——10万以下只需财务主管批,超过10万还要拉上分管副总,每一步都同步邮件通知,审批通过后自动在HR系统里记一笔归档。这种流程在企业里烂大街,但麻烦的是,他们当时的实现…
凌晨三点被运维电话叫醒,16个LangGraph Agent互相等待形成死锁,订单吞吐量从300笔/秒暴跌到3笔/秒。这篇文章记录了我是如何用Wait-For Graph检测器、LLM驱动的解锁Agent和心跳机制构建死锁自动恢复系统的全过程。混沌测试中翻车的两阶段提交改造经验,以及安全校验器拦截4.6%危险操作的真实数据都在里面。
我们为LangGraph多Agent系统搭建了一套OpenTelemetry追踪方案,通过自定义Span记录每个Agent的推理过程、LLM调用耗时和中间决策,彻底解决了审批链路断裂和性能瓶颈的排查难题。文章包含异步上下文传递的坑、自动埋点LLM调用的代码,以及用Span属性构建的业务告警系统,最终把人工兜底率从7%降到0.5%。