AI Agent 可观测性破解多步推理黑盒你上线了一个 AI Agent它表现不错——直到某天客服甩来一条投诉“你们的智能客服把用户的退款金额算错了用户要起诉。”你打开代码一脸懵它到底哪一步推理错了是检索漏了退款政策还是某个工具返回了错误数据这就是多步推理的黑盒问题——一个请求内部要经历「规划 → 检索 → 调工具 → 反思 → 回答」好几步任何一步出错最终都表现为答案错了但你根本定位不到是哪一步。本文带你搞懂 Agent 可观测性把黑盒拆开看。一、为什么传统监控在 Agent 面前失灵了先看一个扎心的对比维度传统后端监控APMAI Agent 可观测性失败类型机械故障500 错误、超时语义故障答案错了、幻觉失败定位单次调用报错即知道多步因果链得回溯每一步行为确定性非确定性同输入不同输出输入空间固定 API 端点无限的自然语言质量度量系统指标CPU、QPS对话质量有没有答对一句话总结传统监控只能回答服务还活着吗Agent 可观测性要回答答案对不对、成本合不合理、推理路径讲不讲得通。而 Agent 最让人头疼的地方恰恰在于一个请求内部会经历「规划 → 检索 → 调用工具 A → 调用工具 B → 反思 → 回答」这样一串步骤。任何一步出错最终都表现为答案错了但你根本不知道是哪一步。二、核心武器Trace追踪破解黑盒的第一把钥匙是把一次 Agent 执行记录成一棵 Span 树。Span一次动作一次 LLM 调用、一次工具调用、一次向量检索Trace一次完整的用户请求由多个 Span 嵌套而成Thread一次完整对话多轮 Trace 串起来一个多步 Agent 的 Trace 长这样用户请求 └─ [Span] 规划LLM 调用 #1 ├─ 输入完整上下文 用户问题 └─ 输出计划「先查天气再查机票最后对比」 ├─ [Span] 工具调用get_weather(上海) ├─ 参数{city: 上海} └─ 结果晴32℃ ├─ [Span] 工具调用search_flights(...) │ └─ 结果3 条航班 └─ [Span] 生成回答LLM 调用 #2 ├─ 输入天气 航班结果 └─ 输出最终答案有了这棵树一个失败的请求就不再是谜你打开它的 Trace就能看到它检索到了什么、计划是什么、哪一步走偏了。统一标准现在行业已经形成共识——用 **OpenTelemetry 的 GenAI 语义约定GenAI Semantic Conventions**来定义这些 Span。它规定了标准的 Span 名称create_agent、invoke_agent、execute_tool和属性gen_ai.usage.input_tokens、gen_ai.usage.output_tokens等。选一个支持这个标准的工具等于给自己上了防锁死保险。三、Agent 特有的观测指标除了通用的延迟、成本、错误率Agent 还需要一组专属指标这些才是多步推理的体检报告指标含义为什么重要推理深度停止前走了多少步156 步 任务太复杂或者 Agent 在打转回溯次数放弃子目标的次数每会话 3 次正常每次都有 计划是坏的工具错误率每个工具的失败率高频工具 32% 错误率 该修了循环次数重复执行同一动作的次数高循环 Agent 卡住了失败子目标Agent 自认无法完成的目标定位 Agent 能力边界的干净信号单步成本每次 LLM/工具调用的花费找出烧钱的那一步接地性Groundedness输出是否基于工具结果直接检测幻觉任务完成度是否真的完成了目标“返回了一句话≠完成了任务”这些指标单独看意义不大组合起来才能定位问题。比如推理深度暴涨 循环次数升高 成本飙升三个信号一起出现基本可以判定 Agent 陷入了死循环或反复重试。四、三大支柱Traces、Metrics、Evals成熟的 Agent 可观测性体系靠三层支撑1. Traces追踪一切的基础。把模型调用、检索、工具调用都包成 Span。有了它成本和延迟数据几乎免费拿到。2. Metrics指标最少监控这三个延迟p50 / p95单次 Token 成本错误率要区分系统错误和语义错误后者才是 Agent 真正的坑3. Evals质量评估这是和传统监控最大的区别——离线评测试题 线上抽样评估。离线用标注数据集跑一遍 Agent算 pass rate发布前拦截劣化线上对线上流量抽样用 LLM-as-judge大模型当裁判给答案打分追踪质量随时间的变化离线评测答题 → 打分 → 低于阈值不发布 线上评测抽样 → 打分 → pass rate 下跌就告警五、2026 年工具生态怎么选工具很多但基本都支持 OpenTelemetry GenAI选对赛道就行工具定位适合谁价格LangSmithLangChain/LangGraph 深度集成已用 LangChain 生态的团队免费 5K traces/月Langfuse开源、OTel-native、可自托管要可移植/自托管/防锁死的团队开源免费Arize PhoenixOTel 评估成熟重视 eval 和漂移检测开源免费Helicone代理式成本追踪多供应商、只关心成本免费 100K 请求/月Braintrust评估优先重视自动化评测循环免费 tierWeights Biases Weave实验追踪 生产监控已用 WB 的团队免费 tier2026 年的默认选择刚起步 →Langfuse 或 LangSmith 免费档前者要可移植后者已用 LangChain已经在用 Datadog / Grafana → 直接加它们的 LLM 模块别重复造轮子规模超大百万 runs/月→ 自建 OTel ClickHouse Grafana 最省钱一个有意思的信号Langfuse 在 2026 年 1 月被 ClickHouse 收购开源路线有了严肃的分析引擎兜底TraceloopOpenLLMetry被 ServiceNow 收购OTel 的标准实现也有了企业背书。六、实践5 分钟接入 Tracing以 Langfuse LangChain 为例接入成本极低fromlangfuse.callbackimportCallbackHandlerfromlangchain_openaiimportChatOpenAIfromlangchain.agentsimportcreate_openai_functions_agent,AgentExecutor# 1. 初始化回调拿到 public_key / secret_key 后配置langfuse_handlerCallbackHandler(public_keypk-xxx,secret_keysk-xxx,hosthttps://cloud.langfuse.com,)# 2. 把回调挂到 LLM 和 Agent 上llmChatOpenAI(modelgpt-4o,callbacks[langfuse_handler])agentcreate_openai_functions_agent(llm,tools,prompt)executorAgentExecutor(agentagent,toolstools,callbacks[langfuse_handler],# 关键这一步让每个工具调用也被追踪)# 3. 正常调用Trace 自动生成resultexecutor.invoke({input:帮我规划一次从上海到北京的出差})跑完这一条Langfuse 后台就会生成完整的 Trace 树你能看到每次 LLM 调用的 prompt、输出、token 数、成本每次工具调用的参数、返回值整条链的延迟分布哪一步最慢一目了然换工具也不难因为大家底层都讲 OTel GenAI 的方言你换 Langfuse → LangSmith → Datadog重装的成本很低。如果你不想绑定任何框架可以直接用 OpenTelemetry 的 GenAI 语义约定手动埋点把每一个动作包成一个 Spanfromopentelemetryimporttracefromopentelemetry.traceimportSpanKind tracertrace.get_tracer(my-agent)defcall_tool(tool_name:str,args:dict):# 每个工具调用 一个 Span属性遵循 GenAI 语义约定spantracer.start_span(nameexecute_tool,kindSpanKind.CLIENT,attributes{gen_ai.tool.name:tool_name,gen_ai.tool.arguments:str(args),},)try:resultrun_actual_tool(tool_name,args)# 真正的工具逻辑span.set_attribute(gen_ai.tool.result,str(result))returnresultfinally:span.end()这样做的意义在于数据格式和行业标准对齐将来无论接 Langfuse 还是 Datadog都只需要一个 OTLP 导出器不用重新埋点。七、实战一次退款金额算错的完整排查光讲理论不够我们走一个真实场景看 Trace 到底怎么帮你破案。背景一个电商客服 Agent负责回答退款政策、计算退款金额。某天质量告警响了退款类任务的线上评测 pass rate 从 92% 跌到 71%同时用户投诉退款金额算错了。传统监控只能告诉你服务正常、没有报错——但答案明明错了。这时候打开 Trace。第一步按失败任务过滤 Trace在观测平台里筛出所有退款金额相关且评测判负的 Trace点开一个典型的看到这样一棵树用户请求「我买了两件商品一件已发货申请全额退款」 └─ [Span] 规划LLM #1 └─ 计划「查退款政策 → 判断已发货商品能否全额退 → 计算金额」 ├─ [Span] 检索retrieve(退款政策) │ └─ 结果命中《退款政策 v2.1》文档片段 ├─ [Span] 工具调用calc_refund(order_idA123) │ └─ 结果{refund: 199, detail: 已发货商品扣除运费} └─ [Span] 回答LLM #2 └─ 输出「您可全额退款 199 元」第二步顺藤摸瓜找根因逐层看答案在检索那一步露了马脚检索命中的是《退款政策 v2.1》但产品侧上周已经更新到了v3.0v3.0 明确规定已发货商品不支持全额退款需扣除 15% 损耗Agent 拿旧政策算出了 199 元实际上应该退 169 元根因不是模型变笨也不是 prompt 写错而是知识库没同步更新——这种问题没有 Trace你翻烂代码也找不到。第三步修复并验证更新向量知识库把 v3.0 政策索引进去顺手加一个断言检索结果里的政策版本号必须匹配最新版本否则告警重跑离线评测套件pass rate 回到 93%从告警到定位到修复全程不到半小时。这就是看得见的系统和黑盒的区别。八、黄金信号与告警观测到数据只是第一步关键是要在出事前收到告警。参考这套分级Critical要立即处理任务成功率 1 小时内跌破 70%单任务成本超过均值 5 倍Agent 执行了被禁止的动作护栏被突破所有 LLM 调用失败供应商宕机Warning通知即可成功率 4 小时内跌破 85%P95 延迟超过正常值 2 倍单日成本超过预算 130%幻觉率超过阈值Weekly周报总任务数、成功率、成本漂移指标、Top 失败原因、成本周环比九、别忽略漂移DriftAgent 用久了会变笨这不是 bug是熵增。常见四类漂移类型表现原因输入漂移用户问的东西变了业务导流变了训练时没见过输出质量漂移答案越来越差知识库过期、模型更新成本漂移单任务成本爬升上下文变长、重试变多行为漂移路由比例异常配置或规则变了检测方法跟踪周滚动均值当前周对比 4 周均值任一指标波动超 15% 就查每周对固定数据集跑一遍评测套件pass rate 跌破阈值就在影响生产前拦截。十、两个容易被忽略的成本钱和安全1. 可观测性本身要花钱别以为上了 Trace 就万事大吉它自己就是一笔开销。算一笔账一个 Agent 跑 100 万次/月每次产生 12 个 Span每个 Span 约 2KB30 天留存压缩后大约要存30GB/月用商业 SaaS 按事件计费这个量级可能要几千美元/月自建 OTel ClickHouse成本能压到个位数美元建议规模小几万 runs/月用 SaaS 免费档省心规模大了再考虑自建。同时记得哈希化敏感字段别把原始 payload 全量存储。2. PII 脱敏是硬要求Trace 里会记录 prompt、用户输入、工具参数——这些极可能包含用户隐私身份证、手机号、地址。一旦 Trace 库泄露就是安全事故。埋点时对敏感字段做脱敏或哈希不要裸存选型时优先看是否支持 PII 自动脱敏比如 LangSmith 的 OTel Gateway 就能在 Trace 出集群前剥离 PII涉及合规金融、医疗脱敏不是可选项是准入门槛十一、结语Agent 可观测性本质是把一个会思考的系统从黑盒变成看得见的系统。这个转变很小但很关键别再只问服务还活着吗要开始问答案对不对、成本合不合理、推理路径讲不讲得通落地的顺序记牢先做 Tracing一切的基础→ 加成本和延迟 → 再上质量评分。每一层都为下一层铺路。最后记住一句话一条不完美的 Trace也远胜过没有 Trace。现在就把你的第一个 LLM 调用包进 Span 里别等出事才后悔。参考资料OpenTelemetry — GenAI Semantic ConventionsLangfuse / LangSmith / Arize Phoenix 官方文档Anthropic — Building Effective AgentsGoogle SRE — Service Level Objectives
