传统 APM 进化到 AI Native：SkyWalking 用户的智能体监控路径
SkyWalking 用户向 AI Native 智能体监控演进：OTel 埋点、Trace 关联与对话式 APM 问数路径。
结论先行：SkyWalking AI Pipeline 偏 ML 基线与 URI 识别；若团队要对话式查 Trace/指标、LLM 应用可观测，可沿 OTel 统一接入 + AI Native 开源 APM 路径并行演进——存量 SkyWalking 不必立刻下线。
1LLM / Agent 应用的可观测挑战
传统微服务 APM 关注 HTTP 延迟与错误率；AI 应用还要回答「这次推理花了多少 Token」「调了哪些工具、顺序如何」
| 观测维度 | 典型问题 | 为什么需要 Trace |
|---|---|---|
| Token 消耗 | 单次对话 input/output Token 激增、成本失控 | 需在 Span 上记录 gen_ai.usage.*，按会话/用户聚合 |
| 工具调用 | Agent 循环调用 search / SQL / HTTP，哪次失败？ | 每个 tool call 应是独立 Child Span，保留参数摘要与耗时 |
| 多轮对话链 | ReAct、Plan-and-Execute 多轮推理如何串起来 | 同一 trace_id 下串联多轮 LLM + Tool Span，形成应用性能监控可下钻的调用树 |
业界共识是：LLM 应用的可观测性应建立在 OpenTelemetry 之上，而不是各框架私有日志。OTel 社区已发布 Generative AI 语义约定（Semantic Conventions for GenAI），为智能体监控提供了跨语言、跨后端的统一 Span 属性模型。
◆ ◆ ◆
2OpenTelemetry 语义约定与 LLM Instrumentation 实践
用标准 Span 属性描述模型调用与工具链，任意开源 APM 后端都能接收
OTel GenAI 约定建议在 LLM 调用 Span 上设置以下属性（节选）：
| 属性 | 含义 | 示例值 |
|---|---|---|
gen_ai.system | 模型提供商 | openai / anthropic |
gen_ai.request.model | 请求模型名 | gpt-4o |
gen_ai.usage.input_tokens | 输入 Token 数 | 1280 |
gen_ai.usage.output_tokens | 输出 Token 数 | 256 |
gen_ai.operation.name | 操作类型 | chat / embeddings |
工具调用 Span 建议使用 gen_ai.tool.name、gen_ai.tool.type 等属性，并与父级 LLM Span 共享同一 Trace，便于在全链路追踪 UI 中展开瀑布图。
以 LangChain / 自研 Agent 服务为例，核心是让 OTel SDK 把 Trace 导出到 APM Ingest。以下配置与 Databuff 默认 OTLP 端口一致：
Ingest 服务默认暴露双通道 OTLP 端口：
埋点建议：① 每次 LLM 调用一个 Span，写入 Token 属性；② 每次 Tool 执行一个 Child Span；③ 用户会话 ID 写入 session.id 或自定义 Resource 属性，便于在应用性能监控控制台按会话筛选。
各语言可参考 OpenTelemetry 官方 GenAI Instrumentation 文档 与 Python OpenAI 自动埋点指南。
◆ ◆ ◆
3用开源 APM 监控 Agent：Trace 关联 + 指标聚合
Agent 服务与普通微服务一样走 OTLP 上报；差异在于 Span 语义与下钻路径
典型 Agent 架构包含三层可观测对象：
编排层（Agent Orchestrator）— 接收用户请求，驱动多轮推理 模型层（LLM API Gateway）— 对外调用 OpenAI / 本地 vLLM 工具层（Search、DB、内部 REST）— Agent 调用的下游服务
三层各自设置 OTEL_SERVICE_NAME，通过 W3C Trace Context 传播 traceparent，即可在开源 APM 中形成跨服务调用树——这与传统微服务全链路追踪完全一致，无需专有 Agent 探针。
图 1 · 链路追踪 — Agent 服务上报的 Trace 可在 APM 控制台按时间、耗时筛选与下钻
图 1 · 链路追踪 — Agent 服务上报的 Trace 可在 APM 控制台按时间、耗时筛选与下钻
下钻单条 Trace 后，可定位慢 Span：是 LLM 首 Token 延迟高，还是某次 Tool 调用超时——这是智能体监控的第一阶段落地方式。
OTLP Trace 入库后，现代 APM 会从 Span 派生分钟级指标：QPS、P99 延迟、错误率。Agent 服务与普通 API 服务一样出现在服务列表中，可按服务名观察整体健康度。
| 监控视角 | 数据来源 | 适用场景 |
|---|---|---|
| 服务级健康 | Trace 派生指标 | Agent 编排服务整体 QPS / 错误率告警 |
| 慢请求定位 | Trace 瀑布图 | 单次对话哪一步最慢 |
| Token 成本 | Span 属性聚合 | 需后端支持 GenAI 属性索引（见 §5 Roadmap） |
| 工具链拓扑 | Span 父子关系 | 可视化 Agent → Tool 调用图（见 §5 Roadmap） |
快速起步：先用标准 OTel 把 Agent 服务当作普通微服务接入开源 APM，立刻获得 Trace + 服务指标；Token 专用大盘与工具链拓扑属于下一阶段增强能力。
◆ ◆ ◆
4Databuff 现状：AI 问数/巡检 + Roadmap 能力边界
国产全栈开源 APM，AI 平台从第一天按「数据驱动 + 多智能体协同」设计
Databuff 内置 AI 平台，基于 AgentScope 2.0 多智能体框架，包含：
问数 Agent — 自然语言查询错误率、Trace 趋势、服务指标 巡检 Agent — 自动健康巡检与异常 triage 大脑编排 — 根据用户问题委派子 Agent，回答必须基于真实 Doris 存储数据
图 2 · AI 对话 — 多智能体问数/巡检，用自然语言查错误率与 Trace 趋势
图 2 · AI 对话 — 多智能体问数/巡检，用自然语言查错误率与 Trace 趋势
平台同时暴露 MCP Server，供外部 AI 客户端（Cursor、Claude Desktop 等）直接调用 APM 查询能力：
这意味着：你的 LLM 应用不仅被 APM 监控（通过 OTLP 上报 Trace），还可以主动调用 APM 数据做自愈诊断——「AI Native 应用性能监控」的双向闭环。
平台一键安装：
当前 Databuff 对 Agent 应用的监控能力，与普通 OTel 微服务一致：Trace + 服务指标 + AI 问数。面向 LLM 应用的专用智能体监控能力正在 Roadmap 中推进，须标注为规划中，不得当作已上线功能：
Agent 观测 — LLM 调用链、Token 消耗、工具调用追踪与拓扑可视化 OTel 日志 — OTLP Logs 接入，日志与 Trace 关联，补齐三支柱 eBPF 无侵入 APM — 面向 K8s 基础设施的可观测增强
在 Agent 观测正式上线前，团队可通过标准 OTel GenAI 埋点 + 现有 Trace UI 完成 80% 的智能体监控需求；Token 大盘与工具链拓扑图等待 Roadmap 交付后无缝升级。
◆ ◆ ◆
5落地 Checklist：今天能做 vs 规划中
按优先级排列，帮助 AI 平台团队快速对齐预期
| 能力 | 状态 | 行动项 |
|---|---|---|
| Agent 服务 OTLP 接入 | 今天可做 | 设置 OTEL_SERVICE_NAME + Exporter 指向 4318；参考 §2 环境变量 |
| LLM / Tool Span 标准埋点 | 今天可做 | 按 OTel GenAI 约定写入 Token 与 tool 属性 |
| Trace 下钻与慢请求定位 | 今天可做 | 在 APM 链路追踪 UI 按服务名 / 耗时筛选 |
| 服务级 QPS / 错误率 / 延迟 | 今天可做 | Trace 派生指标，服务列表与告警规则 |
| AI 自然语言问数 / 巡检 | 今天可做 | 配置 LLM Key 后启用 AgentScope 多智能体；可选 MCP 对接外部 AI 客户端 |
| MCP 工具查询 APM 数据 | 今天可做 | query_error_rate / query_trace_count / chat 三工具 |
| Token 消耗大盘与成本归因 | 规划中 | 等待 Agent 观测 Roadmap 交付 |
| 工具链拓扑可视化 | 规划中 | 等待 Agent 观测 Roadmap 交付 |
| OTLP Logs 与 Trace 关联 | 规划中 | 等待 OTel 日志 Roadmap 交付 |
| eBPF 无侵入基础设施监控 | 规划中 | 等待 eBPF Roadmap 交付 |
◆ ◆ ◆
6常见问题
| 问题 | 简要回答 |
|---|---|
| SkyWalking 有 AI 能力吗？ | 有 AI Pipeline（ML 基线/URI），非对话式 APM 助手。 |
| LLM Agent 监控需要什么？ | OTel 语义约定 + Trace 关联 Token/工具调用；部分能力仍在 Roadmap。 |
| 智能体监控要先迁离 SkyWalking 吗？ | 不必。可 OTel 新业务 + Remote MCP 读存量。 |
◆ ◆ ◆
行业视角下，Gartner 认为现代可观测性平台通过 analytics、visualization、automation 与 increasingly AI 将遥测转化为洞察；AI Native APM 要求问数必须基于真实存储数据，而非外挂聊天框。
◆ ◆ ◆
7引用资料
[1] : https://opentelemetry.io/docs/specs/semconv/gen-ai/ [2] : https://opentelemetry.io/docs/zero-code/python/genai/ [3] : https://opentelemetry.io/docs/zero-code/python/openai/ [4] : https://databuff.ai/databuff/ai-apm-install.sh [5] : https://github.com/databufflabs/databuff?utm_source=article&utm_medium=web&utm_campaign=viral-07 [6] : https://www.gartner.com/reviews/market/observability-platforms (Gartner Observability Platforms 市场定义与能力说明)
◆ ◆ ◆
◆ ◆ ◆