120、Agent的可观测性：Metrics与Tracing昨天下午我盯着监控面板，发现那个Agent在凌晨开始不断重试同一个工具调用，日志里全是“timeout”，可面板上延迟曲线却是一条直线。不是不报，时候未到——因为当时只打了log，没打metrics，也没trace。后来把请求路径串起来才发现，是某个中间层把上下文长度撑爆了，每次重试都在重复同样的事。这让我意识到，Agent和普通服务在可观测性上是两个物种。普通API的调用是有限的、可预测的，请求进来，响应出去，你只需要知道状态码、延迟、QPS就够了。Agent不是这样。一个Agent任务内部会发起多轮LLM调用、工具调用、知识库检索，甚至多个子任务并行。每一步都依赖上一步的结果，而LLM本身又是概率性的，同一个任务可能两次走完全不同的路径。没有Metrics和Tracing，你就等于蒙着眼睛开车，只能靠用户反馈说“它好像疯了”。先说说Metrics。Agent里的指标，我分三类。第一类是资源指标，CPU、内存、队列长度、并发数，这些和普通服务一样，但Agent尤其要关注并发和排队，因为LLM API有并发限制，queue一长，整个Agent就“卡死”了。第二类是性能指标，LLM调用耗时、工具调用耗时、总延迟。注意，我特意说“耗时分布”而不是“平均耗时”。LLM延迟是爆炸形态的，平均值没有意义，有一次调用可能20秒，剩下都在2秒以内，平均值可能只有3秒，但p99可能是15秒。所以我们要用Histogram来记录分布。第三类是业务指标，token消耗、工具调用次数、任务成功率、重试率、上下文长度。这些才是Agent独有的。实际采集的时候，用prometheus_c