当人工智能在代码生成基准测试中不断刷新纪录时，一个更贴近生产现实的问题浮出水面：AI 能否真正理解并处理分布式系统中的可观测性问题？Quesma 团队发布的 OTelBench 基准测试提供了一个令人警醒的答案 —— 即使是最先进的 Claude Opus 4.5，在 OpenTelemetry instrumentation 任务中的通过率也仅有 29%。这一结果不仅揭示了当前 AI 模型在 SRE 领域的局限性，更为工程团队评估与改进 AI 辅助运维能力指明了方向。
从代码生成到生产调试的鸿沟
前沿大语言模型在编写函数、解决算法问题上的能力已经达到了令人惊叹的水平。SWE-Bench 等软件工程基准测试显示，AI 能够正确处理复杂的代码修改请求，完成代码库的 bug 修复和功能实现。然而，生成能够正确运行的代码与调试生产系统之间存在着本质的差异。生产环境中的 SRE 工作要求工程师不仅理解代码逻辑，更要理解业务上下文、用户行为模式以及服务间的调用关系。
OTelBench 基准测试的核心设计正是针对这一差异。测试任务聚焦于 OpenTelemetry instrumentation—— 为微服务添加分布式追踪能力。这是一个在现代云原生系统中至关重要的工程实践，要求工程师能够识别用户请求在整个服务链路中的传播路径，正确创建和传播 TraceID，确保分布式追踪数据能够准确还原完整的调用树形结构。这些任务对于资深 SRE 工程师而言属于日常工作的基础内容，但在 AI 模型眼中却构成了严峻挑战。
商业上下文理解的核心缺陷
OTelBench 测试揭示了一个深层次的 AI 能力缺陷：模型在处理 instrumentation 时表现出机械化的代码生成能力，却缺乏对业务上下文的理解。测试中的一个典型案例清晰地展示了这一问题。
测试场景包含一个搜索服务的两个用户操作：第一条路径是用户成功搜索并获取结果，第二条路径是使用无效令牌导致的 404 错误。从人类工程师的视角来看，这显然是两个独立的用户行为，应当产生两个独立的追踪链路。代码结构也明确地将这两个逻辑分支分开，每个分支代表一个独立的用户旅程。然而，AI 模型在处理时未能识别这种业务语义上的区分，而是将所有 HTTP 调用机械地链接在一起，导致两次用户操作被错误地合并为同一个追踪上下文。
这种失败模式的根源在于当前 AI 模型的工作机制。模型擅长识别代码模式和应用 API，却难以推断代码所服务的业务目的。用户旅程的识别不仅涉及技术层面的调用关系，更需要对业务逻辑的深层理解。成功通过测试的案例往往依赖于模型能够从代码注释或变量命名中提取足够的业务线索，而当这些线索缺失时，模型便无法区分不同的用户操作。
多语言支持的能力分化
OTelBench 测试覆盖了 11 种编程语言的 23 项任务，结果显示 AI 模型在不同语言环境下的表现存在显著差异。C++ 达到了 37% 的通过率，但这部分得益于该语言测试集中包含较为简单的任务。Go 语言作为云原生系统的核心编程语言，在 7 项任务中取得了 20% 的通过率，考虑到分布式系统中 Go 的广泛应用，这一结果具有重要的参考价值。
更值得关注的是能力边界的存在。Java、Ruby 和 Swift 三种语言在所有测试任务中的通过率均为零。部分失败源于构建系统的复杂性 —— 这些语言往往依赖特定的包管理器和构建工具链，AI 模型在处理依赖解析和构建配置时频繁遇到障碍。JavaScript、Python、PHP 和 .NET 则表现出中等水平的成功率，反映出这些语言在训练数据中的高频出现为模型提供了更丰富的知识储备。
Rust 语言仅有一项任务被单个模型成功解决，这暗示着 AI 在处理现代系统编程语言的独特范式时存在困难。语言能力的分化直接关系到 AI 辅助 SRE 在实际生产环境中的可用性，因为真实的分布式系统往往是多语言技术栈的组合。任何单一服务的追踪链路断裂都会导致整体可观测性的丧失，这意味着 AI 必须在所有目标语言上都具备可靠的工作能力。
通过率与资源效率的帕累托前沿
在工程实践中，模型的选择不仅取决于绝对性能，还需要综合考虑成本和延迟因素。OTelBench 的成本效率分析揭示了一个有趣的现象：在当前的前沿模型中，只有四个模型位于帕累托前沿上。
Gemini 3 Flash 以 19% 的通过率成为成本效率的最优选择，其运营成本仅为 Claude Opus 4.5 的十一分之一，平均响应时间也仅需后者的二分之一。对于对成本敏感且可以接受较低成功率的场景，Gemini 3 Flash 提供了极具吸引力的性价比。Claude Sonnet 4.5 则以 22% 的通过率和更快的响应速度占据了速度优先的位置。GPT 5.2 在成本效率维度上紧随其后，达到 26% 的通过率。Claude Opus 4.5 尽管拥有最高的 29% 通过率，但作为唯一同时位于成本和速度前沿的模型，其代价也最为高昂。
这一分析为工程团队提供了务实的决策框架。在构建 AI 辅助 SRE 系统时，团队需要根据自身的可靠性要求和预算约束，在这些选项之间做出权衡。对于非关键的辅助任务，选用成本效率更优的模型可能更为合理；而对于核心的可观测性工作，则可能需要投资于更高成功率的顶级模型。
静默失败与测试验证的必要性
OTelBench 测试方法论中的一个关键设计值得特别关注：测试不仅验证代码是否能够成功编译，更深入检查生成的追踪数据是否符合语义规范。具体而言，测试验证了 span 名称的正确性、父级子级关系的准确性、TraceID 的有效性以及上下文传播的正确实现。
这一验证层次揭示了一个危险的静默失败模式。许多模型生成的代码能够顺利通过编译，甚至在表面上看起来完成了 instrumentation 工作，但实际产生的追踪数据却是畸形的。这种情况比编译失败更加危险，因为表面上的成功会误导工程师信任 AI 生成的代码，而实际上可观测性系统接收到的数据可能是毫无意义的。
这一发现对 AI 辅助 SRE 的工程实践具有重要启示。任何 AI 生成的 instrumentation 代码都必须经过严格的验证流程，包括但不限于功能测试、追踪数据验证以及端到端的链路测试。单纯依赖代码审查或编译通过作为质量标准是不够的，必须建立专门针对可观测性数据的测试断言。
工程改进路径与未来展望
当前 AI 在 SRE 任务上的表现虽然不尽如人意，但并非无法改进。OTelBench 的结果显示，部分困难任务（如 go-microservices-traces）的通过率达到了 55%，表明通过针对性的优化，某些障碍是可以克服的。
强化学习与可验证奖励（RLVR）被认为是极具潜力的改进方向。在 instrumentation 任务中，成功与否可以通过自动化的追踪验证来判定，这为构建奖励模型提供了清晰的信号。通过在大量类似任务上进行 RL 训练，模型有望学会将业务上下文与代码实现正确关联，而不仅仅是在技术层面机械地应用 API。
多智能体系统也是值得探索的改进路径。不同智能体可以分别负责业务逻辑分析、API 选择与代码生成、结果验证等子任务，通过协作来弥补单一模型在长程推理和多维度理解上的不足。这种分工也与人类 SRE 团队的工作方式更加接近。
对于当前的工程团队而言，OTelBench 结果提供了务实的指导。首先，在评估 AI 辅助 SRE 工具时，应使用 OTelBench 或类似的真实 SRE 基准进行测试，而非仅依赖软件工程基准的结果。其次，应建立严格的 AI 输出验证流程，确保 instrumentation 代码产生符合预期的追踪数据。最后，应根据任务类型和可靠性要求选择合适的模型，在关键路径上使用高性能模型，在辅助任务上考虑成本效率更优的选项。
分布式追踪是现代云原生系统的可观测性基石，而 OpenTelemetry 已成为这一领域的事实标准。OTelBench 基准测试清晰地表明，在这一关键工程领域，当前的前沿 AI 仍处于发展的早期阶段。对于工程团队而言，这意味着在短期内，依赖人工编写关键的 instrumentation 代码仍然是确保系统可观测性的稳妥选择。但随着基准测试的持续演进和模型能力的逐步提升，AI 辅助 SRE 的成熟终将到来。
资料来源：Quesma 团队发布的 OTelBench 基准测试（https://quesma.com/blog/introducing-otel-bench/），测试覆盖 14 款前沿大语言模型在 11 种编程语言上的 OpenTelemetry instrumentation 能力。