1. 为什么 LLM 应用上线后传统监控突然不够用了做过几年后端监控的人第一次接手 LLM 应用运维时大概率会经历一段相当别扭的时期。CPU、内存、QPS、P99 延迟这些指标全都绿着告警面板干干净净但用户投诉却一条接一条回答答非所问、工具调用莫名其妙失败、同一个问题昨天答得好今天答得烂、账单月底一看比预期翻了五倍。你打开传统 APM 一看接口 200耗时 800ms一切正常。问题就出在这个正常上——传统可观测体系压根没打算观测模型在想什么。这就是 AgentOps 要解决的事情。简单说AgentOps 是把 DevOps 和 MLOps 的思路延伸到 AI Agent 这一层专门观测 LLM 调用链路、Agent 决策过程、工具调用、Token 消耗、检索质量、会话状态这些传统监控覆盖不到的东西。它观测的对象不是服务是否活着而是Agent 是否在做正确的事、花了合理的成本、给出了可信的答案。我这次要分享的是基于观测云搭建一套完整的 AgentOps 运维体系的实践。观测云本身是一套国内比较成熟的统一可观测平台支持指标、日志、链路追踪、RUM、安全巡检等多种数据类型的统一接入天然适合做这种多源异构数据融合的活儿。LLM 应用的数据形态特别杂有结构化指标Token 数、延迟、有半结构化日志Prompt、Completion、有链路数据Agent 调用链、还有非结构化的语义质量评估结果。观测云在这块的整合能力是我选它的核心原因。这篇文章适合三类人看一是正在把 LLM 应用往生产环境推的后端或平台工程师二是负责 AI 产品稳定性与成本的 SRE/运维同学三是想搞清楚Agent 上线之后到底该盯什么的技术负责人。不管你是刚接触 LLM 开发还是已经踩过几轮坑下面的内容应该都能直接抄作业。2. AgentOps 到底要观测什么核心对象与数据模型拆解2.1 从 LLM 到 AI Agent观测对象的层级变化很多人把 LLM 和 AI Agent 混着说但在可观测这件事上两者差别巨大。LLM 是一个输入文本、输出文本的函数观测它主要看调用成功率、延迟、Token 消耗、内容质量。而 AI Agent 是一个感知—规划—行动—反思的循环体它内部会调用 LLM、调用工具、读写记忆、做多轮决策。观测 Agent 相当于观测一个分布式系统只不过它的服务是模型和工具请求是用户意图。我一般把观测对象分成四层这个分层直接决定了后面数据模型怎么设计层级观测对象典型指标/数据传统监控是否覆盖L1 基础设施层GPU、容器、网络显存占用、GPU 利用率、网络延迟覆盖L2 模型调用层LLM API 调用首 Token 延迟、总延迟、Token 数、错误码部分覆盖L3 Agent 决策层规划、工具调用、记忆读写工具调用成功率、循环轮次、决策路径不覆盖L4 业务语义层回答质量、幻觉、用户满意度相关性评分、幻觉率、会话完成率不覆盖传统 APM 基本只覆盖 L1 和 L2 的一部分L3 和 L4 是 AgentOps 的主战场。这也是为什么很多团队上了 LLM 应用之后监控面板看着漂亮但心里没底——因为真正会出问题的地方压根没被观测到。2.2 AgentOps 的核心数据模型Trace、Span、Event 三层结构观测云的数据模型基于 OpenTelemetry 标准天然支持 Trace/Span 结构。落到 AgentOps 上我建议这样映射Trace一次会话或一次任务代表用户发起的一次完整请求比如帮我分析这份财报并生成摘要。一个 Trace 可能包含多轮 LLM 调用、多次工具调用。Span一次具体操作Trace 下的子单元。一次 LLM 调用是一个 Span一次工具调用是一个 Span一次向量检索也是一个 Span。Span 之间可以有父子关系形成决策树。Event关键事件点Span 内部的关键节点比如Prompt 组装完成模型开始返回工具返回异常。这个结构的好处是你可以沿着 Trace 一路下钻看到 Agent 到底走了哪条决策路径。我见过一个典型故障Agent 在处理退款请求时先调了订单查询工具又调了一次订单查询工具再调了一次……循环了 7 次才给出答案。传统监控完全看不出来但在 Trace 视图里7 个重复的 Span 一目了然。2.3 为什么选观测云而不是自建 Prometheus Grafana这个问题我被问过很多次。自建方案不是不行但有几个现实痛点第一LLM 数据是非结构化的。Prompt 和 Completion 都是长文本塞进 Prometheus 的 label 里会直接爆炸。观测云支持日志和链路数据统一存储长文本处理更自然。第二语义质量评估需要外部数据源。幻觉检测、相关性评分这些往往由另一个模型或人工标注产生需要和链路数据关联。观测云的关联查询能力比 Prometheus 强不少。第三成本核算需要多维度聚合。Token 成本要按模型、按用户、按业务线、按时间段聚合Prometheus 做这种多维分析很吃力。当然观测云也不是银弹。如果你的团队已经有成熟的 ELK Prometheus 体系也可以只把 L3、L4 的数据接进去L1、L2 继续用原有体系。关键是别指望一套工具解决所有问题。3. 搭建 AgentOps 体系的完整实操流程3.1 第一步埋点设计决定你能看到什么埋点是整个体系的地基埋错了后面全白搭。我的经验是先想清楚要回答哪些问题再决定埋什么点。常见的核心问题有这么几类这次请求为什么慢慢在模型还是工具还是检索这次回答为什么不对是 Prompt 问题、检索问题还是模型问题这次花了多少钱哪个业务线、哪个用户、哪个模型最烧钱Agent 有没有陷入死循环或异常重试针对这些问题我设计了一套最小可用埋点集覆盖 LLM 调用、工具调用、检索、会话四个维度# 基于 OpenTelemetry 的埋点示例伪代码展示结构 from opentelemetry import trace tracer trace.get_tracer(agent.ops) def call_llm(prompt, model, user_id, session_id): with tracer.start_as_current_span(llm.call) as span: span.set_attribute(llm.model, model) span.set_attribute(llm.prompt_length, len(prompt)) span.set_attribute(user.id, user_id) span.set_attribute(session.id, session_id) start time.time() response llm_client.invoke(prompt) latency time.time() - start span.set_attribute(llm.latency_ms, latency * 1000) span.set_attribute(llm.prompt_tokens, response.usage.prompt_tokens) span.set_attribute(llm.completion_tokens, response.usage.completion_tokens) span.set_attribute(llm.total_tokens, response.usage.total_tokens) span.set_attribute(llm.finish_reason, response.finish_reason) # Prompt 和 Completion 作为事件记录避免污染 span 属性 span.add_event(llm.prompt, {content: prompt[:2000]}) span.add_event(llm.completion, {content: response.text[:2000]}) return response这里有个细节值得说Prompt 和 Completion 不要直接塞进 span attribute。观测云对 attribute 的长度有限制而且长文本塞进去之后查询性能会下降。正确做法是用add_event或者单独的日志流来存通过 trace_id 关联。3.2 第二步数据接入观测云三种方式怎么选观测云支持多种数据接入方式针对 AgentOps 场景我实际用过三种各有适用场景方式一OpenTelemetry Collector 直连。适合已经有 OTel 埋点的团队改一下 exporter 配置就行。优点是标准化缺点是配置相对复杂需要理解 OTel 的 pipeline 概念。方式二观测云 SDK 直接上报。适合快速验证代码里直接调 SDK 上报指标和日志。优点是上手快缺点是耦合度高换平台要改代码。方式三日志文件采集 Pipeline 解析。适合已有日志体系的团队把 LLM 应用的日志按格式输出用观测云的日志采集器抓取再用 Pipeline 做结构化解析。优点是侵入性小缺点是实时性稍差。我最终选的是方式一为主、方式三为辅的组合核心链路数据走 OTel业务日志走文件采集。这样既保证了链路的完整性又保留了日志的灵活性。配置 OTel Collector 的关键片段大概长这样# otel-collector-config.yaml receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 processors: batch: timeout: 5s send_batch_size: 512 attributes: actions: - key: service.name value: ai-agent-prod action: upsert exporters: otlphttp: endpoint: https://your-guance-endpoint headers: X-Token: ${GUANCE_TOKEN} service: pipelines: traces: receivers: [otlp] processors: [batch, attributes] exporters: [otlphttp] metrics: receivers: [otlp] processors: [batch] exporters: [otlphttp]注意Token 一定要用环境变量注入绝对不要硬编码在配置文件里。我见过不止一次因为配置文件进了 Git 仓库导致密钥泄露的事故。3.3 第三步构建 Agent 决策链路视图数据接进来之后最有价值的视图是决策链路视图。它把一次会话的所有 Span 按时间顺序和父子关系画出来你能直观看到 Agent 的思考过程。我一般会在这个视图里重点看几个东西Span 数量一次简单问答如果产生 20 个 Span说明 Agent 可能在过度规划。重复 Span同名工具连续调用多次大概率是循环或重试逻辑有问题。耗时分布哪个 Span 占了总耗时的 80%优化就盯它。错误 Span工具调用失败、模型返回异常都会在这里暴露。观测云的链路视图支持按 trace_id 查询也支持按属性过滤。我常用的一个查询是找出所有 Span 数超过 15 的 Trace这能快速定位异常复杂的会话。3.4 第四步Token 成本核算与预算告警Token 成本是 LLM 应用最容易被忽视的隐性成本。我见过一个团队上线三个月才发现某个内部测试账号每天烧掉几百块因为它的会话没有做长度限制历史消息无限累积。成本核算的核心是把 Token 数乘以单价按维度聚合。观测云支持自定义指标我一般会定义一个llm.cost指标# 成本计算逻辑 PRICING { gpt-4: {prompt: 0.03, completion: 0.06}, # 每千 token 美元 gpt-3.5-turbo: {prompt: 0.0015, completion: 0.002}, claude-3-sonnet: {prompt: 0.003, completion: 0.015}, } def calc_cost(model, prompt_tokens, completion_tokens): price PRICING.get(model) if not price: return 0 return (prompt_tokens / 1000 * price[prompt] completion_tokens / 1000 * price[completion])然后在观测云里配置告警规则单日成本超过阈值、单用户成本异常、单会话 Token 数超限。这三条告警帮我拦下过好几次事故。3.5 第五步语义质量评估的接入这是 AgentOps 里最难也最有价值的部分。传统监控只能告诉你调用成功了但没法告诉你回答对不对。语义质量评估需要引入额外的评估机制常见的有三种规则评估关键词命中、格式校验、长度检查。简单快速但覆盖有限。模型评估用另一个 LLM 做裁判评估相关性、准确性、幻觉程度。效果好但成本高。人工标注抽样人工评估作为黄金标准校准前两种。我的实践是规则评估全量跑模型评估抽样跑人工标注定期校准。评估结果作为 Event 写回对应的 Trace这样在链路视图里就能看到这次回答的质量评分是 0.6偏低。观测云支持把评估结果作为日志或指标接入我一般用日志方式字段包括 trace_id、评估维度、评分、评估方法。这样可以在链路视图里直接关联查看。4. 生产环境踩过的坑与排查实录4.1 常见问题速查表下面这张表是我和团队在实际运维中积累的问题清单基本覆盖了 80% 的日常故障现象可能原因排查路径解决方向回答质量突然下降Prompt 被改动、模型版本切换、检索结果变差对比改动前后的 Trace看 Prompt 和检索结果回滚 Prompt 或模型版本延迟飙升但模型正常工具调用超时、检索慢、网络抖动看 Span 耗时分布定位最慢的 Span加超时、加缓存、优化检索Token 消耗异常历史消息累积、循环调用、Prompt 冗余按会话聚合 Token看 Top 消耗会话加长度限制、加循环检测工具调用失败率高参数格式错误、工具服务不稳定、鉴权失效看工具 Span 的错误信息和错误码修参数校验、加重试、查鉴权Agent 陷入死循环规划逻辑缺陷、工具返回不符合预期看 Trace 里重复的 Span 模式加最大轮次限制、改规划 Prompt会话状态丢失记忆存储故障、session_id 传递错误看会话 Span 的 session_id 是否连续修记忆存储、检查传递链路4.2 一个真实的排查案例为什么 Agent 突然开始胡说八道上个月我们遇到一个诡异问题某个业务线的 Agent 突然开始给出明显错误的答案但错误率不是 100%大概 30% 左右。传统监控全绿模型 API 成功率 99.9%延迟正常。我打开观测云的链路视图按业务线过滤随机抽了 20 个错误 Trace 和 20 个正常 Trace 对比。很快发现一个规律错误 Trace 的检索 Span 返回的文档数量明显偏少正常 Trace 平均返回 5 篇错误 Trace 只有 1-2 篇。继续下钻发现检索 Span 的查询语句里有一个关键词被错误地分词了。再往上查是前一天有人更新了检索服务的分词词典引入了一个 bug。整个过程从发现问题到定位根因用了不到 20 分钟靠的就是链路数据的完整性和可下钻性。如果只有传统监控这个问题可能要排查一整天——因为从指标上看检索服务的 QPS、延迟、成功率全都正常只是返回的内容质量下降了。这就是 AgentOps 的价值它观测的是内容质量而不只是服务健康。4.3 几个容易踩的坑坑一埋点太粗事后无法下钻。我一开始只埋了 LLM 调用的总耗时没埋首 Token 延迟。结果用户投诉响应慢时我分不清是模型排队慢还是生成慢。后来补上首 Token 延迟才发现是并发高时排队严重。埋点要埋到能回答为什么的粒度。坑二Prompt 全量存储导致成本失控。观测云按数据量计费如果把每个 Prompt 和 Completion 全量存下来数据量会非常恐怖。我的做法是全量存元数据长度、Token 数、模型抽样存内容比如 10% 采样异常会话全量存。这样既控制了成本又保证了关键数据不丢。坑三告警阈值拍脑袋定。Token 成本告警一开始我设了个固定值结果业务高峰期天天误报。后来改成基于历史同期的动态基线误报率大幅下降。观测云支持动态阈值告警这个功能一定要用起来。坑四忽视会话级别的聚合。单次 LLM 调用看起来都很正常但一个会话累积起来可能消耗几万 Token。如果不做会话级聚合你永远发现不了慢性失血。我现在的做法是每个会话结束时上报一个汇总指标包含总 Token、总耗时、总成本、工具调用次数。5. 从能观测到能优化AgentOps 的进阶玩法5.1 用观测数据反哺 Prompt 和 Agent 设计AgentOps 不只是看更要用。我现在的习惯是每周做一次数据复盘从观测数据里找优化点找出高质量回答的共性哪些 Prompt 模板、哪些检索策略产生的回答评分最高把它们沉淀成最佳实践。找出低质量回答的模式是特定类型的问题容易出错还是特定时间段模型不稳定针对性优化。找出成本洼地哪些调用可以用更便宜的模型替代哪些 Prompt 可以精简我实测下来通过 Prompt 精简和模型分级成本能降 30%-40%。5.2 建立 Agent 的 SLO 体系传统服务有 SLO可用性、延迟Agent 也需要自己的 SLO。我目前定义的 Agent SLO 包括任务完成率用户发起的任务中Agent 成功完成的比例目标 95%。回答质量分抽样评估的平均分目标 4.0/5.0。P95 响应延迟目标 5 秒以内。单会话成本目标 0.1 元以内。工具调用成功率目标 99%。这些 SLO 全部接入观测云的告警体系任何一个跌破阈值都会触发告警。有了 SLO团队对Agent 是否健康就有了统一的判断标准不再靠感觉。5.3 多 Agent 协作场景的观测当系统从单 Agent 演进到多 Agent 协作时观测复杂度会指数级上升。多个 Agent 之间会互相调用、传递上下文、共享记忆。这时候 Trace 结构会变成一张网而不是一棵树。我的处理方式是引入 Agent 维度的标签每个 Span 都标记是哪个 Agent 产生的然后在观测云里按 Agent 维度做聚合分析。这样即使调用关系复杂也能快速定位是哪个 Agent 出了问题。另外Agent 之间的消息传递也要埋点记录消息内容、大小、传递耗时这些在排查协作故障时非常关键。5.4 安全与合规的观测LLM 应用有个特殊风险Prompt 注入和敏感信息泄露。用户可能通过精心构造的输入诱导 Agent 泄露系统 Prompt 或执行非预期操作。观测云可以配置规则对 Prompt 和 Completion 做敏感词扫描和异常模式检测一旦发现可疑输入就告警。另外密钥泄露也是重点。我见过有团队把 API Key 写进了 Prompt 模板里结果被模型原样输出给了用户。观测侧的做法是对所有输出做正则扫描检测是否包含疑似密钥的字符串。这个检查成本很低但能拦住大事故。6. 一些个人体会和后续可以扩展的方向这套 AgentOps 体系跑了大半年最大的感受是LLM 应用的可观测本质上是把软件工程的可观测和数据科学的质量评估缝在一起。前者解决系统是否正常后者解决输出是否可信。两者缺一不可而且必须用同一套数据模型串起来否则排查问题时会在多个系统之间来回跳效率极低。如果让我给刚起步的团队一个建议我会说别一上来就追求大而全先把 LLM 调用和工具调用这两类 Span 埋好把 Trace 视图跑通你就能解决 70% 的问题。剩下的语义评估、成本核算、多 Agent 观测可以随着业务复杂度逐步补上。我见过太多团队一开始就设计了一套复杂的埋点方案结果落地时发现维护成本太高最后不了了之。后续我打算扩展的方向有两个一是把观测数据和 A/B 测试打通用数据驱动 Prompt 和模型的迭代决策二是探索基于观测数据的自动优化比如当检测到某类问题频繁出错时自动触发 Prompt 调整建议。这两个方向都还在早期等有成熟经验了再单独写一篇分享。最后分享一个小技巧给每个 Trace 打上业务场景标签比如客服问答文档摘要数据分析。这样在做聚合分析时你可以按场景看指标而不是被全局平均值掩盖问题。我实测下来这个标签的成本几乎为零但分析效率提升非常明显。 基于观测云搭建AgentOps运维体系：LLM应用可观测性实践
1. 为什么 LLM 应用上线后传统监控突然不够用了做过几年后端监控的人第一次接手 LLM 应用运维时大概率会经历一段相当别扭的时期。CPU、内存、QPS、P99 延迟这些指标全都绿着告警面板干干净净但用户投诉却一条接一条回答答非所问、工具调用莫名其妙失败、同一个问题昨天答得好今天答得烂、账单月底一看比预期翻了五倍。你打开传统 APM 一看接口 200耗时 800ms一切正常。问题就出在这个正常上——传统可观测体系压根没打算观测模型在想什么。这就是 AgentOps 要解决的事情。简单说AgentOps 是把 DevOps 和 MLOps 的思路延伸到 AI Agent 这一层专门观测 LLM 调用链路、Agent 决策过程、工具调用、Token 消耗、检索质量、会话状态这些传统监控覆盖不到的东西。它观测的对象不是服务是否活着而是Agent 是否在做正确的事、花了合理的成本、给出了可信的答案。我这次要分享的是基于观测云搭建一套完整的 AgentOps 运维体系的实践。观测云本身是一套国内比较成熟的统一可观测平台支持指标、日志、链路追踪、RUM、安全巡检等多种数据类型的统一接入天然适合做这种多源异构数据融合的活儿。LLM 应用的数据形态特别杂有结构化指标Token 数、延迟、有半结构化日志Prompt、Completion、有链路数据Agent 调用链、还有非结构化的语义质量评估结果。观测云在这块的整合能力是我选它的核心原因。这篇文章适合三类人看一是正在把 LLM 应用往生产环境推的后端或平台工程师二是负责 AI 产品稳定性与成本的 SRE/运维同学三是想搞清楚Agent 上线之后到底该盯什么的技术负责人。不管你是刚接触 LLM 开发还是已经踩过几轮坑下面的内容应该都能直接抄作业。2. AgentOps 到底要观测什么核心对象与数据模型拆解2.1 从 LLM 到 AI Agent观测对象的层级变化很多人把 LLM 和 AI Agent 混着说但在可观测这件事上两者差别巨大。LLM 是一个输入文本、输出文本的函数观测它主要看调用成功率、延迟、Token 消耗、内容质量。而 AI Agent 是一个感知—规划—行动—反思的循环体它内部会调用 LLM、调用工具、读写记忆、做多轮决策。观测 Agent 相当于观测一个分布式系统只不过它的服务是模型和工具请求是用户意图。我一般把观测对象分成四层这个分层直接决定了后面数据模型怎么设计层级观测对象典型指标/数据传统监控是否覆盖L1 基础设施层GPU、容器、网络显存占用、GPU 利用率、网络延迟覆盖L2 模型调用层LLM API 调用首 Token 延迟、总延迟、Token 数、错误码部分覆盖L3 Agent 决策层规划、工具调用、记忆读写工具调用成功率、循环轮次、决策路径不覆盖L4 业务语义层回答质量、幻觉、用户满意度相关性评分、幻觉率、会话完成率不覆盖传统 APM 基本只覆盖 L1 和 L2 的一部分L3 和 L4 是 AgentOps 的主战场。这也是为什么很多团队上了 LLM 应用之后监控面板看着漂亮但心里没底——因为真正会出问题的地方压根没被观测到。2.2 AgentOps 的核心数据模型Trace、Span、Event 三层结构观测云的数据模型基于 OpenTelemetry 标准天然支持 Trace/Span 结构。落到 AgentOps 上我建议这样映射Trace一次会话或一次任务代表用户发起的一次完整请求比如帮我分析这份财报并生成摘要。一个 Trace 可能包含多轮 LLM 调用、多次工具调用。Span一次具体操作Trace 下的子单元。一次 LLM 调用是一个 Span一次工具调用是一个 Span一次向量检索也是一个 Span。Span 之间可以有父子关系形成决策树。Event关键事件点Span 内部的关键节点比如Prompt 组装完成模型开始返回工具返回异常。这个结构的好处是你可以沿着 Trace 一路下钻看到 Agent 到底走了哪条决策路径。我见过一个典型故障Agent 在处理退款请求时先调了订单查询工具又调了一次订单查询工具再调了一次……循环了 7 次才给出答案。传统监控完全看不出来但在 Trace 视图里7 个重复的 Span 一目了然。2.3 为什么选观测云而不是自建 Prometheus Grafana这个问题我被问过很多次。自建方案不是不行但有几个现实痛点第一LLM 数据是非结构化的。Prompt 和 Completion 都是长文本塞进 Prometheus 的 label 里会直接爆炸。观测云支持日志和链路数据统一存储长文本处理更自然。第二语义质量评估需要外部数据源。幻觉检测、相关性评分这些往往由另一个模型或人工标注产生需要和链路数据关联。观测云的关联查询能力比 Prometheus 强不少。第三成本核算需要多维度聚合。Token 成本要按模型、按用户、按业务线、按时间段聚合Prometheus 做这种多维分析很吃力。当然观测云也不是银弹。如果你的团队已经有成熟的 ELK Prometheus 体系也可以只把 L3、L4 的数据接进去L1、L2 继续用原有体系。关键是别指望一套工具解决所有问题。3. 搭建 AgentOps 体系的完整实操流程3.1 第一步埋点设计决定你能看到什么埋点是整个体系的地基埋错了后面全白搭。我的经验是先想清楚要回答哪些问题再决定埋什么点。常见的核心问题有这么几类这次请求为什么慢慢在模型还是工具还是检索这次回答为什么不对是 Prompt 问题、检索问题还是模型问题这次花了多少钱哪个业务线、哪个用户、哪个模型最烧钱Agent 有没有陷入死循环或异常重试针对这些问题我设计了一套最小可用埋点集覆盖 LLM 调用、工具调用、检索、会话四个维度# 基于 OpenTelemetry 的埋点示例伪代码展示结构 from opentelemetry import trace tracer trace.get_tracer(agent.ops) def call_llm(prompt, model, user_id, session_id): with tracer.start_as_current_span(llm.call) as span: span.set_attribute(llm.model, model) span.set_attribute(llm.prompt_length, len(prompt)) span.set_attribute(user.id, user_id) span.set_attribute(session.id, session_id) start time.time() response llm_client.invoke(prompt) latency time.time() - start span.set_attribute(llm.latency_ms, latency * 1000) span.set_attribute(llm.prompt_tokens, response.usage.prompt_tokens) span.set_attribute(llm.completion_tokens, response.usage.completion_tokens) span.set_attribute(llm.total_tokens, response.usage.total_tokens) span.set_attribute(llm.finish_reason, response.finish_reason) # Prompt 和 Completion 作为事件记录避免污染 span 属性 span.add_event(llm.prompt, {content: prompt[:2000]}) span.add_event(llm.completion, {content: response.text[:2000]}) return response这里有个细节值得说Prompt 和 Completion 不要直接塞进 span attribute。观测云对 attribute 的长度有限制而且长文本塞进去之后查询性能会下降。正确做法是用add_event或者单独的日志流来存通过 trace_id 关联。3.2 第二步数据接入观测云三种方式怎么选观测云支持多种数据接入方式针对 AgentOps 场景我实际用过三种各有适用场景方式一OpenTelemetry Collector 直连。适合已经有 OTel 埋点的团队改一下 exporter 配置就行。优点是标准化缺点是配置相对复杂需要理解 OTel 的 pipeline 概念。方式二观测云 SDK 直接上报。适合快速验证代码里直接调 SDK 上报指标和日志。优点是上手快缺点是耦合度高换平台要改代码。方式三日志文件采集 Pipeline 解析。适合已有日志体系的团队把 LLM 应用的日志按格式输出用观测云的日志采集器抓取再用 Pipeline 做结构化解析。优点是侵入性小缺点是实时性稍差。我最终选的是方式一为主、方式三为辅的组合核心链路数据走 OTel业务日志走文件采集。这样既保证了链路的完整性又保留了日志的灵活性。配置 OTel Collector 的关键片段大概长这样# otel-collector-config.yaml receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 processors: batch: timeout: 5s send_batch_size: 512 attributes: actions: - key: service.name value: ai-agent-prod action: upsert exporters: otlphttp: endpoint: https://your-guance-endpoint headers: X-Token: ${GUANCE_TOKEN} service: pipelines: traces: receivers: [otlp] processors: [batch, attributes] exporters: [otlphttp] metrics: receivers: [otlp] processors: [batch] exporters: [otlphttp]注意Token 一定要用环境变量注入绝对不要硬编码在配置文件里。我见过不止一次因为配置文件进了 Git 仓库导致密钥泄露的事故。3.3 第三步构建 Agent 决策链路视图数据接进来之后最有价值的视图是决策链路视图。它把一次会话的所有 Span 按时间顺序和父子关系画出来你能直观看到 Agent 的思考过程。我一般会在这个视图里重点看几个东西Span 数量一次简单问答如果产生 20 个 Span说明 Agent 可能在过度规划。重复 Span同名工具连续调用多次大概率是循环或重试逻辑有问题。耗时分布哪个 Span 占了总耗时的 80%优化就盯它。错误 Span工具调用失败、模型返回异常都会在这里暴露。观测云的链路视图支持按 trace_id 查询也支持按属性过滤。我常用的一个查询是找出所有 Span 数超过 15 的 Trace这能快速定位异常复杂的会话。3.4 第四步Token 成本核算与预算告警Token 成本是 LLM 应用最容易被忽视的隐性成本。我见过一个团队上线三个月才发现某个内部测试账号每天烧掉几百块因为它的会话没有做长度限制历史消息无限累积。成本核算的核心是把 Token 数乘以单价按维度聚合。观测云支持自定义指标我一般会定义一个llm.cost指标# 成本计算逻辑 PRICING { gpt-4: {prompt: 0.03, completion: 0.06}, # 每千 token 美元 gpt-3.5-turbo: {prompt: 0.0015, completion: 0.002}, claude-3-sonnet: {prompt: 0.003, completion: 0.015}, } def calc_cost(model, prompt_tokens, completion_tokens): price PRICING.get(model) if not price: return 0 return (prompt_tokens / 1000 * price[prompt] completion_tokens / 1000 * price[completion])然后在观测云里配置告警规则单日成本超过阈值、单用户成本异常、单会话 Token 数超限。这三条告警帮我拦下过好几次事故。3.5 第五步语义质量评估的接入这是 AgentOps 里最难也最有价值的部分。传统监控只能告诉你调用成功了但没法告诉你回答对不对。语义质量评估需要引入额外的评估机制常见的有三种规则评估关键词命中、格式校验、长度检查。简单快速但覆盖有限。模型评估用另一个 LLM 做裁判评估相关性、准确性、幻觉程度。效果好但成本高。人工标注抽样人工评估作为黄金标准校准前两种。我的实践是规则评估全量跑模型评估抽样跑人工标注定期校准。评估结果作为 Event 写回对应的 Trace这样在链路视图里就能看到这次回答的质量评分是 0.6偏低。观测云支持把评估结果作为日志或指标接入我一般用日志方式字段包括 trace_id、评估维度、评分、评估方法。这样可以在链路视图里直接关联查看。4. 生产环境踩过的坑与排查实录4.1 常见问题速查表下面这张表是我和团队在实际运维中积累的问题清单基本覆盖了 80% 的日常故障现象可能原因排查路径解决方向回答质量突然下降Prompt 被改动、模型版本切换、检索结果变差对比改动前后的 Trace看 Prompt 和检索结果回滚 Prompt 或模型版本延迟飙升但模型正常工具调用超时、检索慢、网络抖动看 Span 耗时分布定位最慢的 Span加超时、加缓存、优化检索Token 消耗异常历史消息累积、循环调用、Prompt 冗余按会话聚合 Token看 Top 消耗会话加长度限制、加循环检测工具调用失败率高参数格式错误、工具服务不稳定、鉴权失效看工具 Span 的错误信息和错误码修参数校验、加重试、查鉴权Agent 陷入死循环规划逻辑缺陷、工具返回不符合预期看 Trace 里重复的 Span 模式加最大轮次限制、改规划 Prompt会话状态丢失记忆存储故障、session_id 传递错误看会话 Span 的 session_id 是否连续修记忆存储、检查传递链路4.2 一个真实的排查案例为什么 Agent 突然开始胡说八道上个月我们遇到一个诡异问题某个业务线的 Agent 突然开始给出明显错误的答案但错误率不是 100%大概 30% 左右。传统监控全绿模型 API 成功率 99.9%延迟正常。我打开观测云的链路视图按业务线过滤随机抽了 20 个错误 Trace 和 20 个正常 Trace 对比。很快发现一个规律错误 Trace 的检索 Span 返回的文档数量明显偏少正常 Trace 平均返回 5 篇错误 Trace 只有 1-2 篇。继续下钻发现检索 Span 的查询语句里有一个关键词被错误地分词了。再往上查是前一天有人更新了检索服务的分词词典引入了一个 bug。整个过程从发现问题到定位根因用了不到 20 分钟靠的就是链路数据的完整性和可下钻性。如果只有传统监控这个问题可能要排查一整天——因为从指标上看检索服务的 QPS、延迟、成功率全都正常只是返回的内容质量下降了。这就是 AgentOps 的价值它观测的是内容质量而不只是服务健康。4.3 几个容易踩的坑坑一埋点太粗事后无法下钻。我一开始只埋了 LLM 调用的总耗时没埋首 Token 延迟。结果用户投诉响应慢时我分不清是模型排队慢还是生成慢。后来补上首 Token 延迟才发现是并发高时排队严重。埋点要埋到能回答为什么的粒度。坑二Prompt 全量存储导致成本失控。观测云按数据量计费如果把每个 Prompt 和 Completion 全量存下来数据量会非常恐怖。我的做法是全量存元数据长度、Token 数、模型抽样存内容比如 10% 采样异常会话全量存。这样既控制了成本又保证了关键数据不丢。坑三告警阈值拍脑袋定。Token 成本告警一开始我设了个固定值结果业务高峰期天天误报。后来改成基于历史同期的动态基线误报率大幅下降。观测云支持动态阈值告警这个功能一定要用起来。坑四忽视会话级别的聚合。单次 LLM 调用看起来都很正常但一个会话累积起来可能消耗几万 Token。如果不做会话级聚合你永远发现不了慢性失血。我现在的做法是每个会话结束时上报一个汇总指标包含总 Token、总耗时、总成本、工具调用次数。5. 从能观测到能优化AgentOps 的进阶玩法5.1 用观测数据反哺 Prompt 和 Agent 设计AgentOps 不只是看更要用。我现在的习惯是每周做一次数据复盘从观测数据里找优化点找出高质量回答的共性哪些 Prompt 模板、哪些检索策略产生的回答评分最高把它们沉淀成最佳实践。找出低质量回答的模式是特定类型的问题容易出错还是特定时间段模型不稳定针对性优化。找出成本洼地哪些调用可以用更便宜的模型替代哪些 Prompt 可以精简我实测下来通过 Prompt 精简和模型分级成本能降 30%-40%。5.2 建立 Agent 的 SLO 体系传统服务有 SLO可用性、延迟Agent 也需要自己的 SLO。我目前定义的 Agent SLO 包括任务完成率用户发起的任务中Agent 成功完成的比例目标 95%。回答质量分抽样评估的平均分目标 4.0/5.0。P95 响应延迟目标 5 秒以内。单会话成本目标 0.1 元以内。工具调用成功率目标 99%。这些 SLO 全部接入观测云的告警体系任何一个跌破阈值都会触发告警。有了 SLO团队对Agent 是否健康就有了统一的判断标准不再靠感觉。5.3 多 Agent 协作场景的观测当系统从单 Agent 演进到多 Agent 协作时观测复杂度会指数级上升。多个 Agent 之间会互相调用、传递上下文、共享记忆。这时候 Trace 结构会变成一张网而不是一棵树。我的处理方式是引入 Agent 维度的标签每个 Span 都标记是哪个 Agent 产生的然后在观测云里按 Agent 维度做聚合分析。这样即使调用关系复杂也能快速定位是哪个 Agent 出了问题。另外Agent 之间的消息传递也要埋点记录消息内容、大小、传递耗时这些在排查协作故障时非常关键。5.4 安全与合规的观测LLM 应用有个特殊风险Prompt 注入和敏感信息泄露。用户可能通过精心构造的输入诱导 Agent 泄露系统 Prompt 或执行非预期操作。观测云可以配置规则对 Prompt 和 Completion 做敏感词扫描和异常模式检测一旦发现可疑输入就告警。另外密钥泄露也是重点。我见过有团队把 API Key 写进了 Prompt 模板里结果被模型原样输出给了用户。观测侧的做法是对所有输出做正则扫描检测是否包含疑似密钥的字符串。这个检查成本很低但能拦住大事故。6. 一些个人体会和后续可以扩展的方向这套 AgentOps 体系跑了大半年最大的感受是LLM 应用的可观测本质上是把软件工程的可观测和数据科学的质量评估缝在一起。前者解决系统是否正常后者解决输出是否可信。两者缺一不可而且必须用同一套数据模型串起来否则排查问题时会在多个系统之间来回跳效率极低。如果让我给刚起步的团队一个建议我会说别一上来就追求大而全先把 LLM 调用和工具调用这两类 Span 埋好把 Trace 视图跑通你就能解决 70% 的问题。剩下的语义评估、成本核算、多 Agent 观测可以随着业务复杂度逐步补上。我见过太多团队一开始就设计了一套复杂的埋点方案结果落地时发现维护成本太高最后不了了之。后续我打算扩展的方向有两个一是把观测数据和 A/B 测试打通用数据驱动 Prompt 和模型的迭代决策二是探索基于观测数据的自动优化比如当检测到某类问题频繁出错时自动触发 Prompt 调整建议。这两个方向都还在早期等有成熟经验了再单独写一篇分享。最后分享一个小技巧给每个 Trace 打上业务场景标签比如客服问答文档摘要数据分析。这样在做聚合分析时你可以按场景看指标而不是被全局平均值掩盖问题。我实测下来这个标签的成本几乎为零但分析效率提升非常明显。