上个月我那个 Agent 答非所问，我猜了一晚上 Prompt。后来开了 Traces，十分钟定位是工具挂了。我太需要一个看清链路的办法。
07.1 普通日志救不了 Agent
普通 Web 应用出事，看接口日志、错误栈就行。Agent 不行。
一次对话，模型先理解，再调工具，工具返回后模型再组织回答。中间哪一步异常，光看最终回复，你根本不知道坏在哪。
07.2 两个面板怎么用
Makers 的观测分两块：
Metrics：看整体。被调用多少次、模型调用多少次、平均耗时、Token 消耗、有没有报错。适合判断服务整体正不正常。
Traces：看单次。每次请求一条完整链路。展开能看到：模型调了几次、调了哪些工具、入参是什么、返回了什么、每步耗时多久。
| 维度 | Metrics | Traces | 标叔的结论 |
|---|---|---|---|
| 看什么 | 整体状态 | 单次细节 | 两个都要 |
| 适合 | 判断健不健康 | 定位哪步坏 | 配合用 |
| 频率 | 每天看 | 出事看 | 出事必看 |
重点看
"出事必看"那格。早期用户反馈很碎。只有把链路看清，才知道是 Prompt 要改、工具要改、还是外部依赖要换。
07.3 实战：一次链路排查
假设用户说 Agent 答非所问。
第一步：开 Traces，找那次请求。
预期结果：看到模型调了两次工具，第二次入参是空的。
第二步：顺藤摸瓜，发现是天气工具超时。
预期结果：问题不在 Prompt，在外部接口。换数据源或加超时重试。
标叔的经验
别靠猜修 Agent。我之前猜了半天 Prompt，其实是工具挂了。有 Traces 后，十分钟定位。
07.4 回顾
能观测，才敢迭代。下一章，我们拿真实项目练手。