预测性维护（PHM）正在从“写死的一条条流水线”转向“智能体按需调用工具”。但一个关键问题没人回答：当智能体通过 MCP 调用工业资产管理工具时，它究竟是在做 PHM 推理，还是只是在猜 JSON 参数？PHMForge 把这个问题拆成了三种被以往评测混在一起的失败来源。
三种混淆
第一是协议混淆：非 MCP 接口把“读懂工具协议”的能力和“推理故障”的能力混在一起，智能体失败可能只是 schema 没看懂。第二是仪表混淆：用合成桩工具时，工具返回错误无法判断是智能体的错还是工具的错。第三是检索混淆：预先指定工具集，等于把“找工具”与“用工具”混为一谈，而真实的工业问题从来不会告诉你该用哪个工具。
PHMForge 的对策相应有三条：全部工具通过 MCP 暴露；工具封装已发表的 PHM 算法，失败可以干净地归因到推理；另设 Unknown-Tools 模式，把工具检索作为独立能力来评。
99 个场景与 39 个工具
基准包含 99 个由领域专家（SME）编写的场景，覆盖八类工业资产——旋转设备、航空发动机、锂离子电池等，底层是 NASA PCoE 等真实公开数据集。工具由三个领域 MCP 服务器提供，共 39 个，封装 C-MAPSS 对齐的剩余寿命估计、ISO 10816 振动分析、Arrhenius 容量衰减模型，以及用于序列预测的时序基础模型。场景标注的一致性用 Krippendorff’s α 检验，30 个分层抽样场景落在 0.74 至 0.82。
评测要求智能体自己选择、排序并组合诊断与维护工具。它不是一个只比最终答案的排行榜，而是把编排过程当作考察对象：先查什么、什么时候换工具、拿到异常结果后怎么复核。作者也写明边界：PHMForge 是可复现的代理环境，用来暴露既有协议看不见的失败模式，不能替代现场部署；与规模相近的 ITBench（IT 运维）和 AssetOpsBench（工业资产运维）相比，它的差别是全链路走 MCP——这正是生产环境里智能体将遇到的接口。
框架与模型：会判断不等于会编排
在 25 个分层场景的子集上，六种开源权重模型配三种框架的结果很说明问题。最强组合是 ReAct 加 Llama-4-Maverick-17B-128E，Pass@1 为 80.0%。单次 ReAct 在多数模型上反而优于“ReAct 加反思”（同一模型 80.0% 对 63.6%）：在边界清晰的工具编排任务里，多一轮反思更容易凭空编造工具调用；例外是 GPT-OSS-120B，反思把工具路由错误纠正了回来，从 56% 升到 68%。
长上下文的工具入参格式成了剩余寿命任务的瓶颈：Mistral-Medium-2505 把传给 MAE 计算的 100 元素数组截断了，RUL 直接 0%；Llama-4-Maverick 选择分块并在外部聚合，拿到 60%。更值得注意的是，Mistral-Medium 在成本效益与安全政策类任务上都是 100%，RUL 却是 0%——只在判断类任务上评测，会严重高估预测性维护能力。
结果说明工具底座不可替代
放开成本限制后，Claude Code 配 Opus 4.6 在全部 99 个场景上达到 80.8% pass@1，Sonnet 4.5 为 64.6%。工业落地研究常把约 85% 的任务准确率视为无人值守运行的前提，这两个数字距门槛仍有距离，且剩余差距主要集中在编排错误，而不是算不对。两个对照更能说明问题：把 MCP 工具换成纯文本 RAG，锂离子电池类的剩余寿命“三次全对”从 100% 掉到 20%；完全不给领域工具，任务完成率降到 25%。作者据此判断，算法封装的 MCP 工具是工业部署的必要底座，而不是一个已经饱和的榜单。
另一个值得记录的背景是生态变化：2025 年 12 月 MCP 被捐给 Linux 基金会下的 Agentic AI Foundation，公开服务器已超过一万个，资产管理侧也开始出现 Maximo 这类 MCP 集成。这意味着在 PHMForge 上验证过的智能体，迁移到生产工具链时不必改架构——但“能连上”不等于“会判断”，基准要测的正是后半句。
资料来源：PHMForge: Evaluating LLM Agents on Industrial Prognostics through MCP-Native, Algorithm-Grounded Tools — arXiv。本文为技术要点整理/编译，非原文全文。