TL;DR

本文核心观点：

  1. 日志的局限 — 记录发生了什么，但不理解为什么发生；传统可观测性在 AI-Native 时代遭遇根本挑战
  2. 意图追踪 — 记录 AI 的决策意图、推理过程和上下文，为可观测性增加第三个维度
  3. 三层可观测性 — 系统层、Agent 层、意图层的立体监控，覆盖从基础设施到 AI 决策的全链路
  4. 可解释性 — 不仅能发现问题，还能解释 AI 为什么做出某个决策，建立对 AI 系统的信任

关键洞察：最好的可观测性不是收集更多数据，而是收集更有意义的意图数据。

传统可观测性的盲区

可观测性三支柱

传统的可观测性建立在三个支柱之上：

  1. Metrics（指标） — CPU、内存、请求量、延迟
  2. Logs（日志） — 应用输出的事件记录
  3. Traces（追踪） — 请求在分布式系统中的流转

这套体系在微服务时代非常有效，但在 AI-Native 时代遇到了根本性的挑战。

场景：一个神秘的 Bug

凌晨 3 点，生产环境告警：推荐系统的点击率下降了 40%。

💡 Key Insight

传统可观测性告诉我们系统”做了什么”，但不告诉我们”为什么这么做”——这正是 AI-Native 时代的根本挑战。

你打开监控面板：

  • ✅ CPU 正常
  • ✅ 内存正常
  • ✅ 请求量正常
  • ✅ 响应延迟正常

所有指标都正常，但业务明显异常。

你查看日志： 日志显示一切正常，但用户收到的推荐明显不合理——全是 6 个月前的冷内容。

你查看追踪：请求从 API 网关到推荐服务到模型服务，链路完整，没有错误。

问题出在哪里？

传统可观测性的盲区

盲区 描述 例子
黑盒推理 不知道 AI 为什么做出某个决策 为什么推荐 A 而不是 B？
意图缺失 不知道用户的真实意图 用户搜索”apple”是想买水果还是电脑？
上下文漂移 不知道决策时的上下文状态 模型用的是哪个版本的 prompt？
推理过程 看不到 AI 的思考过程 Agent 为什么选择了这个工具？

💡 Key Insight

传统可观测性只能告诉你”系统做了什么”，但无法回答”AI 为什么做出这个决策”——这是 AI-Native 时代可观测性面临的核心挑战。

为什么 AI-Native 系统需要新范式

AI 系统的特殊性

AI-Native 系统与传统系统有本质区别：

💡 Key Insight

AI-Native 系统的核心差异在于：传统系统是确定性的（输入 A 总能得出 B），而 AI 系统是概率性的（同样的输入可能产生不同输出）——这让传统的”错误检测”范式完全失效。

1. 概率性而非确定性

传统系统：输入 A → 输出 B（总是如此）

AI 系统：输入 A → 输出 B（90% 概率），输出 C（10% 概率）

同样的输入可能产生不同的输出，这让传统的”错误检测”变得困难。

2. 上下文依赖性

AI 的输出高度依赖上下文：

  • 使用的 Prompt 版本
  • 提供的 Context 内容
  • 模型的温度和参数

传统日志不记录这些，导致无法复现问题。

3. 推理不透明性

对于复杂的 AI Agent：

  • 它为什么选择这个工具？
  • 它如何分解任务？
  • 它从哪些来源获取信息？

这些都是黑盒，传统可观测性无法洞察。

传统监控的失败案例

**案例 1：客服机器人”

客服机器人突然开始给出荒谬的回答。监控显示：

  • API 响应时间正常
  • 没有异常错误
  • 模型服务健康

但用户投诉激增。

原因：上游知识库更新了一个错误的 FAQ，AI 基于错误知识给出了错误回答。传统监控完全无法发现。

案例 2：代码生成工具

开发工具开始生成有安全漏洞的代码。监控显示：

  • 生成成功率 99%
  • 平均生成时间 2.3 秒
  • 用户满意度 4.5/5

但安全审计发现大量 SQL 注入风险。

原因：模型微调数据的分布发生了变化，但监控没有跟踪生成代码的质量指标。

意图追踪：可观测性的第三维度

三层可观测性模型

AI-Native 系统需要三层可观测性：

  • 系统层 — 传统指标、日志、追踪，监控 CPU、内存、网络、API 延迟等基础设施层面的表现，这一层与微服务时代的监控完全兼容
  • Agent 层 — 监控 Agent 的行为模式：选择了哪个工具、分解了哪些子任务、在每个节点上花费了多少时间，这一层需要追踪 Agent 的决策路径
  • 意图层 — 记录每一次 AI 决策背后的意图：输入的原始目标、推理过程中的中间状态、最终决策的依据——这是传统可观测性完全缺失的维度

三层之间相互关联：系统层指标异常会影响 Agent 层的表现，Agent 层的异常行为往往根源于意图层的记录缺失。当推荐系统点击率下降 40% 时，系统层指标可能完全正常，问题出在 Agent 层（选择了错误的推荐策略）和意图层（不知道为什么会这样选）。

这套三层模型的核心洞察是：问题在高层被发现，却需要在更高层才能理解。意图层是唯一能解释”为什么”的一层，也是 AI-Native 可观测性区别于传统监控的本质所在。

什么是意图追踪

意图追踪（Intent Tracing）是一种记录 AI 决策过程的新型可观测性方法。它不仅仅记录”发生了什么”，更关注”AI 为什么做出这个决策”。意图追踪记录的是：

  1. 输入意图 — 用户或系统想要达成什么目标
  2. 推理过程 — AI 如何分解和解决这个意图
  3. 决策依据 — AI 为什么做出某个选择
  4. 上下文状态 — 决策时的完整上下文

意图追踪数据模型

意图追踪的核心数据模型包含以下要素：

1. intent_id — 唯一标识一次完整的意图追踪会话，类似传统追踪中的 trace_id，但关联的是一次 AI 决策过程而非一次 HTTP 请求

2. input_intent — 原始输入目标，以结构化形式记录：用户或系统想要达成什么，是推荐一个商品、生成一段代码、还是回答一个问题

3. reasoning_steps — AI 的推理步骤序列，每个步骤包含：当前步骤的思考内容（thought）、选择执行的行动（action）、行动产生的观察结果（observation），这三者构成一个完整的 ReAct 循环

4. decision_basis — AI 为什么做出某个选择，包含：引用的上下文片段、触发的规则或启发式条件、模型置信度（如果模型输出包含）

5. context_state — 决策时的完整上下文快照，包括：使用的 prompt 版本、加载的 context 内容、模型的温度和参数设置、当前时间窗口——这些是传统日志完全不记录但对问题排查至关重要的信息

6. model_version — 使用的模型版本和配置，同一个输入在不同模型版本下可能产生完全不同的输出，版本追踪是复现问题的前提

7. output_result — 最终输出结果以及与原始意图的匹配度评估

Intent Tracer SDK 将这些字段封装为统一的数据结构，在每一次 AI 决策完成后自动写入存储层。对于一个客服机器人的回复，完整 intent trace 可能包含：用户输入”我的订单什么时候发货” → reasoning_steps 包含识别用户意图、查询订单系统、构造回复等步骤 → context_state 记录了当前客服 Agent 的系统 prompt 版本和用户历史上下文。

意图追踪 vs 传统追踪

维度 传统 Trace 意图 Trace
关注点 请求流转 决策过程
记录内容 服务调用 推理步骤
时间粒度 毫秒级 步骤级
可解释性 低 高
调试价值 定位性能问题 理解行为原因

实战：设计意图感知的可观测系统

第一步：在 AI 组件中埋点

在 AI Agent 的关键决策点植入追踪代码，记录输入、推理过程和输出。这需要理解 AI 组件的执行流程，找到所有”可能产生非预期结果的节点”并重点埋点。

埋点的四个核心位置：

LLM 调用拦截 — 在每一次模型调用前后插入钩子，捕获：输入的完整 prompt（包含系统 prompt、few-shot examples 和用户输入）、模型返回的完整输出、调用时的参数配置（温度、top-p、模型版本）。对于使用 LangChain 或类似框架的系统，可以在 LLMChain 或 Agent 层统一埋点，避免在每个 prompt 路径上手动插入。

工具选择记录 — 当 Agent 决定调用某个工具时，记录：当前推理状态（Agent 认为需要做什么）、候选工具列表及选择理由、最终选择的工具及传入的参数。这是理解 Agent 决策的关键——一个推荐系统异常的问题，可能根源于 Agent 在某次上下文下错误地选择了”冷门内容”而非”热门内容”工具。

上下文加载追踪 — AI 的输出高度依赖加载的上下文，需要记录：哪些文档或知识库被加载到 context 中、以什么顺序加载、加载后的 context 长度（token 消耗）。当模型微调后表现异常时，上下文加载情况往往是首要排查项。

推理步骤序列化 — 对于使用 ReAct 或类似模式的 Agent，需要将每一步的 thought-action-observation 序列完整记录。一个完整的 reasoning chain 可能包含 5-15 个步骤，每个步骤都需要记录时间和中间结果。这部分数据量较大，建议采用采样策略：只记录涉及关键决策的步骤，对简单检索路径做简化记录。

Intent Tracer SDK 提供了这些埋点的标准实现，将复杂的拦截逻辑封装为简单的 API 调用。对于自研系统，建议至少在 LLM 调用层和工具选择层完成埋点，这两个位置覆盖了 80% 以上的调试需求。

第二步：建立意图追踪存储

选择适合意图数据的存储方案，支持快速查询和聚合分析。意图追踪数据与传统日志有本质区别：它包含嵌套的推理步骤序列、半结构化的 context_state 字段、以及需要支持按 intent_id 或 reasoning_steps 内容进行全文检索——关系型数据库的固定表结构无法优雅地处理这种灵活的数据结构。

热数据层（最近 7 天） — 使用 Elasticsearch 或 OpenSearch 存储原始 intent trace。Elasticsearch 的嵌套文档类型非常适合存储 reasoning_steps 数组，每个步骤的 thought、action、observation 都可以独立索引。热数据层需要支持毫秒级查询，因为调试时需要快速定位到特定用户会话的完整推理链。建议配置 3 副本以上保证高可用，单个节点的 SSD 存储，避免机械硬盘在写入高峰时成为瓶颈。

温数据层（7-30 天） — 将热数据进行聚合和压缩后存入 Warm storage。聚合的内容包括：每个会话的意图统计（成功/失败/部分成功）、推理链长度分布、上下文加载效率指标。这一层不需要原始推理步骤的完整细节，重点是支持按时间窗口和意图类型进行趋势分析。可以使用 Elasticsearch 的 ILM（Index Lifecycle Management）自动完成热到温的数据迁移。

冷数据层（30 天以上） — 归档到对象存储（如 S3 或兼容方案），以 Parquet 格式保存。Parquet 的列式存储允许高效扫描特定列（如 intent_id、model_version、decision_outcome），适合做长期的模型表现分析和合规审计。冷数据查询频率低但数据量持续增长，按时间分区存储在降低成本的同时保持可追溯性。

Schema 设计要点 — intent trace 的 Elasticsearch mapping 需要将 reasoning_steps 配置为 nested 类型以支持精确查询；context_state 中的 prompt_version 和 model_config 字段建议设置为 keyword 类型而非 text 类型，因为它们是精确值不需要分词搜索；output_result 中的意图匹配度评分设置为 float 类型以支持范围聚合。合理的 mapping 设计可以让查询性能提升 10 倍以上。

第三步：构建意图分析仪表板

可视化意图数据，支持按 Agent、任务类型、时间范围等维度分析。意图分析仪表板的核心挑战是：如何在一个视图里同时呈现三层可观测性的数据——系统层的延迟和吞吐量、Agent 层的工具选择分布、以及意图层的推理链质量评分。

仪表板的四个核心视图：

意图成功率热力图 — 横轴是时间，纵轴是意图类型（推荐、问答、代码生成等），颜色深浅代表成功率。这是最直接反映业务健康的指标：当某个意图类型的成功率突然下降，意味着对应的 AI 功能出现了问题。结合 Agent 层的工具选择数据，可以进一步定位是意图识别环节出错还是执行环节出错。

推理链长度分布 — 直方图展示每次 AI 决策包含的推理步骤数量。推理链过长往往意味着 Agent 在某个节点陷入了循环或反复尝试；推理链过短则可能表示 Agent 过于仓促地做出了决策。正常的 ReAct 模式推理链长度通常在 3-8 步之间，超出这个范围需要引起警觉。

上下文加载效率 — 散点图展示每次意图追踪的 context token 消耗与输出质量的关系。理想情况下，上下文加载越多应该带来越高的意图匹配度；但如果发现上下文消耗持续增加而匹配度反而下降，往往意味着 prompt 设计存在问题或者 context 中引入了无关的噪声。

告警阈值设置 — 基于历史数据设定动态阈值：意图成功率低于 85% 触发 PagerDuty、推理链长度超过 15 步触发 Slack 通知、上下文漂移检测到模型版本与预期不符时触发安全审计流程。阈值需要根据业务场景调优，初期可以参考行业基准，后期根据实际运行数据校准。

第四步：建立意图告警机制

当意图追踪数据出现异常模式时，自动触发告警，实现主动式可观测性。传统告警基于固定阈值（如 CPU > 80%、延迟 > 500ms），但意图层面的异常往往是相对指标——某个意图类型的成功率从 95% 下降到 88%，绝对值仍然”正常”但趋势已经暴露了问题。

意图告警的四个核心条件：

意图成功率下降 — 当特定意图类型的成功率相比过去 7 天平均值下降超过 15% 时触发。这是最直接的信号：说明 AI 对某类任务的处理能力出现了退化，可能是模型版本变化、prompt 漂移或上游数据问题导致的。相比传统的”成功率 < 90%”静态阈值，基于趋势的动态告警能更早发现问题。

推理链长度异常 — 当某个意图的推理链长度超过历史 P95 的 2 倍时触发。过长的推理链往往意味着 Agent 陷入了某种循环或在某个节点反复尝试，是即将失败的先兆。配合推理链长度分布仪表板，可以在 Agent 完全失败前捕获问题。

上下文漂移检测 — 当同一 intent_id 在不同模型版本下产生截然不同的输出时触发。这需要持续比对：相同 input_intent + 相同 context_state 在新版本模型下的表现与历史记录是否有显著差异。模型升级前的灰度验证和模型升级后的回归监控都需要这个能力。

工具选择偏离 — 当 Agent 对某个意图类型选择的工具分布相比基线发生显著变化时触发。比如推荐系统突然开始更多地使用”冷门内容检索”工具而非”热门内容推荐”工具，这种偏离往往先于成功率下降出现，是最早的预警信号。

意图告警与传统的指标告警本质区别在于：传统告警告诉你”系统出了问题”，意图告警告诉你”AI 即将做出错误的决策”——后者才能实现真正的主动式可观测性。

从监控到理解：可解释性的崛起

可观测性的演进

可观测性经历了从被动到主动的演进，这个演进背后是三次范式转移：

2000 年代：Metrics 优先 — 监控的起点是基础设施指标。CPU、内存、磁盘 I/O、网络吞吐——这些数字容易采集、非黑即白、有成熟的采集和告警体系。Nagios 是这个时代的代表工具。这个阶段的可观测性回答”服务器还活着吗”。

2010 年代：Logs + Traces 加入 — 微服务架构带来了分布式追踪的需求。一次用户请求经过十几个服务，哪个环节出了问题？Apache SkyWalking、Jaeger 等工具让请求链路变得可见。这个阶段的可观测性回答”请求卡在哪一步了”。

2020 年代：Intent-Aware 时代 — AI-Native 系统的兴起让可观测性进入了第三个维度。传统指标、日志、追踪仍然需要，但它们只能描述系统层和 Agent 层的行为。意图层——AI 为什么做出这个决策——需要新的数据模型和采集方式。这不是对前两个支柱的替代，而是补充。

每一次范式转移都不是推翻前一种，而是增加了新的观测维度。今天的 AI-Native 系统同样需要 Metrics、Logs、Traces 作为基础，只是它们不够了——意图追踪填补了”为什么”这个传统监控无法回答的问题。

可解释性的实践

可解释性让我们不只能发现问题，还能理解问题背后的原因。以下是对比示例：

案例：推荐系统异常

传统可观测性：”推荐 API 延迟升高到 2s”

意图可观测性让你看到：模型为什么选择了这个推荐策略，是因为用户历史行为，还是因为上下文中的某个触发因素？这种洞察是传统监控完全无法提供的。

反直觉洞察：少即是多

洞察 1：不是所有数据都值得追踪

追踪意图数据时，反直觉的事实是：追踪所有意图会产生海量数据，反而降低价值。

实际策略：

  • 只追踪关键决策点 —— 每次 AI 决策都有 N 个节点，但不是每个节点都值得记录。只埋点那些”出错时需要知道为什么”的节点
  • 采样非关键路径 —— 对于简单问答或低风险操作，采用 1/10 或 1/100 的采样率，节省存储成本
  • 聚合相似意图 —— 意图相似的请求在聚合后分析，单独看每条 trace 价值有限，但千人千面的聚合模式能揭示系统性问题

洞察 2：意图的质量比数量更重要

在 Intent Tracing 中，详细的单个意图追踪胜过模糊的批量统计。

一个完整的意图 trace 比 1000 行无结构日志更有价值。

工具链与架构

推荐工具链 (2026)

层级 开源方案 商业方案
系统层 Prometheus + Grafana Datadog, New Relic
Agent 层 Langfuse, Helicone Weights & Biases
意图层 自研 / OpenTelemetry 扩展 新兴专用平台

架构建议

推荐采用以下三层可观测性架构：

AI-Native 可观测性系统架构图

三层可观测性模型

各层的具体职责和组件如下：

三层可观测性模型

结语：可观测性的终极目的

让我们回到那个根本问题：为什么需要可观测性？

不是为了收集数据。 不是为了漂亮的图表。 不是为了告警。

可观测性的终极目的是建立信任 ——

  • 信任 AI 系统按预期工作
  • 信任在出问题时能快速定位和修复
  • 信任系统的决策是可理解和可解释的

意图追踪让这种信任成为可能。

系列关联阅读：

下一篇预告：#57 AI-Native 团队的化学反应：角色重构

深度阅读时间：约 18 分钟

Published on 2026-03-14