「Agent 工程化」方向-面向AgenticOps的开源建设 采集标准化、统一语义建模与能力评测

面向AgenticOps的开源建设采集标准化、统一语义建模与能力评测提出捐赠方案提出

SIG方案新仓库合入首个

PRv1.0.0进入稳定版本从提案到稳定版本用了接近两年；当前由7位

maintainer共同维护，阿里占

3席。2024-09-112024-12-142025-01-172026-07两年前播下的一颗种子03

验不准缺少可复现环境、

故障Case和稳定的评分口径线上问题难以固定环境和数据快照模型、工具和评分变化难以分开比较BadCase没有稳定进入版本回归02

读不懂数据缺少统一的对象、关系、时间和来源同一概念在不同框架中使用不同字段多源数据无法归到同一个实体和时间范围长程轨迹缺少统一的阅读和追溯路径01

采不到关键运行事实没有进入统一链路对应建设

采集

UModel

.

BRISE

AgenticOps要先越过三道墙Go、

闭源二进制和开发机Agent仍有覆盖空白推理引擎缺少Token级耗时和调用结果指标、

日志、请求、事件无法按同一时间带回AgenticOps要进入生产，必须同时具备完整的运行事实、统一的故障上下文和可复现的能力验证体系。一次真实故障

可重复验证,OTelGenAISemConv·OTLP

Trace/

Metric

·

HTTP/

LocalJSONLLoongSuiteGo框架规则→编译期注入LoongSuiteSemanticConventions基于开源在生产实践中拓展新场景LoongSuite

PythonLoongSuite

PilotLoongSuiteJava基于OpenTelemetry的采集底座全景五条采集路径覆盖服务端、基础设施和端侧Agent最终进入同一套OpenTelemetry语义与输出。GenAISemanticGoCompile-timeOBI/eBPFPythonGenAIJavaAgenti

cOps·

UModel

·

BRiSE

回馈InstrumentationInstrumentationInstrumentation框架插桩→

GenAI语义框架插桩→

GenAI语义Hook→

GenAI语义Conventions标准Non-Invasive

Data

PathOBI不只是看见网络流量，而是把不可插桩场景还原成可关联、可比较的

GenAI语义。OBI：

让“不能改代码”的应用，变成标准化OpenTelemetry信号标准输出更广覆盖读懂交互TLS边界内获取明文：在加密前/解密后采集，无需密钥任何语言的AIAgent/AppeBPF

内核采集OTelGenAI

Span用户态语义恢复2024-122025-022025-052025-082025-112026-012026-03修复bug补齐能力替换废弃API新增

Dubbo

RPC指标建立独立SemConv页面按规范重构插桩进入stable支持同一条路径继续扩展到更多国产框架生产

Issue暴露错误路径，规范页面明确字段含义，

插桩实现据此修正差异。稳定支持的判定四项工作进入社区流程错误修复、指标补齐、语义规范和长期维护都纳入社区流程。,国产框架贡献进入OpenTelemetry之路以Apache

Dubbo为例，生产问题先进入

Issue规范和实现随后同步修订，满足条件后进入stable支持。RPC数据库访问消息任务调度网关LoongSuite验证轨道OTel上游社区轨道202420252026OpenTelemetry启动GenAI

SemConv讨论社区

maintainer建议先完成真实场景验证

逐项回馈字段、工具与

Agent

插桩两条轨道的分工LoongSuite先验证真实场景成熟的字段和实现再提交OpenTelemetry

，供不同厂商长期使用。202420252026整理内部模型调用与工具执行语义阿里云、阿里控股与蚂蚁开展大规模验证开源

LoongSuite

GenAI

SemConvSemantic

Convention语义规范：

双轨协作Skill：

按业务功能归因Entry/Step：

按调查层级阅读在语义规范之上，

拓展的场景LangchainQwenPawOpenClawCodexAgentScopeHermesAgentClaudeCode工程化贡献从“能追踪”走向“可持续维护”核心机制贡献从0到

1建立原生追踪框架为推理引擎建立请求级OpenTelemetry追踪阿里云贡献让SGLang能够从一次请求下钻到推理阶段，记录引擎中排队、

Prefill

Decode与跨节点传输等重要节点。、定位问题

·优化成本

·评测优化

·安全审计LoongSuite

Pilot：

面向Coding

Agent场景的标准化采集CodexCursorQoderDeepSeekHarnessOpenCodeClaudeCodeCMS/ARMSLangfuse/OTLP多源采集标准语义建模本地/

HTTP自动接入安全治理支持20

+AI

Agent可观测数据采集与处理SLS支持任意可观测后端

条贡献259个

PR（205合并，

79.2%）+

173个

Issue贡献分布Go147Java135eBPF47GenAISemConv23SemConv22community

16官网

12Python

10从贡献到共同治理Go

7席中

3席Java

11席中

1席GenAISemConv

8席中

1席社区贡献：

让生产经验持续进入OpenTelemetry规则进入OpenTelemetry后可以跨厂商复用，用户迁移时无需重做采集和字段映射。03

验不准缺少可复现环境、

故障Case和稳定的评分口径01

采不到02

读不懂数据缺少统一的对象、关系、时间和来源对应建设

采集 UModel

...

BRISEUModel以故障对象为主线，对齐指标、日志、请求和事件中的实体、关系与时间范围，形成可查询、可追溯的调查上下文。AgenticOps要先越过三道墙：数据采不到、上下文读不懂、能力验不准同一概念在不同框架中使用不同字段多源数据无法归到同一个实体和时间范围长程轨迹缺少统一的阅读和追溯路径一次真实故障

可重复验证checkout-service支付成功率在3分钟内下降7.5个百分点92.1%09:58

10:01

发布V2.410:04

DB连接数10:06

paymenttimeoutAgent据此完成四个判断01

哪个对象先变化？04下一步验证什么？四类信息对齐后形成可验证的影响路径Checkout故障可访问数据 MetricsCheckout成功率/SLO

Runbook发布、数据库、下游验证

Logscheckout/

MySQL

日志

请求checkout→

payment①EventsreleaseV2.4

CMDBDeployment/

Pod/

MySQL当前证据将调查重点指向

MySQL连接数、

payment

超时与成

功率下降构成的影响路径，发布变更进入首要核查序列。02哪条证据支持原因？03异常怎样传播？Checkout-service成功率从99.6%降至92.1%Agent需要对齐对象、关系、时间范围和证据来源才能判断三条线索是否属于同一影响路径,

。SEMANTIC

RUNTIME语义运行时解析对象

｜绑定事实｜组织上下文静态语义模型任务上下文运行时围绕当前故障聚合对象、关系、状态和证据

，形成Agent可继续执行的调查上下文。任务发生时动态编译围绕checkout-service和09:58—10:06

，选择发布对

象、

Pod、

payment、

MySQL及其指标、日志、请求

和事件。围绕checkout-service选择对象、

关系和八分钟的证据数据语义

:

规则与动作

对象类型关系类型checkout-service

+09:58—10:06

+根因调查AgentQuery:checkout-service

|window09:58—10:06

|

metrics/logs/requests/

eventsView

DetailedTracesDeployment

Metrics(MetricStore)(LogStore)Pod

Metrics(MetricStore)K8sDeployClusterK8sPodService3HostDatabaseService

Log(LogStore)Node

Metrics

(MetricStore)

View

Error

Details

View

Related

Logs(LogStore)Agent据此完成四个判断确认对象固定时间范围执行只读查询返回可复核证据。2

变更

310:01

releaseV2.4Deployment

/

Pod

首要核查路径

连接数上升

成功率降至

92.1%,

、运行时围绕checkout-service生成可执行、

可追溯的跨域调查路径运行时保留对象、时间和来源

Agent按发布数据库和下游三个方向逐项验证。1

44

下游10:06

payment超时只读查询沿发布、数据库和下游三条路径逐项补齐证据对象checkout-service数据库10:04

MySQLCode

Repo

View

Related

MetricsView

Related

Events

ViewAPM

Metrics

MySQL

Metrics

(MetricStore)Change

Events

(EventStore)Golden

Metrics

(MetricStore)Redis

Metrics

(MetricStore)Host

Metrics

(MetricStore)Trace(LogStore)Host

Events

(EventStore)Issue

DetectedDB

Errors

(LogStore)Service

InstanceOperations

LogsCI/CD

JobRedisAccess

Logs04030102Root

CauseDeployerMySQLNodeRedis21K8sK8s正式发布发起

USS行业倡议发布与倡议官方仓库公共代码与开放协议代码仓库03

开放接口CLI

·

MCP

·

REST公共接口公共语义契约让不同实现围绕同一对象、关系和查询接口协作，并为后续

Benchmark固定上下文边界。UModel

已开源：对象图、

查询服务与Agent

已形成公共语义标准联合发布机构：小鹏汽车｜卓驭科技｜畅捷通｜嘉立创科技｜神州商龙010202

读不懂数据缺少统一的对象、关系、时间和来源同一概念在不同框架中使用不同字段多源数据无法归到同一个实体和时间范围长程轨迹缺少统一的阅读和追溯路径01

采不到关键运行事实没有进入统一链路Go、

闭源二进制和开发机Agent仍有覆盖空白推理引擎缺少Token级耗时和调用结果指标、

日志、请求、事件无法按同一时间带回03

验不准缺少可复现环境、

故障Case和稳定的评分口径对应建设采集采集补齐缺失的运行事实UModelUModel

围绕对象组织故障上下文BRISEBRISE

固定环境、Case和评分口径AgenticOps要先越过三道墙BRiSE固定故障环境Case和评分规则，

开放任务与基线，

让AgenticOps能力能够在同一条件下复现、比较并进入版本回归线上问题难以固定环境和数据快照模型、工具和评分变化难以分开比较BadCase没有稳定进入版本回归一次真实故障

可重复验证、

。不同系统使用不同对象，评测任务均需要说明对象、关系、时间范围、证据来源和交付结果。行业金融行业现场的真实问题Benchmark必须保存的上下文评测任务必须保留的内容查询互联网防火墙入向中ANY访问ANY的日志。防火墙方向、源和目的、时间范围、日志字段，以及异常请求是否集中在同一服务或路径。任务需要把请求路径、服务实例和错误数量对应到同一个故障对象。电力看看这个月的情况，日志条数特别大。日志量的当前值、历史基线、采集器状态、应用重启和注册状态

，以及对应时间窗口。任务同时保存日志基线、采集状态、应用重启和注册结果，形成完整的异常链路。制造巡检

MongoDB资源；再分析

RedisTop500大Key。数据库实例、容量和慢查询，大

Key

占用、

最近使用时间

，以及应用和生产任务关系。任务需要提供基础设施与业务对象的映射，并保留容量、访问记录和生产影响。通信查询过去两小时SLS呼叫数据，识别接通率异常。号码池、时间范围、

呼叫量、接通率、未响铃号码及其历史基线和异常持续时间。任务固定号码池、时间范围、异常阈值和历史基线

，使查询始终围绕明确对象展开。电商对应用执行

RUM页面性能和API异常巡检。页面流量、

FCP/LCP、API错误、异常堆栈、当前窗口和基线窗口

，以及受影响页面。任务需要同时保留性能指标、基线差异、API异常和受影响页面。行业需求决定开源

Benchmark应该覆盖哪些真实任务AgenticOps证据查询与根因推理OpsAgent执行Benchmark应用复现真实对象与故障应用与环境BRiSE固定环境、数据和评分口径评测与回归Benchmark应用复现故障，OpsAgent进行故障排查，BRiSE统一评分，让每次诊断都能复现、复查并进入版本回归形成可以重复评测和优化的流水线010203。内部使用场景趋势

各日合计100%100%50%0%0506070809101112131415161718

数据查询

巡检与异常分析

故障诊断场景任务模板数据查询巡检与异常分析故障诊断Benchmark场景覆盖

数据查询~10%巡检与异常分析~70%故障诊断~10%巡检和异常分析占据大部分请求，极少被现有的

Benchmark关注

Benchmark场景覆盖面向真实生产环境的产业界｜把评测接入研发流程Datadog

BitsAI

EvalServiceNow｜

Elastic｜

Dynatrace典型工程链学术界｜从静态数据走向Agent过程根因与证据

可执行环境

t..

实时与分层

任务从离线表格扩展到可运行的微服务或云环境

，评分开始区分对象、影响边界、证据和调查过程。跨领域

Agent｜开放执行与判定方法AgentBenchBFCLτ-benchSWE-bench

环境状态、测试结果或独立规则判断任务是否完成，并为任务结果提供独立验证。产业界学术界和跨领域评测都在把环境调查过程和独立判定纳入验收据此分别验证数据查询、

异常分析和故障诊断评测接入日常研发流程，每次版本变化都在固定题集上重跑并定位失败原因。产业界已把评测接入研发流程

，

学术界趋向在线环境验证、

、

，

。任务示例｜每道题都能在固定对象和时间范围内复跑数据查询01查询指定应用过去30分钟的请求错误率。02列出CPU最高的

5台主机，并返回聚合口径。03查询指定实例的告警事件和当前资源状态。04沿服务依赖关系找到下游实例和关键指标。05查询配置变更、版本和元数据，并核对时间。巡检与异常分析01识别

K8s

Pod重启、资源压力和副本异常。02从日志聚类中找出新增或突增的异常模式。03检查

ECS负载、磁盘、

网络与系统事件。04核对采集器丢数、重复采集和延迟上报。05分析

RUM页面、API异常和告警规则状态。故障诊断01判断流量突增如何影响下游调用与告警。02结合请求链路与入口延迟验证慢SQL。03判断

DNS失败是否导致服务等待和超时。04定位节点CPU满载对应的受影响Workload。05

区分代码延迟、依赖故障和发布变更。按证据复杂度分层评估结果正确性异常证据和诊断过程在多源数据中识别异常模式418

个任务每个任务记录异常模式、证据匹配规则和评分方法。围绕真实故障完成诊断764

个Case每个Case记录故障环境、GroundTruth、证据链和过程评分器。知道查什么，并取得正确数据1360

道数据查询任务每道题记录对象、

时间范围、可用工具、预期结果和查询正确率。按照数据查询、

异常分析和故障诊断不同复杂度进行分层、故障大类应用代码/运行时微服务依赖/

自建中间件K8s/容器平台主机/OS云产品实例网络流量/安全LLM/Agent变更发布覆盖的数据类型指标｜日志｜请求｜事件

|告警｜性能｜拓扑访问来源分布截至

2026-09-01中国

美国

174新加坡

160日本

30英国评测基准在线环境RCA100/200已经发布，访问来源覆盖

36个国家或地区高频故障类型F014

HTTP

5xxF007

内存压力F026节点CPU高F034CPU满载F066代码延迟F006流量突增F016

限流F075共享内存泄漏F103安全组阻断单一故障类型最高仅占7.1%；未来将进一步补齐

LLM/Agent和变更发布等长尾场景。联合发布机构：信通院｜中科院软件所｜中科院计算机网络信息中心｜清华大学｜复旦大学｜南开大学134908783674626633927232321151513131,16115BRiSE/UModel高校研究团队外部团队开源开发者规范、参考环境与初始Case覆盖算法、模型、Harness与消融实验提交基线并推动歧义Case收敛贡献环境、故障和任务、评测

--------------------学参与者可分别提供环境、任务、

故障和评测发布内容提交资产