基于模型的 Agent

🏦 场景与客户

某制造企业的设备运维助手。设备现在处于什么状态、下一步会怎样，不是一眼能看到的——要结合历史工单、传感器趋势、维修记录一起推断。更麻烦的是信息常常不全：老设备没有传感器，有的工单描述只有一句话。

客户要的是系统能维护一份「现在到底什么情况」的判断，并在信息不全时说清哪里不知道。

📅 实施节奏

• 第 1–2 周：梳理业务真正关心的状态集，收敛到可维护的范围
• 第 3–4 周：搭状态机与事件接入，先跑通单一设备类型
• 第 5–6 周：接入趋势判断与备件建议，与老师傅结论对照
• 第 7 周起：扩到同类产线，保留人工校正入口

🗝️ 方案要点

• 状态显式维护：设备、工单、备件各有一份状态，不靠模型记忆
• 观察不完整是常态：缺数据时明确标「未知」，不做无依据推断
• 预测带不确定度：给区间与依据，不给单一结论
• 状态变更走事件：所有变化有来源事件，可回放、可追责

⚖️ 选型与权衡

🚧 实施难点与排查

• 模型与现实脱节：状态机里还是运行中，实际已停机检修。加人工校正入口并记录校正原因
• 传感器缺失：老设备没有数据源。用人工巡检补点，不做无依据推断
• 状态爆炸：状态组合过多难以维护。按业务关注点收敛状态集，砍掉无人使用的状态
• 预测被当结论用：一线直接按预测备件。明确标注为参考，采购仍需审批

💵 成本与收益

• 成本：状态建模与数据接入是主要工程投入，模型本身开销可控
• 收益：非计划停机减少、备件周转改善，属可量化的运维收益
• 注意：收益高度依赖数据质量，接入不全都难以兑现

🛡️ 风险与保障

• 安全：涉及停机、检修的决策必须人工确认后执行
• 数据：设备数据涉生产机密，按等级授权访问
• 可追溯：每次状态变更可回溯到来源事件
• 降级：数据中断时退回人工巡检流程，系统不阻塞现场

♾️ 可复用与演进

• 可复用到供应链在途、订单履约、能耗管理等状态驱动场景
• 演进方向：从单设备到产线，再到园区级
• 再进一步：状态模型与知识库打通，状态变化直接触发处置建议