去年有个数据：某头部云厂商的客户平均每月产生1.2亿条LLM追踪日志。但问到"有多少问题被自动修复"时，答案是0。
这就是OpenTelemetry（开源遥测框架）在LLM领域的现状——它让你看得清，却不帮你动手。
追踪能给的，和不能给的
OpenTelemetry最近标准化的LLM语义约定确实有用。输入token数、输出延迟、模型版本、温度参数——这些Spans（追踪单元）让分布式追踪终于覆盖到了生成式AI。
但作者Sean McGuire在医疗收入周期管理公司R1 RCM的经历揭示了一个断层：当LLM在凌晨2点对医保理赔做出错误判断时，你收到的只是一条Grafana告警。修复它？还得靠人。
他列出的能力清单很直白。追踪能提供：调用链可视化、延迟分析、成本归因、模型版本追踪。但不能提供：幻觉预检测、自动提示词重写、成本熔断、安全拦截。
换句话说，观测性（Observability）和自治性（Autonomy）之间差着一整层工程。
生产环境的真实剧本
McGuire过去两年在受监管行业搭建AI系统：医疗理赔、电网智能、基因组学流水线。这些场景没有"回滚到昨天版本"的奢侈。
他看到的重复模式：团队砸重金建仪表盘，LLM出错时流程仍是"人工-慢速-事故驱动"。日志再漂亮，决策层还是人。
这个缺口他定义为"输出层的自治修正"。市场空白，于是他做了ARGUS。
ARGUS的架构设计把评估和动作拆成两级：LLM调用先过ARGUS评估层，六个维度实时打分——事实准确性、语义连贯性、指令遵循度、风格一致性、敏感信息泄露、成本效率。Agent系统再加三个：工具调用正确性、循环终止判断、状态一致性。
任一维度阈值触发失败，系统不记录完事，而是进入自治修正循环：提示词重写+重试，修正后的输出才返回应用。
开源层管观测，企业层管自治——这个分层和OpenTelemetry不是替代关系，是拼接关系。ARGUS的评估结果可以作为Spans喂给OTel采集器，基础设施健康和输出质量落在同一条追踪链里。
4.1亿美元收购背后的技术债
McGuire在R1 RCM主导的工程工作支撑了后者41亿美元的收购。系统每月处理数百万条医疗理赔，LLM出错不只是用户体验问题，是合规风险。
他学到的教训被写进ARGUS的设计：追踪数据的价值在行动闭环，不在存储成本。
目前ARGUS的开源核心（argus-ai）已上架PyPI，自治修正层面向企业部署。项目刚发布，GitHub星数还在两位数——但作者的生产背景让这套方法论有真实场景背书。
一个值得玩味的细节：McGuire在文末留了ARGUS的架构图，却刻意没放性能基准数据。是还没跑完大规模测试，还是觉得"自治"本身比数字更难量化？
如果你正在用OpenTelemetry搭LLM监控，你会满足于"看见问题"，还是想要"解决问题"？
热门跟贴