上一期我们聊到，DolphinDB MCP 能够让 AI 调用企业真实数据与业务能力，助力工业 AI 真正进入生产系统。

那么，如何把企业已有的数据查询、分析算法和业务逻辑，封装成 AI 能理解、能调用、能组合的 MCP Tool？

今天，我们进入实战，Intel Berkeley 实验室的 54 个真实传感器数据集为例，从设备注册，到实时监控、健康评分、预测维护，再到故障诊断和设备退役，完整拆解如何使用 DolphinDB MCP Server，将一套设备全生命周期管理能力，封装为标准化的 MCP Tool。

通过这种方式，管理人员可以使用自然语言完成设备从入库到退役的全流程管理，同时保障 AI 应用的准确性与安全性，满足工业级场景对可靠性的要求。

Intel 实验室传感器布线图

第一步，细化你的业务问题

设备管理并不是一个简单的查询问题。面对大量 IoT 设备，运维人员可能需要连续回答：

  • 实验室里有哪些设备？
  • 哪些设备当前状态异常？
  • 哪些设备可能即将发生故障？
  • 哪些设备已经到了退役阶段？

如果把这些问题全部交给大模型，AI 很容易陷入两个问题：AI 很难理解库内的数据语义，找错、缺漏数据；针对复杂的维护脚本，AI 生成的代码逻辑可能出现错误，且无法验证结果的正确性。

因此，一个更可靠的方式是：将业务问题细化为几个流程化模块，在各模块设置可组合的原子化 MCP Tool，再通过大模型的推理编排能力，将多个 Tool 组合为完整的业务模块。

在这个流程中，大模型不是简单地把所有 Tool 调用一遍，而是根据前一步的返回结果动态决策下一步。运维人员只需用自然语言描述意图“查一下 Lab 3 楼有哪些设备不太对劲”，大模型就能自动选择合适的 MCP Tool 组合，完成数据拉取、分析、对比、打分，并返回可直接行动的结构化结论。

这正是 MCP 协议 + 大模型的独特优势：大模型理解业务上下文，自行编排调用顺序，组合出比单独使用任何一个 Tool 都更有价值的综合判断。

将设备管理拆分为 7 个业务模块

针对设备管理的问题，在本案例中，我们将其拆分为 7 个业务模块：

设备注册 → 状态监控 → 健康评分 → 预测维护 → 配置审计 → 诊断排障 → 退役归档

在这里插入图片描述

典型设备管理周期

第二步：封装各模块工具

完成了设备管理流程的细化，接下来就进入了工具封装过程。我们给7个模块分别封装了若干个 Tool，来满足实际使用需求：

模块核心问题MCP Tool
设备注册有哪些设备？在哪里？什么型号？queryDevices、getDeviceDetail、upsertDevice
状态监控哪台设备现在异常？getDeviceRealtimeStatus、getActiveAlerts
健康评分设备当前健康度如何？scoreDeviceHealth、rankDevicesByHealth
预测维护哪些设备即将出问题？predictDeviceFailure、estimateRemainingLife
配置管理最近修改过什么配置？getDeviceConfigHistory、recordConfigChange
诊断排障为什么异常？根因是什么？replayDeviceHistory、compareDeviceToPeers、analyzeMetricCorrelation
退役归档哪些设备应该退役？markDeviceRetired、getRetiredDeviceReport、getLifecycleDashboard

开发人员只需要把各模块的能力沉淀为准确、稳定、可复用的 MCP Tool，并明确输入输出边界；大模型则负责理解用户意图、规划执行步骤，并按需组合调用这些工具，完成设备的全生命周期管理。

接下来，让我们简单分析各个业务模块的 MCP Tool 实现。

1、设备注册与元数据管理

设备管理的第一步，是建立设备台账。面对成百上千台设备，系统首先需要回答：有哪些设备？设备在哪里？什么型号？当前是什么状态？

因此，这一模块设计了三个 Tool，形成检索 → 下钻 → 写入的流程。

在大模型对话中，用户说"看看 lab 有哪些设备"，Agent 即调用 queryDevices 做全景扫描，发现相关设备后，用 getDeviceDetail 做单设备深度查看。用户无需关心底层数据在哪张表，大模型能直接根据用户意图获得结果。另外，upsertDevice 则负责数据的写入，与查询工具形成读写闭环。

核心函数实现示例如下：

// queryDevices：状态/位置过滤 + topN 均下推为一条 SQL
def queryDevices(status_filter, location_filter, topN) {
    conds = ""
    if (trim(status_filter) != "") { conds = "status == \"" + status_filter + "\"" }
    if (trim(location_filter) != "") {
        conds = conds + iif(trim(conds) == "", "", " and ") + "location like \"%" + location_filter + "%\""
    }
    sqlStr = sqlBuilder("*", "loadTable(\"dfs://iot_device_meta\", \"device_metadata\")", conds, "", "", topN, 0)
    t = parseExpr(sqlStr).eval()
    hint = iif(topN > 0 and t.size() >= topN, "（已达 topN 上限，可调大 topN 查看全部）", "")
    return "查询到 " + string(t.size()) + " 台设备" + hint + ":\n" + toStdJson(t)
}

定义好业务函数后，再将其注册为 MCP Tool：

registerTool("queryDevices", queryDevices,
    ["status_filter", "location_filter", "topN"],
    ["string", "string", "number"],
    "查询设备元数据列表。示例：queryDevices('active', '', 20)", info)

想要了解核心函数实现的完整代码，可点击 https://dolphindb-marketplace.oss-cn-hangzhou.aliyuncs.com/20260903MCP.zip 获取完整代码

需要注意的是，Tool 描述同样是开发的一部分，MCP Tool 不只是给程序调用，也是给大模型看的。

例如上述例子中查询设备元数据列表。示例：queryDevices('active', '', 20)", info)。这样的描述可以帮助大模型更准确地理解 Tool 的用途，并正确构造调用参数。

2、实时状态监控与告警

设备上线以后，下一个问题就是：现在谁出了问题？因此第二组 Tool 用于实时状态监控。

三个 Tool 分别对应：查看状态 → 发现告警 → 完成处置。例如运维人员通过 getDeviceRealtimeStatus 查看全设备实时状态快照，在发现某设备电压异常后，通过 getActiveAlerts 筛选告警设备，现场维修结束后调用 resolveAlert 关闭告警——整个过程被完整追踪。

getActiveAlerts(severity_filter=“”, moteid_filter=0, topN=5)

=== 告警概览 ===
[{"severity": "warning","count": 1}]
=== 活跃告警明细（共 1 条） ===
[{"alert_id": 1000001,"moteid": 55,"alert_time": "2004.03.15 16:03:00.000","severity": "warning","alert_type": "low_voltage","message": "电压连续低于 2.3V，疑似电池老化","acknowledged": false,"resolved_time": null}]

更重要的是，这里的异常并不一定要等 AI 临时读取原始数据后再计算。DolphinDB 本身可以通过流计算引擎持续进行异常检测，把告警结果写入告警表。DolphinDB 负责实时计算，AI 负责理解和决策。数据采集、异常检测、告警生成、查询和处置，都可以在同一套数据与计算体系中完成。

3、设备健康度评分

设备异常并不总是一个简单的阈值问题。比如温度偶尔偏高，并不一定说明设备真的发生故障。

因此，我们设置了健康度评分，将温度稳定性、电池衰减、数据完整率、通信质量等多个维度综合为一个 0-100 的分数，量化为可复现、可对比的标准化分数，帮助运维人员更准确地判断设备真实状态。

rankDevicesByHealth 提供设备健康度全局排名，帮助运维人员回答"最需要关注的 10 台设备是谁"。scoreDeviceHealth 则针对特定设备提供各维度的详细评分，帮助理解"它为什么得分低"。两者配合使用，先用排名锁定问题设备，再用评分明细分析根因。

scoreDeviceHealth(moteid=18)

=== 设备 #18 健康度报告 ===
综合评分: 45.1 / 100  等级: D (警告)
---
电池健康度 (25%): 6.9  | 均压: 2.35V
温度稳定性 (20%): 0    | 标准差: 45.14°C
数据完整率 (20%): 76.2 | 完成率: 76.2%
数据质量 (15%): 100    | 异常率: 0%
通信可靠性 (10%): 50.2 | 丢包率: 49.8%
服役健康 (10%): 81.5   | 已服役: 16.6 天

AI 在调用工具后给出总结：18 号设备评分 D（警告）的两个主因：温度标准差 45.14°C（该传感器读数波动剧烈）、丢包率 49.8%。

4、预测性维护与预警

被动响应故障的成本远高于主动预防。本模块不满足于发现已有问题，而是尝试回答“哪些设备即将出问题、大概多久后会出问题”，减少非计划停机时间，优化备件库存管理。

predictDeviceFailure 负责做宏观筛选，从设备群体中筛选高风险设备，estimateRemainingLife 做微观预测，针对某一设备进一步估算剩余寿命。

例如：

=== 设备 #18 剩余寿命预测 ===
电压日均下降 30.87mV，当前 2.02V，预计 -8.9 天后跌破阈值 (2.3V)。 建议本周安排更换电池！

5、设备配置变更审计

在大规模部署中，设备固件升级、参数调整、重新校准是高频操作。出现故障时，通常先确认近期发生了哪些配置变更，再排查故障的原因。本模块提供完整的配置变更追溯能力。

recordConfigChange 自动记录一次配置变更，getDeviceConfigHistory 查询某设备的所有历史变更。getFirmwareVersionDistribution 则提供全局视角——当发现某个版本固件的设备集体出现异常时，版本分布图可以快速验证关联性。

6、设备诊断与根因分析

设备告警触发后，仅知道“温度高了”或“电压低了”是不够的，运维人员需要判断：这是设备自身故障，还是环境因素导致的？是单一指标异常，还是多个指标耦合恶化？本模块提供了三个层次的诊断工具。

典型的排障流程是：

  1. 先通过 scoreDeviceHealth（模块三）确认设备确实不健康
  2. 用 compareDeviceToPeers 判断是否为环境因素——如果同区域设备都出现了类似异常，那大概率是环境变化（如空调故障导致区域高温），而非设备自身故障
  3. 如果排除了环境因素，用 replayDeviceHistory 回放异常发生前后的数据，观察指标变化的时间线和幅度
  4. 对于复杂故障（如怀疑温度异常导致电池加速老化），用 analyzeMetricCorrelation 验证指标间的因果关系

compareDeviceToPeers(moteid=18, radius_meters=10)

=== 设备 #18 vs 同区域参考设备 ===
参考设备: 9 台 (半径 10m)
  温度: 47.1°C (目标) vs 35.93°C (参考均值)
  电压: 2.35V (目标) vs 2.53V (参考均值)
  湿度: 29.1% (目标) vs 34.7% (参考均值)
温度偏差 11.2°C，显著高于同区域设备，可能存在传感器漂移。

可以看到，我们并没有编写一个巨大的“万能诊断函数”。而是把能力拆成多个 Tool，再由 AI 根据任务动态组织。

7、设备退役

设备下线时，需要生成退役报告供审计和复盘，汇总服役期间的运行表现。为设备退役提供规范的流程和可审计的记录，并将退役数据反哺至采购和选型决策，形成设备管理的历史资产。

markDeviceRetired 是退役操作的入口，生成针对单设备的退役摘要。getRetiredDeviceReport 提供退役设备的横向对比，帮助发现系统性规律。getLifecycleDashboard 则提供全局视角，让管理者一眼看清设备整体的生命周期分布。

第三步：给 AI 设置 Prompt

到这里，我们已经拥有了一系列 MCP Tool。但我们还需要让 AI 知道：遇到某类业务问题时，应该按照什么逻辑使用这些工具。

因此 DolphinDB MCP Server 还提供了 Prompt 管理能力。可以把设备管理的最佳提问方式沉淀为可复用、可发布、可参数化的提示词模板，让终端用户无需了解工具细节也能高效驱动大模型完成设备运维。

在这个案例中，Prompt 被划分为系统/场景/任务 Prompt 三个层次，帮助用户快速、便捷地获取更精准的 Prompt，从而获得更高质量的回答。

例如在人物场景中，用户选择 iot_task_diagnose 并填入 moteid=18，客户端调用 prompts/get 得到填充后的文本，Prompt 可以自动生成：

请诊断 18 号设备的异常根因：依次调用 scoreDeviceHealth(18)、compareDeviceToPeers(18,10)、analyzeMetricCorrelation(18)，交叉分析后给出根因与处置建议。

大模型即可按照标准的 Prompt 自动组合多个 MCP Tool 完成任务，给出结论：

=== 设备 #18 多指标关联分析 ===
相关系数矩阵 (temp/hum/volt/light):
[{"metric": "temperature","temperature": 1,"humidity": -0.65,"voltage": 0.78,"light": 0.67},
 {"metric": "humidity","temperature": -0.65,"humidity": 1,"voltage": -0.43,"light": -0.47},
 {"metric": "voltage","temperature": 0.78,"humidity": -0.43,"voltage": 1,"light": 0.6},
 {"metric": "light","temperature": 0.67,"humidity": -0.47,"voltage": 0.6,"light": 1}]
温度-电压强相关 (r=0.78)，电池性能可能受温度影响。
温度-湿度强相关 (r=-0.65)，传感器可能出现耦合干扰。

总体来看，在使用 DolphinDB MCP Server 后，企业设备管理的能力形成了四个层次：DolphinDB 数据与计算 → MCP Tool 封装专业能力 → MCP Prompt 沉淀专家流程 → AI Agent 理解自然语言并自动编排。

这一体系将 DolphinDB 数据存储与高性能计算能力，与 AI Agent 自动化智能连接起来，帮助企业更快发现问题、降低运维成本，持续提升设备管理效率。

DolphinDB MCP Server：让 AI 获得设备管理能力

回看整个案例，我们真正做的事情并不是把设备数据交给大模型，而是把原本散落在数据库、计算脚本和专家经验中的设备管理能力，进一步封装成 AI 可以调用的标准化能力。

将整个设备管理流程拆成 7 个业务模块，明确各模块的 MCP Tool，再让 AI 根据业务上下文动态组合这些 Tool。

这也正是 DolphinDB MCP Server 在设备管理场景中的核心价值：DolphinDB 负责把数据处理和专业计算做准，MCP 负责把这些能力开放给 AI，大模型负责理解业务意图和工具编排。

最终，运维人员面对的不再是数据库、SQL 和多套割裂的业务系统。而只需要用自然语言提出问题：“帮我看看哪些设备最需要关注。” AI 就可以从设备数据出发，一路完成状态查询、健康分析和异常诊断。

DolphinDB MCP Server，让 AI 不只是看懂设备，而是真正参与设备管理。

Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

cover

论文季救命清单：2026写论文用哪个AI？7款论文AI工具覆盖找文献、出初稿到降重！

avatar 2048 AI社区
cover

EasyClick iOS USB 中控 + iDeviceFarm AI 工作站安装教程，AI对话式操作苹果手机

avatar 2048 AI社区
cover

阿里云旗下新平台公测，Qwen3.8-Max、DeepSeek-V4-Pro等模型限时限量免费用

avatar 2048 AI社区