（十五）YModbus自动化调用：CLI、HTTP、MCP怎么服务 AI Agent

GitHub 项目地址https://github.com/lidecong133/YModbus前面讲了协议、库、CLI、主站工具、从站工具。这一篇聊一个后面的方向怎么让这些能力被脚本、测试平台、AI Agent 稳定调用。我不太喜欢把这件事说成“给软件加 AI”。真正有用的不是在界面上放一个聊天框而是把主站读取、从站模拟、报文查看、诊断导出这些能力整理成清楚的工具入口。AI Agent 不应该靠猜按钮位置来操作工业软件。它应该调用一个明确的命令或接口传入参数拿到结构化结果。为什么不建议让AI去点界面图形界面是给人用的。人可以看按钮、看表格、看颜色。AI 如果靠截图和鼠标去点也能做一点事但很脆弱。比如你让它排查一个设备连接192.168.1.10:502读取 UnitId1从地址0开始读 10 个保持寄存器连续读 5 次看数值有没有变化如果失败整理错误和报文如果这些动作只能通过界面完成AI 就要识别窗口、点按钮、等刷新、读表格。按钮位置变一下、窗口被挡一下、语言切换一下都可能失败。如果有 CLI 或 HTTP 接口它只需要调用ymodbusread-holding-registers--host 192.168.1.10--port 502--unit-id 1--address 0--quantity 10返回 JSONAI 再判断下一步。这种方式才稳定。第一层先把CLI做好最容易落地的是 CLI。YModbus.Cli 已经是 JSON-first 的思路适合脚本和 AI Agent。例如读取保持寄存器ymodbusread-holding-registers--host 192.168.1.10--port 502--unit-id 1--address 0--quantity 10返回结果里有success、values、hexValues、地址、数量、端点信息。这对 AI 很友好。它不需要从一段人类描述里猜结果只要看字段。一个很实际的自动化场景是对比两台设备读 A 设备地址0..20读 B 设备地址0..20把不同地址列出来生成一段排查结论这件事用界面做会变成复制粘贴。用 CLI 做就可以变成一段可重复执行的流程。写入必须有安全挡板CLI 里写入默认 dry-run这点很重要。AI 可以帮你准备写入命令但不应该默认真的写设备。比如ymodbuswrite-single-register--host 192.168.1.10--port 502--unit-id 1--address 10--value 500不加--confirm就不真正写。真正写入必须明确ymodbuswrite-single-register--host 192.168.1.10--port 502--unit-id 1--address 10--value 500--confirm这条规则以后给 AI Agent 调用时也应该保留。读操作可以自动化多一点。写操作必须有明确授权。批量写、循环写、写真实设备更要谨慎。第二层控制正在运行的桌面工具CLI 适合直接读写设备。但有时候你想控制已经打开的主站/从站工具比如打开一个工作区让主站连接让主站读一次让从站启动或停止对正在运行的桌面工具做冒烟测试这时候可以用本地 Agent Bridge。它不是让 AI 去点 WinForms 控件而是在桌面程序旁边开一个本机 HTTP 控制口。关键原则默认关闭只监听127.0.0.1请求必须带 token用 CLI 或 HTTP 调用不直接操纵按钮启动主站工具时可以显式开启.\YModbus.MasterApp.exe--agent--agent-token 0123--agent-port 50521启动从站工具.\YModbus.SlaveApp.exe--agent--agent-token 0123--agent-port 50522然后用 Workbench CLI 控制dotnet run--project.\YModbus.Workbench.Cli\YModbus.Workbench.Cli.csproj--master status--token 0123 dotnet run--project.\YModbus.Workbench.Cli\YModbus.Workbench.Cli.csproj--master connect--token 0123 dotnet run--project.\YModbus.Workbench.Cli\YModbus.Workbench.Cli.csproj--masterread-once--token 0123 dotnet run--project.\YModbus.Workbench.Cli\YModbus.Workbench.Cli.csproj--slavestart--port 50522--token 0123这就很适合自动化验证。比如发布前自动启动从站、打开主站、读一次保持寄存器、确认返回成功。这比人工点一遍更可重复。一个更贴近现场的例子假设你有一个客户发来的工作区说主站读不到数据。AI Agent 如果有工具入口可以这样做打开从站模拟工作区启动从站打开主站工作区执行一次读取如果失败读取主站和从站的状态导出最近报文总结是连接问题、站号问题、地址问题还是异常响应这里 AI 做的是“串流程”和“整理证据”。人仍然负责判断是否要对真实设备写入、是否要修改现场参数。这个边界很重要。第三层HTTP接口适合做中间层Agent Bridge 的 HTTP 形态大概是这样GET http://127.0.0.1:50521/status X-YModbus-Agent-Token: 0123执行命令POST http://127.0.0.1:50521/command Content-Type: application/json X-YModbus-Agent-Token: 0123 { command: read-once, arguments: {} }返回结构保持简单{success:true,message:Read succeeded.,data:{}}这个接口不一定直接暴露给最终用户。它更像一个中间层CLI 可以调用它测试程序可以调用它将来的 MCP Server 也可以调用它。这样 WinForms 界面不用被 AI 直接操作核心逻辑也能复用。第四层MCP适合最后封装MCP 的价值是把这些能力注册成 AI Agent 能识别的工具。比如modbus_read_holding_registersmodbus_scan_unitsworkbench_master_read_onceworkbench_slave_startworkbench_open_workspaceworkbench_get_status但我不建议一开始就直接做 MCP。更稳的路线是先把核心库做好再把 CLI 做稳桌面工具用本地 Agent Bridge 暴露有限命令最后 MCP 只是包一层工具描述这样即使不用 MCPCLI 和 HTTP 接口本身也有价值。哪些能力可以放给AI我会分级。低风险可以自动化查看状态读取线圈和寄存器扫小范围 UnitId获取报文打开工作区启动本机从站模拟生成报告中风险需要明确确认写单个寄存器写单个线圈修改从站模拟数据执行较大范围扫描高风险不建议自动放开批量写真实设备循环写真实设备长时间高频轮询修改关键设备参数对未知地址范围盲扫这个边界不是为了限制 AI而是为了保护现场。工业通讯工具跟普通办公软件不一样。读错一般还能解释写错可能影响设备。返回结果要带诊断信息给 AI 调用的接口不能只返回一句“失败”。最好带上是否成功端点UnitId / SlaveId功能码起始地址数量数值十六进制值错误类型异常码请求/响应报文耗时比如读取失败时如果能告诉 AI “设备返回 Illegal Data Address”它就能建议检查地址和数量。如果只是 “timeout”它会建议查 IP、端口、站号、串口参数。返回信息越结构化AI 越不容易胡猜。我希望YModbus最后变成什么样YModbus 不只是一个 NuGet 包。我更希望它慢慢变成一套完整的 Modbus 调试底座核心库给开发者用CLI 给脚本和自动化用主站工具给现场读设备用从站工具给模拟和复现问题用Agent Bridge 给运行中的桌面工具提供本地控制入口MCP Server 给 AI Agent 提供标准工具接口这样以后你可以直接说帮我读一下192.168.1.10的 1 号站地址0..20如果失败把可能原因按优先级列出来。AI 不需要猜按钮。它调用工具拿结果整理证据。人做最后确认。这才是我觉得 AI Agent 在工控调试里比较靠谱的用法。