这不是什么颠覆性的产品，而是一个正在探索中的实验项目。如果你也在关注 LLM + 工业维护的交叉领域，或许可以一起研究下思路。

起点：工业维护里的那些老问题

做工厂的人大概都熟悉这些场景：

• 设备出了故障，老师傅知道怎么回事，但他说不清楚，年轻人也学不走
• 振动、温度这些传感器数据一直在采集，但很少有人真正去看趋势变化
• 报警来了，要手动查手册、查历史、查备件，再决定怎么处理
• CMMS、IoT 平台、微信工作群、邮件系统各自为政，信息散落各处

这些问题不新，很多公司也在用各种方案解决。我们想尝试的是：能不能用 LLM 做一个中间层，把分散的信息和决策流程串起来？

这就是双安（ShuangAn）项目的出发点。

它是什么

双安是一个 Python 框架，用来搭建面向工业预测性维护的 AI Agent。说得直白一点，它做三件事：

1. 把分散的数据源接进来 — CMMS（设备管理系统）、IoT 传感器、设备手册、通信平台，通过连接器统一接入
2. 让 LLM 理解工业语境 — 内置 ISO 14224 和 GB/T 国标的领域模型，不是通用聊天机器人
3. 在条件允许时自动行动 — 趋势恶化时自动报警、创建工单、发送通知

它不是一个开箱即用的产品，更像是一套可组装的积木。你需要根据自己的工厂环境选择和配置合适的连接器，接入自己的 LLM 服务。

五层架构：为什么这么分

项目采用了五层分层的架构设计，这不是为了架构而架构，而是实际需求推动的：

┌─────────────────────────────────┐
│  通道层 — 人机交互入口           │
│  微信 · 钉钉 · 飞书 · CLI       │
├─────────────────────────────────┤
│  Agent 运行时 — 核心调度         │
│  实体解析 · 上下文 · 工具调用     │
├─────────────────────────────────┤
│  领域模型 · LLM 抽象 · 连接器    │
│  三层并列，各自独立              │
├─────────────────────────────────┤
│  可观测性 — 追踪 · 日志 · 成本   │
└─────────────────────────────────┘

通道层解决"人从哪里进来"的问题。国内工厂的技术人员用微信和钉钉沟通，不是 Slack，所以连接器优先支持国内平台。

Agent 运行时解决"收到消息怎么处理"的问题。用户说"P-201 泵的振动偏高"，系统需要先解析出 P-201 是哪台设备，然后并行去查工单、备件、手册，再把结果交给 LLM 生成回答。

领域模型独立出来，是因为工业维护有自己的术语体系。设备有关键度 A/B/C 分级，工单有生命周期状态机，故障模式有 ISO 14224 编码——这些不是通用 LLM 天然理解的。

连接器独立出来，是因为每家工厂用的 CMMS 不一样，有的用 SAP PM，有的用 Maximo，有的就是 Excel 表格。连接器用能力声明（Capability）机制注册，Agent 运行时自动发现可用功能。

可观测性放在最底下，是因为 LLM 调用有成本，工具调用有延迟，出了问题需要能追踪。

几个实际场景

场景一：技术人员用中文提问

用户：冷却水泵 P-201 最近振动偏高，可能是什么原因？
Agent：
根据设备档案，P-201 是一台旋转设备（Grundfos CR 32-2），关键度 A 级。
当前振动值为 6.8 mm/s，趋势呈上升方向。
匹配的故障模式：
1. 轴承磨损（ISO: BPFD）— 置信度 0.8
2. 不平衡（ISO: IMB）— 置信度 0.5
建议：检查轴承温度和润滑状况，振动如继续上升可能需要安排检修。
备件库存：深沟球轴承 6312-2RS1，当前库存 3 个。
这里用到了中文实体解析（"冷却水泵" → 分词匹配到设备注册表）、并行上下文检索（同时查工单、备件、故障模式）、以及 LLM 工具调用。

场景二：自主预测性维护

系统每 5 分钟轮询传感器数据，当趋势分析发现振动值在持续上升：

TrendPredictor 检测到：P-201 振动趋势上升，slope=0.8 mm/s/h
→ 24h 预测值：25.8 mm/s（远超阈值 11.0 mm/s）
→ 预计 3.5 小时后超过阈值
DecisionEngine 判定：CRITICAL
→ 自动创建紧急工单 WO-AUTO-20260623-xxx
→ 通过钉钉发送紧急通知给维护班组
这个流程完全自动运行，不需要人工触发。

场景三：报警到工单的工作流

内置了一个 6 步工作流模板：

报警 → 故障诊断 → 历史查询 → 备件检查 → 生成工单 → 通知技术员
工作流引擎支持模板变量（
{trigger.asset_id}
）、错误策略（重试/跳过/停止）、和超时控制。

LLM 选择：通过 LiteLLM 支持通义千问、文心、智谱、混元、DeepSeek，切换只需改一行配置。Ollama 本地部署也可以。

通信平台：企业微信、钉钉、飞书都做了连接器，支持 Webhook 回调接收消息（不是只能发不能收）。

中文实体解析：这是实际开发中踩的坑。英文分词按空格切就行，但"冷却水泵"需要拆成"冷却"+"水泵"才能匹配到设备注册表。我们做了一个基于工业术语词典的分词器，内置了 50 多个常用词，用最长匹配优先的策略分词。

标准对齐：领域模型同时标注 ISO 14224 编码和 GB/T 国标编码，比如设备的 equipment_class_code（ISO）和 gb_equipment_code（GB/T 35249）。

实验中的发现和修复

既然是实验项目，就不可避免地踩坑。记录几个在开发过程中发现并修复的问题：

趋势预测公式写错了。最初预测值是从回归线的原点外推的，而不是从当前最新值外推。这意味着如果数据点间隔不均匀，预测值会严重偏离。修复为 predicted = current_value + slope × hours。

标准差用了总体标准差。异常检测用 ÷n 还是 ÷(n-1) 看起来是小问题，但传感器数据通常样本量不大，Bessel 校正对阈值影响明显。已改为样本标准差。

决策引擎只看上升趋势。最初只对上升趋势（振动升高、温度升高）触发决策，完全忽略了下降趋势（流量下降、压力下降）。在工业场景中，下降同样危险。现在双向都会触发。

中文连接器的 listen() 是空壳。企业微信、钉钉、飞书的监听方法最初只是 await asyncio.Event().wait()，实际不会接收任何消息。后来用 asyncio.start_server 实现了真正的 Webhook HTTP 服务器。

这些 bug 都不算高深，但在实际使用中会直接导致功能失效。写出来是觉得，做这类项目的同行可能也会遇到类似的问题。

当前状态和局限

坦率地说，这个项目目前的状态：

能做的：

• 基本的 Agent 对话和工具调用链路是跑通的
• 自主监控 → 决策 → 执行的端到端流程可以工作
• 中文实体解析在国内环境下可用
• 连接器扩展机制是清晰的，添加新连接器不难

做不到或做不好的：

• 没有生产环境验证。所有测试都是基于模拟数据和本地文件
• LLM 的回答质量取决于你用哪个模型和怎么写提示词，框架本身不保证诊断准确性
• 趋势预测用的是简单线性回归，对非线性退化模式无能为力
• 工作流引擎是串行执行的，不支持并行步骤和复杂分支
• 文档 RAG 的检索质量取决于分块策略和向量模型，目前比较粗糙

需要谨慎对待的：

• 自动创建工单和发送通知是有风险的，建议先在沙盒模式下运行观察
• LLM API 调用有成本，高频监控场景下需要关注费用
• 传感器数据的可靠性和时效性依赖 IoT 连接器实现，框架不做保证

快速上手

最简单的方式：

pip install shuangan-ai[litellm]
# 使用本地 Ollama（免费，无需 API Key）
python examples/quickstart/agent_cn.py --llm ollama:llama3
或者用 DeepSeek：
bash
export DEEPSEEK_API_KEY="你的密钥"
python examples/quickstart/agent_cn.py --llm deepseek:deepseek-chat

项目里有完整的示例数据（6 台设备、5 个工单、传感器日志、设备手册），开箱可以跑通。

如果你也想做类似的事

几点不成熟的建议：

1. 先跑通最小闭环。一个传感器 + 一个报警 + 一个通知，比什么都接但什么都不深入有用
2. 领域模型很重要。通用 LLM 不知道你的设备编码规则和故障分类体系，需要显式建模
3. 中文分词值得投入。在工业场景里，"冷却水泵"和"冷却水 泵"是两回事
4. 沙盒模式是刚需。LLM 会幻觉，自动执行前一定要有人工确认的环节
5. 连接器是苦力活。每家 CMMS 的 API 都不一样，这块没有捷径

最后

双安是一个实验项目，它在探索"LLM + 工业维护"的一种可能形态。如果你也在这个方向上探索，欢迎交流。

项目地址：https://github.com/jiangnanboy/shuangan