2025 年是 Agentic AI 爆发的一年。从 OpenAI 的 Agents SDK 到 Anthropic 的 MCP (Model Context Protocol)，从 LangGraph 到 CrewAI，构建 AI Agent 的工具链正在快速成熟。更重磅的是 Linux 基金会专门成立了 Agentic AI 子基金会^[1]来推动 Agent 相关开放标准和工具的发展。 该基金会的成立得到了 Anthropic（MCP）、Block（goose）和 OpenAI（AGENTS.md）等公司的创始性贡献。

但随之而来的问题是：当 Agent 出了问题，我们怎么排查？当 Agent 表现不佳，我们怎么优化？

这就是 Agent 可观测性（Agent Observability）要解决的问题。

过去一年，这个领域热度飙升。Datadog 在 2025 年 6 月的 DASH 大会上发布了 AI Agent Monitoring^[2]；OpenTelemetry 正在制定 GenAI Semantic Conventions^[3]；LangSmith、Langfuse 等专用平台快速崛起。一个核心问题浮出水面：传统的可观测性技术栈——Metrics、Logs、Traces 这"三大支柱"——还能用吗？还是我们需要一套全新的方案？

本文的答案是：旧瓶还能用，但确实需要装新酒。而且，当你认真审视这些"新酒"的特征，会发现它们指向一个更深层的变化——Observability 2.0。

一、旧瓶：传统可观测性的基础仍然有效

先说好消息：我们不需要推翻现有的可观测性体系。

三大支柱依然成立。 Agent 应用同样需要：

• Metrics：token 用量、调用延迟、成本统计
• Logs：prompts、responses、tool 输出
• Traces：agent 执行流程、多步推理路径

OpenTelemetry 正在成为 GenAI 的事实标准。 OTel 的 GenAI Semantic Conventions 已进入正式规范（v1.37+），定义了 gen_ai.request.model、gen_ai.usage.input_tokens、gen_ai.provider.name 等标准属性^[4]。Datadog、Langfuse 等平台已原生支持这套规范。

Traces 本质上是结构化 logging 的特殊形式。（Traces is essentially a special form of structured logging.） —— ^[5]

Agent 可观测性不是要推翻旧体系，而是要扩展它。

但问题在于：扩展到什么程度？需要哪些新能力？这正是 Agent 场景带来的挑战。本文将尝试分析和解答。

二、新酒（上）：数据形态与观测目标的本质变化

2.1 半结构化数据的爆炸

传统可观测性处理的数据类型相对清晰：

• 结构化 Metrics：数值型时序数据，schema 固定
• 非结构化 Logs：文本流，自由格式
• 结构化 Traces：span 树，层级明确

但 Agent 带来了大量半结构化数据：

数据类型	特征
Prompts	文本 + 模板变量 + 系统指令 + 上下文注入
Tool Calls	函数名 + 动态参数（可能嵌套）+ 返回值（结构各异）
Memory State	key-value + 复杂嵌套 + 随对话演进
Multi-turn Context	对话历史 + 角色标识 + 元数据

一个典型的 Agent 执行事件可能包含几十甚至上百个字段，而且每次 tool call 的返回结构都可能不同。

这不是简单的"数据量变大"，而是数据形态的根本变化。

传统方案怎么处理？要么把这些数据塞进 Logs（丢失结构，难以查询），要么塞进 Traces（schema 过于僵化，无法表达动态结构）。两种方式都不理想。

Datadog 在其 Agent 监控方案中强调了这一点^[6]：

Agents often maintain internal memory—such as CrewAI's short-term and long-term memory or LangGraph's state—which influences their decisions but may not be exposed in standard logs or spans.

（Agent 通常维护内部记忆——如 CrewAI 的短期和长期记忆，或 LangGraph 的状态——这些影响决策但可能不会暴露在标准的 logs 或 spans 中。）

2.2 数据规模：一个典型 Agent 应用会产生多少可观测数据？

让我们用数字说话。假设一个中型 Agent 应用：

场景设定：

• 日活用户（DAU）：10 万
• 每用户每天平均交互：5 次
• 每次交互平均 LLM 调用：3 次（包括 planning、tool calling、response generation）

数据量估算：

指标	计算	数值
日 LLM 调用数	100K × 5 × 3	150 万次/天
每次调用 token 数	输入 2K + 输出 1K（典型 RAG 场景）	~3K tokens
日 token 总量	150万 × 3K	45 亿 tokens/天
单个 Wide Event 大小	50-200 字段，含 prompt/response	2-8 KB
日可观测数据量	150万 × 5KB（取中位数）	~7.5 GB/天
月可观测数据量	7.5GB × 30	~225 GB/月

如果是大型应用（百万 DAU），数据量会达到 2+ TB/天。

业界真实案例：

• Langfuse（LLM 可观测平台）：生产环境处理每分钟数万事件，后端存储达到数十亿行级别^[7]。小规模部署定义为每月 < 100 万 traces。
• Laminar（Browser Agent 可观测平台）：每天处理数十万 browser session events，曾因 SDK bug 在单日产生超过 10 亿次写入^[8]。
• ClickHouse LogHouse（内部可观测平台）：存储 100+ PB 未压缩数据，近 500 万亿行^[9]。

关键洞察：Agent 可观测数据的特点不仅是"量大"，更是"维度高"。Honeycomb 的经验表明，成熟的可观测数据集通常有 200-500 个维度^[10]。这意味着传统的 metrics 聚合方式（预定义维度）根本无法覆盖 Agent 场景的分析需求。

2.3 从"系统行为"到"语义质量"

第三个不同是观测的目标也在发生变化。

传统监控回答的问题：

• 服务是否可用？✅ / ❌
• 延迟是多少？P50 = 120ms, P99 = 450ms
• 错误率是多少？0.3%

这些是系统行为层面的指标。

但 Agent 监控需要回答一些完全不同的问题：

• 回答是否准确？（Factual Correctness）
• 回答是否相关？（Topic Relevancy）
• 推理是否合理？（Reasoning Quality）
• Tool 选择是否正确？（Decision Quality）
• 是否存在幻觉？（Hallucination Detection）

Datadog 的 LLM Observability 产品内置了一系列质量检查^[11]：Failure to Answer（是否未能回答）、Topic Relevancy（主题相关性）、Toxicity（毒性）、Negative Sentiment（负面情绪）。这些都不是传统 APM 会关心的指标。

我们正在从观测"系统行为"转向观测"语义质量"。

这意味着我们不能只记录"调用了什么"，还要理解"为什么这样调用"以及"结果质量如何"。这需要深入到调用内部，保留完整的上下文。

2.4 反馈闭环：可观测性驱动 Agent 演进

传统可观测性是被动的——系统出了问题，告警响了，工程师开始排查。

Agent 可观测性需要主动的反馈闭环：

Prompt 设计 → 部署 → 观测效果 → 分析模式 → 优化 Prompt → 再部署 → ...

这个闭环的周期决定了 Agent 演进的速度。

正如 Honeycomb CEO Charity Majors 所说^[12]：

Observability 2.0 is very much about how you develop your code... when you have an observability 2.0 mindset and toolkit, you can see where that time is going.

（Observability 2.0 关乎你如何开发代码……当你拥有 2.0 的思维和工具时，你能看到时间花在哪里。）

对 Agent 开发来说，这一点尤为关键。Agent 的行为是非确定性的——相同的输入可能产生不同的输出。反馈周期从"天"缩短到"分钟"，迭代速度将大幅提升。

可观测性不再只是运维工具，而是 Agent 智能化演进的核心基础设施。

三、新酒（下）：Multi-Agent 时代的可观测性挑战

单个 Agent 的可观测性已经够复杂了。当多个 Agent 协作时，问题会指数级放大。

3.1 Observability Trilemma

Galileo 在其博客中提出了"可观测性三难困境"（Observability Trilemma）^[13]：

• Completeness：捕获所有 agent 的所有行为
• Timeliness：数据实时可见，支持快速反馈
• Low Overhead：不显著影响 agent 性能

This presents what we call the "observability trilemma" – you can have completeness (capturing all data), timeliness (seeing it when needed), or low overhead (not disrupting your system) – but rarely all three simultaneously.

（这就是我们所说的"可观测性三难困境"——你可以有完整性、实时性或低开销，但很难同时拥有三者。）

这个三难困境并非绝对，但它准确描述了团队在实践中面临的权衡。在单 Agent 场景下，可以通过取舍来应对。但在 Multi-Agent 协同场景下：

• 每个 Agent 都有自己的 memory state 需要追踪
• Agent 之间的通信、handoff、任务委托需要关联
• 涌现行为（Emergent Behaviors）难以用预定义指标检测

问题呈指数级放大。

3.2 状态的黑洞

Agent 的决策依赖于内部状态：

• Short-term Memory：当前对话的上下文
• Long-term Memory：持久化的知识和偏好
• Framework State：LangGraph 的 state、CrewAI 的 memory

问题是：这些状态往往不透明。

传统的 Trace 视图是这样的，呈黑盒状：

Input → [Black Box] → Output

但理解 Agent 行为，我们需要看到：

Input
  → Planning（推理过程）
  → State Query（查询记忆）
  → Tool Selection（为什么选这个工具？）
  → Tool Execution（执行结果）
  → State Update（状态变更）
  → Response Generation
  → Output

我们需要深入到每一步，每一步的状态都应该可观测，因为都会影响到最终 Agent 的效果。

Datadog 在他们的产品博客里强调了这一点^[6:1]：

This includes visibility into agent memory states such as CrewAI's short-term and long-term memory or LangGraph's state, which can be crucial for understanding decision-making processes.

（这包括对 agent 记忆状态的可见性，如 CrewAI 的短期和长期记忆或 LangGraph 的状态，这对理解决策过程至关重要。）

Agent 的"记忆"和"状态"必须成为一等公民。 不观测状态，就无法理解决策；不理解决策，就无法优化 Agent。这是跟传统 APM 一个非常显著的不同。

3.3 分布式追踪的断裂

以 MCP（Model Context Protocol）为例，一个典型的调用链路：

User → Agent (Client) → LLM Provider → MCP Server → External Tool
         |                                |
         Trace A                          Trace B (断裂!)

Glama 的技术博客详细讨论了这个问题^[14]：

The primary architectural challenge lies in unifying these two paths into a single distributed trace... To achieve true end-to-end tracing, the client must propagate the Trace ID into the request sent to the MCP server.

（主要的架构挑战在于将这两条路径统一到单个分布式追踪中……要实现真正的端到端追踪，客户端必须将 Trace ID 传播到发送给 MCP Server 的请求中。）

当前的挑战：

• Client 端 trace 和 Server 端 trace 如何关联？
• 需要 W3C Trace Context 标准在所有组件间传播
• 缺乏社区共识的 semantic conventions（如 mcp.tool_name、agent.session_id）

OpenTelemetry 正在制定 Agent Framework Semantic Conventions^[15]，定义了 Tasks、Actions、Agents、Teams、Artifacts、Memory 等概念。但距离成熟和广泛采用还有距离。

Multi-Agent 可观测性的核心难题是跨边界的 context 传播。 这不仅是技术问题，更是标准化问题。当然，这个问题在微服务架构时代也没有解决的很好。

四、进一步洞察：这本质上就是 Wide Events

让我们回顾前面发现的挑战：

1. 半结构化、高维度、上下文丰富的数据
2. 需要事后分析语义质量，不能只靠预聚合 metrics
3. 需要保留原始数据支撑快速反馈闭环
4. 需要统一存储消除 data silo（数据孤岛），关联 metrics/logs/traces

这些特征是不是很眼熟？

这正是 Charity Majors 提出的 Observability 2.0 / Wide Events 要解决的问题！

4.1 什么是 Wide Events

Wide Events 是 Honeycomb 提出的数据模型，核心思想是：用单一、宽格式的结构化事件取代分散的 metrics/logs/traces，作为可观测性的单一事实来源。

Charity Majors 在 2024 年底正式提出了 Observability 2.0 的概念^[16]：

Let's call the metrics, logs and traces crowd — the "three pillars" generation of tooling — that's "Observability 1.0". Tools like Honeycomb, which are built based on arbitrarily-wide structured log events, a single source of truth — that's "Observability 2.0".

（我们把 metrics、logs、traces 这些"三大支柱"的工具叫做 Observability 1.0。像 Honeycomb 这样基于任意宽度的结构化日志事件、单一事实来源构建的工具，这是 Observability 2.0。）

Wide Events 的核心特征：

• 高基数（High Cardinality）：可以包含 user_id、trace_id 这样的唯一标识
• 高维度（High Dimensional）：单个事件可能有几十上百个字段
• 上下文丰富（Context-rich）：保留完整的请求上下文
• 单一事实来源（Single Source of Truth）：从原始事件派生 metrics/logs/traces，而不是分开存储

如果你没有了解过，可以来阅读这篇文章《Wide Events 101：何为宽事件，为何需要以及如何落地》。

4.2 Agent 数据天然就是 Wide Events

看一个典型的 Agent 执行事件：

{
  "timestamp": "2025-01-15T10:30:45.123Z",
  "trace_id": "abc123",
  "session_id": "user-session-456",
  "agent_name": "research-assistant",

  "model": "claude-sonnet-4-20250514",
  "input_tokens": 1523,
  "output_tokens": 892,
  "latency_ms": 2340,

  "prompt": "Based on the user's question about...",
  "response": "Here are my findings...",

  "tool_calls": [
    {"name": "web_search", "params": {"query": "..."}, "duration_ms": 450}
  ],

  "reasoning": "User asked about X, decided to search because...",
  "memory_state": {"short_term": [...], "long_term_refs": [...]},

  "quality_score": 0.85,
  "topic_relevancy": 0.92
}

这就是一个典型的 Wide Event：高基数（trace_id、session_id）、高维度（几十个字段）、上下文丰富（保留了 prompt、response、reasoning）。

4.3 为什么 O11y 1.0 方式处理 Agent 数据会很痛苦

如果用传统"三大支柱"的方式：

做法	问题
把 prompt/response 塞进 Logs	丢失结构，难以分析
把 tool calls 塞进 Traces	Schema 僵化，无法表达动态结构
预聚合 token usage 成 Metrics	丢失上下文，无法回溯分析"哪个 prompt 导致了高延迟"
分开存储再关联	Data silo，跨系统查询困难

我们见过团队用传统方案排查一个幻觉问题，需要跨 3 个系统拉数据、手工关联 trace_id，耗时数小时才能定位到问题 prompt。如果用 Wide Events，同样的分析只需要一条查询。

Charity Majors 一针见血地指出^[17]：

The cost of the time engineers spend laboring below the value line—trying to understand their code, their telemetry, their user behaviors—is astronomical. Poor observability is the dark matter of engineering teams.

（工程师在"价值线"以下挣扎的时间成本——试图理解代码、遥测数据、用户行为——是天文数字。糟糕的可观测性是工程团队的暗物质。）

4.4 Agent 场景让 Wide Events 从"更好"变成"必须"

Agent 可观测性需求	Wide Events 如何满足
半结构化数据存储	原生支持高维度、动态 schema
语义质量分析	事后从原始数据派生任意指标
快速反馈闭环	不修改 instrumentation 即可定义新分析维度
状态追踪	单一事实来源，保留完整上下文
统一关联	三大支柱成为同一数据的视图

在传统应用中，Wide Events 是"更好的选择"；在 Agent 场景中，它几乎是"必须"。

Agent 可观测性不是一个全新的领域，而是 Observability 2.0 的最佳实践场景。

五、技术选型：Wide Events 需要什么样的数据库

理解了 Wide Events 的理念，下一个问题是：怎么落地？

5.1 核心能力需求

1. 统一存储 — 一个系统处理 metrics、logs、traces 和半结构化数据，消除 data silo（数据孤岛）
2. 云原生架构 — 对象存储 + 计算存储分离，成本可控且弹性扩展
3. 实时处理 — 低延迟摄入和查询，支持 dashboard 和 alerting
4. 派生能力 — 从原始事件实时派生 metrics 和聚合，不需要预处理
5. 灵活查询 — 支持 routine queries（dashboard）和 exploratory queries（ad-hoc 分析）
6. 开放标准 — 兼容 OTel 协议，避免供应商锁定

关键是把复杂度从 Agent 端转移到存储层——Agent 只负责发送原始事件，存储层负责处理、聚合、索引。

5.2 应对 Observability Trilemma

挑战	解决思路
Completeness	统一存储消除 data silo；原生支持半结构化数据
Timeliness	流式处理引擎实时派生指标；计算存储分离支持弹性查询
Low Overhead	原始数据写入开销低；聚合在存储层异步完成

5.3 行业趋势：数据库厂商的布局

Wide Events 和 Agent Observability 的交叉点正在成为数据库厂商的新战场。

ClickHouse 在 2025 年推出了 ClickStack^[18]，明确采用 Wide Events 作为核心数据模型，并收购 HyperDX 补全 UI 层。其 LLM Observability 方案^[19]支持 OpenAI Agents、LangChain 等框架的追踪，Laminar 等公司已在用它构建 AI Browser Agent 可观测性平台^[8:1]。

GreptimeDB 作为统一可观测性数据库，提出"三大支柱成为视图"的理念^[20]——Metrics、Logs、Traces 不是独立的存储系统，而是对同一底层数据的不同查询视图。其内置的 Pipeline（预处理引擎）支持在数据写入时进行结构化解析和字段提取；Flow Engine（流计算引擎）支持从原始事件实时派生聚合指标，无需预处理管道。这种架构天然适合 Agent 场景：写入高维度原始事件，按需派生 metrics 和 traces。

这种趋势说明什么？Wide Events 不再只是理论概念，而是正在成为下一代可观测性存储的实际架构选择。 无论是 OLAP 数据库（如 ClickHouse）还是统一可观测性数据库（如 GreptimeDB），都在向统一存储、原始数据优先的方向演进。

对于 Agent 可观测性来说，这是好消息——底层基础设施正在成熟。

六、总结

旧瓶依然有用。 Metrics、Logs、Traces 的框架，OpenTelemetry 的标准，这些可观测性的基础设施仍然适用于 Agent 场景。

但确实需要新酒。 Agent 带来了数据形态的根本变化（半结构化、高维度）、观测目标的转变（从系统行为到语义质量）、以及新的使用模式（快速反馈闭环驱动演进）。

更深层的洞察是：这些"新酒"本质上就是 Wide Events。 Agent 可观测性不是一个全新的领域，而是让 Observability 2.0 的价值更加凸显的场景。在传统应用中，Wide Events 是"更好的选择"；在 Agent 场景中，它几乎是"必须"。甚至我们可以下个结论：Agent 是 Observability 2.0 的第一个杀手级应用场景。

技术选型的关键：统一存储、原始数据优先、弹性扩展、实时处理。

想持续关注 Agent 可观测性？建议如下行动：：

• 关注 OpenTelemetry GenAI SIG 的进展
• 尝试 Langfuse、ClickStack 或 GreptimeDB 的 Agent 追踪能力
• 参与 Agent Framework Semantic Conventions 的讨论
• 关注我们的博客，我们将陆续推出一系列文章解析 Agent 可观测性的落地和实践。

标准化正在进行中，现在是参与和塑造这个领域的好时机。

---

参考链接

---

1. Linux Foundation Announces the Formation of the Agentic AI Foundation ↩︎

2. Datadog Expands LLM Observability with New Capabilities to Monitor Agentic AI ↩︎

3. Semantic Conventions for Generative AI Systems | OpenTelemetry ↩︎

4. OpenTelemetry for Generative AI | OpenTelemetry Blog ↩︎

5. Building Unified Observability Storage with Rust | Greptime ↩︎

6. Monitor, troubleshoot, and improve AI agents with Datadog ↩︎ ↩︎

7. Langfuse and ClickHouse: A new data stack for modern LLM applications ↩︎

8. How Laminar is using ClickHouse to reimagine observability for AI browser agents ↩︎ ↩︎

9. Scaling our Observability platform beyond 100 Petabytes by embracing wide events | ClickHouse ↩︎

10. Live Your Best Life With Structured Events | Charity Majors ↩︎

11. Monitor, troubleshoot, improve, and secure your LLM applications with Datadog LLM Observability ↩︎

12. Observability: the present and future, with Charity Majors | The Pragmatic Engineer ↩︎

13. 9 Key Challenges in Monitoring Multi-Agent Systems at Scale | Galileo ↩︎

14. OpenTelemetry for Model Context Protocol (MCP) Analytics and Agent Observability | Glama ↩︎

15. Semantic Conventions for Generative AI Agentic Systems | OpenTelemetry GitHub ↩︎

16. It's Time to Version Observability: Introducing Observability 2.0 | Honeycomb ↩︎

17. There Is Only One Key Difference Between Observability 1.0 and 2.0 | Honeycomb ↩︎

18. ClickStack: High-Performance Open-Source Observability | ClickHouse ↩︎

19. Understanding LLM Observability | ClickHouse ↩︎

20. Observability Data Lake is more than Data Lake itself | Greptime ↩︎