MLflow 3.18 自动归组 Agent 故障：从日志找到该修的问题

MLflow 于 2026 年 11 月 4 日发布 3.18.0，把 Automatic Issue Detection 列为主要新功能：从执行轨迹中发现重复问题，并将相关证据整理到 Issues 页面。对维护 AI 客服、研究助手和工具调用服务的团队，难点往往已经从“有没有日志”变成“哪些日志指向同一个缺陷”。本文用一个库存问答场景，解释这次更新如何帮助定位问题，以及怎样把发现变成可验证的修复。来源：3.18.0 发行说明

原创 AI 概念图，档案与错误内容均为示意，不代表产品界面、真实日志或检测结果。

[配图建议：散乱的执行记录被整理为问题档案，每份档案用线连接到原始记录 + 米白、靛蓝与朱红色的复古技术版画风格。]

一、先把相似失败归组，再回到具体证据

一次 Agent 请求可能经过模型、检索、工具与后续生成。用户只看到一句错误回答，开发者却需要判断：资料没找到，工具调用失败，还是回答阶段没有遵循已经取得的信息？单看最终文本，很难确定应该修改哪一层。

MLflow 的新能力围绕这个定位过程展开：分析 Trace 中的输入、输出、调用步骤、错误等信息，把相关发现归成问题，并链接回支持它的轨迹证据。它处理的是执行记录中的质量和运行问题，不能把“发现问题”理解为已经定位并修复了代码。来源：自动问题检测说明

这条路径的价值，是把浏览单位从“一条日志”换成“一类值得调查的问题”。例如，数次回答错误若都发生在相同工具结果之后，开发者就有机会先调查那条共同路径，而不是逐次修改回答提示词。

不过，归组本身也是待核查的判断。相似措辞可能来自不同原因，不同措辞也可能共享同一原因。真正有用的问题条目，应该能带你找到证据，而不只是给出一个听起来合理的标题。

已有 MLflow Trace 的团队较容易开始；还没有完整记录的项目，先确认调用链能被看见。没有记录下来的工具返回值，很难靠事后分析补齐。

[配图建议：多条不同措辞的失败记录汇入一个候选问题，再分别连接回原始调用步骤 + 清晰的证据关系图风格，不画成已确认的唯一根因。]

二、HTTP 成功，不等于 AI 把事情说对了

假设一个库存助手回答“这件商品还有货”，但库存工具刚刚返回零库存。模型与接口都正常结束，用户却得到错误结论。这是本文自拟的产品场景，不是官方评测样本。

如果只盯异常计数，这次请求可能显得很正常。要判断发生什么，需要同时看到用户问了哪件商品、工具查了哪个标识、返回什么，以及最终怎样组织回答。

MLflow 的单条 Trace 视图可以展示步骤树、各步骤的输入输出与耗时、工具调用、异常及反馈等信息；这些记录提供了复核入口。来源：Trace 详情

面对这个例子，可以沿三个问题向下追：

• 是否查对对象？用户问的商品与工具请求中的标识是否一致？
• 是否取得可用结果？零库存、查询失败与字段缺失有没有被区别处理？
• 是否忠实转述？最终回答是否与已经拿到的数据矛盾？

三种结果对应不同修复方向。查错对象可能需要调整参数映射；返回失败却被当成有货，需要检查错误处理；工具数据正确而回答相反，才值得继续检查回答阶段。一个笼统的“模型幻觉”标签，无法替代这些判断。

多轮场景还要保留对话关联。用户先问黑色款，再说“那白色呢”，若两轮被拆散，第二轮的商品解析就缺少背景。MLflow 支持用会话标识把相关轨迹关联起来；这项记录能力提供上下文，不代表自动证明回答正确。来源：用户与会话追踪

不要只问有多少条错误，而要问哪一步开始偏离预期。这能让问题清单更接近开发者可以处理的工作。

[配图建议：虚构库存请求沿用户问题、工具参数、零库存结果和错误回答四步展开，偏差位置留待标注 + 可读性优先的调用链示意风格。]

三、先缩小分析范围，别把新检测变成另一堆噪声

启用前要确认条件：官方要求已有记录轨迹的实验、Linux 或 macOS 上使用 SQL 后端并启用后台任务的 Tracking Server，以及可调用的受支持模型或 AI Gateway 端点。分析会产生所选模型的使用费用。来源：要求与费用说明

因此，运行 MLflow 服务本身，与运行一次 AI 分析，是两部分成本。自托管提供了部署与存储的选择，也带来服务、数据库和产物存储的维护工作；官方部署说明将这些组件分开介绍。来源：自托管架构

第一次不必把全部历史记录都送去分析。可以先选择同一个应用版本、相近时间段和一种业务任务，保留一组正常记录作参照。这样的范围容易人工核对，也能减少不同版本与不同任务混在一起造成的解释困难。

对库存助手，建议先写清三项业务判断，作为团队复核标准：

这些是本文建议的判断标准，不是工具检出率承诺。还应留下一些人工确认的失败样本，看看检测是否漏掉；仅抽查被报出来的条目，会看不到漏检。

如果重复查询是业务允许的刷新动作，就不能只因次数多而认定缺陷。记录“为什么这个发现成立或不成立”，会比追求一个很大的问题数量更有价值。

[配图建议：一组范围明确的测试记录与人工复核表并排摆放，正常样本和已知失败都保留 + 克制的分析记录单风格，不填虚构准确率。]

四、从问题条目走到回归用例，闭环才算开始

实际操作可以先做一轮手动分析：在实验的 Issues 页面选择检测，确认模型、轨迹范围与费用估计；结果出来后，从一个条目打开源 Trace 检查依据。官方也支持定期检测，但定时运行仍需要服务器配置和持续模型费用。来源：检测与调度说明

当你确认库存问答确有缺陷，下一步应当留下一个可重复的用例：固定用户问题、工具返回的商品标识与库存状态，再定义允许的回答。例如，零库存时不能声称有货；工具失败时应说明无法确认，而不是猜一个库存数量。

修复后还要检查邻近情况：有货时是否仍能正确回答，不同颜色或规格会不会串用结果，多轮追问是否保留了正确对象。只让一个失败样本通过，容易把局部补丁误当成完整改善。

MLflow 的回归测试文档把“数据集总体评分”和“某项具体行为是否退化”分开讨论，并支持使用普通 pytest 流程记录测试结果。其建议也包括固定裁判模型，并关注模型评判的不确定性。来源：回归测试与 CI

对可以程序化核对的条件，优先给出清楚断言；需要语言判断的部分，再明确评分依据。团队真正想得到的不是一个永远增加的问题列表，而是一组逐渐覆盖已知失败的检查。

把原始轨迹、确认理由、修改与复测结果连起来，下一次同类错误出现时才有参照。自动归组节省的是发现线索的工作，修复是否有效仍需要证据。

[配图建议：问题档案依次连接到源轨迹、局部修改和固定回归用例，最后返回同一份记录 + 简洁的闭环流程图风格。]

今天先挑一条“没报异常但答错了”的请求

已经记录 Agent 调用链、又经常遇到重复质量问题的团队，值得用小范围样本尝试这次更新。尚未记录工具输入输出的项目，可以先补齐追踪，再评估自动检测。

今天可做的一步：找出一条接口成功、结论却错误的请求，标出它从哪一步开始偏离预期。你更缺的是把同类问题找齐，还是把一条失败解释清楚？先回答这个问题，再决定分析范围。

资料核查于北京时间 2026 年 11 月 6 日；3.18.0 正式发布于 11 月 4 日。本文为近 72 小时版本深读，依据官方发行说明与文档分析，未部署实测。

[配图建议：一条被圈出的错误结论连回对应工具证据，旁边留下一项明确的复测任务 + 与封面一致的版画收尾风格。]