智能体运维的三重困境：质量难归因、Token 难控、遥测数据爆炸
AI 智能体在推动可观测性场景发生变化的同时，也给响应质量和费用管理出了新难题。即便智能体的执行过程并未报错，它依然可能调用到不准确的信息来源，或产出效果较差的答复。由于一次多步骤任务会涉及多轮提示、工具调用、资料检索、失败重试与模型生成，运维人员往往难以判断质量究竟从哪一环开始下滑，也难以厘清到底是哪些因素在推高 Token 消耗与账单。
另一个压力来自数据量：智能体生成的遥测记录远超普通应用请求，这让保留排查所需信息的开销和复杂度同步上升。为压制成本，不少团队选择压缩脱敏或整段丢掉遥测，结果是问题排查真正需要数据时，反而手头空空。据 InfoQ 报道，Snowflake Observe 即将推出的 Agent Observability 正是针对上述三类痛点，该功能将先以私有预览形式开放。
这项能力的核心思路是：追踪交互全过程，把智能体的实际行为同成本、质量两头挂钩，使团队能够监控、调试并改进 AI 智能体与大语言模型应用。具体而言，Agent Observability 提供调试智能体交互所需要的埋点能力、指标、工具与界面，用于定位性能和质量问题的源头、找出 AI 支出的主要来源，进而撬动业务结果改善。由于原生扎根于 Snowflake，该功能意在让智能体遥测数据以较低成本实现大规模留存与分析；团队还能把这类运行阶段的信号同 Snowflake 内的业务数据相互关联，看清哪些智能体和工作流真正产生了业务价值，并据此修正短板，把投资引向回报更高的方向。
埋点到查询：Agent Observability 即将提供的六项能力
按照规划，团队借助 Agent Observability 将能做到以下几件事：
第一是采集。选用可选的、兼容 OpenTelemetry 的 SDK，按新兴的 OTel 生成式 AI 语义约定抓取提示词、模型生成结果、检索动作、工具调用、Token 使用量和会话 ID；该 SDK 已经过测试与验证，适配 LangChain、Anthropic Agents SDK 以及 OpenAI Agents SDK。团队同样可以选择自行埋点，或在自建框架中通过 OTLP 端点把符合规范的追踪数据推送给 Observe。
第二是让搜索与调试落到对话粒度。凭借智能体探索器（Agent Explorer），可跨追踪记录、会话与单次对话进行检索，查看智能体的行为细节、调用过哪些工具，以及错误或异常响应最初从哪里冒出来。
第三是性能、使用量与成本的持续监控，分析对象是从智能体追踪数据中提炼出的延迟、错误和成本等指标。
第四是在生产流量上开展在线大语言模型裁判评估（LLM-as-judge），用以识别幻觉、安全护栏失效和低质量回复，并用底层跨度（Span）与追踪记录（Trace）回连评估结果，实现质量变化的长期盯守。
第五是离线评估结果的汇集，把既有开发与测试流程中的评估产出以追踪数据或指标形式送到 Observe 里做可视化分析。
第六是编程式访问，开发者可经由 API 从第三方智能体与自动化工作流处查询追踪记录、指标以及在线评估结果。
遥测体量为何远超传统应用
随着企业上线更多智能体、铺开更多应用场景，理解这些智能体所需的遥测数据也在迅速膨胀，而这种膨胀根源于智能体交互自身的结构特点。一条智能体追踪记录要覆盖某次交互背后的全部环节，包含模型调用、资料检索、工具执行、重试动作与中间输出，由此带来三个后果：持续时间更长、单个跨度携带的信息更多、跨度总数更庞大。
这对团队构成了实际的数据难题。他们必须保留足够细节来复盘关键交互，但这样做很可能让可观测性支出明显抬高。已有一些团队担忧，持续上涨的数据规模最终会逼迫自己对数据降采样甚至丢弃，进而在问题调查时制造信息空洞。
据原文介绍，Observe 本身就是面向高吞吐、复杂事件数据而搭建的，其底层架构让 Agent Observability 有能力留存并查询高保真的智能体遥测。具体实现路径分为三点：
其一，把长时间运行的追踪记录和对话完整留住。Observe 把用于应用性能监控的事件驱动思路扩展到智能体交互中，跨度按事件存放，按追踪 ID 与会话 ID 检索，让迟到跨度和较长空隙仍能被收进完整的交互记录。
其二，支撑包含大量上下文的大跨度数据查询。Snowflake 对这种复杂半结构化事件数据有原生支持，提示词、模型响应、检索到的上下文、工具输入输出都能连同有价值细节一起存储与检出。
其三，用较低成本承载不断膨胀的遥测。云对象存储能以更低的代价保存细致的智能体遥测，而 Observe 的遥测湖仓基础架构（Telemetry Lakehouse Foundation）把存储与计算拆开，使团队可以多留数据，并按搜索、分析、调试的实际需要单独扩展算力。
从上下文图谱到大模型裁判：把质量与成本还原到具体环节
当智能体输出欠佳，最终的回复往往无法说明问题出在何处。工程师需要知道智能体收到了什么上下文，模型调用、资料检索、工具执行与重试按什么顺序发生，每一步产出了什么中间结果，以及整个工作流从哪一步开始偏离预期。
据原文中的客户反馈，这些信息常常散落在应用程序、智能体框架、模型供应商和各种支持服务之间；一旦请求离开自己的环境，部分团队就失去了观测能力，于是用户关于延迟、错误或异常行为的投诉，有可能演变成耗时数小时乃至数天的排查。他们真正需要的，是在同一平台上端到端追查智能体工作流的办法。
Observe 的设计正是去捕获这些交互背后的上下文，并依次按对话、会话、追踪记录和单个跨度整理成面向智能体的不同视图。借助智能体探索器（Agent Explorer），团队可以用已采集的属性搜索智能体交互，并从对话一级级钻到底层追踪记录，查看提示词、模型输出、检索上下文、工具活动和重试过程，从而定位故障或异常回复初次出现的环节。其追踪视图能够重建模型调用与工具活动的先后顺序及耗时，并展示每个跨度中记录的提示词、响应和属性。
还需要注意，慢响应和错误响应不只源自智能体工作流内部，例如模型处理、信息化检索、工具使用或编排，也可能肇始于支撑该工作流的应用、服务或基础设施组件。Observe 的上下文图谱（Context Graph）把智能体遥测同关联的应用、服务、API、数据库与基础设施连在一起，使团队能将智能体跨度与上下游依赖做关联，而不是孤立看待智能体工作流。
传统可观测性只能说明请求是否够快、是否没出错，却判断不了答复是否准确、相关、有用。对非确定性系统来说，质量必须成为生产环境中可以量度的指标。Observe 支持在生产追踪数据上跑在线大语言模型裁判评估，并把评估结果转成可长期监控的指标；每条评估结论都与底层交互绑定，工程师能把质量问题一路追到提示词、检索上下文、工具选择、支持服务或模型响应，并检验相应调整是否真的改善了线上表现。其评估视图（Evaluations）会跟踪准确性、相关性、幻觉率和指令遵循情况等生产质量指标，包括分数及随时间的变化。团队还可以把既有离线评估流程的产出作为追踪数据或指标送入 Observe，在不更换现有工具的前提下，用统一视图同时查看开发期结果与生产实况。
在成本一头，来自客户的反馈是：只看 Token 消耗总量并不足以判断 AI 花钱是否花得值。管理者想按具体应用或项目归因资源消耗，并知道这些钱换来了什么。于是团队需要读懂左右成本和性能的各类因素——模型如何选、提示词多长、检索了什么上下文、工具使用方式、重试次数与工作流设计。工程团队经过分析即可找出不必要的重试、过贵的模型选择等低效之处，这类环节往往在推高成本的同时并未改善质量；举例来说，评估流程配置不当，可能以远超预期速度烧掉可用 AI 预算。
指标视图（Metrics）会持续跟进 Token 使用量、延迟、请求量以及跨度类型随时间的变化，帮团队识别智能体性能和资源消耗的变动。Observe 从智能体追踪数据里抽取延迟、错误、Token 使用量和预估成本等指标，用于对照不同智能体、模型与工作流，找出低效执行路径。逻辑很直白：低成本模型若导致更多评估失败，就未必是更好的选项；反过来，高成本模型若换不来实质性质量提升，多出来的开销也难言合理。
这正是 Observe 与 NoSnowflake 能力合璧之处。优化支出时，Observe 帮团队把性能、质量与成本三者摆平；Snowflake 则补上理解这些决策后果所需的业务语境。面向客户的智能体，可与客户体验、问题解决率、转化率和收入挂钩；面向内部的智能体，则可对应任务完成情况和员工生产力。企业由此可以根据智能体实际产生的成效持续改良，把 AI 预算投向真能创造价值的场景。
用 OTel 与 Iceberg 守住开放与灵活
智能体架构演进很快，可观测性不该限定团队选用哪家模型、哪个框架或哪种网关。据原文，客户提及自己已经在使用自定义框架、专门评估产品与云原生服务，他们需要的是在这些环境里获得一致的可见性，同时既要避免被另一种专有数据格式锁死，也不要因为架构变动而重造采集体系。
Observe 通过 OTLP 端点支持原生 OTel 数据采集，其可选的兼容 OTel SDK 则提供了一条便捷路径，以新兴生成式 AI 语义约定来采集与串联智能体遥测。对开放标准的支持还顺着 Apache Iceberg™ 延伸到存储层：Observe 能够处理存于 Iceberg 表里的受支持遥测，兼容的查询引擎也可以经开放式 REST 目录访问同一批数据。OTel 与 Iceberg 并用，让团队在采集、存储、查询引擎之间留有余地，又不丢失 Observe 的排查与监控能力。
按照原文信息，Agent Observability 即将进入私有预览。若团队的需求是追查智能体交互、衡量生产质量、优化 AI 支出，或对大体积智能体遥测做保留，可申请加入预览。10 月 22 日，Snowflake 可观测性业务总经理 Jeremy Burton 与 Snowflake 产品执行副总裁 Christian Kleinerman 将在发布活动中分享相关洞见；也可联系 Observe 客户团队申请私有预览资格。
小结：Snowflake Observe 把智能体遥测的采集、留存与质量评估收拢进 Snowflake 原生平台，用 OTel 语义约定对接主流框架、用 Iceberg 保持存储开放。对 AI 工程师与可观测性负责人而言，关键在于把由提示门调用与重试链路串起的 Black Boxing 变为成本与质量的可关联信号，而非只盯着 Token 报表。