时序洞察工具（39个）
时序洞察服务器通过 MCP 对外提供的工具共 39个（2026.10 — 在 2026.09 的 33个基础上，新增了 AI 发现·
生产分析工具六个）。在聊天中，这些工具会在前面加上 insight_
前缀，以 insight_analyze_asset 的形式被调用。
初始开启的是 34种（2026.10 再发布（2026-10-20），MCP 网关策略）。以关闭状态加入的有四个 ——
forecast_order_completion · autonomy_status · get_oee_losses · get_spc_chart —— 写入工具 trigger_feature_pipeline
无法开启。开启和关闭的位置是 AI 管理控制台 › MCP 网关 › 工具 → MCP 网关
- 即使开启这么多，模型也不会在每个问题中全部收到 —— 网关的工具检索会按问题挑选最多 20 个相符的工具载入 → MCP 工具地图
- 时序洞察新增工具时以关闭状态加入。管理员改过一次的值不会被覆盖。
- 至再发布 8 为止由 Copilot 保存开启/关闭状态，只开启了
get_attention_ranking等少数几个。这些值不会迁移。
按想问的问题来选择
| 想问的问题 | 工具 |
|---|---|
| 这台设备现在正常吗 | analyze_asset · get_asset_health |
| 为什么异常 | explain_asset_anomaly · analyze_alarm_correlation |
| 以前也发生过吗 | find_similar_anomalies · search_pattern |
| 是不是快要故障了 | check_failure_precursor · forecast_* |
| 其他设备也这样吗 | find_fleet_outlier · find_similar_assets |
| 这个标签测的是什么 | get_asset_profile · get_asset_tag_relations |
| 今天应该先看哪里 | get_attention_ranking · list_findings |
| 这个工单能按时完成吗 · 为什么 OEE 低 | forecast_order_completion · get_oee_losses · get_spc_chart |
| AI 最近改了什么 | autonomy_status · list_findings |
异常检测 · 预测 — 按对象成对出现
detect_* 回答现在是否异常，forecast_* 回答未来会如何。对象
共有六种，各自成对。
| 对象 | 异常检测 | 预测 | 所看的内容 |
|---|---|---|---|
| 设备传感器 | detect_asset_anomaly | forecast_asset | 温度·压力·振动等实际测量值 |
| 系统资源 | detect_system_anomaly | forecast_system | CPU · 内存 · 磁盘 |
| OEE | detect_oee_anomaly | forecast_oee | 可用率 · 性能 · 品质 |
| RAM（可靠性） | detect_ram_anomaly | forecast_ram | MTBF · MTTR · 故障率 |
| EMS（能源） | detect_ems_anomaly | forecast_ems | 耗电量 · 碳排放 |
| 生产（工单） | detect_order_anomaly | forecast_order | 以工单为基准的 OEE/RAM/EMS |
target_columns）也可以detect_asset_anomaly · forecast_asset 在未指定目标标签时，会自动查找该设备
绑定的标签并运行。只有在只想看特定标签时才需要指定。
底层模型方面，异常检测采用 IBM Granite TSPulse，预测采用 Granite-TTM R3 → AI 模型
detect_asset_anomaly 的分数并非每次调用都归一化到 0~1，而是以分析窗口紧邻的前一区间
为基准，衡量"偏离平常波动的倍数"（稳健 z 值）。省略 threshold 时
默认为 5.0。🔴 若给出 0 ，则不再是"自动"，而是只要略高于基准中位数
就判定为异常。
OEE · RAM · EMS 等领域侧的 detect_* 仍然是每次调用都归一化到 0~1 的分数——两者的
threshold 尺度不同。
| 情况 | 响应 |
|---|---|
| 数据不足 | 不使用 TTM，改用简单外推，返回 200 · model_used: "NAIVE"——无法预测的列记录在 dropped_columns ，若全部无法预测则返回 422 |
| 对象不存在 · 输入有误 | 404 · 422 |
| 无法连接推理服务器 | 503 + Retry-After |
| 无法连接元数据存储（PostgreSQL） | 503 · upstream: "postgres_unavailable" |
| 其他（配置错误 · 权重加载失败 · 代码缺陷） | 500——不会用简单外推掩盖 |
若请求了置信区间却没有返回，响应中的 bounds_reason 会说明原因 →
时序洞察
与历史对照——「以前也发生过吗」
以下四个是时序洞察的核心。它们比较的不是数值，而是波形的形状。
| 工具 | 功能 |
|---|---|
find_similar_anomalies | 查找与当前波形相似的历史异常（基于 TSPulse 嵌入的近邻搜索） |
search_pattern | 以截至指定时刻的波形为窗口，查找形状相同的历史区间 |
check_failure_precursor | 将当前波形与ERROR 报警发生前的波形集合比对，得出风险度 |
find_fleet_outlier | 比较使用同一通道的同类设备，找出独自偏离的那台 |
阈值只能看"是否越线"。以上四个看的是越线之前的形状——如果故障前 总会出现的波动此刻又出现了，即使数值本身仍在正常范围内也会被捕捉到。
综合查看一台设备
| 工具 | 功能 |
|---|---|
analyze_asset | 一次性全看——健康评分 · 传感器 · 状态 · 报警 · OEE/RAM/EMS · 原因线索 |
get_asset_health | 整合传感器+OEE+RAM+EMS+报警的0~100健康指数 |
explain_asset_anomaly | 关联已检测到异常的标签 · 报警 · 状态变化，推测原因 |
get_asset_context | 该设备的每日综合分析摘要文（便于 LLM 阅读的形式） |
find_similar_assets | 基于嵌入余弦相似度查找相似设备 |
list_asset_tags | 设备绑定的标签列表 |
不知从何下手时，先用 analyze_asset 一个工具即可。 其余工具用于根据该结果
进一步缩小范围。
如何解读健康指数——2026.10 再发布3中的变化
get_asset_health 的分数为"100 − 扣分"。本版本中扣分与判定保留的规则发生了变化。
-
停机扣分只计«计划外»停机。 设置（SETUP）· 计划停机 · 日历中的计划停机与休息日 · 班次时间外均不扣分。 具体如何计算，响应中的
idle.basis会说明。idle.basis含义 unplanned计为计划外停机 all_planned所有停机均为计划内——不扣分 held刚开始观察该状态不久，判定保留——不扣分 plan_partial无法读取日历，或该设备的班次时段不在日历中——不假设为24小时运转，仅扣除已读取到的计划停机 plan_unknown无状态来源，按旧方式（运行比率）计算 no_data无数据——不扣分 -
历史较短的领域不是0分，而是«判定保留»。 尚无校准标签的传感器领域、历史较短的 OEE · RAM · EMS 领域会 从分数中排除，并在
held_domains中连同理由（insufficient_data）一并记录。若用剩余领域得出了等级，则为grade_provisional: true，聊天回答中会附带 「Held domains … not judged」、「Grade is PROVISIONAL」——请将其理解为暂定等级。 -
字符串标签（原因代码 · 停机原因等标签名）会被归类为
categorical，从异常分数 · 预测 · 统计中排除。排除原因会记录在响应中—— 而不是「数值未上报」。在get_asset_profile中也会显示为«类别（字符串代码——非数值分析对象）»。 -
特征存储中数据点少于30个的区间不计算异常分数，标记为
insufficient_data（新标签的首个区间 · 采集空白）。 并非0分（正常）。
标签测的是什么——画像
| 工具 | 功能 |
|---|---|
get_asset_profile | 各标签测的是什么 · 正常范围 · 置信度 |
get_asset_tag_relations | 设备内联动变化的标签对及先导-滞后关系（因果候选） |
现场标签名往往像 TIC_1023_PV 一样难以让人读懂。get_asset_profile 能将其
解析为"这是测什么的值"，因此可以减少 AI 选错标签作答的情况。
以统计方式查看报警
| 工具 | 功能 |
|---|---|
get_alarm_stats | 频率 · 优先级分布 · Top 报警设置 · Top 标签 |
analyze_alarm_duration | 持续时间分析——劣化检测、MTTA（平均确认时间）趋势 |
analyze_alarm_correlation | 报警与传感器标签之间的相关性 |
detect_alarm_anomaly | 按时间段的报警发生模式异常 |
forecast_alarm | 根据报警频率趋势预测未来模式 |
AI 发现与重点关注设备——2026.10 新增内容
用于读取 AI 自行发现的内容的工具。它们不会重新计算，只是返回时序洞察预先 生成的发现·排名·状态。与管理控制台时序洞察 → AI 自主页面的数据相同 → AI 管理控制台
| 工具 | 功能 | 默认 |
|---|---|---|
get_attention_ranking | 各站点的**「今天应先查看的设备」**排名——根据未结发现 · 健康评分 · 24小时趋势计算出的关注分数（0~100）与三个理由，以及较昨日的排名变化 | 开启 |
list_findings | AI 发现的发现事项列表——设备异常 · 工单目标未达成 · 数据中断 · 数据质量 · 连锁停机 · 故障风险 · AI 自主变更等。含严重度 · 紧急度 · 依据 · 状态（open · acked · closed） | 开启 |
autonomy_status | AI 自主改进（正常基线 · 异常判定评分器）的当前状态——模式 · 使用中版本 · 影子 · 候选 · 暂停状态 | 关闭 |
list_findings 不会返回尚未经人工批准的«影子»发现。只会传递
已通知现场的相同内容——因为如果只是加个标记留存，AI 在摘要时会把该标记丢掉，导致验证前的判定被当作事实传达。
自 2026.10 再发布3（规则版 order_shortfall-3）起，«工单目标未达成»发现在以下两种情况下会保留判定而不开启。
- 工单刚开始时——经过时间不足60分钟（且不超过计划工期一半）（
held:early） - 即使按计划进行，到目前为止应产出的数量也不足1个时——即无法以数量衡量进度的情况，例如几小时才生产一件的工单（
held:no_progress_evidence）
若已开启的发现事项触及此条件，则会以 out_of_scope 关闭。从一开始就停止的大型工单不受此保留限制，照常开启。
生产分析
| 工具 | 功能 | 默认 |
|---|---|---|
forecast_order_completion | 判断进行中的工单在计划结束前能否达到目标数量——预估最终良品数（P10~P90）· 达成概率 · 预计完成时间 · 缺口数量 | 关闭 |
get_oee_losses | OEE 为什么低——可动率 · 性能 · 品质损失时间，六大损失，停机原因（含短暂停机），与平台 OEE 的对比。默认最近24小时（最长744小时） | 关闭 |
get_spc_chart | 设备 · 产品的不良率控制图（p 控制图，过度离散时采用 Laney p′）——中心线 · 控制限 · Western Electric 信号 | 关闭 |
forecast_order 与 forecast_order_completion 不同forecast_order 看的是后续多个工单的 OEE 趋势，forecast_order_completion 看的是当前正在运行的
单个工单是否能达成目标。「这个工单还差多少」属于后者。
特征存储 · 状态
| 工具 | 功能 |
|---|---|
get_asset_features | 健康评分 · 异常分数 · 报警 · 状态 · 生产指标 |
get_feature_status | 调度器作业列表 · 最后执行时间 · 回填状态 |
health_check | 服务器与依赖网络的状态——事件存储（Cassandra）· 元数据存储（PostgreSQL）· 推理服务器 · 嵌入 |
trigger_feature_pipeline | 手动执行流水线——🔴 因属于写操作，出于策略被阻止，无法开启 |
设备综合·相似度系列工具使用的是特征存储中预先计算好的值。如果调度器未运行，
工具本身可以正常连接，但返回结果为空——请用 get_feature_status 从最后执行时间开始
排查。