12-production-best-practices 生产实践：观测、安全、成本、评测和持续演进

LangChain4j 进阶实战：第 12 篇，生产实践：观测、安全、成本、评测和持续演进

前言

很多大模型应用 Demo 看起来很顺：

用户输入 -> 大模型 -> 返回答案

但真正上线后，问题会集中出现：

• 为什么今天回答变差了？
• 为什么同一个问题昨天可以，今天不行？
• 为什么 token 成本突然上涨？
• 为什么工具调用失败了？
• 为什么 RAG 检索到了错误资料？
• 为什么模型返回了不存在的 ID？
• 为什么用户 A 看到了用户 B 的数据？
• Prompt 改坏了怎么回滚？

这些问题不是 LangChain4j 某一个 API 能解决的，而是 AI 应用生产治理问题。

这一篇作为系列收尾，重点讲生产环境里必须补上的能力：观测、安全、成本、评测、灰度、降级和持续演进。

1. Demo 和生产系统的差距

Demo 关注：

功能能不能跑通

生产系统关注：

长期运行是否稳定、可控、可解释、可回滚

对比一下：

我的理解是：AI 应用上线不是把 Demo 部署到服务器，而是把不可控的模型能力放进可控的软件工程体系里。

2. 调用日志：先做到可观测

AI 系统必须记录调用日志，否则问题很难排查。

建议每次模型调用记录：

requestId userId agentCode agentVersion workflowExecutionId modelName temperature maxTokens input output promptTokens completionTokens totalTokens latencyMs status errorMessage createdAt

如果涉及 RAG，还要记录：

retrieverName query topK minScore filter retrievedSegmentIds retrievedScores sources

如果涉及工具，还要记录：

toolName toolArguments toolResult toolLatencyMs toolStatus

日志不只是排错用，也用于后续优化：

• 哪些 Agent 最耗 token。
• 哪些问题经常检索不到。
• 哪些工具失败率高。
• 哪些 Prompt 版本效果变差。
• 哪些用户场景最常见。

注意：日志里可能包含隐私信息，生产环境要做脱敏和访问控制。

3. requestId 贯穿全链路

一个复杂 AI 请求可能经过：

Controller Workflow Agent Memory RAG Milvus MCP Tool Model Provider Database

必须有统一requestId贯穿。

建议：

publicclassAiRequestContext{privateStringrequestId;privateStringuserId;privateStringagentCode;privateStringworkflowExecutionId;}

日志格式：

[requestId=xxx] [userId=10001] [agent=outfit_agent] start model call

否则线上排查时，你会看到一堆零散日志，却拼不出完整链路。

4. Prompt 版本管理

Prompt 是 AI 应用里的“业务逻辑”。既然是业务逻辑，就不能随便改。

建议 P