文章测试了14个AI模型在微服务系统中使用OpenTelemetry标准添加分布式追踪的能力，结果显示即使表现最好的Claude 4.5 Opus模型成功率也仅29%，所有模型在此任务上表现均不理想。作者开源了OTelBench基准测试工具供社区使用。

基准测试OpenTelemetry：AI能否追踪你的登录失败？

前沿AI模型在分布式追踪中的表现

尽管前沿AI模型在编写代码方面表现出色，但在调试生产系统时仍面临挑战。为了验证这一点，我们对14个主流AI模型进行了测试，评估它们在现有代码库中添加分布式追踪（使用行业标准OpenTelemetry工具）的能力。测试任务模拟了站点可靠性工程师（SRE）的日常工作场景。

测试结果

• 整体表现：表现最佳的Claude 4.5 Opus模型通过率仅为29%，GPT 5.2以26%紧随其后。令人意外的是，Gemini 3 Pro并未显著优于更轻量的Gemini 3 Flash（19%）。
• 开源基准：我们发布了OTelBench作为开源测试框架，包含11种编程语言的23项任务，支持通过Harbor框架复现结果或扩展新测试。

分布式追踪的背景

在微服务架构中，单个用户请求可能涉及数十个服务，传统日志追踪变得低效。分布式追踪通过以下步骤解决该问题： 1. 创建追踪：为每个请求生成唯一标识（TraceID）。 2. 传递上下文：在服务间调用时保持TraceID一致。 3. 数据可视化：将追踪数据发送至后端分析平台。

OpenTelemetry作为行业标准，提供了统一的语义规范、多语言SDK和自动化工具，但其复杂性仍令39%的开发者感到困扰（2025年可观测性调查报告）。

测试设计

• 任务类型：要求模型为模拟真实场景的微服务（约300行代码）添加追踪功能，需满足OpenTelemetry规范。
• 失败案例：例如，模型未能区分用户成功搜索和无效令牌请求两个独立事件，导致错误合并为单一追踪链路。

关键发现

1. 语言差异：C++任务通过率最高（37%），而Java、Ruby和Swift任务全军覆没。
2. 成本效率：Gemini 3 Flash以19%通过率成为性价比最优选，成本仅为Claude Opus 4.5的1/11。
3. 隐性缺陷：部分解决方案虽能编译，但生成错误格式的追踪数据或混淆业务上下文。

AI的挑战

• 长周期任务：需要模型保持对复杂上下文的连贯理解。
• 多语言环境：需掌握不同语言的构建工具（如CMake、Go模块系统）。
• 数据稀缺：企业级应用代码通常闭源，导致训练样本不足。

结论与展望

当前AI模型尚无法替代人类SRE，但部分任务（如Go微服务追踪）已展现55%的潜力。行业需要建立类似SWE-Bench的标准化测试，以推动AI在分布式系统领域的进步。

最终建议：如需跨服务追踪功能，暂时仍需手动编码实现。

（完整数据与讨论参见OTelBench官网或参与Hacker News交流）

评论主要围绕AI在SRE（站点可靠性工程）任务中的表现展开，观点可分为以下几类：

1. 质疑AI能力

   • 认为AI缺乏分布式调试经验，难以处理复杂问题
     引用：
     "there’s not a lot of high quality training for distributed debugging" (whynotminot)
     "AI excels at individual coding patterns but struggles with holistic understanding" (asyncadventure)

2. 测试方法问题

   • 指出测试指令模糊，基准设计不合理
     引用：
     "instruction.md is very brief, quite vague" (NitpickLawyer)
     "the prompts for this are pretty sparse" (linuxftw)

3. 人类同样困难

   • 强调OpenTelemetry本身复杂，人类专家也面临挑战
     引用：
     "I’m a human with 20+ years of experience and making OTEL work on Go was painful" (yomismoaqui)
     "Our humans struggle with them too" (dgxyz)

4. 乐观预期

   • 相信随着技术发展AI会进步
     引用：
     "I wouldn’t expect this wall to hold up for too long" (whynotminot)
     "The key is LLMs can assist" (benatkin)

5. 微服务架构批评

   • 认为问题根源在于微服务设计
     引用：
     "this is just another reason not to use microservices" (rapsacnz)
     "It’s painful for humans to debug" (AnotherGoodName)

6. 成功案例

   • 分享AI辅助成功的实践经验
     引用：
     "I’ve been incredibly impressed with the ability for frontier models" (jcims)
     "It took me like a day to implement tracing" (derfurth)

主要争议点：29%成功率是否准确反映了AI能力，以及测试设计是否合理。多数评论认为OpenTelemetry任务本身复杂度高，当前测试方法有待改进，但AI作为辅助工具已显现价值。