生产环境里的Agent出故障，传统排查手段基本失效。你问它为什么慢了、为什么报错、为什么突然自言自语，日志里只有一堆token，没有答案。火山引擎钱世俊在QCon 2026北京的分享给出了一个工程化解法：给Agent建一套"CT系统"。（来源：《给Agent做"CT"：大规模Agent的可观测与质量保障体系》InfoQ/QCon）
图注：CT的逻辑是把内部结构逐层照亮，Agent可观测的目标是同一件事。
为什么传统监控失效了
传统应用的因果关系清晰：输入确定，逻辑确定，输出确定。Agent不是这样。它自主规划任务、调用外部工具、沉淀记忆，任何一次请求在内部都涉及大量复杂的工作流，不是一次模型调用就能完成的。
具体来说有三个断层。链路断：不同层次的观测采集方式各异，业务上下文在不同层级透传时容易丢失。语义断：不同供应商之间链路孤岛，内部语义不对齐，整体排障极为困难。因果断：底层硬件指标与上层推理逻辑之间脱节，比如一次模型推理异常和某次GPU瞬时波动怎么关联，就是个工程难题。（来源：《给Agent做"CT"》）
更特殊的是成本问题。传统微服务场景里，成本可以通过压测精准预估。但Agent场景下，一旦内部逻辑出现偏差，可能在极短时间内触发巨量模型调用，Token消耗呈指数级激增。这不是普通的性能问题，是直接烧钱的问题。
四层架构，各看各的
整个Agent系统自上而下分四层，每层关注的指标完全不同。
业务应用层关心DAU、用户反馈、端到端延迟与成功率。Agent框架层关心整体规划延迟、工具调用成功率、Memory或知识库的召回成功率。大模型推理服务层关心TTFT（首Token延迟）、TPOT（Token间延迟）、Token使用量。云基础设施层关心GPU使用率、网络吞吐量。
这四个层次的数据分散在不同系统里，各说各话。钱世俊团队的解法是先建统一观测基座：融合Metrics、Traces、Logs三驾马车，再加上AI特有的数据——用户Prompt、模型返回内容、Token消耗。在这个基座之上，协同五大能力：统一采集、统一加工、统一门户、统一看板、统一告警。（来源：《给Agent做"CT"》）
采集层用的是OpenTelemetry标准生态，外加一个自研采集器OneAgent。在200K QPS条件下，OneAgent与OTel Collector的性能对比：前者数据吞吐量高出一倍；在部分极端场景节点上，性能提升近三倍。
图注：Agent系统的四层监控断层是钱世俊团队面对的核心问题。
三个典型故障，三个根因
钱世俊分享了三个实际排障案例，都来自OpenClaw的落地实践。
案例一：某个下游API导致Agent响应异常缓慢。 拿到用户ID，找到对应Trace，查看火焰图。发现一个调用get_weather_api的Span耗时占整个请求的90%，最终返回网络超时错误。根因：天气查询API供应商发生网络抖动。修复：增加超时机制与重试机制，对该工具做降级处理。
案例二：Token成本爆炸。 财务部门预警某时段Token消耗爆炸性增长。从成本看板定位到具体Agent和异常时段，再筛选异常Trace，发现generate_summary工具被频繁调用数十次。进一步查看Prompt，发现Agent在不停对记忆内容摘要、再摘要，形成无限循环，上下文雪球式放大。根因：Prompt设计缺陷，没有明确终止指令。修复：重做Prompt、设置最大迭代次数、增加Token预算与早停机制，并把失败案例加入回归测试集。
案例三：长对话后期Agent开始胡说八道。 模型在标准评测集上表现正常，但多轮对话后期出现幻觉。检查会话完整Trace，发现两个问题：一是搜索增强生成的召回得分极低，口语化查询与知识库标准术语相似度太低，RAG实质失效；二是记忆加载的上下文在多轮迭代后被截断，丢失了用户早期输入的关键信息。修复：引入查询重写、优化记忆摘要机制、建立长对话场景的召回率评测。（来源：《给Agent做"CT"》）
图注：三类典型故障的根因分布：工具超时、Prompt循环、记忆截断。
从排障到持续进化
光排障还不够，还要形成闭环。钱世俊提炼了四点闭环路径：先有观测数据，把观测数据回流形成评测集，再做系统化评估，最后根据评估结果持续迭代。
高价值Trace有两类：调用失败的异常场景，和高频使用的典型链路。离线回流：按规则周期性清洗、提取，转化为评测集。在线回流：通过用户点赞/点踩、核心异常监控，实时回流支撑分钟级告警。
评测系统的核心设计是：版本控制保证评测集样本科学性；多维度指标覆盖准确性、Token效率、API调用合理性、规划轨迹分析、拒答率统计；自动化大模型评估器加人工复核，针对高价值高风险场景引入人工标注对齐能力。（来源：《给Agent做"CT"》）
阿里云也在做类似的事。基于开源LoongSuite，为DeepSeek Harness提供两条可观测路线：独立安装的dsh-plugin，和内置于LoongSuite Pilot的集成。两者都基于OpenTelemetry GenAI语义，数据进入用户自选的兼容后端。（来源：《DeepSeek Harness全景可观测实践》阿里云云原生）
源势AI怎么看
我们做企业Agent落地，见过太多"上了线才发现没法排障"的项目。Token成本失控是最常见的一个：一个设计有缺陷的Prompt，能让一次本来消耗几千Token的任务变成消耗几十万。这类问题在日志里几乎看不出来，只有把Trace链路、成本看板、Prompt内容三者关联起来才能定位。
我们的建议很直接：上线前先想清楚三个问题。慢在哪，错在哪，成本花在哪。如果这三个问题回答不了，可观测性就先于功能开发做进去，而不是出事了再补。OpenTelemetry GenAI语义标准已经成熟，工具链也不缺，缺的是把观测数据真正接入评测闭环的那一步。
