Agent 可观测概述2：我如何理解 Agent 的关键对象
这是 Agent 可观测性系列的第二篇文章。上一篇我们聊了为什么 Agent 让”看得见”变难，这一篇来聊聊：在 Agent 的世界里，我们到底要观测什么？
从一个类比说起
做传统微服务的可观测性时，我们有一套成熟的心智模型：
- 服务是基本单元
- 依赖是服务之间的调用关系
- 链路是一次请求经过的所有服务
这套模型之所以有效，是因为它准确地抽象了微服务架构中的核心对象和关系。
那么问题来了：Agent 的世界里，核心对象是什么？它们之间的关系又是什么？
在做 Agent 可观测性的过程中，我逐渐形成了一套自己的理解框架。这篇文章就来分享这个框架。
一、Agent 世界的四类核心对象
经过一段时间的实践，我把 Agent 世界中需要观测的对象归纳为四类：
1. Agent（智能体）
这是最核心的对象。
但什么是 Agent？从可观测的角度，我给它的定义是：具备自主推理能力，能够主动发起对 LLM 的请求并根据响应调用外部工具的工作负载。
注意几个关键词：
- 自主推理：不是简单的 if-else 逻辑，而是基于 LLM 的概率推理
- 主动发起：Agent 不是被动等待请求，它会主动”思考”和”行动”
- 调用工具：Agent 的能力边界取决于它能调用哪些工具
从运维视角看，Agent 通常是一个长期运行的进程（或 Pod），它的特征包括：
- 频繁向 LLM 服务发起 HTTPS 请求
- 同时连接多个下游服务（数据库、API、外部工具）
- 流量模式是”长文本”的 Request-Response
2. Model Source（模型源）
Agent 的”大脑”不在本地，而是在远程的 LLM 服务。这个服务就是模型源。
模型源可以分两类：
- 公有云模型：OpenAI、Anthropic、Google Gemini 等
- 私有化部署：Ollama、vLLM、TGI 等自建模型服务
为什么模型源重要？
因为 Agent 与模型源之间的通信，承载了最核心的语义信息：
- Prompt（Agent 想做什么）
- Response（模型建议怎么做）
- Tool Calls（Agent 决定执行什么）
如果你只能观测一个地方，那就观测 Agent 与模型源之间的流量。
3. Tool（工具）
工具是 Agent 产生实际效果的载体。
Agent 本身不能直接改变世界——它需要通过调用工具来执行操作。一个 Agent 可能调用的工具包括：
基础设施工具：
- Kubernetes API（kubectl）
- 云服务 CLI（aws、gcloud）
- 容器运行时命令
数据工具：
- 数据库（PostgreSQL、Redis）
- 向量库（Milvus、Pinecone）
- 对象存储
外部 API：
- GitHub、Slack、Jira 等 SaaS 服务
- MCP (Model Context Protocol) 服务器
工具调用是最容易出问题的环节。Agent 的一个错误推理，可能导致：
- 误删数据
- 泄露敏感信息
- 执行危险命令
4. Agent-to-Agent Link（协作链路）
在复杂场景中，Agent 往往不是单打独斗，而是多个 Agent 协作完成任务。
比如：
- Planner Agent 负责拆解任务
- Executor Agent 负责执行具体操作
- Reviewer Agent 负责检查结果
这些 Agent 之间的协作关系，构成了协作链路。
协作链路带来的观测挑战是：一个任务的执行可能跨越多个 Agent，每个 Agent 有自己的推理过程和工具调用，如何把它们串联起来？
二、从”资产与链路”的角度理解可观测性
有了上面的四类对象，我们可以换一个视角来理解可观测性。
传统微服务的可观测性，本质上是在做两件事：
- 资产盘点：系统里有哪些服务？每个服务的状态如何？
- 链路追踪：一次请求经过了哪些服务？每个环节的耗时和状态如何？
Agent 可观测性也可以用这个框架来理解：
资产层面：我有哪些 Agent？它们依赖什么？
- 集群里运行了哪些 Agent？
- 每个 Agent 连接了哪些模型源？
- 每个 Agent 可以调用哪些工具？
- Agent 之间有哪些协作关系？
这是静态的资产拓扑，回答的是”系统长什么样”。
链路层面：一次任务经历了什么？
- Agent 收到了什么输入？
- Agent 向模型发送了什么 Prompt？
- 模型返回了什么建议？
- Agent 调用了哪些工具？参数是什么？结果是什么？
- 如果涉及多 Agent 协作，任务是如何在 Agent 之间流转的？
这是动态的执行链路，回答的是”这次任务发生了什么”。
把两者结合起来，形成的图景是：
┌─────────────────────────────────────────────────────────┐
│ 资产拓扑 │
│ ┌─────────┐ A2L ┌─────────┐ │
│ │ Agent │ ────────→ │ Model │ │
│ │ │ │ Source │ │
│ └────┬────┘ └─────────┘ │
│ │ A2T │
│ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Tool │ │ Tool │ │ Tool │ │
│ │ (Infra) │ │ (Data) │ │ (SaaS) │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ A2A (Agent-to-Agent) │
│ ┌─────────┐ ┌─────────┐ │
│ │ Planner │ ────────→ │Executor │ │
│ │ Agent │ │ Agent │ │
│ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────────────────┘其中的三种链路类型：
- A2L (Agent-to-LLM)：Agent 与模型源之间的推理请求
- A2T (Agent-to-Tool)：Agent 调用工具产生实际效果
- A2A (Agent-to-Agent)：多 Agent 协作时的任务流转
三、从现有方案获得的启发
在构建 Agent 可观测性的过程中，我参考了不少现有的方案。虽然不想直接点名，但有几个共性的启发值得分享：
启发 1：SDK 埋点 vs 无侵入采集
市面上大多数 Agent 可观测方案采用 SDK 埋点的方式——在你的 Agent 代码里引入它们的 SDK，SDK 会自动上报调用数据。
这种方式的优点是：
- 实现简单
- 能获取到应用层的语义信息（比如 Prompt、Tool Call 参数）
缺点是：
- 需要修改业务代码
- 只能观测”愿意被观测”的行为
- 难以覆盖所有 Agent 框架
另一种思路是无侵入采集：在网络层或系统调用层拦截数据，不需要修改业务代码。
这种方式的优点是：
- 零改动
- 能观测到所有行为，包括”没打算被观测”的
- 更适合安全审计场景
缺点是：
- 实现复杂
- 加密流量需要额外处理
- 可能有性能开销
我的选择：对于生产环境的安全可观测，无侵入采集是更好的选择。SDK 埋点适合开发调试阶段。
启发 2：关注点在”Trace”还是”Audit”
不同的可观测方案有不同的侧重点：
有些方案侧重于调试体验——帮你看清 Agent 的推理过程，方便调优 Prompt、优化 Tool 调用。这类方案的数据模型类似传统的 Distributed Tracing。
有些方案侧重于安全审计——帮你记录 Agent 的所有行为，检测异常和风险。这类方案的数据模型更像 Audit Log。
两者的差异体现在：
- Trace 关心”延迟”，Audit 关心”完整性”
- Trace 可以采样，Audit 必须全量
- Trace 保留时间短，Audit 需要长期存储
我的选择：两者都需要，但在生产环境，Audit 优先于 Trace。
启发 3：数据模型要能”关联”
无论是哪种方案，一个共同的挑战是：如何把不同来源的数据关联起来。
- 网络流量 + 进程信息
- K8s Audit Log + 容器内行为
- Agent 推理过程 + 工具调用结果
如果这些数据是孤立的，价值会大打折扣。
设计数据模型时，关联能力应该是第一优先级。
小结
理解 Agent 世界的关键对象，是构建可观测性的基础：
- 四类核心对象：Agent、Model Source、Tool、Agent-to-Agent Link
- 两个观测维度：资产拓扑（静态）+ 执行链路（动态）
- 三种链路类型：A2L、A2T、A2A
在下一篇文章中，我会深入聊聊”采集”这个话题——面对这么多种类的数据，应该用什么方式采集？代码埋点、网络代理、运行时监控，各有什么权衡？
评论