避坑指南：在生产环境部署 LLM Agent 时的“状态漂移”与一致性陷阱

在 AI Lab 的实际交付过程中，我们经常遇到一个极具欺骗性的问题：Agent 在开发环境（Dev）表现完美，但在生产环境（Prod）运行一段时间后，逻辑开始出现不可预知的“漂移”。

很多团队将其归结为模型随机性（Temperature），但经过深度复盘，我们发现核心问题在于“状态管理”的工程缺陷。

1. 什么是状态漂移？

在复杂的 Agent 工作流中，Agent 需要维护一个上下文状态（State）。当这个状态在分布式环境下传递，或者在长对话中被不断压缩/总结时，会产生两种漂移：
- 语义漂移：Agent 在第 10 轮对话时，忘记了第 1 轮设定的严格约束。
- 结构漂移：Agent 输出的 JSON 格式在压力测试下偶尔缺失关键字段，导致下游解析崩溃。

2. 实战教训：从“全量记忆”到“结构化快照”

早期的方案是简单地将所有历史记录（Chat History）喂给模型。结果是：随着 Token 增加，模型对指令的遵循度呈线性下降。

优化方案：引入 State Snapshot（状态快照）机制。
我们将 Agent 的状态分为三层：
- Core Identity (不变)：系统级 Prompt，强制锁定角色和禁忌。
- Session Context (动态)：当前任务的关键变量（如 user_id, current_step, goal），以结构化 JSON 形式存储在 Redis 中，每轮迭代强制刷新。
- Working Memory (临时)：最近 3-5 轮的原始对话。

通过这种方式，即使对话很长，Agent 在每一轮开始前都会重新读取一次“结构化快照”，确保其目标没有偏移。

3. 工程实践：防御性输出验证 (Guardrails)

不要信任 LLM 的 JSON 输出。在生产环境中，我们实施了“验证-重试”循环：
1. Schema 强校验：使用 Pydantic 定义严格的输出模型。
2. 自修复机制：如果校验失败，将错误信息（例如 Missing field 'action_id'）直接反馈给模型进行一次快速修正（Fast-Retry），而不是直接报错给用户。
3. 确定性路由：对于关键的分支判断（如：是否需要调用支付接口），不再依赖 LLM 的自然语言描述，而是要求其输出特定的枚举值（Enum），并在代码层做硬映射。

4. 给工程团队的建议

如果你正在构建一个面向用户的 Agent 产品，请记住：LLM 是不稳定的组件，而工程架构必须是稳定的。

• 不要试图用 Prompt 解决所有逻辑问题 $\rightarrow$ 用代码定义工作流（DAG），用 LLM 完成节点内的内容生成。
• 监控不仅仅是 Token 数 $\rightarrow$ 建立“意图达成率”和“格式错误率”的监控指标。
• 版本控制不仅是代码 $\rightarrow$ Prompt 的微小变动可能导致整个 Pipeline 的崩溃，必须像管理代码一样管理 Prompt 版本。

文字炼金的本质不是追求完美的咒语，而是构建一套能够容忍不完美输出的工业级流水线。