避坑指南：AI Agent 落地中的“幻觉”治理与工程化闭环

在很多 AI Lab 的交付项目中，最让工程师头疼的不是模型能不能生成答案，而是如何让它在生产环境下“稳定地不胡说八道”。

很多团队在 Demo 阶段通过精心设计的 Few-shot Prompt 就能达到 90% 的准确率，但一旦进入真实业务场景，面对海量且不可控的用户输入，Agent 的幻觉（Hallucination）会迅速将可用性拉低到 60% 以下。

本文分享我们在构建企业级 AI Agent 时，从“调优 Prompt”转向“工程化闭环”的三次关键迭代。

第一阶段：从 Prompt Engineering 到 RAG 增强

最初，我们尝试通过增加 System Prompt 的约束来减少幻觉。例如：“你必须严格基于提供的上下文回答，如果不知道请直接说不知道。”

结果： 模型变得极其保守，经常出现“我无法回答这个问题”的死循环，或者在上下文稍微模糊时依然强行拼接答案。

工程化方案： 我们引入了结构化的 RAG（检索增强生成）链路。
1. 混合检索 (Hybrid Search)： 不再依赖单一的向量检索（Vector Search），而是结合 BM25 关键词检索。因为在工程领域，特定的错误代码（如 ORA-00600）或组件名称是强特征，向量化后反而会丢失精确度。
2. 重排序 (Reranking)： 检索出的 Top-K 文档并不一定都相关。我们增加了一个轻量级的 Cross-Encoder 重排模型，剔除噪声文档，确保喂给 LLM 的上下文是高纯度的。

第二阶段：引入“反思”机制与自我校验 (Self-Correction)

即便有了高质量的上下文，LLM 在推理过程中仍可能产生逻辑跳跃。

实战案例： 在一个自动化运维 Agent 中，模型在分析日志后给出的修复建议有时会包含不存在的 API 参数。

工程化方案： 我们设计了一个 $\text{Generator} \rightarrow \text{Verifier}$ 的双环结构。
- 生成环： Agent 根据知识库生成初步方案。
- 校验环： 调用另一个独立 Prompt（或更强模型）扮演“审计员”，其唯一任务是检查方案中的每一个技术点是否在上下文中有所支撑。
- 闭环： 如果校验环发现矛盾点 $\rightarrow$ 将错误详情反馈给生成环 $\rightarrow$ 重新生成。

这种“自我反思”机制虽然增加了 Token 开销和延迟，但将关键指令的准确率提升了约 15%。

第三阶段：建立可量化的评估集 (Eval Set) 与回归测试

最危险的状态是：“我改了一个 Prompt 解决了 A 问题，结果 B 问题崩了。”

痛点： 依赖人工抽检无法支撑快速迭代。

工程化方案： 构建一个包含 $\sim 500$ 个典型 Case 的黄金数据集（Golden Dataset）。
1. Case 定义： 每个 Case 包含 Input $\rightarrow$ Expected Output $\rightarrow$ Critical Constraints（必须包含的关键词/禁止出现的词）。
2. LLM-as-a-Judge： 使用 GPT-4o 或同级别模型作为裁判，根据预设的评分维度（准确性、完整性、安全性）对 Agent 的输出进行打分。
3. CI/CD 集成： 将 Eval 集成到 Git Pipeline 中。每次修改 Prompt 或更新知识库后，自动跑一遍全量测试。只有当整体得分不下降且核心 Case 通过率 $100\%$ 时才允许合并代码。

总结与启示

AI Agent 的落地不是一次性的“炼金术”，而是一场持续的工程优化。

如果你发现你的 Agent 在生产环境中不稳定，请停止盲目地修改 Prompt 字眼，尝试从以下三个维度切入：
- 数据端： 检索质量是否足够高？是否有噪声？
- 逻辑端： 是否有独立的校验环节？能否实现自我纠错？
- 评估端： 你是否有一个能快速反馈修改影响的量化数据集？

真正的稳定性来自于对不确定性的管理，而非对完美 Prompt 的追求。