当 AI 模型在代码生成任务中表现优异时，我们很容易产生一种错觉：它们已经具备了处理生产级系统问题的能力。然而，Quesma 团队发布的 OTelBench 基准测试结果打破了这一幻想 —— 即使是表现最佳的 Claude Opus 4.5 模型，在 OpenTelemetry 仪器化任务中的通过率也仅为 29%。这一数据背后隐藏着更深层的问题：AI 在 SRE 领域的能力边界究竟在哪里？本文将从评估方法论入手，系统拆解 AI 在四类 SRE 任务中的典型失败模式，并尝试归因分析其根本原因。
评估方法论的核心设计
OTelBench 的评估框架建立在真实 SRE 场景之上，而非人工设计的简单任务。测试团队选取了 14 个主流大语言模型，覆盖 11 种编程语言，要求模型为现有代码库添加分布式追踪能力。具体而言，每个任务都来源于真实的 OpenTelemetry 仪器化需求，例如为登录失败场景配置追踪、为数据库查询添加 span、或在微服务调用链中传递上下文信息。这种设计确保了测试的实用价值 —— 它衡量的不是模型能否写出一个「hello world」级别的追踪代码，而是能否理解生产环境中复杂的依赖关系和 instrumentation 规范。
评估采用 Harbor 框架作为底层支撑，这是由 TerminalBench 创建者开发的标准化评估工具。Harbor 框架的核心优势在于其任务定义的严谨性：每个测试用例都包含完整的代码上下文、预期输出、以及评判标准。这种设计避免了主观评分带来的偏差，使得不同模型之间的比较具有可信度。值得注意的是，测试并未设置任何提示工程（prompt engineering）的优化空间，模型需要在零样本（zero-shot）条件下完成所有任务。这模拟了真实场景中 SRE 工程师面对陌生代码库时的处境 —— 他们无法依赖详细的示例，只能依靠自身对 OpenTelemetry 规范的理解来完成任务。
从测试结果来看，整体通过率维持在 14% 左右，这意味着超过五分之四的 instrumentation 尝试以失败告终。即使是被视为顶级模型的 Claude Opus 4.5 和 GPT-5.2，其表现也未能突破 30% 的门槛。更令人意外的是，Gemini 3 Pro 相比 Gemini 3 Flash 并未展现出显著优势，这暗示着模型规模的简单提升并不能直接转化为 instrumentation 能力的增强。这些数据共同指向一个结论：当前的 AI 技术在 SRE 领域存在系统性的能力短板。
任务分类体系与失败模式映射
深入分析 OTelBench 的测试用例，可以将 SRE 任务划分为四个核心类别，每类任务对应着不同的能力要求和失败模式。
第一类是上下文传播任务，这是分布式追踪的基础能力。在微服务架构中，一个请求需要在多个服务之间传递追踪上下文（trace context），包括 trace ID、span ID 和父级关系等信息。AI 在这类任务中的主要失败模式是上下文丢失或错误传递。典型表现包括：在 HTTP 请求头中遗漏必要的 W3C Trace Context 标准字段、在 gRPC 元数据中未能正确序列化追踪信息、或者在异步任务队列中完全忽略上下文继承。这类失败的根因在于模型对分布式系统「请求生命周期」概念的把握不足 —— 它们往往只关注单个函数或类的实现，而忽视了跨越服务边界的状态传递需求。
第二类是 span 创建与属性配置任务。Span 是追踪的基本单元，每个 span 需要包含操作名称、时间戳、属性标签和事件等元素。AI 的失败模式集中体现在属性语义的不当使用上。具体而言，模型倾向于为所有操作添加冗余的属性信息，却遗漏关键的业务语义标签；或者错误地使用 OpenTelemetry 语义约定（Semantic Conventions），将不符合规范的键值对写入 span 属性。例如，在描述 HTTP 请求时，模型可能使用 http.method 替代标准的 http.request.method，或者为数据库操作添加 db.system 而忽略 db.operation 的填充。这类失败反映了模型对 OpenTelemetry 规范细节的掌握程度有限。
第三类是采样策略与配置任务。生产环境中的追踪需要采样策略来控制数据量，而 AI 在配置层面的表现尤为糟糕。常见失败包括：无法理解采样率与追踪完整性的权衡关系、为所有请求启用 100% 采样、或在配置中混淆采样决策器（sampler）与导出器（exporter）的职责范围。更严重的是，模型经常生成与目标语言 SDK 不兼容的配置代码，例如为 Python 应用编写不符合 OpenTelemetry Python API 规范的初始化逻辑。这类失败揭示了 AI 在「配置工程」这一 SRE 核心能力上的明显短板。
第四类是错误处理与异常追踪任务。当系统出现异常时，追踪信息需要准确反映错误状态和堆栈轨迹。AI 在这类任务中的失败模式包括：未能正确记录 exception 事件、遗漏关键错误属性如 exception.type 和 exception.message、或错误地将应用层异常与基础设施层错误混淆。特别值得注意的是，模型对于「什么是值得追踪的错误」缺乏判断能力 —— 它们可能为每一个 caught 异常都创建 span 事件，却忽略了真正需要关注的上游传播错误。这一模式的根因在于 AI 缺乏对「生产系统错误语义」的深刻理解。
根因归因的多维分析
从技术层面剖析 AI 在 SRE 任务中失败的根本原因，可以归纳为三个相互交织的维度。
首先是训练数据的结构性缺失。当前的大语言模型主要基于公开代码仓库和编程教程进行训练，而这些数据源中 OpenTelemetry instrumentation 的覆盖率极低。SRE 相关的代码实践往往存在于私有代码库或企业内部分享中，极少出现在公开语料里。更关键的是，OpenTelemetry 本身是一个快速演进的项目，其 API 和 SDK 在不同语言之间存在细微但重要的差异。模型难以从有限的公开示例中习得这些差异对应的最佳实践。
其次是系统级思维的缺失。SRE 任务本质上要求执行者具备「端到端」的系统视角 —— 理解请求如何流经各个服务组件、追踪数据如何在基础设施中流转、以及 instrumentation 如何影响系统整体性能。AI 模型在处理这类任务时，倾向于将其分解为孤立的代码修改，而非系统性的设计决策。它们可能正确地为单个函数添加了 span，却破坏了整体的上下文传播链；或者优化了局部追踪配置，却引入了循环依赖或性能回退。
第三是业务语义的鸿沟。OTelBench 测试中发现的许多失败，根源在于模型无法理解被 instrumentation 代码的业务上下文。例如，对于一个登录失败场景，模型需要理解「失败登录」与「成功登录」在业务层面的区别，才能决定应该记录哪些属性、设置何种 span 级别、以及如何关联用户身份信息。这种业务理解能力恰恰是当前 AI 模型最欠缺的 —— 它们能够生成语法正确的代码，却难以把握代码背后的业务意图。
工程实践的启示与建议
基于 OTelBench 的评估结果，工程团队需要重新审视 AI 在 SRE 工作流中的角色定位。短期内，将 AI 应用于 OpenTelemetry instrumentation 的期望需要适度降低。当前模型更适合作为「辅助工具」而非「自主执行者」—— 它们可以生成初始配置的草稿、建议可能的 span 命名规范、或解释现有的追踪结构，但最终的配置审核和质量保证仍需人类 SRE 工程师完成。
从长期来看，提升 AI 在 SRE 领域能力需要三条并行的路径。第一是构建高质量的领域特定训练语料，将企业内部的 instrumentation 实践脱敏后贡献给开源社区，或用于特定领域的模型微调。第二是发展更精细的评估框架，不仅关注「是否通过」这样的二元结果，更要分析失败的具体模式和改进空间。第三是探索人机协作的新范式，让 AI 负责高频低风险的配置任务，而人类专家聚焦于关键路径的决策和审计。
OTelBench 的价值不仅在于揭示了 AI 的能力边界，更在于提供了一套可复用的评估方法论。随着 observability 领域的持续演进，我们可以期待更多类似的基准测试出现，帮助整个行业更准确地定位 AI 技术的适用场景。对于 SRE 工程师而言，这意味着需要在保持专业技能敏锐度的同时，学会与 AI 工具协同工作 —— 既不盲目信任其能力，也不忽视其在特定任务上的辅助价值。
参考资料
- Quesma 团队发布 OTelBench 基准测试，测试覆盖 14 个模型和 11 种编程语言，揭示当前顶级模型在 OpenTelemetry 仪器化任务中的通过率上限约为 29%。