AgentOps 是什么Agent 可观测性从零到一Agent 不是调一次 API 就完事的应用——它在多轮思考、工具调用、甚至自我纠错中完成一个任务。这种复杂性让可观测性从锦上添花变成了保命刚需。一、引言2025 年被称为Agent 元年。从 coding agent、客服 agent 到 browser-use agentAI 应用正在从单次问答进化到多步自主执行。但 Agent 带来了全新的工程挑战——一个用户请求可能触发5 次 LLM 调用思考、规划、执行、校验、总结3 次工具调用搜索文档、查询数据库、执行代码2 次内部循环结果不符合预期 → 重试当用户说你的 Agent 回答错了你该怎么排查是 Prompt 的问题是检索到的上下文有问题还是工具调用返回了错误结果传统的日志系统完全无法应对这种复杂度。读完这篇文章你将理解AgentOps 与 LLMOps 的核心区别Agent 场景独有的可观测性维度主流方案的能力对比和选型建议如何从零搭建 Agent 可观测性体系二、为什么 Agent 需要专门的可观测性2.1 Agent 的多跳推理让故障定位变得困难这是传统 LLM 应用的调用链用户请求 → [RAG 检索] → LLM 调用 → 返回结果这是 Agent 的调用链用户请求 ├→ LLM 思考规划子任务 ├→ 工具调用 1搜索知识库 │ └→ 结果校验 → 不理想换关键词重新搜索 ├→ 工具调用 2查询数据库 ├→ LLM 综合信息生成回答 └→ LLM 自检 → 发现遗漏 → 补充工具调用 3 → 最终回答一个请求可能产生 10-20 个子步骤任何一个环节出错都会传递到最终结果。你需要的不是某次 LLM 调用的日志而是整棵执行树的完整回放。2.2 新出现的可观测维度Agent 带来了一些传统后端监控完全不覆盖的维度新维度说明为什么重要决策 TraceAgent 每一步的思考 → 行动 → 观察循环理解 Agent 为什么做了某个选择工具调用链调了哪个工具、参数是什么、返回值是什么定位工具集成问题重试与循环Agent 自我纠错的次数和原因发现 Prompt 设计缺陷任务成功率多步任务的整体完成率非单次调用成功率Agent 评估的核心指标Token 放大效应一个用户请求实际触发了多少 LLM 调用和 Token成本控制三、AgentOps 的核心能力拆解3.1 Trace Span不只是调用链而是决策树分布式追踪Distributed Tracing的概念在微服务领域已经成熟但 Agent 的 Trace 需要承载更多信息传统 Spanserviceuser-service, operationGET /users, duration23msAgent Spanspan: type: llm.think input: 用户想订一张从北京到上海的机票... output: 我需要先查航班信息再确认用户偏好... model: claude-sonnet-4-6 token_usage: {prompt: 342, completion: 156} duration_ms: 2340 metadata: step_in_plan: gather_info parent_span: task_book_flight关键设计原则每个 LLM 调用和工具调用都是独立 SpanSpan 之间构成树状结构根 Span 代表用户请求需要记录 IO 内容至少摘要方便事后回放分析3.2 决策回放排查问题的终极武器Agent 最让人头疼的场景是同样的输入有时对有时错。为什么因为温度参数、检索结果、API 返回值的微小差异都会让 Agent “走上不同的路”。决策回放Decision Replay能力让你能以时间线形式回看 Agent 的每一步看到每一步的输入、输出、耗时、模型参数对比成功路径和失败路径的分叉点# 伪代码用 LangFuse 获取一次 Trace 并分析fromlangfuseimportLangfuse langfuseLangfuse()# 获取某次用户投诉的 Tracetracelangfuse.get_trace(trace_idtrace_abc123)print(f任务:{trace.name})print(f总步数:{len(trace.observations)})print(f总 Token:{trace.usage.total})print(f总耗时:{trace.duration}ms)forobsintrace.observations:print(f [{obs.type}]{obs.name}| f耗时{obs.duration_ms}ms | fToken{obs.usage.totalifobs.usageelse0})3.3 工具调用可观测性Agent 的手不能是黑盒Agent 通过工具Tool/Function Call与外部世界交互。工具的可靠性直接影响 Agent 的可靠性。每个工具调用需要记录{tool_name:search_knowledge_base,input:{query:Python GIL 是什么,top_k:5},output:{documents:[...],count:3,elapsed_ms:234},status:success,error:null}工具层面的关键指标指标计算方式告警阈值建议工具调用成功率success / total 95%工具调用 P99 延迟排序取 P99 2000ms空结果率搜索类工具empty_result / total 30%工具调用次数分布按工具名分组统计异常尖峰3.4 成本归因Agent 是烧钱机器还是物有所值单个 LLM 调用的成本大概在 $0.001-$0.01看起来不贵。但一个 Agent 任务可能调用 10 次 LLM每次的上下文又越来越长RAG 检索结果被拼入后续 Prompt导致成本非线性增长。成本归因需要回答哪个用户/租户花的 Token 最多哪种类型的任务平均成本最高Agent 的多轮循环中哪一轮最烧钱# 成本归因示例defcalculate_session_cost(trace):total_cost0cost_breakdown{}forobsintrace.observations:ifobs.typegenerationandobs.usage:modelobs.model input_cost(obs.usage.prompt_tokens/1_000_000)*PRICING[model].inputoutput_cost(obs.usage.completion_tokens/1_000_000)*PRICING[model].output costinput_costoutput_cost total_costcost cost_breakdown[obs.name]cost_breakdown.get(obs.name,0)costreturntotal_cost,cost_breakdown四、主流 AgentOps 方案对比方案类型核心优势短板适合场景LangFuse开源/商业全栈Trace 评测 Prompt 管理 成本LangChain/OpenAI 原生集成自部署需要基础设施中小团队首选LangSmith商业LangChain 深度集成Hub 社区共享 Prompt非 LangChain 栈集成成本高重度 LangChain 用户Arize Phoenix开源质量评估和漂移检测能力强Trace 功能相对弱侧重质量监控的团队Weights Biases商业训练评估一条龙实验追踪成熟Agent 场景的支持较新同时做微调和 Agent 的团队自研方案自建完全定制数据不外传研发成本高长期维护负担大厂/强合规需求选型建议2-5 人团队、做 Agent 原型LangFuse Cloud免费额度够用10-50 人团队、Agent 在产品中LangFuse 自部署 Phoenix 做质量50 人、多个 Agent 产品线LangSmith商业支持 自研部分组件强合规/私有化LangFuse 自部署 定制开发五、从零搭建 Agent 可观测性最小可行版本第 1 步集成 Trace SDK30 分钟fromlangfuseimportLangfusefromlangfuse.decoratorsimportobserve,langfuse_context# 初始化langfuseLangfuse(public_keypk-...,secret_keysk-...,)observe(as_typegeneration)defcall_llm(messages,modelgpt-4o):# 你的 LLM 调用逻辑responseopenai_client.chat.completions.create(...)# 自动记录 Token 使用langfuse_context.update_current_observation(usage{input:response.usage.prompt_tokens,output:response.usage.completion_tokens},modelmodel)returnresponseobserve()defagent_loop(user_request):# Agent 主循环plancall_llm(...)# 自动嵌套为子 Spantool_resultexecute_tool(...)final_answercall_llm(...)returnfinal_answer第 2 步建立质量评估1 小时fromlangfuseimportLangfuse langfuseLangfuse()# 在 Trace 上打分tracelangfuse.trace(nameagent_booking,user_iduser_123)# 对最终回答评分trace.score(nameuser_satisfaction,value4,# 1-5 分comment订票成功但耗时较长)trace.score(nametask_success,value1,# 0 或 1comment正确完成了机票预订)第 3 步配置告警30 分钟LangFuse 支持 Webhook 和 Prometheus 集成至少配置这几个告警任务成功率 80%Agent 可能出问题P95 延迟 30s某些任务卡住了单次任务 Token 50K可能出现了无限循环工具调用错误率 5%外部依赖有问题六、实战案例一次 Agent 线上故障的排查回放某团队的知识库问答 Agent 在周四突然出现质量骤降。通过 LangFuse Trace 排查过程定位问题 Trace筛选用户点踩的会话找到 5 个代表性 Trace回放对比将这些 Trace 与前一天的成功 Trace 对比找到分叉点发现搜索知识库工具返回的空结果率从 3% 飙升到 35%根因周三晚上知识库的向量索引重建任务失败导致大量文档检索不到修复重建索引30 分钟后恢复正常没有 Agent 可观测性这个过程可能需要一整个下午——而你有了 Trace只用了 15 分钟。七、总结Agent 的可观测性不是可选项多跳推理 工具调用 自我纠错 必须要有 Trace 和回放AgentOps 是 LLMOps 的超集多出了决策回放、工具调用链、任务成功率等关键维度最小起步选 LangFuse开源、全栈、集成简单30 分钟就能看到第一棵 Trace 树成本归因要趁早Agent 的 Token 放大效应会让成本 “安静地” 增长等你发现已经晚了评估和可观测是一体的没有自动评估的可观测只是一堆漂亮图表——在生产中它们必须一起工作AgentOps 还处在非常早期的阶段。LangFuse、LangSmith、Arize 每个月都在发布 Agent 相关的新功能。建议持续关注这些项目的 ChangelogAgent 的可观测性标准还在被定义中。
LLM和Agent——专题5： LLM Ops 入门（2）
发布时间：2026/6/18 18:52:34
AgentOps 是什么Agent 可观测性从零到一Agent 不是调一次 API 就完事的应用——它在多轮思考、工具调用、甚至自我纠错中完成一个任务。这种复杂性让可观测性从锦上添花变成了保命刚需。一、引言2025 年被称为Agent 元年。从 coding agent、客服 agent 到 browser-use agentAI 应用正在从单次问答进化到多步自主执行。但 Agent 带来了全新的工程挑战——一个用户请求可能触发5 次 LLM 调用思考、规划、执行、校验、总结3 次工具调用搜索文档、查询数据库、执行代码2 次内部循环结果不符合预期 → 重试当用户说你的 Agent 回答错了你该怎么排查是 Prompt 的问题是检索到的上下文有问题还是工具调用返回了错误结果传统的日志系统完全无法应对这种复杂度。读完这篇文章你将理解AgentOps 与 LLMOps 的核心区别Agent 场景独有的可观测性维度主流方案的能力对比和选型建议如何从零搭建 Agent 可观测性体系二、为什么 Agent 需要专门的可观测性2.1 Agent 的多跳推理让故障定位变得困难这是传统 LLM 应用的调用链用户请求 → [RAG 检索] → LLM 调用 → 返回结果这是 Agent 的调用链用户请求 ├→ LLM 思考规划子任务 ├→ 工具调用 1搜索知识库 │ └→ 结果校验 → 不理想换关键词重新搜索 ├→ 工具调用 2查询数据库 ├→ LLM 综合信息生成回答 └→ LLM 自检 → 发现遗漏 → 补充工具调用 3 → 最终回答一个请求可能产生 10-20 个子步骤任何一个环节出错都会传递到最终结果。你需要的不是某次 LLM 调用的日志而是整棵执行树的完整回放。2.2 新出现的可观测维度Agent 带来了一些传统后端监控完全不覆盖的维度新维度说明为什么重要决策 TraceAgent 每一步的思考 → 行动 → 观察循环理解 Agent 为什么做了某个选择工具调用链调了哪个工具、参数是什么、返回值是什么定位工具集成问题重试与循环Agent 自我纠错的次数和原因发现 Prompt 设计缺陷任务成功率多步任务的整体完成率非单次调用成功率Agent 评估的核心指标Token 放大效应一个用户请求实际触发了多少 LLM 调用和 Token成本控制三、AgentOps 的核心能力拆解3.1 Trace Span不只是调用链而是决策树分布式追踪Distributed Tracing的概念在微服务领域已经成熟但 Agent 的 Trace 需要承载更多信息传统 Spanserviceuser-service, operationGET /users, duration23msAgent Spanspan: type: llm.think input: 用户想订一张从北京到上海的机票... output: 我需要先查航班信息再确认用户偏好... model: claude-sonnet-4-6 token_usage: {prompt: 342, completion: 156} duration_ms: 2340 metadata: step_in_plan: gather_info parent_span: task_book_flight关键设计原则每个 LLM 调用和工具调用都是独立 SpanSpan 之间构成树状结构根 Span 代表用户请求需要记录 IO 内容至少摘要方便事后回放分析3.2 决策回放排查问题的终极武器Agent 最让人头疼的场景是同样的输入有时对有时错。为什么因为温度参数、检索结果、API 返回值的微小差异都会让 Agent “走上不同的路”。决策回放Decision Replay能力让你能以时间线形式回看 Agent 的每一步看到每一步的输入、输出、耗时、模型参数对比成功路径和失败路径的分叉点# 伪代码用 LangFuse 获取一次 Trace 并分析fromlangfuseimportLangfuse langfuseLangfuse()# 获取某次用户投诉的 Tracetracelangfuse.get_trace(trace_idtrace_abc123)print(f任务:{trace.name})print(f总步数:{len(trace.observations)})print(f总 Token:{trace.usage.total})print(f总耗时:{trace.duration}ms)forobsintrace.observations:print(f [{obs.type}]{obs.name}| f耗时{obs.duration_ms}ms | fToken{obs.usage.totalifobs.usageelse0})3.3 工具调用可观测性Agent 的手不能是黑盒Agent 通过工具Tool/Function Call与外部世界交互。工具的可靠性直接影响 Agent 的可靠性。每个工具调用需要记录{tool_name:search_knowledge_base,input:{query:Python GIL 是什么,top_k:5},output:{documents:[...],count:3,elapsed_ms:234},status:success,error:null}工具层面的关键指标指标计算方式告警阈值建议工具调用成功率success / total 95%工具调用 P99 延迟排序取 P99 2000ms空结果率搜索类工具empty_result / total 30%工具调用次数分布按工具名分组统计异常尖峰3.4 成本归因Agent 是烧钱机器还是物有所值单个 LLM 调用的成本大概在 $0.001-$0.01看起来不贵。但一个 Agent 任务可能调用 10 次 LLM每次的上下文又越来越长RAG 检索结果被拼入后续 Prompt导致成本非线性增长。成本归因需要回答哪个用户/租户花的 Token 最多哪种类型的任务平均成本最高Agent 的多轮循环中哪一轮最烧钱# 成本归因示例defcalculate_session_cost(trace):total_cost0cost_breakdown{}forobsintrace.observations:ifobs.typegenerationandobs.usage:modelobs.model input_cost(obs.usage.prompt_tokens/1_000_000)*PRICING[model].inputoutput_cost(obs.usage.completion_tokens/1_000_000)*PRICING[model].output costinput_costoutput_cost total_costcost cost_breakdown[obs.name]cost_breakdown.get(obs.name,0)costreturntotal_cost,cost_breakdown四、主流 AgentOps 方案对比方案类型核心优势短板适合场景LangFuse开源/商业全栈Trace 评测 Prompt 管理 成本LangChain/OpenAI 原生集成自部署需要基础设施中小团队首选LangSmith商业LangChain 深度集成Hub 社区共享 Prompt非 LangChain 栈集成成本高重度 LangChain 用户Arize Phoenix开源质量评估和漂移检测能力强Trace 功能相对弱侧重质量监控的团队Weights Biases商业训练评估一条龙实验追踪成熟Agent 场景的支持较新同时做微调和 Agent 的团队自研方案自建完全定制数据不外传研发成本高长期维护负担大厂/强合规需求选型建议2-5 人团队、做 Agent 原型LangFuse Cloud免费额度够用10-50 人团队、Agent 在产品中LangFuse 自部署 Phoenix 做质量50 人、多个 Agent 产品线LangSmith商业支持 自研部分组件强合规/私有化LangFuse 自部署 定制开发五、从零搭建 Agent 可观测性最小可行版本第 1 步集成 Trace SDK30 分钟fromlangfuseimportLangfusefromlangfuse.decoratorsimportobserve,langfuse_context# 初始化langfuseLangfuse(public_keypk-...,secret_keysk-...,)observe(as_typegeneration)defcall_llm(messages,modelgpt-4o):# 你的 LLM 调用逻辑responseopenai_client.chat.completions.create(...)# 自动记录 Token 使用langfuse_context.update_current_observation(usage{input:response.usage.prompt_tokens,output:response.usage.completion_tokens},modelmodel)returnresponseobserve()defagent_loop(user_request):# Agent 主循环plancall_llm(...)# 自动嵌套为子 Spantool_resultexecute_tool(...)final_answercall_llm(...)returnfinal_answer第 2 步建立质量评估1 小时fromlangfuseimportLangfuse langfuseLangfuse()# 在 Trace 上打分tracelangfuse.trace(nameagent_booking,user_iduser_123)# 对最终回答评分trace.score(nameuser_satisfaction,value4,# 1-5 分comment订票成功但耗时较长)trace.score(nametask_success,value1,# 0 或 1comment正确完成了机票预订)第 3 步配置告警30 分钟LangFuse 支持 Webhook 和 Prometheus 集成至少配置这几个告警任务成功率 80%Agent 可能出问题P95 延迟 30s某些任务卡住了单次任务 Token 50K可能出现了无限循环工具调用错误率 5%外部依赖有问题六、实战案例一次 Agent 线上故障的排查回放某团队的知识库问答 Agent 在周四突然出现质量骤降。通过 LangFuse Trace 排查过程定位问题 Trace筛选用户点踩的会话找到 5 个代表性 Trace回放对比将这些 Trace 与前一天的成功 Trace 对比找到分叉点发现搜索知识库工具返回的空结果率从 3% 飙升到 35%根因周三晚上知识库的向量索引重建任务失败导致大量文档检索不到修复重建索引30 分钟后恢复正常没有 Agent 可观测性这个过程可能需要一整个下午——而你有了 Trace只用了 15 分钟。七、总结Agent 的可观测性不是可选项多跳推理 工具调用 自我纠错 必须要有 Trace 和回放AgentOps 是 LLMOps 的超集多出了决策回放、工具调用链、任务成功率等关键维度最小起步选 LangFuse开源、全栈、集成简单30 分钟就能看到第一棵 Trace 树成本归因要趁早Agent 的 Token 放大效应会让成本 “安静地” 增长等你发现已经晚了评估和可观测是一体的没有自动评估的可观测只是一堆漂亮图表——在生产中它们必须一起工作AgentOps 还处在非常早期的阶段。LangFuse、LangSmith、Arize 每个月都在发布 Agent 相关的新功能。建议持续关注这些项目的 ChangelogAgent 的可观测性标准还在被定义中。
