对三个代码库的审查发现，仅仅安装 OpenTelemetry (OTel) 并不能为 AI 辅助编程智能体 (AI-assisted coding agents) 闭合反馈回路。如果没有一个有效的回路，遥测数据 (telemetry) 就无法帮助智能体决定修改什么，开发者也会在添加一个永远无法与模型交互的工具上浪费时间。

为什么“可观测性优先”的思维方式行不通

许多团队将可观测性视为一个“勾选项”：引入一个追踪库，启用一个仪表板，然后就万事大吉了。现实情况是一个三步走的阶梯：

  1. 存在一种可观测性机制。
  2. 系统确实产生了遥测数据。
  3. AI 智能体可以消费这些遥测数据以做出决策。

大多数项目都卡在第 1 步。如果应用程序从未调用某个经过完美插桩 (instrumented) 的中间件，它就会处于闲置状态，产生零数据。扫描源码的 AI 智能体看到了追踪代码，并假设系统是可观测的，结果却发现运行时数据一片空白。“拥有工具”与“拥有回路”之间的差距，正是努力付诸东流的地方。

可用数据的六个条件

要将原始 trace 转化为 AI 编程智能体的可操作输入，遥测数据必须满足六个实际条件：

  • 标准化 (Standardization)。 使用一致的属性名称和类型，以便智能体无需定制映射即可解析数据。
  • 传播 (Propagation)。 在所有服务和语言边界之间携带单一的 trace 标识符，允许智能体重建端到端的执行过程。
  • 可发现性 (Discoverability)。 通过代码级钩子 (hooks) 或简单的 CLI 命令暴露数据，以便模型无需手动挖掘即可定位数据。
  • 可控性 (Controllability)。 允许智能体按时间范围或结果数量限制查询，防止其被无关的 span 淹没。
  • 可访问性 (Accessibility)。 确保数据在智能体运行的同一会话中是可读的，理想情况下来自本地文件或 stdout 流。
  • 可比性 (Comparability)。 提供一种在相同条件下获取“修改前”和“修改后”快照的方法，以便智能体衡量变更的影响。

当这些支柱中的任何一个缺失时，反馈回路就会断裂，AI 智能体只能靠猜测。

开发阶段，本地流水线优于云端

生产环境依赖于基于云端的遥测收集器、聚合服务和仪表板。这些流水线对于大规模监控至关重要，但它们会带来以分钟计的延迟。一个需要等待数分钟才能获取数据的 AI 智能体，无法参与到需要在数秒内做出决策的开发回路中。

一个实际的替代方案是本地遥测流水线 (local telemetry pipeline)：

  • 将遥测数据写入本地文件或 stdout。 OTel 支持将 JSON 或纯文本 span 直接导出到开发者的工作区。
  • 通过简单工具暴露数据。 一个极简的 HTTP 服务器、命令行查询接口或轻量级 SQL 封装器，都可以根据需求向智能体提供 trace。
  • 让智能体读取原始输出。 JSON 或 Markdown 表示形式非常便于语言模型在同一个编辑会话中进行解析和比较。

从大规模的自动插桩开始只会增加噪音。请选择一个单一且关键的执行路径——例如请求处理例程或构建步骤——并对其进行端到端插桩。完成整个链路：生成 (Generate) → 传播 (Propagate) → 存储 (Store) → 查询 (Query) → 比较 (Compare)。一旦该回路运转起来，再逐步扩展。

团队接下来应该做什么

  1. 识别最有价值的流程。 选择一段变更会对性能或正确性产生可衡量影响的代码。
  2. 使用 OTel 对该流程进行插桩。 使用特定语言的 API 创建 span，附加标准化属性，并传播 trace 上下文。
  3. 本地导出。 配置导出器将 JSON 行写入项目目录中的文件，或打印到控制台。
  4. 提供查询接口。 一个通过 trace ID 和时间窗口过滤文件的微型脚本，就足以让智能体检索到正确的数据片段。
  5. 将数据喂给 AI 智能体。 向模型提供“修改前”的 trace 并要求进行修改，然后运行更新后的代码，并收集“修改后”的 trace 进行比较。
  6. 迭代。 每一次成功的回路都会验证这六个条件，并扩大可观测的范围。

总结

OpenTelemetry 为你的代码提供了一种通用的链路追踪语言，但只有当数据满足六个具体条件，并能在紧凑的本地反馈循环中获取时，这种语言才会发挥作用。从小处着手：对单个流程进行插桩，将其导出到文件，然后让 AI 智能体在原位读取并对比这些链路追踪数据。这就是从“我拥有可观测性”迈向“我的 AI 助手能真正优化我的代码”的务实路径。