Agent 可观测概述1: 为什么 Agent 会让"看得见"变难

这是 Agent 可观测性系列的第一篇文章。在这个系列中，我将分享自己在构建 AI Agent 可观测体系过程中的思考与实践。

从一个真实的困惑说起

前段时间，团队的一个 AI Agent 在生产环境出了问题——它”完成”了用户交给它的任务，但结果完全不对。

当我们试图复盘这个问题时，发现自己陷入了一种奇怪的困境：我们能看到 Agent 调用了哪些 API，能看到它消耗了多少 Token，甚至能看到整个请求链路的延迟分布。但我们无法回答一个最基本的问题：它为什么会做出那个错误的决定？

这让我开始意识到，Agent 时代的可观测性，和我们熟悉的那套东西，可能完全不是一回事。

一、Agent 的不确定性与动态路径

传统微服务的可观测性建立在一个隐含假设之上：服务的行为是确定性的。

给定相同的输入，服务会走相同的代码路径，调用相同的下游服务，返回相同的结果。即使有分支逻辑，这些分支也是可穷举的——它们都写在代码里。

但 Agent 打破了这个假设。

Agent 本质上是一个以 LLM 为核心推理引擎的循环系统：

感知 (Perception) → 规划 (Planning) → 行动 (Action) → 反馈 → 再规划...

这个循环中的每一步”规划”，都是基于概率推理的结果。同样的输入，不同时刻执行，Agent 可能会选择完全不同的工具、走完全不同的路径。

举个例子：当你让 Agent “帮我分析一下这个项目的代码质量”，它可能会：

  • 第一次运行：先读取 README，再扫描目录结构，最后检查几个核心文件
  • 第二次运行：直接跑一个 lint 工具，然后分析输出
  • 第三次运行：先查找已有的 CI 配置，再针对性地检查

哪种路径是”对”的？很难说。但问题在于——你无法预测它会选择哪条路径。

这种不确定性意味着：

  • 传统的调用链（Trace）变得不可预测
  • 基于固定拓扑的告警规则失效
  • 性能基线难以建立（每次执行路径都不一样，延迟波动是正常的还是异常的？）

二、“做了什么”与”为什么做”的分裂

这是我在做 Agent 可观测性时遇到的最核心的痛点：传统监控只能回答”What”，但 Agent 需要我们回答”Why”。

让我用一个具体场景来说明。

假设一个 Agent 执行了这样一个操作：

DELETE /api/v1/resources/12345

从 APM 的视角，这只是一个 HTTP 请求。你能看到：

  • 请求方法：DELETE
  • 目标 URL：/api/v1/resources/12345
  • 响应状态：200
  • 延迟：150ms

但你无法知道：

  • Agent 为什么决定删除这个资源？
  • 它是在执行用户的明确指令，还是基于某种推理做出的”自主判断”？
  • 它是否考虑过其他方案但最终选择了删除？
  • 这个删除操作是否符合预期？

更棘手的是，Agent 的决策过程（Chain of Thought）和它的实际行为（Tool Calls）是割裂的。

  • CoT 是 Agent “内心的独白”，通常只存在于 LLM 的响应中，不会被传统监控系统捕获
  • 工具调用是 Agent “外在的动作”，能被 APM 捕获，但缺乏语义上下文

这种割裂导致一个尴尬的局面：当 Agent 出问题时，我们能看到它”做了什么”，但无法理解它”为什么做”。

三、传统监控在这里最容易忽略的盲区

基于上面的分析，我总结了三个传统监控最容易忽略的盲区：

盲区 1：审计日志与运行时行为的错位

以 Kubernetes 环境为例。

假设一个 Agent 通过 kubectl exec 进入 Pod 执行命令。K8s Audit Log 会记录：

  • 谁发起了 exec 请求
  • 目标 Pod 是什么
  • 请求时间

但 Audit Log 不会记录容器内实际执行了什么命令。

另一边，如果你在节点上用 eBPF 监控 syscall，你能看到：

  • 容器内执行了 rm -rf /data/*
  • 执行进程的 PID
  • 执行时间

但你不知道这个命令是谁发起的——因为 Linux 内核不感知 Kubernetes 的身份体系。

审计知道”谁”，运行时知道”做了什么”，但两者之间缺少关联。

盲区 2：网络层只能看到”连接”，看不到”意图”

传统的网络安全工具（防火墙、CNI 策略）工作在 IP 层。它们能看到：

  • Pod A 连接了 Pod B
  • 流量大小
  • 协议类型

但它们无法理解：

  • Agent 发送的 Prompt 是什么
  • 工具调用的参数是什么
  • Agent 是否在执行危险操作

更要命的是，很多 Agent 与外部 LLM 的通信是 HTTPS 加密的。即使你做了流量镜像，看到的也只是加密后的字节流。

盲区 3：APM 关注”性能”，不关注”语义”

APM 工具的核心指标是：

  • 延迟（Latency）
  • 吞吐（Throughput）
  • 错误率（Error Rate）

这些指标对于理解”系统是否健康”很有用，但对于理解”Agent 是否在正确地工作”几乎没有帮助。

一个 Agent 可以：

  • 延迟很低 → 但做出了错误的决策
  • 没有报错 → 但执行了危险的操作
  • 吞吐很高 → 但陷入了无意义的循环

性能健康 ≠ 行为正确。

这是 Agent 可观测性区别于传统可观测性的根本差异。

小结

Agent 让”看得见”变难，根本原因在于：

  1. 不确定性：Agent 的执行路径是概率性的，无法预测和穷举
  2. 语义鸿沟：传统监控只能回答”做了什么”，无法回答”为什么做”
  3. 数据孤岛：审计、运行时、网络、APM 各自为战，缺乏关联

在下一篇文章中，我会分享自己是如何理解 Agent 世界中的”关键对象”的——包括 Agent 本身、模型源、工具、以及它们之间的协作链路。

只有先搞清楚”要观测什么”，才能回答”怎么观测”。

下一篇：Agent 可观测概述2: 我如何理解 Agent 的关键对象

评论