大家好，我是 Kryon。

最近看 AI Agent 的资料，我越来越确定一件事：以后会用 AI 写代码还不够，你得看得懂一次 AI 执行到底发生了什么。

我用一个最小客服 Agent 场景复现了一次问题。

用户问：

表面看，Agent 最后给了答案。 但它花了 38.6 秒，跑了 7 次 LLM 调用，查了 3 个工具，还把同一个订单接口重试了两次。

更麻烦的是，答案也不完全对。

第一反应很自然：是不是模型不行？

打开 trace 后，锅没那么简单。

Trace 里先看三件事

一次 AI 执行，不能只看输入和输出。

至少要看三层：

OpenTelemetry 现在已经给 GenAI 场景定义了语义字段，比如：

这几个字段看起来普通，但它们能回答三个线上问题：

它为什么慢？它为什么错？它为什么贵？

这次慢，不是模型慢

下面是复现样例里整理出来的一段 trace 摘要：

如果只看最后响应时间，你会觉得模型慢。

但 trace 很直接：真正拖时间的是退款状态接口两次超时，以及最后一次 LLM 把前面所有上下文又塞回去了。

这就是 AI 应用和普通接口不一样的地方。

普通接口慢，通常看 SQL、缓存、网络。 Agent 慢，还要看它有没有绕路、有没有重复查、有没有把历史上下文越滚越大。

这次错，不是幻觉这么简单

最后答案说：

这个回答看起来没问题，但 trace 里能看到，Agent 并没有拿到退款状态接口的有效结果。

它真正拿到的是支付记录：

然后它根据通用规则补了一句「1-3 个工作日」。

问题不在这句话本身，而在它把缺失数据当成了可回答数据。

这类问题，光靠最终答案很难发现。用户只会觉得「AI 又瞎说」。 但 trace 会把关键步骤钉出来：退款工具失败了，Agent 没有停止，也没有要求补查，而是继续生成了答案。

这时候该修的不是 prompt 文案，而是执行策略：

没有拿到关键证据，就不要生成确定答案。

这条规则写进代码，比在 prompt 里写十遍「请谨慎回答」更管用。

这次贵，是上下文越滚越大

再看 token。

第一次 LLM 调用输入只有 1,184 tokens。 最后一次到了 14,906 tokens。

原因很常见：每一步都把完整对话、完整工具返回、完整错误堆栈塞回上下文。

OpenAI Agents SDK 的 usage 能看到一次 run 内聚合的 input tokens、output tokens、total tokens，也能按 request 拆开看。LangSmith 这类工具也要求记录 provider、model、token usage，才能展示 token 和 cost。

所以成本排查不能只看总账单。

你要能定位到：

Datadog 2026 的 AI Engineering 报告里有个数据很扎眼：2026 年 2 月，他们观察到的 LLM call spans 里，5% 报错，其中 60% 是 rate limit。到 3 月，错误比例降到 2%，但 rate limit 仍接近三分之一，数量接近 840 万次。

这说明 AI 应用的线上问题，已经不只是「模型答得好不好」。

容量、重试、并发、预算、上下文膨胀，都会变成工程问题。

我现在会这样看一个 AI Trace

如果要排查一个 Agent，我会按这个顺序看：

这里面最容易被忽略的是第四步。

很多 AI 答错，不是模型完全乱编，而是它拿到了一半证据，却装成拿到了全部证据。

Trace 的价值，就是把这件事暴露出来。

未来 AI 工程师要补一门新基本功

过去我们上线一个接口，会看日志、指标、链路追踪。

现在做 AI 应用，也要看同样的东西，只是字段变了：

OpenAI Agents SDK 已经默认支持 tracing，会记录 LLM generation、tool calls、handoffs、guardrails 和自定义事件。OpenTelemetry 也在把 GenAI trace 字段标准化。

这说明方向已经很清楚了。

会写 prompt，只能把 demo 做出来。 会看 trace，才有机会把 AI 应用跑稳。

最后

我对 AI Observability 的判断很简单：

未来的 AI 工程师，不能只问模型怎么回答。还要能说清楚：它哪一步慢了，哪一步错了，哪一步烧钱了。

看不懂 trace，AI 应用出了问题就只能猜。

而工程里最贵的，往往就是猜。