当人工智能模型在代码生成基准测试中屡创佳绩时，一个更关键的问题浮出水面：它们能否真正解决生产环境中的系统可靠性问题？ Quesma 团队发布的 OTelBench 基准测试为此提供了首个系统性评估框架。该测试聚焦于一项对 SRE 工程师而言稀松平常却对系统可观测性至关重要的任务：为微服务添加 OpenTelemetry 分布式追踪埋点。测试结果令人警醒：在 14 个前沿模型中，表现最佳的 Claude Opus 4.5 仅取得 29% 的通过率，而部分主流语言如 Java、Ruby 和 Swift 的任务甚至全军覆没。这一结果不仅揭示了 AI 在长周期、多步骤工程任务上的能力短板，更对当前 AI SRE 解决方案的实际可用性提出了严峻质疑。

分布式追踪与 OpenTelemetry 的工程现实

理解 OTelBench 的意义，首先需要把握分布式追踪在现代微服务架构中的核心地位。当应用程序运行在单机环境时，工程师可以通过查看日志文件追踪错误根源；然而在由数十个微服务组成的分布式系统中，单个用户请求会在服务间跳转十数次甚至数十次，产生海量分散的日志片段。分布式追踪通过为每次请求分配唯一的 TraceID，将这些散落的事件重新串联成完整的调用链，使工程师能够跟随用户的每一次点击，从 API 网关到认证服务再到数据库，完整还原请求的整个生命周期。这项能力对于定位性能瓶颈、诊断跨服务故障以及优化系统延迟至关重要。

OpenTelemetry 已成为可观测性领域的行业标准，其生态系统涵盖三大核心组件：语义规范提供统一的命名约定，取代了此前混乱的 ip_address 与 host.ip 等不一致命名；多语言官方 SDK 为每种主流编程语言提供标准化的埋点接口；Collector 代理则负责在数据导出前进行集中处理与 enrichment，例如添加 Kubernetes 标签。然而标准化的接口并不意味着易用性 ——Grafana 2025 年可观测性调查显示，39% 的受访者将 OpenTelemetry 的复杂性列为主要痛点。对于真实的生产系统，服务往往由多种编程语言混合构成，代码库可能历经多任维护者且文档缺失，这使得埋点工作既繁琐又容易出错。

OTelBench 测试设计与方法论

OTelBench 的测试设计体现了对真实工程场景的刻意追求。基准测试覆盖 11 种编程语言，包括 Go、Java、C++、Python、JavaScript、PHP、Ruby、Rust、Erlang、.NET 和 Swift，共计 23 个 OpenTelemetry 埋点任务。每个任务从一个约 300 行代码的真实微服务入手，要求 AI 模型在 Linux 终端环境中完成代码编辑并运行必要命令进行验证。之所以选择短小精悍的服务代码，是因为研究团队希望将复杂度锁定在 OpenTelemetry 埋点本身，避免因服务规模过大而引入干扰因素。

以 Go 微服务追踪任务为例，提示词明确要求：埋点必须符合 OpenTelemetry 语义规范和业界最佳实践，必须匹配服务的业务领域，必须将追踪数据发送至标准环境变量定义的端点，并且必须使用最新版本的 OTEL SDK。值得注意的是，OTelBench 不仅检查代码是否编译通过，更会对生成的追踪数据进行深度验证：span 名称是否准确、父级子级关系是否正确、TraceID 是否有效、上下文传播是否完整。这套严格的验证机制能够捕获那些「编译成功但追踪失效」的隐蔽问题，而这恰恰是 AI 模型最常见的失败模式之一。

整个基准测试的执行成本约为 522 美元，包含 966 次独立运行（23 个任务 × 3 次尝试 × 14 个模型）。测试基于 Harbor 框架构建，该框架由 TerminalBench 的创建者开发，支持研究者自行复现结果、测试新模型或扩展自定义任务集。所有任务代码和评测脚本均已在 GitHub 开源，推动行业对 AI SRE 能力的独立验证。

模型表现的核心发现：期望与现实的落差

测试结果揭示了当前 AI 模型在 SRE 任务上的严峻现实。最优秀的 Claude Opus 4.5 仅取得 29% 的通过率，GPT 5.2 以 26% 紧随其后，而被寄予厚望的 Gemini 3 Pro 竟然与轻量版 Gemini 3 Flash 持平，均在 18% 左右。更具讽刺意味的是，专注于代码生成的 GPT 5.2 Codex 版本反而大幅落后于其通用版本，这表明单纯的代码生成优化并不能直接迁移到工程埋点任务上。

这些任务对于人类工程师而言可谓小儿科 ——300 行代码的微服务、短平快的业务逻辑、标准化的埋点接口。然而即便如此简单的场景，AI 模型依然频繁折戟。研究团队对此表达了强烈关切：如果模型连干净代码库的简单埋点都难以胜任，它们如何能够处理动辄数万行、充满历史债务、文档缺失的生产级服务？一个真实的 SRE 场景往往涉及遗留系统的改造、多语言服务的一致性埋点、以及在高压环境下的快速故障定位 —— 这些对当前 AI 而言皆是难以逾越的鸿沟。

语言支持的不均衡进一步放大了这一困境。按编程语言统计，C++ 以 37% 的通过率位居榜首，但这主要得益于其测试集中包含一个相对简单的任务；Go 作为分布式系统的核心语言，在 7 项任务的测试中取得 20% 的通过率，表现差强人意；JavaScript、Python、PHP 和 .NET 处于中等水平；Rust 仅有一项任务被单个模型艰难攻克；而 Java、Ruby 和 Swift 的所有任务全部失败。这一分布并非偶然，它反映了 AI 训练数据中各语言出现频率的差异 ——Python 和 TypeScript 因其流行度获得了更多关注，而 Swift、Ruby 等语言则长期处于边缘位置。

核心失败模式剖析：上下文理解的缺失

OTelBench 最有价值的贡献之一，是其对 AI 失败模式的深度剖析。研究团队识别出一种典型的错误模式，可将其概括为「机械埋点与业务上下文的脱节」。以基准测试中的一个具体场景为例：系统需要追踪用户的搜索和结果获取流程，同时模拟两种用户行为 —— 正常搜索获取令牌并成功获取结果，以及使用无效令牌获取结果时的 404 错误。从代码结构看，这显然是两个独立的用户动作，应当生成两条完全独立的追踪链路，每条链路拥有独立的 TraceID。

然而 AI 模型的处理方式暴露了其根本性缺陷：它们将埋点视为纯粹的 HTTP 调用集合，而非业务流程的映射。模型机械地为每个 HTTP 请求添加追踪代码，却未能理解这些请求应当归属于不同的用户会话。正确的结果应该是两条清晰独立的追踪树，每条树完整记录一次用户操作的完整调用链；但模型生成的追踪将两次用户行为错误地合并为单一追踪，TraceID 在两次操作间延续，导致追踪数据完全失去诊断价值。

这种失败模式的根源在于当前 AI 模型缺乏对业务语境的深层理解。埋点工作表面上是技术活，实际上需要工程师理解「用户点击登录按钮是一次独立事件」「用户搜索并获取结果是另一次独立事件」「这两条追踪路径应当在业务层面被明确区分」。模型能够熟练掌握 API 调用语法和 SDK 接口，却无法将这些调用与业务语义建立关联。它们看到的是扁平的 HTTP 请求列表，而非立体的用户旅程树。

更隐蔽的是，许多失败的代码甚至能够编译运行，产生形式上「正确」但内容上完全错误的追踪数据。这类缺陷仅通过代码审查或简单测试难以发现，只有对追踪数据进行语义级验证才能捕获。这提醒我们，在 SRE 领域「能跑通」远非充分条件，追踪数据的正确性和可用性才是真正的质量标准。

成本效益与帕累托前沿的启示

在实际部署中，模型的选择不仅要考虑绝对性能，更需权衡成本与响应速度。OTelBench 的分析揭示了一个有趣的帕累托前沿格局：在测试的 14 个模型中，只有四个位于效率前沿上。Gemini 3 Flash 以 11 倍低于 Claude Opus 4.5 的成本和 2 倍的速度取得了 19% 的通过率，堪称性价比之王；Claude Sonnet 4.5 在速度维度表现优异；GPT 5.2 则是成本效率的另一个选择；而 Claude Opus 4.5 虽然最昂贵且仅以微弱优势领先，但依然是追求最高通过率的唯一选择。

这一发现对实际应用具有直接指导意义。如果业务场景允许一定程度的容错，且埋点任务相对简单，选择 Gemini 3 Flash 这类轻量模型可能更具经济理性。但如果追求稳定性和准确率，愿意为 10 个百分点的提升支付 11 倍溢价，Claude Opus 4.5 仍是当前首选。值得注意的是，Gemini 3 Pro 在通用智能测试中表现亮眼，却在埋点任务中与 Flash 版持平甚至略逊，这说明通用推理能力与特定工程任务能力之间存在显著分野，不能简单地将通用测试成绩外推至专业领域。

AI SRE 的现状与未来展望

OTelBench 的结果与更广泛的行业观察形成呼应。研究团队将当前的 AI SRE 类比于 2015 年的 DevOps 异常检测：厂商宣传铺天盖地，独立验证却严重缺位。ClickHouse 近期发布的研究同样指出，LLM 虽能提供辅助，但在系统性可靠性工程能力上仍远逊于资深 SRE。市场上不乏 SaaS 厂商突然终止可观测性产品支持的案例，这提醒用户在选择 AI SRE 解决方案时需保持审慎。

然而并非全是悲观。部分困难任务（如 go-microservices-traces）的通过率达到了 55%，显示出在特定场景下 AI 的潜力。随着强化学习验证奖励（RLVR）等技术的成熟，模型有望在长周期任务上取得突破。多智能体系统或许是另一条路径 —— 将复杂的埋点任务分解为上下文理解、代码生成、验证反馈等多个子智能体协作完成，可能比单一模型更能应对工程挑战。

OTelBench 的真正价值，或许在于为行业提供了一面诚实的镜子。它拒绝跟随营销话术的泡沫，而是用数据说话：AI 可以辅助 SRE 工作，但距离真正「自主完成」还有相当距离。对于正在评估 AI SRE 工具的企业，这份基准测试提供了必要的预期校准 —— 如果连 300 行代码的简单埋点都难以保证，AI 更不适合被委以生产系统的关键故障处理。结论如作者所言：如果你需要跨服务的可靠分布式追踪，暂时还是得自己动手。

参考资料