Agent 可观测性（Agent Observability）

一次普通的 API 调用很好观测：一个请求进来，一个响应出去,一条日志基本就能说清发生了什么。但 Agent 不是这么工作的。一个编程 Agent 处理一个任务时，可能要读好几个文件、调用一次搜索工具、跑一条 shell 命令、根据返回结果再调用别的工具，如此反复几十步才算完成——或者跑到一半就失败了。Agent 可观测性要做的，就是把这整条执行轨迹都记录下来，而不只是记第一个请求和最后的结果，这样开发者才能真正看清 Agent 为什么会做出某个行为。

这个说法流行起来，是因为 Agent 系统从演示 demo 走向了实际生产使用——『大部分时候能跑』已经不够了，团队需要能定位某一次具体的失败运行、发现某个工具在悄悄出错、或者搞清楚大量运行下来的成本和延迟情况。它和通用的应用可观测性有交集但并不完全一样：Agent 出问题往往不是进程崩溃这种硬故障，而是一串『看起来还算合理但其实错了』的决策链条，这种问题普通的请求日志很难暴露出来。

目前这个领域还没有统一的标准工具集，2026 年仍在快速发展中。不少通用的应用可观测性厂商已经加上了针对 Agent 的追踪功能，同时也有一批专门为 Agent 和 LLM 工作流打造的工具，两类产品并存,行业还没有收敛到某一种主导方案。

怎么运作

Agent 可观测性通常由图中几层互补的数据构成。调用轨迹（Traces） 是单次 Agent 运行的逐步记录——每一次工具调用、输入输出，以及背后导致这次调用的推理或决策，一般会组织成树状或时间线结构，方便开发者事后回放整个过程。日志（Logs） 记录运行过程中产生的更底层、更自由格式的事件——报错、警告、中间输出——补充调用轨迹本身可能没覆盖到的细节。指标（Metrics） 则是跨大量运行的汇总统计——比如某个工具调用的失败率、典型的步骤数、每次运行的延迟和成本——用来发现单次调用轨迹看不出来的规律。这三者结合起来，既能帮团队排查某一次具体的失败运行，也能跟踪 Agent 行为随时间的变化趋势；当关注点从『这一次运行发生了什么』转向『这些运行整体质量如何』时，就和 agent-evaluation 紧密相关了。

举个例子

假设一个原本该修好某个失败测试的编程 Agent，结果反而把仓库改坏了。没有可观测性的话，开发者只能看到最终的代码 diff，只能靠猜去还原到底哪里出了问题。有了调用轨迹之后，就能看到 Agent 一开始读错了文件，调用搜索工具时又拿到了一个不相关的结果，随后基于这个错误的上下文做了修改——真正的问题出在这一步，而不是最后呈现出来的结果本身。

常见误解

常见问题