你正在运行一个多智能体应用程序，其中各个智能体承担不同任务并相互传递信息。突然出错了：也许你的用户得到了错误的答案，或者根本没有得到任何回答。于是你做了往常会做的事——打开监控仪表板。一切看起来都正常：HTTP 请求、错误率、响应时间，你可能会看到类似这样的数据。我们将这个智能体命名为“首席执行官（CEO）智能体”。
它显示状态为 200 OK，耗时 2.3 秒。但你的用户却得到了错误的答案。因此，仅仅知道这里发生了一次请求是不够的。在多智能体系统中，你需要能够看到你的智能体是否调用了错误的工具，或者某个 MCP 服务器返回了空数据，以及许多其他在这个 AI 时代新出现的问题。例如：我发出的五次 LLM（大语言模型）调用中，是否有三次在无人查看数月之久的提示词上浪费了令牌？因此，今天我们将超越请求级别的监控，进入真正的 LLM 可观测性领域。
为了做到这一点，我们将使用 MLflow。MLflow 是一个与开放遥测（OpenTelemetry）兼容的平台，它捕获用户发送请求后发生的每个步骤中的输入、输出和元数据。在本视频结束时，你将了解追踪（Tracing）的工作原理，如何使用 LLM 裁判评估智能体质量。最后，我将分享一些将演示项目与生产级部署区分开来的配置选择。让我们通过一个例子来具体说明：你构建了一个抵押贷款申请应用程序，用户可以就他们的需求进行聊天，系统会告诉他们符合资格的贷款类型。
在后台，这是一个 FastAPI 应用，路由到五个具有不同人设的智能体：一个探矿者（Prospector）、借款人、贷款官员、核保人员，以及用于内部分析的首席执行官助手。这些智能体可以调用不同的工具，如数据库、LLM 和 MCP 服务器，而这一切都发生在用户收到响应之前。让我们谈谈这里隐藏在我们试图捕捉的空白中的问题：首先是静默的工具故障，即 MCP 工具返回空数据，但智能体仍继续进行并自信地基于不完整的信息作答。
其次是级联延迟：缓慢的数据库查询导致 LLM 调用延迟，进而延迟了响应，而你无法确定链条中的哪个环节是瓶颈。第三是上下文溢出：智能体将太多内容塞入提示词中，调用因 cryptic 错误而失败，用户看到的只是一个通用的超时信息。最后也是最重要的一点是非确定性：同一个问题每次运行产生的结果不同，因此 bug 不会在你的笔记本电脑上重现。非确定性意味着没有质量基线，无法证明你的智能体给出了一致且准确的答案。
在像贷款这样受监管的领域，这是一个合规性问题。MLflow 的核心可观测性原语是追踪（Trace）。追踪是对一次请求的完整记录。现在，这个追踪由单独的跨度（Spans）组成。这些跨度是一个单一的 LLM 调用、一次工具调用或一个数据库查询，它们被组织成父子树结构，显示了谁调用了什么、输入是什么、输出是什么以及每个步骤耗时多久。此外，你还能获得令牌计数、每步延迟、工具参数、提示词与补全对以及数据库结果。
你可以为这些追踪标记单个用户和会话 ID，以便调出个别用户的会话并重播智能体的决策路径。但在你到达那一步之前，在 AI 开发的内部循环中，你可以在笔记本中进行工作，允许你在实际让用户接触系统之前调整提示词、运行评估等，以获得快速反馈。到目前为止，我们讨论了 MLflow 的确定性分数：有些是正则表达式检查、精确匹配或延迟阈值，但在非确定性时代的另一个现代评估框架是使用 LLM 作为裁判的评分。
现在你可以使用第二个模型（通过 MLflow）根据定义的标准对智能体的输出进行评分。这些标准可以是工具调用的正确性：智能体是否为问题选择了正确的工具？调用效率：智能体是以最少的步骤或调用来达成目标，还是漫无目的地徘徊？相关性：响应是否真正解决了用户提出的问题？安全性：响应是否得体合适？最后是指导方针（Guidelines）：你可以通过指导方针将合规要求编写为自然语言指令。对于我们的抵押贷款助手，这可能意味着：“乐于助人，永远不要承诺利率，保持专业。”
另一个很酷的功能是提示词注册表（Prompt Registry）。如果你发现一个值得 A+ 的系统提示词，你可以使用版本控制对其进行注册。这些系统提示词可以想象成 Git。现在我们已经有了强烈的概念理解，让我们谈谈四个快速技巧，这些技巧将笔记本演示与生产部署区分开来。第一：给追踪服务器一个真正的数据库。默认的基于文件的后端在你的笔记本电脑上没问题，但在并发写入时会崩溃。在团队共享实例之前，将 --backend-store-uri 指向 Postgres 或 MySQL，并将工件放在对象存储上。
如果你使用的是 Kubernetes 或 OpenShift，请在身份验证代理后面运行它。MLflow 本身没有附带任何认证故事。开启异步追踪日志记录：在生产环境中，你不希望追踪导出阻塞在你的请求路径中。MLflow 支持异步日志记录，因此跨度在后台发送，而不是为每个用户响应增加延迟。在高流量下添加采样：一旦系统稳定，你很少需要 100% 的追踪数据，但你总是希望获得 100% 的错误记录。第三：仔细选择你的裁判模型（Thank you. Pick your judge model deliberately）。
LLM 裁判默认使用托管的 OpenAI 模型，但在企业或空气隔离环境中，这通常是一个不可接受的问题。因此，将裁判指向你自己的端点。请记住，每次裁判调用都是一次 LLM 调用：如果你用五个裁判对包含 500 个示例的数据集进行评分，你就发出了 2,500 次推理请求。为此做好预算，并在正则表达式能胜任的地方依赖确定性分数。第四：在 CI（持续集成）中评估，而不仅仅是在笔记本中。内部循环是你迭代的地方，但回报在于当相同的分数自动运行于每次提示词或智能体更改时。
这就像单元测试一样的质量门禁：提示词注册表加上版本化的评估运行提供了审计轨迹。将 mlflow.genai.evaluate() 接入你的管道可以给你提供执行力。MLflow 追踪基于开放遥测（OpenTelemetry），这是行业标准，它与其它工具配合得很好。你的追踪数据不会被锁定：你可以双路导出到 Jaeger、Grafana Tempo 或平台团队已经运行的任何后端。MLflow 还与数十种 LLM 提供商和智能体框架集成，对于支持的框架来说，只需一行代码。
只需调用一次 Mlflow.langchain.autolog，即可实现自动化追踪。此后，所有的 LangChain 和 LangGraph 操作、大语言模型（LLM）调用、工具执行以及智能体的决策，都会被自动捕获。这一过程无需对智能体本身的逻辑进行任何修改。
如果你在不同框架之间编写了自定义的 Python 胶水代码，只需使用 @mlflow.trace 对其进行装饰即可。这些追踪数据同样会汇入同一棵树状结构中，保持结构的一致性。
希望以上内容对你有所帮助。如果觉得有用，请点赞并订阅频道。此外，我想了解一个有趣的问题：在你的监控体系中，智能体曾成功绕过检测的最离奇的静默失败案例是什么？欢迎在评论区分享你的经历。谢谢。