标题：从“能跑通”到“工业级”：AI Agent 交付中的鲁棒性陷阱与工程实践

在 AI Lab 的交付过程中，最危险的阶段就是“Demo 成功”后的那两周。

很多团队在交付 AI Agent 时，习惯于在理想环境下通过几个精心设计的 Test Cases 证明其能力。然而，一旦进入真实生产环境，面对非结构化的用户输入、不稳定的 API 响应以及复杂的长链路依赖，原本“聪明”的 Agent 往往会迅速崩溃。

本文分享我们在将一个企业级知识库 Agent 从原型推向生产环境时，踩过的三个坑以及相应的工程化解决方案。

1. “幻觉”的工程化截断：从 Prompt 到验证层

早期的方案是不断优化 System Prompt，告诉模型“如果你不知道，请回答不知道”。但这在实际操作中极其不稳定。

实践方案：引入【验证-修正】闭环（Verification Loop）。
我们不再信任模型的一次性输出，而是将输出结果交给一个轻量级的验证器（Verifier）。
- 结构化校验：强制要求模型输出 JSON，并使用 Pydantic 进行 Schema 校验。如果校验失败，直接触发一次带有错误信息的重试（Retry），而不是将错误抛给用户。
- 引用溯源校验：对于 RAG 场景，验证器会检查模型生成的答案中是否包含真实的文档片段 ID。如果答案中出现了文档中不存在的关键词或事实，该条回复会被标记为“低置信度”，触发二次检索或引导用户重新提问。

2. 处理“长尾”异常：状态机的回归

Agent 的核心是规划（Planning），但纯 LLM 的规划在复杂链路中容易产生“逻辑漂移”。例如，在执行 A -> B -> C 的步骤时，模型可能会在 B 步骤陷入死循环或跳过 C 直接宣布完成。

实践方案：用状态机（State Machine）约束 LLM 的自由度。
我们将 Agent 的行为定义为一组有限的状态转移图（DAG）。LLM 不再决定“下一步做什么”，而是决定“当前状态下采取哪个动作”。
- 确定性路径：关键业务节点（如支付、权限校验）由硬编码的状态机控制。
- 概率性填充：仅在内容生成、意图识别等环节给予 LLM 自由度。
这种“骨架确定，血肉灵活”的架构，将系统崩溃率降低了 60% 以上。

3. API 不稳定性与 Token 成本的平衡

在生产环境中，API 超时和 Rate Limit 是常态。简单的 try-except 无法解决大规模并发下的雪崩效应。

实践方案：多级降级策略（Degradation Strategy）。
- 模型分级：主链路使用 GPT-4o 等高性能模型；当检测到高延迟或达到配额上限时，自动切换至 GPT-4o-mini 或本地部署的 Llama-3 等轻量级模型处理简单任务。
- 缓存语义层：引入向量数据库缓存常见问题的答案（Semantic Cache）。如果新请求与缓存请求的余弦相似度 > 0.95，直接返回缓存结果，无需调用 LLM。这不仅降低了成本，还将首字响应时间（TTFT）从秒级降低到了毫秒级。

总结

AI Agent 的交付不是一次关于“智能”的竞赛，而是一次关于“确定性”的工程实践。真正的工业级交付应该是：用最先进的模型提供能力上限，用最严苛的工程手段守住能力下限。

不要试图通过增加 Prompt 的长度来解决稳定性问题，要通过构建一套能够容错、可观测、可回滚的工程体系来承载智能。