阿里巴巴 & 蚂蚁 LoongSuite GenAI 可观测语义规范：从统一数据语言到规模化落地

来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, OpenClaw, 记忆系统, 电商, 办公效率, 网络安全, 编程, 芯片, 大模型
原文链接： https://mp.weixin.qq.com/s/vr_wp73rqUQAZT3p_g4GVQ

摘要

背景随着 AI，尤其是 Generative AI（后文简称 GenAI）的快速发展，AI Agent 系统中涌现出大量新的核心概念，例如 Model、Prompt、Token、Tool Calling、Agent、Memory、Session 等。这些概念已成为算法工程师、运维人员和可观测平台用户最关心的观测对象。它们需要像传统系统中的 HTTP 请求、数据库调用一样，被标准化地采集、展示和消费，以便系统维护者清晰了解调用过程、高效排查问题。基于此，OpenTelemetry（后文简称 OTel）早在 2024 年初就开始推动 Gen AI 语义规范建设，希望为这些新对象...

核心内容

背景

随着 AI，尤其是 Generative AI（后文简称 GenAI）的快速发展，AI Agent 系统中涌现出大量新的核心概念，例如 Model、Prompt、Token、Tool Calling、Agent、Memory、Session 等。这些概念已成为算法工程师、运维人员和可观测平台用户最关心的观测对象。它们需要像传统系统中的 HTTP 请求、数据库调用一样，被标准化地采集、展示和消费，以便系统维护者清晰了解调用过程、高效排查问题。

基于此，OpenTelemetry（后文简称 OTel）早在 2024 年初就开始推动 Gen AI 语义规范建设，希望为这些新对象建立统一的数据采集规范——Semantic Conventions（后文简称 SemConv），以解决相关领域可观测数据采集标准缺失、口径不统一等问题。

SemConv 定位与价值

Java、Go 和 Python 等各语言的自动插桩（Auto Instrumentation）或 SDK 等可观测采集工具，在许多对 OTel 刚接触的人眼里，可能会认为它们是 OTel 社区的核心价值所在。

然而，深入了解社区后会发现，相比于 SemConv，这些采集能力更多扮演的是"术"的角色，服务于 OTel 真正的"道"——通过 SemConv 建立统一的可观测数据语言。OTel SemConv 是一套汇聚全球几十家头部可观测厂商、数百名领域专家共同设计并持续演进的可观测数据采集标准。过去几年，在多次 KubeCon 会议上与社区核心 Maintainer 和 Co-founder 交流后，我们了解到，在他们眼中，SemConv 是 OTel 的灵魂，推动其逐步完善并走向 Stable 是社区最重要的工作。

一个统一的可观测 SemConv 可以实现如下效果：

统一数据语言，解决口径不一致

以 GenAI 语义为例，其应用场景天然跨模型、跨框架、跨平台。没有统一语义规范时，不同团队往往会各自记录“模型名”、“输入长度”、“Token 数”、“响应内容”等信息，字段命名和统计口径无法对齐。OTel GenAI SemConv 的核心价值在于为这些通用概念提供标准化字段，例如gen_ai.system、gen_ai.request.model、gen_ai.usage.input_tokens等。

一旦这些关键字段被标准化，不同业务、不同基础设施、不同观测后端就能共享同一套分析方法，真正做到“同一类问题用同一套数据解释”。这也是语义规范最基础、最重要的价值。

支撑性能、成本、质量与安全的统一治理

可观测建设的目标不仅仅是排障，还包括性能、效率、安全与输出行为的持续治理。比如在 GenAI SemConv 场景中，统一的 SemConv 在把模型参数、响应元数据、Token 用量等关键信息标准化后，团队才能更容易追踪性能、成本和安全相关问题。

对大型企业来说，这意味着可以在统一标准上解决如下几个实际诉求：

技术排查：通过 Trace ID 查看跨 Agent 完整链路，分钟级定位各类问题，如：某业务模型调用时延异常。
经营分析：效果数据跨业务可比，直接用于产品决策，极大提升 BI、产品、数科等角色做跨业务分析时的效率。
评测：真实用户轨迹持续积累，自动构建评测数据集，特别是多 Agent 协同场景的端到端评测。
合规：统一的审计链路，满足安全备案刚性要求。

如果没有统一语义，这些问题就只能停留在单系统内局部分析，无法形成集团级治理能力。

降低接入成本，推动基础设施复用

OTel 的设计目标之一，是通过标准协议、语义规范、SDK、自动插桩和 Collector 等组件，让遥测数据可以复用同一条采集与治理链路。在 GenAI 场景中，统一语义规范的价值也在这里体现得尤其明显：一旦字段、Span 结构、事件模型和上下文传递方式定义清楚，无侵入埋点、SDK 封装、平台分析、看板和告警策略都能复用。

这意味着业务不需要每次都从“我要采什么字段”开始思考，而可以直接站在已有规范之上接入能力，降低整体建设成本。

LoongSuite GenAI SemConv 介绍

背景

作为当前可观测业界的事实标准，OTel 虽早在 2024 年初就开始了 GenAI 语义规范的讨论和设计，但由于早期的人力投入有限，再加上社区标准更强调广泛适用与长期稳定，更新节奏整体较慢。相比之下，阿里巴巴集团内部有大量的大模型应用落地场景，遇到了大量真实场景中的案例问题，因此有将相关问题抽象成为统一标准的诉求。

2025 年：阿里云、阿里控股与蚂蚁集团的可观测团队联合启动，在 OTel GenAI 语义基础上对内部场景中 OTel 尚未覆盖的内容进行语义建模，并基于此推进内部可观测采集工具的实现与落地。

2026 年：与 OTel 社区 GenAI 主要 Maintainer 沟通后，考虑到相关内容较多且迭代较快，在社区 Maintainer 的建议下，先将成果开源至阿里巴巴 LoongSuite 可观测品牌下，作为 OTel GenAI SemConv 的厂商增强标准，后续择机逐步贡献至 OTel 上游。

内容与落地

目前，该规范已在集团内多个核心场景完成落地，形成了从 Agent 层到基建层的全栈可观测能力。例如以下是部分相关 Loongsuite GenAI SemConv 相比于 OTel GenAI SemConv 的增强内容：

新增 Entry/Step Span

问题背景

我们在 AI Agent 的实践过程中发现，当 Agent 执行长程任务时，其执行逻辑会变得越来越复杂。它会包含多轮工具调用和模型调用，导致单个 Trace 中包含成百上千个 Span。这些 Span 在同一链路中展示时显得非常冗长，导致调用链轨迹难以清晰观测。为了解决这个问题，我们引入了以下两个关键设计：

Entry Span：在 Agent 调用的入口处创建 Span，用于还原模型和用户的原始输入、输出，形成对话历史。这样可以确保在执行下游任务时，处理的数据不受 System Prompt 或框架 Prompt 的干扰，能够获取最原始的客户请求。
Step Span：Step 代表 Agent 在每次 ReAct 过程中的层次化表达。在每次 ReAct 过程中，Agent 都需要完成"反思 → 工具调用 → 模型调用"的循环。在排查问题时，通常采用 Top-down 的方式来定位 Agent 的执行情况。具体流程是：首先观察整体情况，例如当 Agent 执行包含 10 轮 ReAct 过程时，先定位是哪一轮出现问题，然后再深入分析该轮中具体是哪一步出错。通过这种逐轮的 Span 结构，可以清晰展示 Agent 的多轮行动、反思以及对应的执行结果，使每轮循环的轨迹一目了然。

语义建模

新增的 Entry 和 Step Span 类型定义如下：

属性

说明

状态

ENTRY

AI应用系统的入口点调用标识符

Dev

...(内容截断，完整内容请查看原文)

本页由自动化脚本生成，待人工审核补充