AI Agent Observability - Evolving Standards and Best Practices

作者：Guangya Liu (IBM)，Sujay Solomon (Google) |

2025：AI 代理年

AI 代理正成为 2025 年人工智能领域的下一个重大飞跃。从自主工作流到智能决策，AI 代理将在各行各业驱动众多应用。然而，随着这种演进，特别是将这些代理扩展到满足企业需求时，对 AI 代理可观测性的迫切需求也随之而来。如果没有适当的监控、追踪和日志记录机制，诊断问题、提高效率和确保 AI 代理驱动应用程序的可靠性将充满挑战。

什么是 AI 代理

AI 代理是一种应用程序，它结合了 LLM 能力、连接外部世界的工具以及高级推理来达到期望的最终目标或状态；或者，也可以将代理视为一种系统，其中 LLM 动态地指导自己的进程和工具使用，并控制其完成任务的方式。

Sample RAG based application w/ReAct reasoning/planning 图片来源：Google AI Agent 白皮书。

有关 AI 代理的更多信息，请参阅

可观测性及其他

通常，应用程序的遥测数据用于监控和故障排除。对于 AI 代理而言，鉴于其非确定性，遥测数据也可用作反馈循环，通过将其用作评估工具的输入来不断学习和改进代理的质量。

鉴于 GenAI 的可观测性和评估工具来自不同的供应商，因此建立围绕代理应用程序生成的遥测数据形状的标准非常重要，以避免因供应商或框架特定格式造成的锁定。

AI 代理可观测性的现状

随着 AI 代理生态系统的不断成熟，标准化和强大的可观测性的需求变得更加明显。虽然一些框架提供了内置插桩，但其他框架则依赖于与可观测性工具的集成。这种碎片化的格局凸显了 GenAI 可观测性项目和 OpenTelemetry 新兴语义约定的重要性，这些约定旨在统一遥测数据的收集和报告方式。

理解 AI 代理应用与 AI 代理框架

区分“AI 代理应用”和“AI 代理框架”至关重要。

AI agent application vs AI agent framework

建立标准化的语义约定

如今，OpenTelemetry 内的 GenAI 可观测性项目 正在积极定义语义约定，以标准化 AI 代理可观测性。这项工作主要由以下内容驱动：

  • 代理应用语义约定 – 作为 OpenTelemetry 语义约定存储库 中讨论的一部分，已建立并最终确定了 AI 代理应用语义约定的草案。最初的 AI 代理语义约定基于 Google 的 AI 代理白皮书，为定义可观测性标准提供了基础框架。未来，我们将继续完善和增强此初步约定，使其更加健壮和全面。
  • 代理框架语义约定 – 现在，重点已转移到为所有 AI 代理框架定义通用语义约定。这项工作正在 此 OpenTelemetry issue 中讨论，旨在为 IBM Bee Stack、IBM wxFlow、CrewAI、AutoGen、LangGraph 等框架建立标准化方法。此外，不同的 AI 代理框架将能够在遵守通用标准的同时定义自己的框架供应商特定语义约定。

通过建立这些约定，我们确保 AI 代理框架可以报告标准化的指标、追踪和日志，从而更容易集成可观测性解决方案并比较不同框架之间的性能。

注意：OpenTelemetry 中已为模型提供实验性约定，位于 GenAI 语义约定。

插桩方法

为了使系统可观测，必须对其进行插桩：也就是说，系统组件中的代码必须发出追踪、指标和日志。

不同的 AI 代理框架在实现可观测性方面有不同的方法，主要分为两个选项：

选项 1：内置插桩

第一个选项是实现内置插桩，该插桩使用 OpenTelemetry 语义约定发出遥测数据。这意味着可观测性是一项原生功能，允许用户无缝跟踪代理性能、任务执行和资源利用率。一些 AI 代理框架（如 CrewAI）遵循此模式。

作为代理框架的开发者，以下是此内置插桩的一些优缺点：

  • 优点
    • 可以承担维护插桩以保持遥测数据最新的开销。
    • 简化了不熟悉 OpenTelemetry 配置的用户的采用。
    • 可以在发布日为新功能提供插桩，同时将其保密。
  • 缺点
    • 对于不需要可观测性功能的用户来说，会增加框架的冗余。
    • 如果框架的 OpenTelemetry 依赖项落后于上游更新，则存在版本锁定风险。
    • 对于更喜欢自定义插桩的高级用户来说，灵活性较低。
    • 您可能无法获得熟悉当前语义约定的 OTel 贡献者的反馈/审查。
    • 您的插桩可能在最佳实践/约定方面滞后（不仅仅是 OTel 库依赖项的版本）。
  • 如果您考虑此方法，请遵循一些最佳实践：
    • 提供一个配置设置，允许用户轻松启用或禁用来自框架内置插桩的遥测收集。
    • 提前规划用户想要使用其他外部插桩包的需求，并避免冲突。
    • 如果选择此路径，请考虑在 OpenTelemetry 注册表中列出您的代理框架。
  • 作为代理应用的开发者，如果您希望选择一个带有内置插桩的代理框架，则可能意味着：
    • 对代理应用代码中的外部包的依赖性最小。
    • 开箱即用的可观测性，无需手动设置。

选项 2：通过 OpenTelemetry 进行插桩

此选项是在一些 GitHub 存储库中发布 OpenTelemetry 插桩库。这些插桩库可以导入到代理中，并根据 OpenTelemetry 语义约定配置为发出遥测数据。

发布 OpenTelemetry 插桩有两种选项：

这两种选项都很好，但长期目标是将代码托管在 OpenTelemetry 拥有的存储库中，就像 Traceloop 正在尝试将插桩代码捐赠给 OpenTelemetry 一样。

作为代理框架的开发者，以下是使用 OpenTelemetry 插桩的一些优缺点：

  • 优点
    • 将可观测性与核心框架解耦，减少冗余。
    • 利用 OpenTelemetry 的社区驱动维护来更新插桩。
    • 允许用户根据其特定需求（例如，云提供商、LLM 供应商）混合搭配 contrib 库。
    • 更有可能利用有关语义约定和零代码插桩的最佳实践。
  • 缺点
    • 如果用户依赖不兼容或过时的 contrib 包（用于安装和运行时），则存在碎片化风险。
    • 当 OpenTelemetry 审查队列中有过多的 PR 时，开发速度会变慢。
  • 此方法的最佳实践
    • 确保与流行的 OpenTelemetry contrib 库（例如，LLM 供应商、向量数据库）兼容。
    • 提供关于推荐的 contrib 包和配置示例的清晰文档。
    • 避免重复造轮子；遵循现有的 OpenTelemetry 标准。
  • 作为代理应用的开发者，如果您希望选择一个带有内置插桩的代理框架，则可能意味着：
    • 您需要对遥测源和目标进行细粒度的控制。
    • 您的用例需要将可观测性与利基或自定义工具集成。

注意：无论采用哪种方法，所有 AI 代理框架都必须采用 AI 代理框架语义约定，以确保可观测性数据具有互操作性和一致性。

AI 代理可观测性的未来

展望未来，AI 代理可观测性将继续发展，涵盖：

  • 更强大的语义约定，以涵盖边缘情况和新兴的 AI 代理框架。
  • 统一的 AI 代理框架语义约定，以确保不同框架之间的互操作性，同时允许供应商特定扩展的灵活性。
  • 对 AI 代理语义约定的持续改进，以完善初步标准并应对 AI 代理不断发展带来的新挑战。
  • 改进的 AI 代理监控、调试和优化工具。
  • 与 AI 模型可观测性更紧密的集成，以提供对 AI 驱动应用程序的端到端可见性。

OpenTelemetry GenAI SIG 的作用

OpenTelemetry 的 GenAI 特别兴趣小组 (SIG) 正在积极定义 GenAI 语义约定，涵盖关键领域，例如：

  • LLM 或模型语义约定
  • VectorDB 语义约定
  • AI 代理语义约定（是更广泛的 GenAI 语义约定中的关键组成部分）

除了约定之外，SIG 还扩大了其范围，为 Python 和其他语言中的代理和模型提供插桩覆盖。随着 AI 代理变得越来越复杂，可观测性将在确保其可靠性、效率和可信度方面发挥基础性作用。建立 AI 代理可观测性的标准化方法需要协作，我们欢迎更广泛的 AI 社区的贡献。

我们期待与不同的 AI 代理框架社区合作，共同制定最佳实践并完善这些标准。您的见解和贡献将有助于塑造 AI 可观测性的未来，促进一个更透明、更有效的 AI 生态系统。

不要错过这个机会，帮助塑造 GenAI 可观测性行业标准的未来！加入我们的 CNCF Slack #otel-genai-instrumentation 频道，或参加 GenAI SIG 会议。

最后修改于 2025 年 3 月 13 日：blog: fix slack channel name up-to-date (#6531) (08d392d8)