您的智能体已发出开放遥测数据。您为何不对其进行监控？

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

太长不看版：Spring AI、LangChain4j、Koog（Kotlin）、Python 的 OpenLLMetry 风格插桩工具以及 Go 语言的开放遥测软件开发工具包现在都原生发出 gen_ai.* 跨度。因此，你无需使用供应商提供的软件开发工具包即可实现智能体的可观测性——你只需要一个知道如何处理你的框架已通过网络发送的跨度的开放遥测协议端点。以下是通过三行 YAML 配置或一个 Kotlin 扩展函数实现的效果。

你团队中的某人在两个月前部署了一个大语言模型智能体。今天，它在二十分钟内产生了 400 美元的费用，向真实客户编造了退款政策，并陷入了工具调用循环，在速率限制器介入之前，同一项损坏的 payments.create 调用被重试了十七次。

你希望知道这些事件中哪一件最先发生，哪个智能体应负责任（你现在已有四个），用户输入了什么内容，以及规划器为何认为调用支付应用程序接口是对“如何取消订阅”这一问题的合理响应。

如果你像观察其他服务一样观察你的智能体，你或许只能回答其中两个问题，而且还需要在与编写提示词的工程师进行漫长的 Slack 线程讨论之后才能得知。名为 POST /chat 的追踪跨度对你没有帮助。/v1/agent/run 的百分之九十九延迟指标也无济于事。

本文旨在探讨这种差距存在的原因、它为何即将消失，以及你今天可以采取的措施。

智能体可观测性差距

现有的两种方法勉强可行，但大多情况下无效：

通用应用性能监控工具（如 Datadog、New Relic、默认配置的 Honeycomb）将你的智能体视为任何其他超文本传输协议服务。你能获得延迟直方图、错误率和顶层跨度。但你无法获取提示词、模型、令牌计数、工具调用或成本信息。这些信号被淹没在“请求正文”中，或者根本未被捕获。

供应商提供的大语言模型可观测性软件开发工具包（如 Langfuse、Helicone、Phoenix 以及各种专有工具）能捕获所有正确的信号，但作为沉重的软件开发工具包附加到你的服务上。每次框架升级都变成了协调问题。每次切换后端都需要重写代码。而且，你的技术栈使用的框架越多（例如使用 Spring AI 作为编排器，使用 LangChain4j 作为检索增强生成服务，使用 Koog 进行某个 Kotlin 试点项目），你需要携带的软件开发工具包就越多。

这两种方式都不够理想。理想的方式是：你的框架发出标准信号，你的后端理解标准信号，你无需更改任何应用程序代码。

直到最近，这还不可能实现。开放遥测社区一年来一直在制定 gen_ai.* 语义约定，但框架支持参差不齐，且约定不断变化。

这种情况在过去六个月中发生了改变。具体而言：

• Spring AI 1.0 通过 Micrometer 观测功能发出 gen_ai.client.chat、gen_ai.tool.execute 等信号。
• LangChain4j 通过其 ChatModelListener 应用程序接口发出相同的信号。
• Koog 0.8 提供了一流的开放遥测功能，包括 addDatadogExporter、addLangfuseExporter、addWeaveExporter。
• Python 的 OpenLLMetry / OpenInference 插桩工具（适用于 Anthropic、OpenAI、LangChain、LlamaIndex）发出相同的约定，并通过标准开放遥测导出器流式传输。
• Go 语言的 otel-instrumentation-genai 处于阿尔法阶段，具有相同的形态。

换句话说：无论你的团队选择了哪种框架，信号都以标准形式在网络上传输。 缺失的是一个能对其执行有用操作的后端。

四行代码的 Spring AI 版本