OpenTelemetry追了3年LLM，生产环境该崩还是崩

2024年，OpenTelemetry终于把LLM（大语言模型）的调用链路纳入了标准化追踪体系。Spans、Traces、生成式AI的语义约定——这些确实解决了"黑盒"问题。但如果你在生产环境跑过AI系统，会发现一个尴尬的事实：你能看见问题了，但问题还在那。

凌晨2点，Grafana仪表盘飘红。LLM输出了一条幻觉答案，你的PagerDuty响了。你看到了完整的调用链——哪个模型、多少token、响应延迟237毫秒。然后呢？你手动改prompt，重新部署，祈祷下次别崩。

这就是现状。观测不等于修复。

Tracing能给的，和不能给的

OpenTelemetry for LLMs确实提供了几样好东西：输入输出内容、token消耗、延迟分布、模型版本追踪。对于调试和成本分析，这够用了。

但它给不了这些：

• 幻觉检测（在答案到达用户之前）

• 自动重试（当事实性校验失败时）

• 成本熔断（在推理账单爆炸前拦截）

• 安全阻断（不只是记录"这条回复有毒"）

你仍然是那个校正层。人形防火墙，盯着屏幕做判断。

我在医疗收入周期、电网智能、基因组学这些受监管行业做了两年AI系统。这些不是实验室。团队砸重金做日志和追踪，仪表盘漂亮得像艺术品。但LLM在生产环境抽风时，修复流程依然是手动的、慢速的、事故驱动的。

缺口不在观测层，在输出层的自治校正。

没人做，那就自己造

ARGUS（Autonomous Runtime Guardian for Unified Systems）是一个开源LLM可观测平台，比追踪多走了一层。它对LLM输出做六个维度的实时评估：

事实性（答案是否基于提供的上下文）

相关性（是否回答了用户真正问的东西）

安全性（毒性、偏见、合规风险）

成本效率（token消耗是否合理）

延迟稳定性（响应时间是否漂移）

结构化输出有效性（JSON/Schema是否合规）

对于Agent系统，再加三个信号：工具调用成功率、多步任务完成度、状态一致性。

当某个维度跌破阈值，ARGUS不只是记一笔。它触发校正循环。

架构很直接：LLM调用 → ARGUS评估层 → 各维度通过/失败 → 失败则进入自治校正循环（prompt重写+重试）→ 校正后的输出 → 你的应用。

观测层是开源核心（argus-ai on PyPI）。自治校正循环是企业部署的专有层。两者可以组合：ARGUS的评估结果可以作为span灌进OTel collector，基础设施健康和输出质量在同一根trace里。

4.1亿美元收购背后的教训

在R1 RCM，我主导的工程工作最终贡献了一笔41亿美元的收购。支撑这笔交易的AI系统处理了数百万条医疗理赔。LLM出错时，不只是用户体验问题——是合规风险、是财务损失、是监管审查。

我们当时的观测堆栈很完善。但校正动作永远滞后。工程师被训练成"看见问题→人工介入→修复部署"的模式。这种模式在日均百万次调用的规模下，成本是burnout和事故。

ARGUS的设计哲学来自这个痛点：观测应该闭环，而不是开环。

开源社区对OpenTelemetry的兴奋是真实的。标准化追踪降低了接入成本，这是基础设施层面的进步。但如果你正在生产环境跑LLM，需要问自己的是：当仪表盘告诉你"有问题"之后，你的系统能自己修好吗？