LLM不读寄存器：用语义工具层让Modbus解码交给确定性代码

你让 LLM 直接读一个 Modbus 寄存器：地址 40001 对应的是电压还是温度？如果它是 32 位浮点数，那高字在前还是低字在前？要不要乘系数？如果设备手册写的是数据地址，而实际工具用的是协议地址，又差了几格？这些问题抛给通用大模型，它通常会给你一个结构完整、自信满满、但完全不能用于现场调参的答案。

最近我在做工业设备数据接入时试过几款主流 LLM。结论很明确：它们可以解释 Modbus RTU 报文，可以写出 Modbus Poll 这类调试工具的基本用法，可以告诉你 03 功能码读的是保持寄存器。但如果你把一份真实的寄存器原始值贴在对话里，让它还原成“电压 220.5V、状态位 bit0=1”这样的物理量，它给出的结果经常是错的。这种错还很难发现，因为输出看起来像模像样，可能只有小数点后面的数字不对，或者在某个状态位上差一位。

所以我做了一个不太一样的调整：与其想办法让 LLM 变聪明去理解寄存器，不如把解码这件事从模型那里整个拿掉。让确定性代码去解析协议，让 LLM 只通过工具接口消费已经语义化后的 JSON。LLM 负责理解用户意图和生成回答，设备通信和数值解码交给一个中间层。

这正是标题里那句话的落地方式：LLMs are bad at decoding Modbus registers, so I made sure they never have to。

1. Modbus 寄存器解析根本不是 LLM 该干的活

1.1 寄存器解码表面简单，本质是协议约定

Modbus 是一个非常“老”但极其常见的工业通信协议。它的数据模型分为线圈、离散输入、输入寄存器、保持寄存器等几类。对于普通开发者来说，最常用到的是保持寄存器，因为很多智能电表、传感器、PLC 都通过它对外提供数据。

单个保持寄存器是 16 bit，可以表示一个无符号整数、有符号整数，也可以表达状态位。但实际设备里的“电压”“温度”往往不是 16 bit 能装下的。于是设备厂商会把两个甚至更多寄存器拼在一起，组成 32 位整数、32 位浮点数，或者更复杂的结构。

这时问题就来了：

• 两个寄存器，谁在高位，谁在低位？
• 寄存器内部字节是大端还是小端？
• 32 位浮点是否还有字交换、字节交换的变体？
• 原始值是 0 到 65535，还是带符号？
• 最终要不要乘 0.1、0.01 之类的缩放系数？
• 设备手册写的是“寄存器地址 40001”，但协议报文里的地址可能是 0x0000。映射关系到底差多少？
• 某些值不是一个数字，而是打包在一个 16 位字里的多个状态位，每个 bit 代表一个告警信号。

这些规则从设备手册到实际代码转换，每一步都需要严格按照约定执行。中途只要有一个约定理解错，结果就是错的。

你可能会说：这不就是查手册、写代码吗？对，但对 LLM 来说，这恰恰是最容易出问题的环节。因为它不是“查手册”和“写代码”两种能力的简单叠加，而是要求模型在概率生成的过程中，始终严格遵循一个不常见的、由设备厂商自定义的编码规则。

1.2 让模型直接解码为什么错得如此隐蔽

LLM 的本质是概率语言模型。它根据上下文预测下一个 token。处理“根据 Modbus 协议把寄存器值还原成物理量”这种任务，它需要的是确定性计算：字节拼接、符号扩展、字节序调整、浮点解析。这些步骤每一步都是精确的，但 LLM 并不天然具备这种精确性。

我见过很多真实案例：

• 模型把0x1234和0x5678两个寄存器拼成0x12345678，结果应该是两百多万，它算出来是“12345678”对应的十进制，但因为符号位处理错误，得到负数。
• 模型搞错字节序，把0x12 0x34按小端读成0x3412，数值差了好几倍。
• 模型看到data_type: "float32"，不知道应该先读两个寄存器再解析，直接把第一个寄存器的整数值当成浮点数。
• 模型在结果里“编造”了一个合理的电压值，比如 220.5V，但原始寄存器值根本对应不到 220.5。

更麻烦的是，这类错误不会直接报错。LLM 不会说“这里我不确定”，它通常会给出一个看起来正常的答案。在工业现场，一个“看起来正常但实际错误”的数值，比一个明显的报错更可怕。因为你会下意识相信它，然后带着错误的判断去操作设备。

所以我的判断很明确：不要让 LLM 参与寄存器解码，无论它能不能在单次测试里碰巧答对。因为概率模型的成功不可控，而工业数据要求确定性。

2. 把解码从模型里拆出去：一个三层语义接口

2.1 核心判断：LLM 不应该懂字节序

我们通常会习惯性地认为，一个“智能”系统应该什么都能做。于是让 LLM 直接解析 Modbus 寄存器，听起来像是一个很自然的“智能化”需求。但工程上的正确答案往往是反过来的：越是需要确定性、一致性、可审计的步骤，越应该交给普通代码；越是需要理解模糊意图、组织语言、综合上下文的任务，越应该交给 LLM。

字节序、缩放、地址映射、状态位解析，全部属于“确定性计算”。这些计算不需要“智能”，需要的是“不犯错”。而 LLM 恰恰会在这种地方犯错。

所以我做的方案里，LLM 根本不需要知道字节序是什么。它只需要知道：这个设备有一个工具函数叫做read_device_values，调用它之后，会返回一个已经变成人能看懂的 JSON，里面有电压、电流、温度、告警状态。

2.2 三层结构：通信层、解析层、语义层

我采用的架构可以拆成三层：

通信层可以基于常见的 Modbus 库实现，比如 Python 生态里的 pymodbus，或者其他语言的对应实现。这一层不应该有任何“智能”业务，只管收发协议帧。

解析层是核心。它根据设备手册定义好的映射表，把[0x1234, 0x5678, 0x0003]这样的原始数组，转换成：

{ "line_voltage": 220.5, "alarm_status": { "over_voltage": false, "under_voltage": true } }

LLM 只消费这个 JSON。它不需要知道line_voltage是存在 40001 还是 40002，也不需要知道它是怎么从两个寄存器里拼出来的。

2.3 为什么这样做比微调模型更可持续

有些人可能会想：与其搞这么一层中间解析，不如拿一批“寄存器原始值-正确结果”数据去微调模型，让它学会解码。

这个思路表面上可行，但落地时有几个问题：

• 设备型号一变，寄存器地址、字节序、缩放系数都变了，微调的样本就失效了。你要重新整理数据集、重新训练。
• 微调后的模型仍然是一个概率模型。它即使见过类似样本，也可能在边缘 case 上出错。
• Modbus 设备的“点表”通常不算复杂，但差异化极强。用微调去记忆这些细节，成本高、收益低。
• 调试时你还需要能定位错误：是模型理解错，还是数据源错？如果模型直接输出结果，中间没有解析层，你很难区分。

解析层方案把“设备差异”变成了“配置文件差异”。新增设备时，不需要改模型，只需要新增一个设备描述文件，然后在工具注册表里增加一个实例。

这才是可持续的设计。

3. 最小可用方案：映射表、解码器、工具调用

3.1 先做设备描述文件：把寄存器表变成配置

落地第一步，是把设备手册里的寄存器表整理成一个机器可读的描述文件。常见做法是 YAML 或 JSON。

下面是一个简化的示例结构，重点看流程，不是完整实现：

{ "device": "example_energy_meter", "endpoint": "192.168.1.10:502", "unit_id": 1, "registers": [ { "name": "line_voltage", "register": 0x0000, "length": 2, "data_type": "float32", "byte_order": "big_endian", "scale": 1.0, "unit": "V" }, { "name": "alarm_status", "register": 0x0002, "length": 1, "data_type": "uint16", "bits": { "over_voltage": 0, "under_voltage": 1 } } ] }

注意几个容易踩坑的地方：

• register字段要明确是协议地址还是数据地址。如果用的是设备手册里的 PLC 地址 40001，需要映射成协议地址 0x0000。
• byte_order的取值必须在自己系统里标准化。不同库可能叫big_endian、little_endian，有的还要区分word_order和byte_order。如果你不做内部约定，后面一定乱。
• length是寄存器个数。float32通常占 2 个寄存器，不是 1 个。
• 对于状态位，不要只用 int 返回，建议拆成具名字段，方便 LLM 直接理解。

3.2 写一个确定性解码器：把原始值变成语义字段

通信层拿到原始寄存器数组后，解析层根据配置转换成 JSON。这里的关键是：无论什么情况，解码逻辑必须可预期、可单测、可审计。

下面是一个简化版的 Python 示意：

def decode_registers(raw_values, mapping): result = {} offset = 0 for reg_conf in mapping["registers"]: length = reg_conf["length"] raw = raw_values[offset:offset + length] offset += length value = decode_by_type( raw, data_type=reg_conf["data_type"], byte_order=reg_conf["byte_order"] ) if reg_conf.get("scale"): value = value * reg_conf["scale"] if "bits" in reg_conf: result[reg_conf["name"]] = { bit_name: bool(value & (1 << bit_index)) for bit_name, bit_index in reg_conf["bits"].items() } else: result[reg_conf["name"]] = value return result

这段代码只是流程示意。实际项目中，decode_by_type需要对每种数据类型、字节序组合做完整实现，并且用已知的寄存器值做单元测试。

有一点必须提醒：不要在没有验证的情况下直接套用某个库的默认字节序。不同库对big_endian的定义可能不同，尤其涉及 32 位浮点时，有的设备是“寄存器顺序交换但字节不交换”，有的则是“完全大端”。配置字段里最好显式提供，而不是依赖库默认值。

3.3 给 LLM 的工具：只暴露语义函数，不暴露寄存器

解析层完成后，需要把能力封装成 LLM 可以调用的工具函数。无论你用的是 OpenAI Function Calling、开源模型的 Tool Use，还是自建的 Agent 框架，思路都一样：

只暴露语义函数，不要暴露底层寄存器函数。

比如可以暴露：

def read_device_values(device_id: str, group: str = "default") -> dict: """读取指定设备的当前测量值，返回已转换为工程单位的数据""" raw_values = read_modbus_registers(device_id) device_mapping = load_device_mapping(device_id) return decode_registers(raw_values, device_mapping)

对应的工具声明，通常会包含一个 JSON Schema：

{ "name": "read_device_values", "description": "读取指定设备的当前测量值，返回已转换为工程单位的数据", "parameters": { "type": "object", "properties": { "device_id": { "type": "string", "description": "设备标识，比如 example_energy_meter" }, "group": { "type": "string", "description": "寄存器分组，默认 default" } }, "required": ["device_id"] } }

为什么不要暴露read_raw_register(register_address: int)？

因为只要暴露了原始寄存器地址，LLM 就多了一个自己拼地址、猜字节序的机会。哪怕它只是偶尔拼错，也会破坏整体确定性。工具层应该把“设备内部细节”屏蔽掉，给模型的不是“可能性”，而是“结果”。

如果某些场景确实需要 LLM 读原始寄存器，也应该是在后端函数里明确写清楚映射规则，而不是让模型自己决定传什么地址。

3.4 最小链路验证的三个步骤

第一次搭建时，不要急着直接问 LLM 复杂问题。按照下面的顺序走一遍：

1. 先用 Modbus Poll 或自己的调试脚本读取设备原始寄存器值，记录下一组真实数据。
2. 把这一组原始值喂给解码器，对比输出是否与设备手册里的预期一致。
3. 再通过 LLM 工具调用入口问一句“现在的电压是多少”，观察模型是否只调用了read_device_values，而没有任何自行计算或猜测。

如果第 2 步就错了，不要继续去调 prompt，先修解析层。我见过太多人跳过前面两步，直接拿 LLM 的错乱输出去调试 prompt，最后发现根因在寄存器映射表，白白浪费了大量时间。

4. 工程化落地时要补上的细节和排查顺序

4.1 错误信息要按 LLM 能理解的结构返回

设备通信不是永远稳定的。Modbus TCP 可能会超时，RTU 可能收不到响应，寄存器可能越界。这些错误不能简单返回一个字符串 “error”。LLM 接收到这样的错误信息后，无法判断是设备离线、地址错误还是权限问题，它只能基于训练数据编一个“可能的解释”。

更好的做法是让工具统一返回结构化错误对象：

{ "status": "timeout", "reason": "device_not_reachable", "suggestion": "check network or device power", "read_at": "2025-04-01T10:30:00Z" }

这样 LLM 至少能告诉用户：“当前设备连接超时，建议检查网络或设备电源。”而不是“我无法读取数据，可能电压有问题。”

4.2 寄存器映射文件的长期维护策略

设备点表不是一成不变的。相同型号的设备，固件版本不同，寄存器偏移可能变化。新增设备时，最怕的不是写代码，而是 mapping 文件里出现重复地址、长度越界、类型不匹配。

建议在系统启动时做一次配置校验：

• 检查每个 register 地址和 length 是否越界。
• 检查不同字段是否指向同一个寄存器区域。
• 检查 data_type 和 length 是否匹配，比如 float32 必须 length=2。
• 检查 byte_order 是否在支持列表内。

把这个校验做成独立模块，而不是在读取时才报错。配置错误越早发现，影响越小。

4.3 写操作必须白名单化

读操作相对安全，写操作要格外谨慎。不要让 LLM 通过“写保持寄存器地址 0x0001 = 50”这种方式去控制设备。应该封装成具名操作：

def write_setpoint(device_id: str, setpoint: float) -> dict: # 内部检查 setpoint 范围 # 再映射到 Modbus 寄存器 ...

这样 LLM 只需要理解“setpoint 是目标温度”，而不需要理解它应该写到哪个寄存器。后端函数负责校验范围、权限、限幅和写入后的确认读取。

在工业控制场景中，写操作一定要有额外保护：操作确认、数值范围检查、硬件互锁、操作日志。这些不能依赖 LLM 自觉。

4.4 数据新鲜度：缓存、刷新与时间戳

LLM Agent 在回答多轮问题时，可能会多次调用同一个工具。如果每次都去设备重新读一次，既慢又可能给设备增加负担。所以工具层可以做短时间缓存。

但缓存会带来新问题：用户问“现在电流多少”，如果拿到的是 10 秒前的数据，可能不够新鲜。建议在返回结果里带上read_at时间戳，同时给工具增加一个force_refresh参数。这样模型可以根据用户语气判断是否需要强制刷新。

如果设备数据变化很快，比如毫秒级，那这种工具调用模式本身就不适合。你应该考虑更直接的实时推送链路，而不是让 LLM 在中间做问答。

4.5 排查链路：问题到底出在哪一层

当最终回答不对时，必须按层级定位，而不是一上来就改 prompt。

我的排查顺序是：

1. 先看 LLM 有没有调用工具。如果没有调用，说明模型没有理解意图，这是 prompt 或工具描述的问题。
2. 如果调用了工具，看工具返回的 JSON 是什么。返回本身是否合理？如果合理，那就是模型在生成回答时曲解了数据。
3. 如果 JSON 不合理，看解码器输出。拿同一组原始寄存器值直接跑解码函数，看是否和预期一致。
4. 如果解码器输出不对，看映射表和原始值。用 Modbus Poll 等工具读一下原始寄存器，确认数据源。
5. 如果原始值本身就不对，再看通信层：地址、从站号、Byte order、功能码。

这个顺序的核心是：从模型往底层逐层排除。不要一上来怀疑模型能力不够，很多时候问题在底层数据，而不是模型智商。

5. 这套方案对 LLM 应用开发的通用启发

5.1 不只是“智能问答”，而是“设备即 API”

把 Modbus 设备包装成“语义 API”之后，你会发现它的价值不只是给 LLM 用。同一个解析层，可以同时服务于：

• 传统 REST API 接口
• 前端看板
• 告警规则引擎
• 定时报表
• LLM 问答

也就是说，LLM 只是这套设备数据接口的其中一个消费方。当设备模型被结构化之后，所有上层应用都能受益。这也是我认为这个方案比“调 prompt 让模型懂 Modbus”更有价值的原因。

5.2 适用边界：这套方案适合谁，不适合谁

适合的情况：

• 需要让非技术人员用自然语言查询设备状态。
• 设备型号多，点表差异大，需要快速接入。
• 希望把设备数据统一成 JSON，供多个系统复用。
• 已有的 Modbus 通信代码稳定，只需要在上层加语义层。

不适合的情况：

• 对实时性要求极高的控制闭环，不允许中间再嵌入 LLM 调用。
• 点表非常少，只有几个寄存器，直接写死即可。
• 没有足够的工程资源维护映射表和解码器，只想临时问一次。
• 设备涉及严格的安全规范，且不允许外部 Agent 操作。

所以在动手之前，先判断你的场景到底需不需要“自然语言问答”这一层。如果不需要，就老老实实直接写定时读取。

5.3 沉淀一个通用框架：意图靠模型，数据靠代码，决策靠人

最后我想把这件事提炼成一个更通用的原则：

• 理解模糊意图，交给 LLM。
• 执行确定性转换，交给代码。
• 做出高风险决策，交给人。

Modbus 寄存器解码属于“确定性转换”，所以它不应该出现在 LLM 应该负责的范畴里。不只是 Modbus，其他很多和硬件、协议、数据格式相关的任务也是如此：解析二进制文件、计算 CRC、做数据校验、权限判断、交易金额计算，这些都应该由确定性模块来处理。

所谓让 LLM 不擅长的事情永远不发生，不是因为它能力不够，而是因为它本来就不该出现在那个位置。Modbus 只是其中一个例子，但它把这个道理揭示得很清楚：当模型无法稳定做好某件事时，最好的解决方案不是逼模型做得更好，而是重新设计系统，让模型根本不需要去做它。