24｜用户：Agent，你知错了吗，错在哪儿了？
邓明
你好，我是大明。
做过传统后端开发的人，对可观测性都不陌生。线上接口变慢了，就看 Metrics、Trace 和 Log，顺着调用链找到慢查询、超时或者异常节点。
但是到了 Agent 里面，事情就麻烦了。比如用户明确要求推荐一台 8000 元以内的笔记本，Agent 最后却推荐了一台 9999 元的游戏本。你打开监控一看：HTTP 200，大模型调用成功，商品检索成功，数据库正常，整个请求甚至没有任何异常。
所有监控都是绿的，但答案就是错的。
这就是 Agent 可观测性的独特问题：系统正常运行，不代表 Agent 正确运行。
所以 Agent 的可观测性除了回答“系统有没有挂”，还必须回答：Agent 当时看到了什么？为什么这么决定？究竟从哪一步开始错了？
这一讲，我们就来讨论怎么把 Agent 的执行过程真正“看见”，以及出了问题之后，怎么顺着执行链找到真正的根因。
从传统可观测性说起
在讨论 Agent 的可观测性之前，我们先回到传统软件工程里面看看“可观测性”到底是干什么的，也就是所谓的 Metrics、Trace 和 Log。如这个经典图片：
Metrics 可以翻译为指标、度量等，是可聚合的指标。解决的是“系统整体怎么样”。比如说包括 QPS，RT/P99 RT，错误率，CPU 使用率等。
Trace 可以翻译为链路追踪，解决的是“一次请求到底经历了什么”。比如说一个请求经过网关 -> 订单服务 -> 商品服务 -> Redis -> MySQL，如果整个请求耗时 2 秒，而 Trace 告诉你其中 1.8 秒都花在 MySQL 上，那么排查范围瞬间就缩小了。
Log 是指日志信息，解决的是“这个节点具体发生了什么”。比如说你继续查看数据库相关日志，最后发现某条 SQL 没有走索引，一次查询扫了几百万行。那么到这里，这次故障基本上就定位清楚了：SQL 未命中索引的问题。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《AI Agent 系统设计面试现场》，新⼈⾸单¥59
《AI Agent 系统设计面试现场》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论