MLflow Blog

Multi-Harness AI Agents Need Multi-Layer Observability: Omnigent in MLflow

8.5内容质量
Multi-Harness AI Agents Need Multi-Layer Observability: Omnigent in MLflow

TL;DR · AI 摘要

Omnigent通过统一接口和MLflow Tracing解决多框架AI代理的可观测性问题，提升调试与审计效率。

核心要点

  • Omnigent支持 Claude Code、Codex、Pi 等多工具协同，减少人工复制粘贴
  • MLflow Tracing 可自动采集 6 类关键指标（token数/耗时/工具调用等）
  • 安装命令：uv tool install omnigent mlflow

结构提纲

按章节快速跳转。

  1. §引言

    揭示多框架AI代理在生产环境面临的可观测性挑战

  2. ·可见性差距

    失败时需追踪6个关键问题却因框架差异难以实现

  3. ·统一接口方案

    Omnigent通过标准化接口整合不同框架的代理流程

  4. ›技术实现

    与MLflow Tracing集成实现自动追踪无需代码修改

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • 多框架AI代理可观测性解决方案
    • 问题
      • 框架差异导致可观测性黑洞
    • 解决方案
      • Omnigent统一接口
      • MLflow Tracing自动追踪
    • 技术指标
      • 支持6种代理框架
      • 采集6类监控指标

金句 / Highlights

值得收藏与分享的关键句。

#MLflow#Omnigent#AI代理#可观测性
打开原文

多框架AI代理需要多层次可观测性：MLflow中的Omnigent | MLflow

多框架AI代理需要多层次可观测性：MLflow中的Omnigent

2026年7月2日

·

6分钟阅读

Khalil Kafrouni

Databricks公司MLflow GTM负责人

AI代理的价值主张在于自主性：给代理一个目标，让它自行发现实现路径。然而，在实际环境中让它们运行的现实情况却要复杂得多。不同团队选择不同框架。最初基于Codex的流程现在有了新需求，Claude Code实现起来更便捷；Pi以其他工具无法实现的方式完成特定任务。你可能会在Cursor中开始规划阶段，在Claude code中构建，在Pi中编写测试，最后由Codex审查代码。所有这些都需要在不同框架之间反复复制粘贴提示和输出。最终生产环境会使用多个框架的代理，每个框架都有自己的惯例、日志输出和盲区。这就是多框架问题。这不仅是工程问题：它会在AI系统中制造巨大的可观测性漏洞，使调试更困难、审计更复杂、信任更难建立。

可观测性差距

每当代理失败时，需要回答一系列问题：用户请求了什么？模型做了什么？它决定使用哪些工具？传递了哪些参数？每一步消耗了多少token（以及多少时间）？这些步骤中是否有不必要的步骤？

即使对于单框架代理，这个问题本身就已经足够复杂。当涉及多个框架时，情况很容易变得一团糟，每个代理以不同结构生成不同数据。拼凑这些信息成为一项艰巨任务，这也是大多数团队选择放弃可观测性的原因。但好消息是，这个问题最近已经被解决了。

一个API，多个框架

Omnigent最近发布后迅速在开发者中流行起来，不到一个月就获得了6000个GitHub星标。其核心理念是统一不同框架的接口。它允许你协调不同代理框架，每个框架启动后执行各自擅长的任务。你可以让Claude Code编写代码，由Codex进行审查；可以用Cursor制定编码计划，用Pi以极简方式执行，最重要的是，所有操作都可以通过单一界面完成。

这种统一至关重要，不仅对开发有意义，对可观测性同样关键。现在所有代理都通过单一层面流动，所有追踪信息都标准化，可以顺畅地传递给可观测性层而无需混乱。这正是Omnigent通过MLflow Tracing实现的。

无需代码修改的自动追踪

该集成无缝衔接。Omnigent作为可选依赖项与MLflow一起提供。安装方法如下：

code
uv tool install omnigent mlflow

然后指向正在运行的MLflow追踪服务器并设置环境变量：

code
export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:5000"  # 或你的MLflow服务器运行地址
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
export OTEL_EXPORTER_OTLP_TRACES_HEADERS="x-mlflow-experiment-id=0"  # 你的实验ID
export OMNIGENT_TELEMETRY_ENABLED="true"
export OMNIGENT_OTEL_HTTP_CLIENT_INSTRUMENTATION="false"
export OMNIGENT_OTEL_CAPTURE_CONTENT="true"

然后，运行 omnigent run 即可开始。所有内容会自动完成配置。通过此设置，在 MLflow 中你可以获得：

  • 代理回合，包括提示和响应
  • 工具调用及其参数、结果和耗时
  • 每回合的令牌消耗情况
  • 会话元数据（模型名称、代理名称等）

你可以用它做什么

现在进入最令人兴奋的部分：这里展示了未来可能实现的广阔天地。随着所有代理工具链都被追踪，你不再需要盲目猜测。不再依赖个人判断来评估工作流程变更是否有效，现在你可以实际进行测量。

举个例子，当一个新推出的廉价开源模型发布时，你想要分析其性能是否足够好，可以替代你在所有工具链中使用的昂贵大语言模型。你只需在 Omnigent 中切换模型，然后在 MLflow 中对追踪数据进行前后对比分析。你不仅能确定哪个模型在绝对性能上更优，还可以分析不同大语言模型下哪些工具链和工具调用表现最佳。

就像数据分析通过让企业发现隐藏机会并削减不必要的成本而彻底改变了市场，AI 可观测性对原生 AI 业务也产生了同样的影响。例如，如果你使用 MCP 服务器来启用代理执行特定操作，现在你可以对不同供应商进行 A/B 测试，并分析哪家供应商性价比最高。

此外，它还能帮助你成为更优秀的工程师，通过回答以下关键问题：

  • 随着时间推移，你投入了多少工作量在构建新功能上，而不是修复漏洞？
  • 这些漏洞是否存在共同点？
  • 哪些类型的请求让代理花费了大量时间完成？
  • 哪个工具链最适合规划、分析代码库或执行任务？

回答这些问题能让你在更快交付、更高质量和更低成本方面占据优势。

缩小差距

多工具协调器将长期存在。开发人员和团队会持续寻找最适合完成任务的最佳工具，而每个任务都可能有其他工具表现更优。解决方案不是将所有工作强制纳入单一框架，而是协调和整合这些工具。这需要一个可观测性层来监控所有内容并发现机会与低效之处。Omnigent 的 MLflow 集成就是这个"眼睛"，虽然只是架构上的小幅调整，却能显著改变你和团队的时间投入方向。

开始使用：Omnigent 的 MLflow 追踪

有问题或反馈？通过提交 Issue留言或加入MLflow 社区讨论。

⭐ 在 GitHub 上给我们加星标，支持这个项目！