这套逻辑完全失效，甚至Ke以说是致命的。

想象一下你正站在嘈杂的车间里传送带以每分钟几十米的速度运转。AOI设备正在疯狂抓拍，而背后的 Agent 正在等待 LLM 返回判决结果：这个批次是放行还是拦截？这时候，API 超时了。

站在设备前的操作员还在盯着屏幕等结果。你总不Neng直接给他返回一个 Python 的 Traceback 吧？或者geng糟糕，直接让程序卡死，导致整条产线因为一个 API 的响应延迟而被迫停线？

当“重试”变成一种奢侈

这绝对称得上是个严重的生产事故。我见过太多因为小问题导致大灾难的例子。记得有一次整条产线停摆了半天原因竟然只是因为一个负责物料的小插件没有按原计划抵达。急急挂了

“重试”不是一个Ke以随便拍脑袋Zuo的决定。Ru果 Agent 正在等待 AOI 的检测结果来判决当前批次是否放行，你贸然重试 3 次每次等 5 秒，整条线就多等了 15 秒。在工业现场，节拍往往是以秒计算的。15 秒的延迟，意味着堆积的半成品、浪费的产Neng，甚至可Neng导致下游的断供。在这个分秒必争的世界里这是绝对不Neng接受的。

过往云烟我Zuo品质组长的时候，生产主管和生产组长对我是又怕又恨。为什么？因为我说停线就得停线，绝不像视频里那样拖泥带水。下班后我从来不跟产线的人走太近，Zuo品质的人得有底线和原则，不然没法Zuo。有问题Ke以向上按流程反馈，但底线不Neng破。就像那次10分钟我没见到料，我就踏平仓库。哼！收个蛋啊！点个数dou点不清楚！这种对“确定性”的执着，是工业人的本Neng。

LLM 的不可靠性与工业级的确定性

接上一篇，我们聊了工具注册中心让 Agent Neng操控 AOI 设备。但下一个问题geng棘手：每次工具调用背后dou有 LLM 调用，而 LLM API 的可靠性，跟工业相机那种硬核设备比起来差了至少两个数量级。

工业设备有个基本假设：你发指令，它执行，响应时间可预测。AOI 相机的采集延迟是毫秒级确定的，运动控制卡的响应周期是固定的——它可Neng不快，但极其稳定。你不会担心相机突然“思考”人生，或者运动控制卡因为“请求过多”而拒绝响应。

LLM API 不是这样的。它可Neng会抽风，可Neng会限流，可Neng会莫名其妙地超时。就像那个让人头疼的仓库管理员，后来产线反馈，因为他的原因，来拿料的人找不到料，结果产线停线了。挂了 构建防御工事：LLMGuard 的核心逻辑

所以我们需要一个像“LLMGuard”这样的中间层。这玩意儿本身代码量不多，核心逻辑也不复杂。真正的工程难点不在代码量，而在想清楚每次失败后系统应该处于什么状态。这需要你真的在产线上跑过被痛骂过才知道哪些错误类型Zui常见、降级到什么程度还Neng接受。

每一次 LLM 调用，无论经历了什么路径——是直连成功？重试后成功？切换备用模型成功？缓存命中？还是优雅降级？——Zui终dou必须返回同一个结构化的对象：

@dataclass
class LLMResult:
    content: str          # 生成的文本
    model: str            # 实际用的模型
    latency_ms: float     # 总耗时
    success: bool
    attempts: int         # 经历几次调用才拿到结果
    is_fallback: bool     # 是不是降级结果
    fallback_level: int   # 0=主模型, 1=备用, 2=缓存, 3=兜底
    recovery_hint: str    # 给 Agent 的恢复建议："限流中，建议降低调用频率"

Agent 的上层逻辑不需要关心底层重试了几次它只kan success 和 content。但是recovery_hint 这个字段至关重要。它会告诉 Agent 为什么失败以及怎么恢复。这对构建自愈型 Agent 至关重要。比如Ru果提示说“当前模型触发限流”，Agent 就Ke以决定暂时跳过非关键的工具调用，只保留 AOI 检测和 XML 读取这两个核心工具，苟住活下来。

容错的第一步：判断要不要重试

容错的第一件事不是“怎么重试”，而是判断要不要重试。不是所有错误dou值得再试一次。Ru果是认证错误，你重试一万次也是白搭；Ru果是参数错误，重试只会让服务器geng讨厌你。

我们需要一个分类器：

class LLMErrorClassifier:
    STATUS_MAP = {
        429: RATE_LIMIT,
        500: SERVER_ERROR,
        401: AUTH,
        ...
    }
    KEYWORD_RULES = 

这里有个细节值得大书特书：从 HTTP 响应中提取 Retry-After header。Ru果 API 明确告诉你“请等待 5 秒后再试”，你就老老实实精确等 5 秒——而不是用通用的退避公式算一个 1s -> 2s -> 4s 的序列。精确等待意味着恢复时间可控，意味着你Neng给操作员一个准确的预期。

降级策略：从主模型到兜底方案

当主模型连续失败后我们不Neng干等着。我们需要一条层层递进的降级链：

DeepSeek-Chat速度快，成本低。

DeepSeek-Reasoner推理Neng力geng强但geng慢，作为保底。

LLM 响应缓存近期成功调用的语义匹配。

兜底回复“检测系统暂时异常，请稍后重试或切换人工复判模式”。

缓存降级在这一层特别有用。 AOI 产线的 Agent 对话有hen强的重复性——“分析这张图的缺陷类型”、“检查当前 canny 阈值是否需要调整”、“输出这批的 NG 统计”。这些 prompt 的语义高度相似。我们在实际使用中发现，一个简单的 LRU 缓存，其命中率比想象的高得多。当 API 全挂的时候，缓存仍然Ke以返回上一次相似分析的结果结构。虽然可Neng不是Zui新的，但至少Neng给 Agent 一个参考，避免系统彻底瘫痪。

缓存 key 的生成方式直接但不粗暴：

key = hashlib.md5 + "|" + model).hexdigest

在 Agent 循环中，消息格式高度结构化，hash 冲突在实际风险中几乎Ke以忽略不计。

重试的艺术：不仅仅是 Sleep

固定等待 5 秒重试 3 次的Zuo法，在分布式系统里是大忌。这叫“惊群效应”，或者geng直白点，叫“DDoS 自己”。

所以重试策略必须带上递增超时和随机抖动

for attempt in range:
    # 每次重试给geng长的超时
    current_timeout = min), max_timeout)
    try:
        response = client.create
        return response
    except Exception as exc:
        err_type, retry_after = classify
        if not err_type.retryable:
            break  # 认证/参数错误不重试
        delay = retry_after or ))
        delay = min
        delay *=  * 0.5)  # 抖动
        time.sleep

这里的 jitter不是什么算法优化，它是分布式系统的生存策略。没有它，当网络恢复时所有挂起的请求会在同一毫秒触发，瞬间把服务器 打挂。就像产线Zui怕的那样：不稳定、停线、查故障慢。第一级小交换机挂了后面所有设备全断；一根线松了一片区域离线。产线就是：停线！停线！停线！

与 Agent 的无缝集成

我们在产线服务器上把它封装成一个健康检查服务，每15分钟自动调用一次异常立即飞书告警。LIC_ERR_203 意味着不是服务器挂了而是你的机器连不上那个 IP。把它放进 Jenkins 的 pre-build 步骤，只要哈希不对，构建直接终止——宁可停线，也不让带毒工具链污染固件二进制。

同样的道理，LLMGuard 的 API 设计成原始的 OpenAI 消息格式。为了让它在 LangGraph 的 create_react_agent 中无缝替换 ChatOpenAI，我们需要一个轻量的 LangChain wrapper：

class GuardedChatModel:
    guard: LLMGuard
    def _generate:
        # LangChain messages → OpenAI dicts
        # LangChain tools → OpenAI function calling format
        result = self.guard.chat
        # OpenAI response → LangChain AIMessage 
        ...

这对 Agent 循环完全透明。它只知道自己在调一个 ChatModel，不知道下面重试了 3 次还切了一次备用模型。这种封装让业务逻辑保持干净，不需要到处充斥着 try...except 的垃圾代码。

工程是关于妥协的艺术

你板子烧了电源挂了信号完整性测试不通过接插件接触不良，总线挂了……把你的东西拿掉就好了。有人被你东西电了你芯片功Neng太弱了你芯片功Neng太冗余了你代码怎么不那样注释，你程序构架有问题，你程序有 bug……

面对这些指责，我们需要的不是完美的代码，而是健壮的系统。LLMGuard 就是这样一种尝试：在不可靠的网络和模型之间，构建一道可靠的防线。它承认失败，处理失败，并尽力在失败中继续前行。

下一篇，我可Neng会写Zui核心的模块：AOI XML 配置 。也就是 Agent 怎么读懂检测参数、判断调整方向、安全地写入上位机配置。这是整个项目里跟“通用 Agent”Zui无关、跟我的日常工作关系Zui紧密的部分。毕竟我们不是为了用 AI 而用 AI，而是为了解决那个让人半夜三点惊醒的问题：产线别停。

---