1. 从能跑到跑得明白AgentOps 到底要解决什么LLM 应用和传统后端服务有一个本质区别传统服务的输入输出基本是确定的一个 HTTP 请求进来走哪条链路、调哪个数据库、耗时多少链路追踪一拉就清清楚楚。但 LLM 应用不一样同一个问题问两次模型可能给你两个完全不同的答案中间还可能穿插工具调用、多轮推理、检索增强甚至多个 Agent 互相协作。这种不确定性让传统的监控手段几乎失效——你看到接口返回 200不代表这次回答是好的你看到耗时 3 秒也不知道这 3 秒到底花在检索上、模型推理上还是工具调用上。这就是 AgentOps 要解决的问题。简单说AgentOps 是把 DevOps 那套可观测、可追踪、可回归的思路搬到 LLM 和 AI Agent 的运维场景里来。它关注的不是服务器 CPU 高不高而是这次对话的 token 消耗是多少、检索召回的文档相不相关、工具调用有没有失败、多轮推理在哪一步跑偏了、用户的实际反馈是好是坏。没有这套体系你的 Agent 就是一个黑盒出了问题只能靠再问一遍看看这在生产环境里是灾难。我接触过不少团队做 Demo 的时候效果惊艳一上生产就各种翻车有的回答开始胡编、有的工具调用超时、有的成本一个月飙到几万块还不知道钱花哪了。根因基本都是同一个——没有可观测。你无法度量就无法优化。所以搭建 AgentOps 体系不是锦上添花而是 LLM 应用从能跑走向跑得明白的必经之路。这篇内容我会围绕基于观测云搭建 AgentOps 运维体系这个主题把整套思路拆开讲LLM 和 Agent 的可观测到底要观测哪些维度、观测云这类平台在其中扮演什么角色、数据怎么采集怎么建模、链路追踪怎么串起来、成本和质量怎么量化以及我在实操中踩过的那些坑。适合正在做 AI Agent 开发、准备把 LLM 应用推上生产、或者已经被线上问题折磨过的同学参考。2. LLM 与 Agent 的可观测维度拆解2.1 为什么传统 APM 在 LLM 场景下会失灵传统 APM应用性能监控的核心假设是调用链路是确定的、可枚举的。它通过埋点记录每个函数、每个 RPC 调用的耗时和状态然后聚合成指标。这套逻辑对 CRUD 服务非常好用但放到 LLM 场景就力不从心。第一个问题是语义缺失。APM 能告诉你调用 OpenAI 接口耗时 2.3 秒返回 200但它不知道这次返回的内容质量如何、有没有幻觉、有没有答非所问。对 LLM 应用来说一次成功的 HTTP 调用可能对应一次完全失败的用户体验。第二个问题是链路非线性。一个 Agent 处理用户请求可能是理解意图 → 检索知识库 → 调用工具 → 再推理 → 生成回答这样的多步流程中间还可能根据中间结果动态决定下一步走哪。这种动态链路传统 APM 的固定埋点根本覆盖不了。第三个问题是成本维度缺失。LLM 调用是按 token 计费的一次请求可能消耗几百到几万 token。APM 不关心 token但你的账单关心。没有 token 级别的可观测成本优化就是盲人摸象。所以 LLM 可观测需要一套新的数据模型它要能同时承载链路Trace、指标Metric、日志Log还要额外加上语义内容Prompt/Completion和评估结果Evaluation。2.2 AgentOps 需要观测的五类核心信号结合我自己的实践一个完整的 AgentOps 体系至少要覆盖五类信号缺一不可信号类型具体内容解决什么问题链路追踪每次请求的完整调用树、各步骤耗时、父子关系定位慢在哪、断在哪Token 与成本输入/输出 token 数、模型单价、累计成本控制预算、发现异常消耗质量评估相关性、忠实度、幻觉检测、用户反馈判断回答好不好工具调用工具名、入参、出参、成功率、耗时排查工具失败、参数错误会话上下文多轮对话历史、记忆读写、状态流转复现问题、分析多轮退化这五类信号里链路追踪是骨架其他四类都挂在链路的各个节点上。比如一次 Agent 请求的 Trace 里会有一个检索span它下面挂着召回了哪些文档质量信号、消耗了多少 token成本信号会有一个工具调用span记录工具名和结果工具信号整个 Trace 还会关联到具体的会话 ID上下文信号。2.3 观测云在 AgentOps 中的定位观测云这类平台的核心价值是提供一个统一的数据底座。它本身不是专门为 LLM 设计的但它支持 OpenTelemetry 标准能接收 Trace、Metric、Log 三类数据并且支持自定义数据模型和标签。这意味着你可以把 LLM 特有的信号token、评估分数、工具调用作为自定义字段塞进标准的 Trace 结构里从而复用成熟的存储、查询、告警、看板能力。我选择用观测云而不是自建一套主要考虑三点一是它原生支持 OTel接入成本低二是它的数据模型灵活能自定义字段和标签不用为了 LLM 场景改底层三是它的看板和告警配置比较成熟省去了自己搭 Grafana Prometheus Jaeger 那一整套的运维成本。当然如果你的团队已经有成熟的可观测栈也可以把同样的思路迁移过去核心是数据模型的设计平台只是载体。3. 数据采集层把 Agent 的每一步都录下来3.1 用 OpenTelemetry 统一埋点标准采集层最关键的一个决策是用什么标准埋点。我的建议是毫不犹豫地选 OpenTelemetry。原因很简单LLM 生态变化太快今天用 LangChain明天可能换 LlamaIndex后天可能自己写。如果你的埋点是跟框架绑死的换框架就得重写一遍。而 OTel 是厂商中立的只要你的埋点遵循 OTel 语义约定换什么框架、换什么后端都不用动。具体到 LLM 场景OTel 社区已经在推进 GenAI 语义约定Semantic Conventions for GenAI定义了一批标准属性比如gen_ai.system模型提供方、gen_ai.request.model模型名、gen_ai.usage.input_tokens输入 token、gen_ai.usage.output_tokens输出 token。你埋点的时候尽量对齐这些约定未来迁移和工具兼容性都会好很多。一个典型的 Agent 请求我会这样组织 span 层级Trace: agent_request (根 span) ├── span: intent_parse (意图理解) ├── span: retrieval (知识库检索) │ ├── span: embedding (向量化) │ └── span: vector_search (向量检索) ├── span: llm_call (模型推理) ├── span: tool_call (工具调用) │ └── span: http_request (工具内部请求) └── span: response_generate (回答生成)每个 span 上挂对应的属性。比如llm_call这个 span 上我会记录模型名、输入输出 token、耗时、是否命中缓存retrieval上记录召回文档数、top 相似度分数tool_call上记录工具名、是否成功、错误码。3.2 埋点代码的实操写法以 Python 为例用 OTel SDK 埋一个 LLM 调用的 span大致是这样from opentelemetry import trace tracer trace.get_tracer(agent.ops) def call_llm(prompt, modelgpt-4): with tracer.start_as_current_span(llm_call) as span: span.set_attribute(gen_ai.system, openai) span.set_attribute(gen_ai.request.model, model) span.set_attribute(gen_ai.request.prompt_length, len(prompt)) response client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}] ) span.set_attribute(gen_ai.usage.input_tokens, response.usage.prompt_tokens) span.set_attribute(gen_ai.usage.output_tokens, response.usage.completion_tokens) span.set_attribute(gen_ai.response.finish_reason, response.choices[0].finish_reason) return response这里有几个实操细节值得说。第一prompt 和 completion 的内容要不要记录这是个需要权衡的问题。记录内容对排查问题帮助极大但涉及隐私和存储成本。我的做法是生产环境默认只记录长度和哈希需要排查时通过开关临时开启内容记录并且对敏感字段做脱敏。第二token 数一定要记这是成本核算的基础而且很多 SDK 返回的 usage 字段是现成的不记白不记。第三finish_reason 要记它能告诉你这次生成是正常结束、还是被长度截断、还是触发了内容过滤对判断回答质量很有用。3.3 采集层的三个常见坑第一个坑是异步和流式场景下的 span 管理。LLM 调用经常是流式的token 一个个吐出来如果你在流式开始时就结束 span那耗时和 token 数都不准。正确做法是在流式结束时才关闭 span并且把流式过程中累计的 token 数补上。异步场景同理要注意 context 的传递别让 span 挂错了父节点。第二个坑是采样策略。生产环境全量采集 Trace 成本很高尤其是高并发场景。我的建议是分层采样错误请求、慢请求、高 token 消耗请求 100% 采集正常请求按比例采样比如 10%。观测云支持基于属性的采样规则可以按errortrue或token 阈值这样的条件配置。第三个坑是标签基数爆炸。如果你把用户 ID、会话 ID 这种高基数high cardinality的值直接当标签会导致指标聚合时维度爆炸查询变慢。正确做法是把高基数值放在 span 属性里用于检索而不是放在 metric 标签里用于聚合。这个区别很多人一开始分不清踩过坑就记住了。4. 链路追踪把多轮对话和 Agent 协作串成一条线4.1 单次请求的 Trace 怎么组织单次请求的 Trace 组织相对简单就是前面说的 span 树。但有几个设计决策需要提前想清楚。根 span 的命名。我习惯用agent.{agent_name}.request这样的格式比如agent.customer_service.request。这样在观测云里按服务名筛选时能一眼看出是哪个 Agent 的请求。关键路径的标记。不是所有 span 都同等重要。我会给关键 span 打上criticaltrue的标记比如 LLM 调用、检索、核心工具调用。这样在看板里可以只关注关键路径的耗时过滤掉那些辅助性的 span。错误的传播。Agent 里的错误处理很微妙。一个工具调用失败Agent 可能会重试、可能会降级、也可能直接把错误抛给用户。我在 span 上会记录error.type和error.handled两个属性前者标明错误类型后者标明这个错误是否被 Agent 自己处理掉了。这样排查时能区分真故障和被优雅降级的故障。4.2 多轮对话的上下文关联多轮对话是 LLM 应用的典型场景也是可观测的难点。用户问了第一句Agent 回答用户追问Agent 再回答——这两次交互在业务上是一个会话但在技术上可能是两次独立的请求。如果不做关联你根本没法分析为什么第三轮回答开始跑偏。我的做法是引入session.id和turn.number两个属性。session.id标识整个会话turn.number标识这是第几轮。所有属于同一会话的 Trace 都带上相同的session.id这样在观测云里可以用session.id把整个会话的所有 Trace 拉出来按turn.number排序就能还原完整的对话过程。更进一步我会在每轮 Trace 上记录上下文长度这轮喂给模型的对话历史有多长和上下文压缩情况如果做了历史摘要或截断记录压缩前后的长度。这两个指标对分析多轮退化特别有用——很多时候 Agent 越聊越傻就是因为上下文被截断或压缩得太狠把关键信息丢了。4.3 多 Agent 协作的追踪难题当系统里有多个 Agent 协作时追踪会变得复杂。比如一个客服 Agent接到问题后发现需要查订单就转给订单 Agent订单 Agent 查完再转回来。这种情况下一次用户请求会跨越多个 Agent形成一张网而不是一棵树。处理这种场景我的经验是用统一的 trace_id 贯穿用 span 的父子关系表达调用用agent.name属性区分是哪个 Agent。不要试图为每个 Agent 建独立的 Trace那样就断了。观测云支持跨服务的 Trace 关联只要 trace_id 一致就能把不同 Agent 的 span 拼成一棵完整的树。还有一个细节Agent 之间的消息传递内容要不要记录。我的建议是记录消息的元信息消息类型、长度、是否包含工具调用内容本身按需记录。因为多 Agent 场景下消息量很大全记内容存储成本扛不住。5. 成本与质量AgentOps 里最容易被忽视的两件事5.1 Token 成本的可观测与归因成本是 LLM 应用最现实的痛点。我见过太多团队上线第一个月账单出来才傻眼。成本可观测的核心是归因——你要能回答这笔钱是谁花的、花在哪个环节。我的做法是在 Trace 上记录 token 消耗然后通过标签做多维归因。归因维度至少包括按 Agent 归因哪个 Agent 最费钱、按模型归因哪个模型用得最多、按用户/租户归因哪个客户消耗最大、按环节归因是检索费钱还是生成费钱。观测云里可以基于 Trace 数据做聚合查询比如过去 24 小时各 Agent 的 token 消耗 Top 10或者某租户的日均成本趋势。这些看板一挂出来成本问题立刻变得可见。这里有个实操技巧给不同模型设置不同的单价在查询时动态计算成本。因为模型价格经常变如果你在埋点时就写死成本价格一调历史数据就错了。更好的做法是埋点只记 token 数成本在查询层用当前单价计算或者维护一张价格表做关联。5.2 质量评估怎么落地质量评估是 AgentOps 里最难的部分因为好和坏本身就很主观。但再难也得做否则你没法知道优化有没有效果。我的落地思路是分层评估。第一层是自动指标比如回答长度、是否包含引用、是否触发了内容过滤、finish_reason 是否正常。这些不需要额外模型直接从 Trace 里算。第二层是模型评估用一个便宜的模型比如小模型给回答打分评估相关性、忠实度、是否有幻觉。第三层是用户反馈点赞点踩、追问率、会话时长这些是最真实的信号。三层评估的结果都作为属性挂到 Trace 上然后在观测云里做聚合。比如过去一周幻觉率趋势、不同 Prompt 版本的用户满意度对比。有了这些数据Prompt 优化、模型切换、检索策略调整才有依据而不是拍脑袋。提示模型评估本身也要花 token别用最贵的模型去评估。我一般用 GPT-3.5 级别的小模型做评估成本可控效果也够用。评估的 Prompt 要固定否则评估结果本身就不稳定。5.3 成本与质量的平衡看板成本和质量的最终目的是平衡。一个只追求质量不看成本的方案账单会教你做人一个只压成本不看质量的方案用户会教你做人。我会在观测云里做一个成本-质量联合看板横轴是单位请求成本纵轴是质量分数每个点是一个配置版本比如不同的模型、不同的检索参数。这样一眼就能看出哪些配置是高性价比的哪些是又贵又差的。这个看板在做模型选型和参数调优时特别有用能把主观决策变成数据决策。6. 告警与看板让问题主动找你6.1 该配哪些告警可观测的最终价值是主动发现问题而不是等用户投诉。AgentOps 的告警我一般配这几类错误率告警工具调用失败率、LLM 调用失败率超过阈值延迟告警P95 延迟超过阈值尤其是 LLM 调用和检索环节成本告警单小时 token 消耗突增、单租户成本超预算质量告警幻觉率、内容过滤触发率异常升高业务告警用户点踩率、追问率突增告警的阈值不要拍脑袋定先用一两周的数据跑出基线再基于基线设阈值。比如延迟告警先看正常情况下的 P95 是多少然后设成基线的 1.5 倍。6.2 看板设计的分层思路看板不要做成一个大杂烩要分层。我的习惯是分三层第一层是总览看板给团队负责人看核心就几个数字请求量、成功率、平均延迟、总成本、平均质量分。一眼看全局。第二层是诊断看板给开发和运维看按 Agent、按模型、按环节拆解能快速定位问题出在哪。第三层是专题看板比如成本专题、质量专题、多轮对话专题给做专项优化的同学用。观测云支持看板分层和钻取从总览点进去能下钻到诊断再下钻到具体 Trace这个链路要打通否则排查时还得手动切来切去。6.3 从告警到根因的排查链路告警响了之后排查链路要顺畅。我的经验是告警里直接带上可点击的 Trace 链接点进去就能看到出问题的具体请求。然后在 Trace 详情里能看到完整的 span 树、每个 span 的属性、关联的日志。这样从发现异常到定位根因能在几分钟内完成而不是几小时。这里有个细节Trace 和 Log 的关联。LLM 应用里很多问题需要看日志才能定位比如工具调用的详细报错。所以埋点时要把 trace_id 打到日志里观测云支持 Trace 和 Log 的关联查询这样在 Trace 详情里能直接看到相关日志不用再去日志系统里搜。7. 实操中踩过的坑与经验总结7.1 埋点过度导致性能下降一开始我埋得很细每个函数都加 span结果发现埋点本身成了性能瓶颈尤其是高频调用的向量检索环节。后来我调整策略只埋关键路径辅助环节用 metric 代替 span。span 适合表达调用关系metric 适合表达数值趋势别用 span 干 metric 的活。7.2 内容记录的隐私与合规记录 prompt 和 completion 内容对排查帮助大但隐私风险也大。我的做法是默认脱敏按需开启。对手机号、身份证、邮箱这类敏感信息做正则脱敏对业务敏感内容通过配置开关控制是否记录。另外内容记录要有保留期限不能无限期存着。7.3 评估模型的稳定性问题用模型做质量评估最大的坑是评估结果本身不稳定。同一个回答评估模型可能今天打 4 分明天打 3 分。解决办法是固定评估 Prompt、固定评估模型版本、对评估结果做多次采样取平均。另外评估模型和被评估模型最好别是同一个否则会有自己评自己的偏差。7.4 多轮对话的上下文膨胀多轮对话做久了上下文会越来越长token 成本飙升而且模型对超长上下文的注意力也会下降。我的经验是设置上下文窗口上限超过就做摘要压缩并且把压缩前后的长度都记录下来。这样既能控制成本又能在质量下降时快速定位是不是压缩导致的。7.5 别追求一步到位AgentOps 体系不是一天建成的。我的建议是先跑通最小闭环能采集 Trace、能看到链路、能算 token 成本。这三件事做完就已经能解决 80% 的问题了。质量评估、多 Agent 追踪、成本归因这些可以后续逐步加。一上来就追求大而全往往做一半就烂尾了。8. 写在最后的一点个人体会搭 AgentOps 这套体系技术上最难的不是埋点也不是看板而是想清楚你到底要观测什么。LLM 应用的可观测维度比传统服务多得多如果什么都想观测最后什么都观测不好。我的经验是从业务问题出发反推需要什么信号。用户投诉回答不准那就重点做质量评估老板抱怨成本高那就重点做成本归因线上经常超时那就重点做链路追踪。需求驱动而不是技术驱动这套体系才建得起来、用得上。另外观测云这类平台只是工具真正决定 AgentOps 效果的是你对 LLM 应用运行机制的理解。你得知道一次请求背后发生了什么、哪些环节容易出问题、哪些指标能反映问题才能设计出有用的可观测方案。工具会换平台会变但这套理解系统、度量系统、优化系统的思路是不变的。