2025 年是 Agentic AI 爆发的一年。从 OpenAI 的 Agents SDK 到 Anthropic 的 MCP (Model Context Protocol)，从 LangGraph 到 CrewAI，构建 AI Agent 的工具链正在快速成熟。更重磅的是 Linux 基金会专门成立了 Agentic AI 子基金来推动 Agent 相关开放标准和工具的发展。
但随之而来的问题是：当 Agent 出了问题，我们怎么排查？当 Agent 表现不佳，我们怎么优化？
这就是 Agent 可观测性（Agent Observability）要解决的问题。
过去一年，这个领域热度飙升。Datadog 在 2025 年 6 月的 DASH 大会上发布了 AI Agent Monitoring[^1]；OpenTelemetry 正在制定 GenAI Semantic Conventions[^2]；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等标准属性[^3]。Datadog、Langfuse 等平台已原生支持这套规范。
❝
Traces 本质上是结构化 logging 的特殊形式。—— 引用 [^4]
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 监控方案中强调了这一点[^5]：
❝
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 可观测平台）：生产环境处理每分钟数万事件，后端存储达到数十亿行级别[^17]。小规模部署定义为每月 < 100 万 traces。
- Laminar（Browser Agent 可观测平台）：每天处理数十万 browser session events，曾因 SDK bug 在单日产生超过 10 亿次写入[^15]。
- ClickHouse LogHouse（内部可观测平台）：存储100+ PB 未压缩数据，近 500 万亿行[^18]。
关键洞察：Agent 可观测数据的特点不仅是"量大"，更是"维度高"。Honeycomb 的经验表明，成熟的可观测数据集通常有200-500 个维度[^19]。这意味着传统的 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 产品内置了一系列质量检查[^6]：Failure to Answer（是否未能回答）、Topic Relevancy（主题相关性）、Toxicity（毒性）、Negative Sentiment（负面情绪）。这些都不是传统 APM 会关心的指标。
我们正在从观测"系统行为"转向观测"语义质量"。
这意味着我们不能只记录"调用了什么"，还要理解"为什么这样调用"以及"结果质量如何"。这需要深入到调用内部，保留完整的上下文。
2.4 反馈闭环：可观测性驱动 Agent 演进
传统可观测性是被动的——系统出了问题，告警响了，工程师开始排查。
Agent 可观测性需要主动的反馈闭环：
Prompt 设计 → 部署 → 观测效果 → 分析模式 → 优化 Prompt → 再部署 → ...这个闭环的周期决定了 Agent 演进的速度。
正如 Honeycomb CEO Charity Majors 所说[^7]：
❝
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）[^8]：
Completeness（完整性） /\ / \ / \ / \ /________\ Timeliness Low Overhead （实时性） （低开销）- 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 在他们的产品介绍中强调了这一点[^5]：
❝
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 的技术博客详细讨论了这个问题[^9]：
❝
主要的架构挑战在于将这两条路径统一到单个分布式追踪中……要实现真正的端到端追踪，客户端必须将 Trace ID 传播到发送给 MCP Server 的请求中。
当前的挑战：
- Client 端 trace 和 Server 端 trace 如何关联？
- 需要 W3C Trace Context 标准在所有组件间传播
- 缺乏社区共识的 semantic conventions（如
mcp.tool_name、agent.session_id）
OpenTelemetry 正在制定 Agent Framework Semantic Conventions[^10]，定义了 Tasks、Actions、Agents、Teams、Artifacts、Memory 等概念。但距离成熟和广泛采用还有距离。
Multi-Agent 可观测性的核心难题是跨边界的 context 传播。这不仅是技术问题，更是标准化问题。当然，这个问题在微服务架构时代也没有解决的很好。
四、进一步洞察：这本质上就是 Wide Events
让我们回顾前面发现的挑战：
- 半结构化、高维度、上下文丰富的数据
- 需要事后分析语义质量，不能只靠预聚合 metrics
- 需要保留原始数据支撑快速反馈闭环
- 需要统一存储消除 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 的概念[^11]：
❝
我们把 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 一针见血地指出[^12]：
❝
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 核心能力需求
- 统一存储— 一个系统处理 metrics、logs、traces 和半结构化数据，消除 data silo（数据孤岛）
- 云原生架构— 对象存储 + 计算存储分离，成本可控且弹性扩展
- 实时处理— 低延迟摄入和查询，支持 dashboard 和 alerting
- 派生能力— 从原始事件实时派生 metrics 和聚合，不需要预处理
- 灵活查询— 支持 routine queries（dashboard）和 exploratory queries（ad-hoc 分析）
- 开放标准— 兼容 OTel 协议，避免供应商锁定
关键是把复杂度从 Agent 端转移到存储层——Agent 只负责发送原始事件，存储层负责处理、聚合、索引。
5.2 应对 Observability Trilemma
| 挑战 | 解决思路 |
|---|---|
| Completeness | 统一存储消除 data silo；原生支持半结构化数据 |
| Timeliness | 流式处理引擎实时派生指标；计算存储分离支持弹性查询 |
| Low Overhead | 原始数据写入开销低；聚合在存储层异步完成 |
5.3 行业趋势：数据库厂商的布局
Wide Events 和 Agent Observability 的交叉点正在成为数据库厂商的新战场。
ClickHouse在 2025 年推出了 ClickStack[^13]，明确采用 Wide Events 作为核心数据模型，并收购 HyperDX 补全 UI 层。其 LLM Observability 方案[^14]支持 OpenAI Agents、LangChain 等框架的追踪，Laminar 等公司已在用它构建 AI Browser Agent 可观测性平台[^15]。
GreptimeDB作为统一可观测性数据库，提出"三大支柱成为视图"的理念[^16]——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 是 Observability 2.0 的第一个杀手级应用场景。
技术选型的关键：统一存储、原始数据优先、弹性扩展、实时处理。
想持续关注 Agent 可观测性？建议如下行动：
- 关注 OpenTelemetry GenAI SIG 的进展
- 尝试 Langfuse、ClickStack 或 GreptimeDB 的 Agent 追踪能力
- 参与 Agent Framework Semantic Conventions 的讨论
- 关注我们公众号，我们将陆续推出一系列文章解析 Agent 可观测性
标准化正在进行中，现在是参与和塑造这个领域的好时机。
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
第一阶段（10天）：初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示（Embeddings）
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段（30天）：模型训练
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段（20天）：商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。
如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。
