水务环保企业问数智能体开发，设备运维、能耗指标智能查询项目

水厂、污水厂、管网与泵站每天都在产生数据。可当运行值班人员想确认某台设备近期的检修情况，或者能源管理员想弄清某个厂区的电耗为什么比同类厂区高，多数时候仍要走完提需求、等取数、看报表的流程。数据躺在系统里，答案却不在手边，这是不少水务环保企业在数字化推进到一定阶段后遇到的共同处境。某水务环保行业头部集团与数商云的合作，正是从这个具体问题切入：围绕设备运维、能耗指标等高频查询场景，开发面向业务人员的问数智能体，让业务人员用日常语言提问就能拿到可用的答案。以下从背景、需求、方案、落地与成效几个层面，还原这个项目的实际过程。

一、项目背景：数据家底不薄，取数体验却跟不上

1. 查询需求从少而重变成多而急

(1) 集团业务覆盖原水、供水、污水处理、污泥处置以及管网泵站运营，下属厂站分布在不同区域。设备台账、检修工单、运行记录、能耗与药耗数据分别沉淀在资产管理系统、生产运行系统和能源管理系统里。数据并非没有，而是散落在不同系统中，彼此之间缺少业务语义上的连接。

(2) 提查询的人在变。过去主要是管理层和数据岗，现在运行值班、设备工程师、工艺工程师、能源管理员都在提，而且问题发生的时点就在现场。等报表走完流程，工况可能已经过去了，答案的时效性打了折扣。

(3) 问题的形态也在变。从把数据拉出来，变成追问原因和横向比较。前者要归因，后者要找到可比对象，靠预设好的固定报表很难回答。

2. 既有报表体系覆盖常规题，覆盖不了追问

(1) 报表按预设维度生成，维度一换就要重新提需求，走排期、开发、验证的流程。业务侧的体验是，问题问出去以后要等，等着等着就不问了。

(2) 数据团队被重复取数占住。相同口径、相近维度的需求，不同部门反复提，工程师反复写，真正需要专业判断的指标治理和模型优化反而往后排。

(3) 时间一长，业务侧形成一个印象：取数成本高，能不查就不查。数据平台投入不小，实际使用率却被这个习惯压住，数据资产没有发挥出应有的价值。

3. 选型时提出的硬性条件

(1) 用业务语言提问。使用者不需要懂表结构、字段名和关联关系，问的应该是某个厂区的电耗为什么偏高这类问题，而不是从哪张表取哪个字段。

(2) 答案要能解释。结果从哪个口径来、按什么范围统计、过滤了哪些条件，要能回溯。没有可解释性的答案，在运维和能源管理场景里没人敢用。

(3) 权限要跟人走。区域负责人看全域，厂站人员看本站，不同岗位对成本类、设备类数据的可见范围不同，这套规则必须落到问数入口上。

(4) 场景要能生长。新指标、新问法通过配置扩展，不靠一次次改代码。否则智能体上线即定型，很快会被业务抛下。

这几条看起来朴素，放到实际系统里却互相牵制。问得越自由，管住越难；管得越严，体验越差。项目真正的难点，是在自由与可控之间找到平衡点。

二、需求拆解：先把想问什么梳理清楚

问数智能体不是把大模型接到数据库上就能用。项目组在开发前花了大量时间做需求梳理，把业务人员真正会问的问题收集上来，按场景归类，再判断哪些适合交给智能体，哪些还需要人工判断。

1. 设备运维场景：从查得到到看得懂

(1) 查设备本身。设备装在哪、属于哪个工艺段、型号与维保单位是什么。这类问题看起来简单，实际要跨资产系统与生产系统拼接，人工查的时候经常要在多个界面之间切换。

(2) 查状态与历史。近期有没有检修、故障描述写了什么、处理结果如何、换过哪些备件。难点在工单里的文本描述不规范，同一类故障有多种写法，需要做语义归一。

(3) 查对比与分布。同类设备在不同厂站的故障集中度、同一工艺段设备的检修频次差异。这类问题直接指向管理动作，比如某类设备是否该调整维保策略。

表格里的问法来自一线访谈，不是凭空设计的测试题。项目组把它们作为后续验收的基础语料，问数智能体能不能答、答得准不准，都拿这些真实问法来检验。

2. 能耗指标场景：口径统一是前提

(1) 指标先要定义清楚。电耗统计的是总用电还是工艺用电，是否包含办公与生活用电；单位处理量能耗的分母是进水量还是处理水量；药耗按有效成分折算还是按商品量计。口径不定，同一问题在不同部门会得到不同答案，智能体只会把这种混乱放大。

(2) 对比类问题需求密集。同比、环比、同类厂站横向对比、实际值与计划值对比。业务人员关心的不是孤立数值，而是这个数值处于什么位置。

(3) 异常定位最难。某个厂区能耗抬升，要沿着处理量变化、进水水质波动、设备运行方式调整、季节因素等方向拆开看。智能体在这类问题上适合做拆解辅助，把相关指标摆出来，结论仍由人判断。

3. 权限、口径与可解释性的底线要求

(1) 权限方面，按组织、厂站、岗位控制数据范围，规则要与既有账号体系一致，不能在问数入口另建规则。

(2) 口径方面，同一指标在全集团只能有一个定义，变更要留痕，历史答案按当时的版本可追溯。

(3) 可解释方面，每个答案都要说明取数范围、统计周期和过滤条件，让使用者知道这个数是怎么来的。

需求梳理的产出不是一份功能清单，而是形成约定：哪些问题智能体直接答，哪些问题答一半并提示风险，哪些问题明确不答、转人工处理。这些约定后来成为项目验收和运营的基础。

三、方案设计：让智能体听懂业务话

数商云在这个项目中采用的是指标层、语义层、智能体层与应用层分层的建设思路。分层的目的不是把架构画得好看，而是让每一层的责任清晰，出问题时能快速定位是口径错了、语义没映射上，还是数据源本身有问题。

1. 指标层先行，语义层承接，智能体做编排

(1) 指标层把设备运维与能耗相关的核心指标定义、计算逻辑、数据来源固定下来，形成可复用的指标资产。后续所有问数都优先走指标，而不是让模型直接拼查询语句。

(2) 语义层负责把业务术语、行业俗称、同义词映射到指标和字段。设备运维里的“大修”“小修”“抢修”，能耗里的“电单耗”“单位电耗”“吨水耗电”，说的是同一件事，叫法却不一样，语义层就是解决这个问题的。

(3) 智能体层负责意图识别、查询规划、工具调用、结果组织与追问引导。它不直接面对原始数据表，而是调用已经治理好的指标与查询工具，这样答案的稳定性才有保障。

(4) 应用层提供统一问答入口，嵌入到业务人员日常使用的门户和数据看板中。工具要出现在业务动线上，而不是让人专门去找一个系统登录。

指标层先行这个选择在项目中很关键。行业里不少问数项目先做交互、后补指标，前期演示效果不错，一到真实业务就答不准，返工成本很高。

2. 指标与口径治理是地基

(1) 联合业务部门梳理指标清单，逐条确认定义、计算公式、数据来源和责任部门。设备类的指标相对客观，能耗类指标争议多，讨论过程本身就是统一认识的过程。

(2) 建同义词库。把一线人员的口语表达收集起来，映射到标准指标。同义词库不是建完就结束，而是在使用中持续补充，业务人员怎么问，库里就收什么。

(3) 口径变更走审批和版本管理。指标定义调整后，历史答案仍按当时版本可查，避免前后数据对不上却又说不清原因。

3. 问数交互：把问不准的概率降下来

(1) 意图识别与澄清。问题缺少时间范围、厂站范围或对比对象时，智能体先反问，不硬猜。宁可多问一句，也不要给一个看似完整、实际错误的答案。

(2) 多轮追问。保留上下文，支持接着问按厂站拆开看看、换成累计口径再算这类延续性问题。业务分析本来就是层层递进的，一问一答式的交互很难支撑。

(3) 答案组织。结论先行，表格随后，必要时补充趋势描述和口径说明。能耗指标分析场景里，业务人员最需要的是判断，而不是一堆原始数字。

(4) 兜底机制。识别不了、数据缺失、权限不足，都要给出明确说明，并提供转人工或转数据团队的入口。兜底记录还是优化线索，哪些问题高频失败，下一轮就优先补。

4. 权限、安全与可追溯

(1) 权限继承既有账号体系，组织调整后问数范围自动跟随，减少维护成本。

(2) 敏感字段做屏蔽或聚合，成本类数据按岗位分级开放。

(3) 全链路留痕。谁在什么时间问了什么、系统调用了哪些数据、返回了什么结果，都要可查。留痕既是安全要求，也为后续分析业务关注点提供依据。

四、落地过程：窄场景跑通，再逐步铺开

问数智能体的建设很难在上线时就完全定型。项目组采取的策略是先选窄场景跑通，验证效果后再扩，避免一上来铺得太大、问题集中爆发。

1. 场景切口的选择

(1) 优先选高频、口径相对清晰、答错代价可控的场景。设备台账查询和能耗指标查询符合这些条件，被放在前面。

(2) 复杂归因类问题先做辅助。系统把相关指标和维度摆出来，提示可能的影响因素，但不直接下结论。这样做既降低了误判风险，也让业务侧逐步建立对工具的信任。

(3) 明确能力边界。哪些问题暂时不接，提前和业务部门讲清楚，比事后解释更有效。

2. 用业务反馈做调优

(1) 定期收集答得不对的问题，按口径问题、语义问题、数据质量问题、能力边界问题分类处理。不同原因对应不同责任方，避免所有问题都压在算法侧。

(2) 把典型问法固化进提示与规则。一线人员的表达方式有规律，同类问法处理过后即可复用。

(3) 数据质量问题回流到源头系统整改。问数智能体像镜子一样，把主数据不一致、工单填写不规范、能耗计量缺失这些问题照了出来。这些问题不解决，问数体验很难真正好起来。

3. 推广方式与使用习惯的迁移

(1) 先让愿意用的人用起来。设备工程师和能源管理员中对数据敏感的群体，是最早的种子用户，他们的使用反馈也最具体。

(2) 编制问法手册，把常用问法写成例子，降低上手门槛。手册不追求大而全，按岗位组织，设备岗看设备部分，能源岗看能耗部分。

(3) 把问数入口嵌到看板和数据门户里。业务人员看到异常指标，顺手就能问一句，这个动作才可能形成习惯。

推广过程中，项目组没有把使用量当成唯一指标，更关注的是问题解决率，也就是业务人员问完之后有没有得到可用的答案。使用量高但答案不被采纳，说明方向偏了。

五、项目成效：查询方式变了，工作方式跟着变

系统上线并稳定运行后，变化先出现在查询环节，随后传导到工作方式上。项目组在复盘时把成效分为几个方面来看。

1. 设备运维侧

(1) 查设备信息不用再跨系统切换。设备位置、工艺段归属、维保单位、检修历史可以在统一问答入口里拿到，设备工程师到现场之前就能把情况了解清楚。

(2) 检修记录从文本变成可检索的结构。同类故障的历史处理方式可以按设备聚合查看，新问题有参照，减少重复摸索。

(3) 设备管理从被动响应转向主动关注。哪些设备故障集中、哪些维保策略需要调整，可以在日常查询中发现问题，而不是等到故障发生后才回头分析。

2. 能耗管理侧

(1) 指标口径统一后，厂站之间的横向对比有了共同语言。以往讨论能耗，先要花时间争论口径，现在可以直接进入分析。

(2) 异常发现更早。能源管理员在日常查询中就能发现某厂区指标偏离，及时排查，不必等到定期复盘。

(3) 能耗指标分析从阶段性工作变成日常动作。查询成本降下来之后，分析的频次自然上去，节能机会也更容易被看见。

3. 数据团队侧

(1) 重复取数需求被分流。常规查询由业务人员自助完成，数据团队把精力放在指标治理、数据质量与模型优化上。

(2) 指标资产越用越厚。每次口径澄清、每个新增同义词，都会沉淀到指标与语义层，后续项目可以直接复用。

(3) 数据质量问题暴露得更快。业务人员问不出来，往往能快速指向某个源系统的数据问题，整改有了明确方向。

4. 管理侧

(1) 问数过程留痕，形成对业务关注点的观察。哪些指标被反复问、哪些厂区被频繁对比，能反映管理重心和风险点。

(2) 决策讨论引用同一口径，减少会上对数、会后再核的情况。

(3) 数据文化从口号落到动作。业务人员开始习惯用数据提问，这比任何培训都更有效。

六、客户评价与经验沉淀

1. 客户评价

该集团项目负责人在复盘时提到，系统带来的变化不只是查数快了，更重要的是业务人员提问的方式变了。“以前大家习惯说要一份什么表，现在会直接问某个厂区的能耗为什么偏高、某类设备的故障是不是集中。问题问得更具体，说明大家开始把数据当成日常工具，而不是需要申请的稀缺资源。”

负责设备管理的业务人员则更关注答案的可解释性。“问数给出来的结果会带口径说明，能看出来源，这一点在运维场景里很重要。设备判断容不得含糊，知道数据是怎么来的，才敢拿它做决定。”

2. 可复用的经验

(1) 指标治理不能后置。问数智能体的上限由指标体系的成熟度决定。交互做得再顺，口径不清楚，答案就不可信。项目前期在指标梳理上投入的时间，后期都以更少的返工收了回来。

(2) 智能体是入口，不是替代。它替代的是重复取数和初步筛选，替代不了业务判断。把归因结论的责任交给人，工具的可信度反而更高，使用范围也更稳。

(3) 场景选择要克制。高频、口径清晰、答错代价可控的场景先做，复杂场景后置。铺得太开，问题会集中暴露，业务侧的信任一旦流失，再挽回成本很高。

(4) 运营机制要跟上。问数智能体不是上线即完成的项目，答不准的问题怎么收集、口径变更怎么审批、同义词怎么补充，都需要明确的责任人和节奏。没有运营，工具会慢慢脱离业务。

对水务环保企业来说，设备运维与能耗指标是两个绕不开的管理主题。数据智能体的价值，不在于技术本身有多新，而在于它能不能把分散的数据变成业务人员随手可用的答案。数商云在这个项目中做的，是把指标治理、语义映射、权限控制和交互设计拼成一条可运行的路径，让问数从演示走向日常。这条路径对其他水务环保企业同样适用：先把口径理清楚，再选窄场景验证，然后用运营机制把它养起来，问数智能体才可能真正沉到业务里。