Mlops

LLM 与 AI Agent 可观测性 传统微服务常看请求量、错误率和耗时，到了 AI 应用里，也可以先用 Token、Error、Duration 建立一组基础指标；不过这三项只能说明服务有没有运行、花了多少钱、速度是否正常，还不能回答模型为什么给出了这个结果，更无法判断一次 HTTP 200 背后的答案是不是正确。 对普通 LLM 调用来说，一次请求已经可能包括 prompt 拼装、模型推理、内容清洗和结果返回；换成 LLM Agent / AI Agent 后，链路还会加入意图识别、RAG 检索、工具选择、参数构造、多次 LLM 调用与重试，因此真正需要建设的不是“多打一批日志”，而是让整条执行轨迹能够被还原、评分和归因。 1. 为什么传统 APM 还不够 传统 APM 擅长回答“哪里慢了”“哪里报错了”，但 AI Agent 会出现一些没有异常堆栈的失败，例如模型很自信地答错、选中了相似但不适用的工具、参数类型正确却语义错误，或者在几个工具之间来回循环，最终造成 token 和账单持续增长；这些现象在 HTTP 状态码上可能全部是成功，用户拿到的结果却不可用。 因此，AI Agent 可观测性至少要能回答下面几类问题： 一次任务内部执行过哪些步骤，每一步花了多少时间和 Token RAG 召回了哪些文档，排序和 score 是否合理，最终答案有没有使用这些证据 Agent 选择了哪个工具，tool args 是否正确，调用顺序与依赖关系有没有被满足 最终输出是否准确、相关、完整，格式和安全要求有没有达到 失败发生在 Prompt、retrieval、Tool、LLM 还是 orchestration，能否复现到具体 span 单次请求、用户、组织和模型分别产生了多少成本，异常调用是否触发了熔断或 fallback AgentTrace 将结构化轨迹分为 operational、cognitive、contextual 三类 surface，并把可观测性用于安全、可复现性、问责与实时监控；这类设计比单纯保存最终 input/output 更接近 Agent 的实际运行方式。 ...