MLflow 3.15：从实验跟踪到 Agent 可观测性的平台化演进

一个平台，两种历史包袱

MLflow 的 README 开篇就亮明身份：面向 agents、LLMs 与 ML models 的 AI 工程平台。这句话背后是一条漫长的演进线。它起家于实验跟踪与模型注册，是许多数据团队最早接触的 ML 工具之一。如今它把 LLM tracing、评估、prompt 管理、AI Gateway 全部塞进同一个屋檐下。这种扩张带来一个直接问题：新用户面对的是一个功能密度极高的系统，而不是某个单一工具。README 强调 60 万月下载量，但下载量不等于易用性。对于只想做模型实验跟踪的团队，MLflow 现在显得臃肿；对于想完整管理 LLM 应用的团队，它又未必够深。这个平台试图同时服务两类人，代价是学习曲线变陡。

tracing 的接入路径：从一行命令到 OpenTelemetry

README 给出的最快启动方式是 uvx mlflow@latest agent setup，声称一条命令安装 skills 并启动 coding agent 来为你的应用添加 tracing。这听起来很省事，但实际效果取决于你的代码结构。更传统的手动接入方式是三步：启动服务器、设置 tracking URI、调用 mlflow.openai.autolog()。这个 autolog 机制是 MLflow 的核心便利，它自动捕获 OpenAI 调用的输入输出与元数据，无需逐行埋点。但它的适用范围有限，README 明确说支持所有 LLM 提供商与 agent 框架，实际依赖 OpenTelemetry 的集成层。如果你的 provider 没有现成的 autolog 支持，就得手动创建 spans。另一个需要留意的点是，tracing 数据最终会写入 MLflow 的后端存储，默认是本地文件或 SQLite，生产环境需要配置独立的数据库与对象存储。README 没有给出这些配置细节，但这是任何自托管 tracing 系统都绕不开的运维成本。

评估：内置指标与自定义的边界

MLflow 的评估模块提供 50 多种内置指标和 LLM judges，也允许自定义。README 强调可以“catch regressions before they reach production”，这听起来很理想，但评估的有效性取决于你如何定义指标。内置指标覆盖了常见的准确性、相关性、毒性等维度，但 agent 应用的评估往往需要针对特定任务设计评判标准。比如一个多步工具调用的 agent，其成功标准不是单次回答的质量，而是任务完成率与工具调用序列的合理性。MLflow 允许自定义指标，但这需要你写代码，不是配置就能解决。另一个限制是评估与 tracing 的关联，README 提到可以跟踪质量指标随时间的变化，但具体如何将一次评估结果绑定到某条 trace 的某个节点，文档没有展开。对于需要细粒度归因的团队，这可能是一个需要自行摸索的坑。

AI Gateway：成本控制与供应商锁定的权衡

AI Gateway 是 MLflow 针对 LLM 成本与访问管理给出的答案。它提供一个 OpenAI 兼容的接口，统一路由到不同供应商，支持 rate limit、fallback、credential 管理、guardrails 和流量拆分。这个设计的直接好处是，你的应用代码可以只面向一个 API 风格，底层供应商可以随时切换。但代价是，你被绑定到 MLflow 的网关层。如果未来某个供应商推出了独特的功能，比如更细粒度的 token 用量或自定义推理参数，OpenAI 兼容接口可能无法透传。README 提到 traffic splitting 用于 A/B 测试，这很实用，但配置方式没有给出示例。另一个实际问题是，AI Gateway 本身是一个需要常驻的服务组件，它引入了额外的网络跳转与故障点。对于延迟敏感的应用，这种代理层的开销需要实测评估，README 没有提供任何性能数据。

传统 ML 功能的延续：实验跟踪与模型注册

在 LLM 功能之外，MLflow 仍然保留了完整的 ML 生命周期工具：实验跟踪、模型评估、模型注册与部署。这些是它的老本行，文档也相对成熟。对于同时做传统机器学习与 LLM 应用的团队，MLflow 提供了一个统一的后端与 UI，这是它相比纯 LLM 观测工具的核心优势。但要注意，部署功能支持 Docker、Kubernetes、Azure ML、SageMaker，这些是集成而非内置的。你仍然需要自己管理部署环境。模型注册表解决了模型版本与 stage 的管理，但它的权限模型是粗粒度的，README 没有提到细粒度访问控制。如果你的团队需要严格的模型审批流程，可能需要额外的外部流程来配合。

上手成本与运维现实

README 强调“no complex setup or major code changes required”，这个说法需要打折扣。对于已有的 Python 应用，加上 mlflow.openai.autolog() 确实改动很小。但如果你要部署到生产，需要规划后端存储、网络策略、UI 访问控制等。MLflow 是 Apache-2.0 许可，这意味着你可以自由使用、修改与商用，但如果你修改了代码并分发，需要保留版权声明。对于不想自己维护服务器的团队，README 没有提到任何官方托管服务，这意味着要么自托管，要么依赖第三方云服务。版本方面，最近发布了 v3.15.2 与 v3.15.1，更新频率较高，这既是活跃的证明，也意味着你需要关注升级带来的兼容性变化。特别是 tracing 与评估功能还在快速迭代，API 可能不稳定。

替代方案的差异：为什么不是 Langfuse 或 Weights & Biases

如果你只关心 LLM 应用的 tracing 与评估，Langfuse 是更专注的选择，它围绕 trace 的查询与评分做了深度的 UI 优化，而 MLflow 的 UI 更偏向实验管理。Weights & Biases 在实验跟踪方面更成熟，但它是商业产品，且对 LLM tracing 的支持不如 MLflow 的 OpenTelemetry 集成那么开放。MLflow 的核心差异在于它试图统一传统 ML 与 LLM 工作流，并且完全开源、可自托管。如果你的团队已经有 MLflow 部署，那么扩展使用它的 LLM 功能是自然的；如果从零开始，且只做 LLM 应用，那么一个更轻量的专用工具可能更容易上手。另一个值得注意的差异是，MLflow 的 AI Gateway 是内置的，而其他工具往往需要额外搭配 API 管理服务。

编辑结论

MLflow 适合已经使用 Python 进行模型训练，并希望在同一套系统里管理实验、模型注册与 LLM 应用观测的团队。它尤其适合那些需要从传统 ML 工作流平滑过渡到 Agent 或 LLM 应用的中小型团队，因为可以用 uvx mlflow server 一条命令启动，再用 mlflow.openai.autolog() 接入现有代码。不适合的场景包括：对数据主权有严格要求的私有化部署（虽然可以自托管，但需要自行维护服务器与存储）、需要深度定制网关逻辑的团队（AI Gateway 的 OpenAI 兼容接口是便利也是约束），以及尚未确定 LLM 供应商、希望完全避免供应商锁定的项目。采用前应重点验证三件事：一是 tracing 数据在 OpenTelemetry 与 MLflow 后端之间的完整链路是否符合你的审计需求，二是评估指标中内置的 50 余项是否覆盖你的业务场景，三是 AI Gateway 的流量拆分与 guardrails 功能是否满足你的 A/B 测试与安全策略。MLflow 的定位是平台而非框架，它不会替你决定 agent 如何编排，但能让你看清每一步发生了什么。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes