我在模型上下文协议 (MCP) 正式发布之前就开始接触它了，当时是在 IBM Maximo Application Suite (MAS) 9.2。我甚至为 MAS 构建了自己的 MCP 服务器，并在一系列博文中对此进行了记录（与 Maximo 对话的难题），旨在帮助 AI 代理与 Maximo Manage 建立连接。自那时起，社区中许多人也开始关注如何为 Maximo 团队应用这一技术。
‍

目前大多数讨论都集中在 MAS 9.2 对 MCP 的支持上，但本文旨在深入探讨 MCP 服务器的工作原理、架构设计，以及它如何赋能 AI 代理 与 Maximo 进行安全协作。我将梳理核心概念，并分析这些功能对于希望在 Maximo 环境中应用 MCP 的团队意味着什么。
‍

MCP 服务器的定位

如果您还没读过我的系列博文，也不了解什么是 MCP，我在这里为您快速回顾一下。
‍

MCP 服务器位于 AI 代理与 Maximo Manage API 之间。在 MAS 9.2 中，它可以为内置的 资产生命周期管理 (ALM) 代理提供服务——这里的 ALM 指的是部署在 AI 服务中的 AI 组件，以及 Insights、Reliability 等其他基于 AI 的解决方案。ALM 及相关资源是实际通过 MCP 与 Maximo 交互的 AI 服务，为整个套件提供智能化能力。
‍

不过，它并不局限于内置的智能体。它同样支持 外部智能体，包括客户自有的智能体或其他智能体框架（如 IBM Bob、Claude 和 OpenAI），只要它们通过受支持的路由和身份验证模型进行连接即可。
‍

最简单的理解方式是：Manage 始终是事实来源，而 MCP 服务器则是面向智能体的、通往特定 Manage 功能的门户。
‍

Manage 本身已公开了 OpenAPI 规范。在 MAS 9.2 中，MCP 服务器利用这些规范来识别哪些功能可作为 AI 工具使用。Manage 负责跟踪工具定义，而 MCP 服务器则会轮询 Manage 以获取更新。默认情况下，该轮询每 10 分钟执行一次，但时间间隔可以根据需要进行配置。
‍

轮询过程使用 ETag。Manage 会保留其自身的 ETag 以记录工具规范的变更，而 MCP 服务器则在内存中维护一个 ETag。当这两个值不一致时，MCP 服务器会刷新其工具列表并拉取最新的 OpenAPI 规范。这就是新增、更新和删除操作同步到面向智能体的工具目录中的方式。
‍

这些工具还采用了结构化的输入和输出定义。演示中提到了 Pydantic 输入和输出对象，它们为智能体提供了更严格的遵循模式（我曾在 运营层：从发现到行动中提到过这一点）。这不仅仅是一个实现细节。当智能体面对的是狭窄且明确的契约，而非庞大的 API 接口时，其表现会更加稳定。

安全性遵循 Maximo 模型

此处最出色的设计选择之一是，MCP 并未在 Maximo 之外另起炉灶建立一套独立的安全性体系。身份验证和授权依然遵循标准的 MAS 和 Manage 模式。
‍

对于内置智能体路径，UI 会在发送工具请求时附带一个 x-access-token JWT。MCP 服务器将该令牌发送至 Core IDP 进行身份验证，获取用户上下文，并在调用工具时将用户 ID 传递给 Manage。最终，Manage 仍会决定该用户是否有权执行相应操作。
‍

这意味着即使是合法用户，也无法自动调用所有 MCP 工具。如果用户不应被允许调用某项工具或访问特定的 AI 配置，那么即便请求是通过 MCP 发起的，这些限制依然有效。
‍

对于外部智能体，MAS 9.2 支持通过 Maximo API 密钥或 JWT 令牌进行身份验证。对于需要统一权限集的集成类场景，API 密钥通常是首选；而当智能体需要代表不同用户执行操作时，JWT 令牌则更为适用。
‍

MCP、Manage 和 Core 之间的内部通信使用 MAS 证书。MCP 的设计初衷并非绕过企业管控，而是为智能体提供接入 Maximo 的途径，同时确保现有的管控机制依然发挥作用。

外部智能体是设计的一部分

“自带智能体”（Bring Your Own Agent）是本次发布中最引人注目的亮点之一。
‍

部分客户会使用 IBM 内置的 ALM 智能体，而另一些客户可能已有自己的智能体投入，或者希望采用 IBM 智能体与外部智能体共同与 Maximo 交互的混合模式。MCP 服务器支持这种更广泛的模型，这非常令人振奋！
‍

要连接外部智能体，客户需要两样东西：对外暴露的 MCP 路由和一种身份验证方法。路由通过 OpenShift 自动暴露，智能体则根据身份验证模式发送 Maximo API 密钥或 x-access-token 标头。
‍

这意味着 Maximo 的功能可以通过行业标准协议提供给外部智能体，而无需进行一次性的定制集成。对于拥有现有 AI 平台的客户来说，这可能是 MAS 9.2 最实用的功能之一。他们既能保留原有的智能体策略，又能继续将 Maximo 作为受控的记录系统使用。

MCP 工具即 API，但并非所有 API 都是工具

该设计的一个有趣之处在于，Manage 中的所有 MCP 工具均为 REST API，但并非所有 Maximo API 都是 MCP 工具。
‍

这种区分至关重要。Maximo 拥有极其庞大的 API 接口群，如果将所有接口都开放给智能体，不仅成本高昂、干扰信息过多，还存在风险。智能体将面临过于复杂的模式处理、过多的路径选择，以及更高的误操作概率。
‍

MCP 工具是一个更具选择性的层。它们通过描述、模式和注释来公开旨在供智能体使用的功能，从而帮助智能体决定何时以及如何调用这些功能。
‍

MAS 9.2 将 Manage MCP 工具分为五大类。

AI 配置工具

AI 配置工具基于 Manage 中已激活的 AI 配置。已安装 AI 服务支持的推理类型包括分类、相似度、助手、文档搜索和条件洞察。
‍

助手功能尤为引人注目，因为它可以用作引导工具。它可以接收自然语言请求，并推断出 REST API 调用应有的形式。在某些情况下，该流程会拆分为两个工具：一个用于推断 API 请求，另一个用于执行请求。这种拆分让智能体有机会在执行下一步操作前向用户展示其意图。
‍

AI 配置工具使用 MAXAICFGTOOL 表中维护的白名单。一旦支持的 AI 配置被激活，它就可以自动变为可用工具。这与其他几种需要显式部署步骤的工具类型不同。
‍

描述在这里至关重要。AI 配置的描述会成为工具描述，智能体会利用这些内容来判断该工具是否符合用户的请求。模糊的描述会增加规划难度，而具体的描述则能为智能体提供更好的指导。

对象结构工具

对象结构功能强大，但其模式可能非常庞大。工单、资产或位置对象结构可能包含许多操作和字段。将整个模式交给智能体通常不是合适的做法。我在构建自己的 MCP 服务器时，就曾多次遇到上下文窗口限制的问题。
‍

OS 工具通过从大型对象结构模型中切分出更精简的工具来解决这一问题。OS 工具不再公开资产对象结构的所有功能，而是专注于特定的操作，例如移动资产或报告停机时间。

脚本工具

自动化脚本是客户和合作伙伴扩展 Maximo 最常用的方式之一。MAS 9.2 将这种扩展模式引入了 MCP 模型。
‍

脚本工具遵循与 REST API 脚本编写相同的通用方法。字面脚本变量将成为请求模式。当脚本返回结构化输出时，可以使用 responseBody 参数添加响应模式。只有处于活动状态的脚本才会部署为 MCP 工具。  

工作流工具

工作流工具为团队提供了一种更直观的方式，将业务流程呈现给智能体。这在 Maximo 场景中非常有用，因为许多重要操作已经以工作流而非代码的形式建模。
‍

此功能仅支持非交互式工作流，即由节点、条件节点和操作组成的工作流。依赖弹出对话框或交互式询问的工作流不包含在首个版本中。
‍

请求模式很简单：一个用于标识工作流运行目标记录的 href 元素。与脚本和 OS 工具一样，该记录可以来自之前的助手查询。
‍

处于活动且已启用的工作流可以部署为 MCP 工具，其描述将成为智能体判断何时使用它们的重要依据。

API 路由工具

最后一种工具类型是 API 路由工具。这些是由 IBM 提供的工具，主要用于管理或系统级功能，而非客户定义的业务逻辑。
‍

API 模式工具就是一个例子。未来，IBM 可能会开发此类系统级工具，例如能够回答有关已安装产品、插件、行业解决方案、语言或升级信息等问题的智能体。

此类别不提供供客户配置的 UI。客户和合作伙伴已有脚本、工作流和对象结构工具来进行自定义扩展。API 路由工具更适合被理解为 IBM 提供的后台功能构建模块。

各类工具的必备事项

无论哪种工具，其核心逻辑如出一辙：工具描述就是智能体所阅读的操作手册。
‍

这听起来很简单，但往往是决定项目成败的关键。智能体需要的不仅仅是一个接口，它还需要明确工具的用途、适用场景、所需信息以及支持的各种变体。
‍

对工具进行标注至关重要。管理员可以将工具标记为“只读”或“破坏性”，智能体在采取行动前会参考这些信息。如果工具仅用于检索数据，智能体可将其视为低风险操作；如果工具涉及修改记录、启动工作流或运行脚本，智能体则有充分的理由暂停并请求确认。虽然这些标注无法约束所有外部智能体，但能为设计良好的智能体提供明确的预警。
‍

这正是 Maximo 经验发挥价值的地方。最优秀的 MCP 工具目录绝非简单地堆砌功能，而是通过精选操作、定义严谨的架构，并撰写出如同专家指导般清晰的说明来实现的。

这对 Maximo 客户有何意义

MAS 9.2 中的 MCP 服务器不仅是为了给 Maximo 引入 AI，更是为了在 Maximo 内部为 AI 智能体提供一套受控的运行模式。
‍

如果没有 MCP，客户在将智能体连接到 Maximo 时，必须自行决定暴露多少 API 接口、如何描述每个操作、如何处理身份验证、如何保持工具定义同步，以及如何防止智能体执行错误操作。MCP 为这些问题提供了标准化的解决方案。
‍

对于已经使用 AI 配置的团队，一旦配置激活并获得支持，工具暴露路径即可实现自动化。对于拥有成熟 Maximo 定制化方案的团队，脚本和工作流无需放弃原有的扩展模式，即可直接转化为智能体可调用的工具。对于自行构建智能体的团队，外部路由以及 API 密钥或 JWT 身份验证模型，使得将 Maximo 集成到更广泛的 AI 架构中变得更加轻松。
‍

其结果是在 Maximo 现有的业务逻辑与全新的智能体层之间架起了一座实用的桥梁。这并未降低治理的重要性，反而让良好的治理变得更加直观。工具描述、架构、权限和标注都成为了智能体工作规划的一部分。
‍

这是正确的方向。企业级智能体需要的不仅仅是答案，更需要受限的操作、明确的契约以及尊重记录系统的访问权限。MAS 9.2 的 MCP 服务器为 Maximo 团队开展此类智能体工作奠定了坚实的基础。