7.1 AIoT 技术全景与演进

作者：张红元 · © 2016–2026 · 保留所有权利 · 版权与许可

本章展开智能体能力之前，先接住第 6 章的结论：微服务、容器化与可观测性构成的云原生底座，不只是让平台“跑起来”，它同时是智能体的运行面——模型调用、Tool 执行、会话状态与审计记录都落在这一底座上。没有第 6 章那套可部署、可伸缩、可观测的服务化平台，本章讨论的 Agent 能力只能在演示环境里存活。

7.1.1 AIoT 的定义与演进脉络

大屏弹出红色告警——某台冷却泵振动值越限。操作员手动拉起趋势图，翻看设备档案，比对维修日志，经过一轮人工判断后才能区分偶发抖动和轴承磨损前兆。数据看得见，决策靠人猜。物联网解决了“连接”的问题——传感器、PLC、RFID 源源不断地把数据上传到平台。但连接的终点仍常常是人类操作员：数据呈现在仪表盘上，分析靠经验，决策靠判断，执行靠手动点击。

AIoT（人工智能物联网，Artificial Intelligence of Things）打破了这种割裂。它把人工智能，尤其是大语言模型和多模态模型，嵌入到物联网“采集—分析—决策—执行”闭环中，让机器不仅看得见数据，还能理解语义、推理因果、自动操作。一条线概括：IoT 让世界可感知，AI 让感知可行动。

IoT DC3 平台的设计抓住了这条主线。AI 提出的动作最终都要进入平台真实 API，经网关注入主体上下文，再由鉴权中心做 RBAC 权限校验与租户隔离——模型拿不到比对应账号更多的权限。这意味着 AIoT 不是在物联网之上“叠”一层智能，而是将模型纳入已有的受控操作链路；可信的是经过鉴权、校验、确认与审计的执行过程，而不是模型本身。

1. 演进三阶段：连接、智能分析、自主决策

AIoT 的成熟大致经历了三个阶段，每个阶段的技术特征和智能化程度有明显差异。下面用示意图展示作者整理的演进脉络。

图 7-1 AIoT 演进阶段示意

第一阶段：连接与数据采集。 主题是“把设备连起来”。大型物联网平台重点解决设备注册、协议适配、数据采集与存储。平台像一条数据管道：传感器值经过网关、流处理引擎，存入时序数据库，最终展现在仪表盘上供人查看。智能非常浅——大多是基于阈值的告警规则引擎（诸如温度越限触发告警）。规则引擎确定性强，但无法处理模糊、多变、语义丰富的场景。运维人员需要频繁调整阈值来适应工况变化，误报和漏报一直是痛点。这个阶段的核心交付物是可读、可查的数据，而非可执行的智能。

第二阶段：智能分析与人机协作。 边缘计算和轻量级机器学习模型开始落地。异常检测、预测性维护等算法被引入。模型跑在独立推理服务上，输出结果喂给告警系统或大屏。近年来，主流大语言模型具备了多步推理和工具调用能力，使物联网系统第一次能借助设备手册与实时数据理解自然语言任务，再由应用根据模型生成的结构化请求调用平台能力。IoT DC3 的 Agentic Center 正是在这个背景下诞生的——它把 OpenAI API 兼容的大模型接到设备、位号和数据能力上，用户用自然语言提问，模型按需选择平台内置工具去读元数据、查实时值；有副作用的位号写入则先创建待确认 Action。与第一阶段的核心区别在于：模型不再是旁观者，而是受控操作链路中的决策参与者。

第三阶段：受约束决策与有界自治（正在成形）。 Agent 不再只等待人类发问，而是可以由告警事件或计划任务触发，主动汇总证据、诊断根因并提出策略。真正执行时，Agent Runtime 还必须限定身份、设备范围、时间窗口、工具白名单和风险预算，并在关键节点进入确定性 Workflow 或人工确认。该阶段的典型特征包括：定时健康报告、多模型按任务复杂度路由，以及外部 AI Agent 通过授权后的 MCP 端点（截至 2026 年中）发现和调用白名单能力。人类从逐步操作转向监督、审批和异常接管，但不会退出安全关键决策。IoT DC3 当前已经具备会话、显式 Tool、租户上下文和位号写 Action 等基础，事件触发、长期任务状态机、恢复与统一治理仍需继续建设。

2. 核心驱动力：算力与模型的共生

从第二阶段向第三阶段演进，背后有两条并行的驱动力。

第一条：算力下沉。 物联网的经典痛点是云端推理延迟高、带宽贵、隐私风险大。合理的工程分工是“云侧训练、边缘推理、端侧响应”：云上用全量历史数据训练模型，下发到边缘做低延迟推理，端侧只做最后一脚的快速响应。以嵌入式 AI 芯片为代表的边缘计算设备，已能在有限功耗下运行轻量级 LLM 或视觉模型，使得边缘端部署大语言模型成为工程可行。算力下沉的直接收益是推理时延显著降低，且敏感数据不必离开本地网络。

第二条：模型能力的跃迁。 大语言模型近年完成了从“文本对话”到“工具调用”的能力跃迁。传统物联网智能依赖规则和分类回归模型，而今天的 LLM 能根据“把二号线的进料阀调到较低开度”这样的自然语言指令，推理出需要调哪个 API、传什么参数、甚至做边界校验。这种能力与物联网“指令密集”的特性天然匹配。IoT DC3 的处理方式很务实：通过 Spring AI 将工具调用变成普通的 Java 方法调用，让模型的理解能力与平台已有的业务逻辑无缝衔接。模型无需感知底层协议差异（Modbus、OPC UA、MQTT），因为这些差异已被平台的设备抽象层屏蔽。

这两条驱动力共同指向一个结论：AIoT 已经从概念走向工程落地。接下来的小节会逐一拆解大模型在物联网中的具体角色（7.1.2）、Agent 如何实现自主决策（7.1.3）、RAG、Tool-Calling、MCP 等让模型伸手够到物理世界的关键技术（7.1.4、7.1.5），以及如何分层评测 RAG 系统（7.1.6）。

7.1.2 大模型在物联网中的角色：从感知到认知

规则引擎作为传统物联网的重要分析手段，已运行多年：温度超阈值就告警，离线就通知。这套机制边界清楚——它擅长执行预先定义的确定性条件，但复杂时序比较和多源关联需要额外编码。当运维人员面对“二号泵房温度比昨天同期高了5度，但负载是下降的”这类复合判断时，简单阈值规则只能输出“温度超限”；要比较同期、负载与维修记录，必须增加查询、特征计算和关联逻辑。

接入工具和检索后，大模型可以把季节、负载、历史趋势和维修记录组织成一份带证据的解释，并提出“检查冷却泵效率”等候选假设。这里发生的是从单一阈值到多源证据组织的扩展，不是模型凭文本完成了因果证明。根因仍需由时序分析、机理模型、对照实验或现场检修验证。规则引擎继续承担确定性事件，大模型承担资料检索、证据归纳、假设生成和人机交互，两者职责互补。

1. 从规则到语义：自然语言指令穿透设备层

第一个显著变化是设备操作入口。传统路径是：打开设备列表→找到目标设备→展开属性→输入值→点击写入，多步操作、深层嵌套。大模型可以把用户表达压缩为结构化候选动作：“关掉一楼走廊灯”对应某个可控开关位号，“温度调到 85 度”对应目标值与设备位号。平台收到候选动作后，还要完成 Schema、权限、工况与风险校验；涉及副作用时进入 Workflow 或人工确认，最后才由确定性代码调用真实设备接口。

IoT DC3 的 Agentic Center 正是按这个思路设计的。它通过 Spring AI 的 @Tool 注解，把设备、Driver、物模型、位号和位号值等平台能力暴露给大模型。当操作员说“读取锅炉温度和风机转速”，Agentic Center 可以先定位设备与位号，再读取两个最新值。工具通过项目 Facade 复用平台能力，租户与用户上下文随请求进入 Tool，确保模型读取的是当前平台数据，而非训练集里的记忆。

这里有一个工程边界必须明确：自然语言指令适用于操作意图清晰、安全风险可控的场景。IoT DC3 当前的位号写 Tool 不直接下发，而是创建待确认 Action；用户通过 Action 接口确认后，平台才提交写命令。这个设计不是为了保护模型，而是为了让人始终保持在决策环内。

2. 多模态融合：不止是文本对话

工业场景的输入不限于文本和数字。摄像头拍到设备面板异常指示灯闪烁，运维人员拍了张照片发到群聊问“这是什么意思？”——传统平台无法处理这种输入。多模态大模型（例如 OpenAI 的 GPT-5、Anthropic 的 Claude 4.5 等主流模型，截至 2026 年中）可以同时接受图像和文本输入：照片里的闪烁灯模式、仪表指针位置、电线烧焦的颜色，都能纳入推理范围。

但职责边界需要划清：大模型擅长语义推理，不负责毫秒级实时控制。电机紧急刹车、继电器跳闸这类响应，仍由硬件控制器和边缘实时系统承担。大模型的注意力放在认知层——帮运维人员理解“为什么出了这个异常”“下一步该做什么”。这与消防系统的分工类似：喷淋头由温度传感器即时触发，但“全楼是否疏散、通知哪几个部门”的判断，托付给懂上下文的决策者。大模型扮演的正是这个决策辅助角色，工作重点是减少人的认知负担而非取代硬件控制回路。

3. 从描述到推理：自动生成运维策略

规则引擎检测到告警可以稳定地产生“温度超过85℃”事件。大模型则可通过受控工具拉取过去7天趋势、同期数据和维修日志，形成诊断摘要，例如：“升温速度高于已选基线，冷却泵效率下降是候选原因之一；建议先核对电流、出口压力和传感器质量标记。”基线、时间窗和判断阈值必须由代码计算并随证据返回，不能让模型凭措辞捏造“2倍”或“30分钟”等精确结论。

这是从描述性分析（“现在温度是多少”）到诊断性分析（“为什么温度高”），再到建议性分析（“接下来该怎么办”）的跃迁。支撑这一跃迁的关键基础是工具调用能力——大模型本身不具备读取实时数据的权限，必须通过 Agentic Center 当前 Provider 显式注册的 8 类 Tool 获取设备、Driver、物模型、位号和值等信息，再综合判断输出建议。未注册进 Provider 的 Tool 不能算作默认会话能力（注册清单见 7.3.1 节）。

表7-1：大模型在物联网中的典型应用场景对比

场景	传统规则引擎处理方式	大模型介入后的处理方式
设备控制	通过仪表盘手动点击或预设写值指令	自然语言指令自动解析意图，调用工具执行、用户确认后写入
告警触发	固定阈值判断，触发后发送模板化通知	组织上下文证据、生成根因假设与待验证步骤
异常分析	显示超限数据和基础统计	梳理趋势、关联日志，生成自然语言解释与应对策略
运维策略	人工根据历史数据报告制定	模型综合多种数据源，主动给出操作建议和报告

大模型在物联网中的角色可以这样收束：它补上了长期缺失的认知层。传感器采集海量数据，规则引擎做快速判决，但“理解上下文、生成建议、与人对话”在过去一直空缺。大模型正好填补这块空白，让物联网从只能被动感知，进化为能够主动认知，同时不取代原有的实时控制逻辑。下面进一步讨论：如何用 Agent Runtime 承载这种认知能力，并把概率性决策约束为可治理的工业执行。

图 7-2 大模型在物联网中的角色：从感知到认知

7.1.3 Agent Runtime：从模型能力到受治理执行

规则引擎能处理预设判断，大模型能理解模糊意图，但“排查 2 号线温度异常”既不是单步告警，也不是一次模型调用。它要求系统建立任务上下文，查询设备和历史数据，选择下一步能力，处理超时与空结果，在必要时等待人工确认，执行后验证结果，并把全过程保存为可审计记录。只讨论“模型会不会调用工具”，无法覆盖这些工程责任。

因此，本书把 Agent 与 Agent Runtime 分开：

• Agent 是在给定上下文中判断下一步行动的决策主体，擅长理解意图、归纳证据和动态规划。
• Agent Runtime 是承载 Agent 运行的受治理执行环境，负责上下文、状态、能力、权限、调度、恢复、审计和人工接管。

一个模型加几个 Tool 可以完成演示，但只有 Runtime 才能回答生产系统真正关心的问题：任务执行到哪一步、谁授权了什么、调用是否重复、失败后如何恢复、何时必须交还给人，以及系统能否证明没有越过安全边界。

1. 运行时的四个平面

工业 Agent Runtime 可以拆成四个相互约束的平面。

决策平面负责理解目标和生成下一步候选行动，包括意图识别、任务规划、模型路由和完成判断。大模型位于这一平面，但不是整个运行时。模型输出的是候选计划或工具请求，不能直接等同于已经获准执行的设备命令。

上下文平面负责为每一步提供可信信息，包括当前用户和租户、目标设备、实时状态、会话历史、检索证据和任务记忆。这里需要区分上下文与记忆：上下文是本次决策可见的工作集，记忆是可以跨轮次或跨任务保存、检索和淘汰的信息。把所有历史对话无条件塞回提示词，既不是可靠记忆，也会带来数据泄漏和上下文污染风险。

执行平面负责把候选行动变成受控调用，包括确定性 Workflow、可复用 Skill、原子 Tool、MCP 连接和业务 API。执行平面不信任自然语言承诺，只接受经过 Schema 校验、权限判断和风险策略处理的结构化请求。

治理平面横切前三个平面，负责身份与租户隔离、风险分级、人工确认、超时、重试、幂等、补偿、审计、可观测性和评测。工业系统与普通聊天应用的根本差异，正体现在治理平面：一次回答不准确可以纠正，一次错误设备指令却可能产生不可逆副作用。

图 7-3 工业 Agent Runtime 四平面架构

2. Tool、MCP、Skill 与 Workflow 的关系

这些概念经常被混用。为了避免随框架变化而漂移，本书采用以下工程定义。

概念	本书中的定义	主要回答	是否负责流程状态
Tool	具有明确输入、输出和副作用语义的原子能力	“能做什么？”	通常不负责
MCP	AI 应用发现和调用外部 Tool、Resource、Prompt 的连接协议	“如何标准化暴露和连接能力？”	不负责业务流程状态
Skill	面向特定领域任务的可复用能力包，可组合提示模板、知识、Tool 和 Workflow	“如何复用领域做法？”	取决于内部实现
Workflow	由显式步骤、条件、超时、补偿和审批节点组成的确定性编排	“规定流程如何稳定执行？”	负责
Agent	根据当前 Context 动态选择下一步行动的决策主体	“此刻应该做什么？”	不应单独承担持久化
Agent Runtime	承载 Agent 生命周期、状态、能力、治理和执行的运行环境	“如何安全、持续地把任务做完？”	负责

Tool 是能力，不是完整任务。例如“查询设备状态”和“写入位号值”可以是两个 Tool。MCP 可以把它们暴露给外部 Agent，但不会自动把它们编排成可靠的检修流程。Skill 是本书对领域复用单元的称呼，例如“泵房离线排查 Skill”可以包含排查提示、设备拓扑知识、三个只读 Tool 和一条人工确认 Workflow；不同框架对 Skill 的命名和封装方式尚不统一，因此工程上必须明确它包含什么，而不能只贴一个标签。

Workflow 与 Agent 也不是互相替代。Workflow 适合步骤稳定、责任明确、失败补偿已知的过程；Agent 适合目标清楚但路径需要根据现场信息动态选择的任务。工业场景常用的组合是：Agent 选择路径，Workflow 守住关键步骤，Tool 执行原子动作，MCP 连接外部能力，Runtime 管理整个生命周期。

3. 任务状态比“思考循环”更重要

ReAct（Reasoning + Acting）解释了模型如何在“推理—行动—观察”之间循环，但生产系统还需要一个独立于模型的任务状态机。一个最小状态集合可以包括：

RECEIVED → CONTEXT_READY → PLANNING → POLICY_CHECK
                                      │
                         ┌────────────┴────────────┐
                         ▼                         ▼
                WAITING_APPROVAL                RUNNING
                         │                         │
                         └──────────→ VERIFYING ←──┘
                                      │
                         ┌────────────┼────────────┐
                         ▼            ▼            ▼
                    SUCCEEDED       FAILED      CANCELLED

状态机必须由 Runtime 持久化，而不是依赖模型“记住自己做到哪里”。每个任务至少要保存 run_id、租户与操作者、目标资源、当前状态、截止时间、已调用 Tool、幂等键、审批记录和副作用摘要。模型超时或进程重启后，系统才能判断是安全重试、等待回执、执行补偿，还是转人工处理。

这里还要区分三类失败：

1. 决策失败：计划不完整、证据不足或工具选择错误，应回到上下文或规划阶段。
2. 调用失败：网络超时、MCP 不可用或下游返回错误，应按 Tool 的重试语义处理。
3. 副作用不确定：命令已发出但回执丢失，不能盲目重试；必须查询设备状态、使用幂等键或转人工确认。

第三类最危险，因为“没有收到成功响应”不等于“设备没有执行”。这也是工业 Agent Runtime 必须独立管理状态和副作用账本的原因。

4. 示意案例：排查泵房离线

以“排查 1 号泵房离线”为例，Runtime 的职责链可以这样展开：

1. 接纳任务：记录操作者、租户、目标泵房和任务截止时间。
2. 构建上下文：查询设备、Driver、最近状态和维护窗口，只把当前任务需要的信息交给模型。
3. 生成计划：Agent 建议先判断是单设备故障、Driver 故障还是网络域故障。
4. 执行只读 Tool：查询设备状态、Driver 状态和影响范围；每次调用都记录输入、结果与耗时。
5. 验证结论：若 Driver 在线而单设备离线，输出现场链路排查建议；若 Driver 及其设备同时离线，转入 Driver 恢复流程。
6. 进入确定性边界：如果后续希望重启 Driver，Runtime 先检查当前是否存在该 Tool、调用人是否有权限、设备是否处于允许维护窗口，并按风险策略等待审批。
7. 收束任务：保存已确认事实、未确认假设、执行结果和后续责任人。若条件不足，明确以 FAILED 或“转人工”结束，不让模型用自然语言掩盖失败。

这个例子中，模型负责判断“下一步查什么”，Runtime 负责保证“以什么身份查、查到哪里、能否执行、失败怎么办、证据留在哪里”。二者缺一不可。

5. 工业场景的不可越过边界

Agent Runtime 可以提高诊断和运维效率，但不能把概率性推理伪装成确定性控制。以下职责仍应保留在 PLC、SIS、边缘控制器或显式 Workflow 中：

• 毫秒级实时控制与安全联锁；
• 急停、泄压、过载保护等故障保护；
• 对时序、顺序和一致性有硬约束的工艺步骤；
• 无法可靠补偿的高风险物理动作。

Runtime 的价值不是让模型绕过这些系统，而是把人的意图转换成受约束的任务，在安全边界之外完成查询、分析、建议、编排和有限执行。

表7-2：Agent Runtime 落地检查表

维度	必须回答的问题
上下文	身份、租户、设备范围和证据版本是否明确？
状态	任务能否在进程重启后恢复，是否区分失败与副作用不确定？
能力	Tool 的输入、输出、副作用、超时和幂等语义是否声明？
编排	动态决策与确定性 Workflow 的边界在哪里？
治理	哪些动作自动放行，哪些等待审批，哪些永远禁止？
恢复	重试、补偿、人工接管和 kill switch 是否可用？
证据	是否保存调用 Trace、审批、回执和最终状态，而非内部思维过程？

7.1.4 RAG 与 Tool-Calling：扩展知识边界

大模型接入物联网运维，很快就会撞上两个实打实的短板。第一个是知识边界：模型训练完的那一刻，它知道的就已经过时了——昨晚上线的变频器、刚刚更新的寄存器映射表、这个季度才改的标准化作业流程，它一概不知。第二个是行动边界：模型再聪明，也只能输出文本，没法直接往总线上发指令。操作员问“重启3号泵”，它只能回答“请登录平台，在设备管理界面找到3号泵，点击重启按钮”。RAG（Retrieval-Augmented Generation，检索增强生成）和 Tool-Calling（工具调用）正好各自解决一个缺口：前者让模型带着实时资料回答问题，后者让模型能真正操作设备。

1. RAG：让模型不再“凭空回答”

RAG 的核心思路很直白：模型在生成回复之前，先从外部知识库检索最相关的信息片段作为上下文，然后再生成。这样一来，大语言模型不必靠训练参数里封存的记忆来作答——那些记忆可能已经过期，甚至根本没存过你系统里的专有设备。在物联网运维场景中，RAG 的检索对象通常包括设备安装手册、Modbus 寄存器映射表、历史故障记录、标准化作业流程（SOP）、驱动程序升级日志等。

一个典型的检索流程是：操作员在对话中问“这台温控器报 E4 故障该做什么”，系统先把查询转换成向量表示，在文档向量库中检索最相关的故障排除记录，连同原始问题一起发给大语言模型，模型据此生成排查步骤并列出需要检查的位号。对 IoT DC3 而言，这是一种可选的智能告警扩展方案；其当前实现尚未内置向量库、案例入库任务与自动告警触发流水线。这里要区分两个层面：RAG 是完整 AI Native 平台应具备的扩展能力，DC3 当前实现只是它的一部分——后文会说明这条能力的边界与第 14 章的落地路径，而不是把“尚未实现“等同于“不该具备”。

RAG 的工程难点在于检索质量。知识库里混入过时的维护记录，模型就可能基于错误信息给出建议；向量化分块时把 SOP 的步骤 A 和步骤 D 切到了同一个块，模型拿到的上下文就是混乱的。工业手册类语料尤其考验切分策略：参数表、寄存器映射表、报警代码表往往一行就是一个知识点，按固定字符数切块会把表格拦腰截断，检索到半张表格等于没有检索。工程上通常先做结构化解析，沿标题、段落和表格的文档结构切分，让表格整表或按行进入索引；检索时再配合父文档检索——命中子块后返回其所属小节或整张表格，保证模型拿到完整上下文。实践中通常引入两个工程手段：文档版本管理和检索结果重排序。新部署的设备文档必须标注版本号，过期的文档从向量库中移除或降权；检索到的候选条目再用轻量级排序模型（如 Cohere Rerank 或 BGE Reranker）重排一次，确保最相关的文档优先进入大语言模型上下文窗口。

用 LangChain 实现 RAG 的代码如下：

from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain.chains.combine_documents import create_stuff_documents_chain
from langchain.chains import create_retrieval_chain
from langchain_core.prompts import ChatPromptTemplate

# 加载运维知识库（设备文档、SOP）
embeddings = OpenAIEmbeddings()
# 安全提示：allow_dangerous_deserialization=True 会执行 pickle 反序列化，
# 加载被篡改的索引文件可能导致任意代码执行，仅限加载自己生成并妥善保管的本地索引
vectorstore = FAISS.load_local("iot_knowledge_base", embeddings, allow_dangerous_deserialization=True)
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

llm = ChatOpenAI(model="gpt-5", temperature=0)
prompt = ChatPromptTemplate.from_template(
    "根据以下资料回答问题：\n\n资料：\n{context}\n\n问题：{input}"
)
question_answer_chain = create_stuff_documents_chain(llm, prompt)
rag_chain = create_retrieval_chain(retriever, question_answer_chain)

response = rag_chain.invoke({"input": "二号除尘风机持续高温告警，该怎么处理？"})
print(response["answer"])
# 输出：检索到2024-08的维护记录，第一步检查变频器散热风道是否堵塞。

这个代码假设你已经有了一个本地向量库，里面存储了设备的运维文档和 SOP。实际生产环境中，还需要考虑文档的增量更新、向量数据库的性能，以及不同租户间知识库的隔离。

2. Tool-Calling：让模型从“说”变成“做”

Tool-Calling 让大语言模型在生成回复时输出结构化的函数调用请求——指定函数名和参数，而不是自然语言。应用层执行对应业务逻辑，再把结果返回给模型组织回复。IoT DC3 源码中共有 10 个 Tool 类，当前 Provider 显式注册其中 8 类，未注册的两个类不构成默认会话能力（注册清单见 7.3.1 节）。工具 Bean 也不会仅因带有 @Tool 就被 ChatClient.Builder 全局自动扫描，必须通过 tools()、defaultTools() 或显式 ToolCallbackProvider 注册。

一个典型的 Tool-Calling 示意（基于 Spring AI）：

@Tool(description = "创建一条新的告警规则")
public String createAlarmRule(
    @ToolParam(description = "规则名称，如'温度超限'") String ruleName,
    @ToolParam(description = "触发条件表达式，如'pointValue>100'") String condition,
    @ToolParam(description = "通知方式：sms/email/webhook") String notifyMethod
) {
    return alarmRuleService.create(ruleName, condition, notifyMethod);
}

操作员说“给1号线温度位号加一个超过90度就发短信的告警规则”，大语言模型解析意图后，自动调用 createAlarmRule 方法，填入 ruleName="1号线温度超限"、condition="line01_temp>90"、notifyMethod="sms"。方法执行后返回规则 ID，模型再将结果组织成“已创建规则”。整个过程省去了操作员在多个界面间跳转配置的环节。

Tool-Calling 的安全风险值得特别关注。如果模型误读意图——比如把“暂停 3 号泵”理解成“关闭 3 号泵”——一次错误调用就可能造成设备损坏。IoT DC3 当前可执行的写路径是 PointValueTool.writePointValue：它只创建待确认 Action，不直接写设备；用户确认后 ActionService 才调用 PointCommandFacade 提交命令。该流程由业务代码和持久化状态实现，不是 @WriteOperation 注解或 Spring AI 自动拦截。

3. 结合使用：先检索后执行

RAG 解决的是模型“知不知道”的问题，Tool-Calling 解决的是模型“能不能做”的问题。在复杂运维场景中，两者常常串联使用：先通过 RAG 检索出正确的操作步骤或参数模板，再由 Tool-Calling 执行具体操作。

联合工作流的典型对话：

操作员：“二号车间的除湿机频繁跳闸，按标准流程排查处理。”
Agent 执行过程：

1. RAG 检索：从知识库命中“DC-DEHUM-02 重复跳闸 SOP V2”
2. 步骤1：查当前状态 → 调用 PointValueTool 读取 dehum02/status 和 dehum02/fault_code
3. 步骤2：结合 SOP 分析 fault_code=0xE3 表示“压缩机过流”，输出初步诊断
4. 步骤3：建议动作：按 SOP 做现场检查；如果要写控制位号，则由 PointValueTool 创建待确认 Action
5. 结果：返回诊断依据和拟执行动作；只有用户确认且平台执行成功后，才能表述为“已执行”。

没有 RAG，模型不认识 0xE3 这个故障码，也无从知道 SOP 里写了什么；没有 Tool-Calling，模型只能给出“建议重启”这样的文本建议，操作员还得手动跳转多个界面才能执行。两者结合之后，大语言模型才真正从“能说的顾问”变成“能动手值班员”。

图 7-4 RAG + Tool-Calling 联合工作流

RAG 与 Tool-Calling 的组合，让大语言模型在物联网运维中同时具备两项具体能力：知识面随语料库更新而更新，不必等模型重新训练；动作面经平台 Schema、权限与确认校验收敛，自然语言承诺不会直接变成设备命令。前者压缩了知识维护的时间差，后者保证了操作语义的确定性。下面把视角从单个工具调用拉升到系统集成层面，看看这些能力如何通过标准协议暴露给外部 AI Agent。

7.1.5 MCP 协议：跨系统交互标准

RAG 补上知识滞后，Tool Calling 让模型能够执行动作。当物联网平台希望把设备、数据和运维 API 暴露给外部 AI Agent 时，如果每个客户端都单独适配接口描述、鉴权和版本，维护成本会迅速失控。MCP（Model Context Protocol，模型上下文协议）提供了统一的能力协商、发现和调用方式。

Tools、Resources 与 Prompts 不是同一概念

MCP 基于 JSON-RPC 2.0，并把服务端能力区分为三类：

• Tools：模型可调用的动作或函数，带输入参数模式，通过 tools/list 发现、tools/call 调用。
• Resources：客户端可读取的上下文数据，通过 resources/list、resources/read 等方法访问。
• Prompts：可枚举、可参数化的提示模板，通过 prompts/list、prompts/get 等方法访问。

因此不能把平台所有能力统称为 Resource，也不能把 tools/call 描述成“调用 Resource”。客户端在 initialize 阶段协商协议版本与能力，后续只能调用服务端实际声明的能力。

传输与授权：stdio 与 Streamable HTTP

已发布的 2025-11-25 MCP 规范定义 stdio 与 Streamable HTTP 两种标准传输。stdio 面向本地子进程，Streamable HTTP 面向远程 HTTP 端点；后者取代了早期 HTTP+SSE 传输。2026-07-28 文档是提出无状态生命周期等变化的发布候选版，阅读时必须区分稳定规范、候选设计与项目实际实现。IoT DC3 源码快照在 Gateway 暴露处理 JSON-RPC 的 POST /mcp，可确认它是网络可达的 HTTP POST MCP 入口；但仅凭一个 POST 路由不能宣称已实现 Streamable HTTP 的全部 GET、SSE 与会话语义。无论传输子集如何，该端点都必须按 Web API 标准落实认证、授权与访问控制，不能按“本地进程”的信任级别对待。

规范还定义了由 Client 声明的 sampling 能力：Server 处理请求时，可以请求 Client 侧模型生成内容。IoT DC3 该 MCP 端点没有声明或实现相关方法，只能确认“当前未实现”，不能替源码臆测产品决策原因。若未来启用，应单独评估租户数据是否越界、用户同意、模型选择、配额和审计面。

授权方面，MCP 的授权框架基于 OAuth 2.1 草案构建，客户端访问受保护的 MCP 服务器前须先完成标准 OAuth 流程——7.6.1 CHK-10 中“OAuth 2.1”的出处即在于此；机制细节见第 9 章 9.5 节与第 8 章。

IoT DC3 当前 MCP 边界

IoT DC3 的 987c96d50 源码快照在 Gateway 的 POST /mcp 提供 MCP JSON-RPC 入口，协议修订号为 2025-06-18，只声明 tools capability，实现 initialize、ping、tools/list、tools/call，并接受 notifications/initialized。Resources、Prompts 与 Tasks 均未声明，也未实现相应方法。

工具目录也不是扫描 Spring AI @Tool 方法后生成“Resource 列表”。Auth 中的 McpOpenApiAggregator 把 dc3_api、dc3_resource 中的平台目录与版本化静态 OpenAPI 快照结合，生成 Tool 名称、描述和输入 Schema；Gateway 的 tools/list 再按 OAuth scope、租户、权限与风险策略返回当前调用者可见的目录。每次 tools/call 前，Gateway 都会重新校验 Bearer Token、连接上下文、工具可见性与授权，再把调用转发到实际 REST 后端。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "manager__device__get",
    "arguments": {"id": 1001}
  }
}

这套目录机制还回应了一个容易被低估的攻击面：对模型而言，工具描述本身就是不可信输入。恶意或被篡改的 MCP 服务器可以在工具描述里植入诱导指令（tool poisoning），让模型在后续调用中泄露数据或执行越权动作；工具目录也可能被悄悄替换——今天列出的安全工具，明天可能被同名的恶意实现顶替（rug pull）；当 Agent 按一个服务器的指引去调用另一个服务器时，还会形成 confused deputy 攻击面。DC3 的前述设计降低了这些风险：工具定义来自 Auth 侧的平台目录与版本化 OpenAPI 快照，而不是运行时任意抓取；Gateway 按 scope、租户、权限和风险策略裁剪可见工具，每次调用重验 Token 与授权。但静态快照和本地目录仍需供应链校验、变更审查与版本同步，不能把“受控”写成“天然可信”。这类新型攻击面在第 8 章展开。

MCP 与 REST、MQTT 的关系

REST 仍是平台真实业务 API，MCP 在其上提供面向模型的 Tool 目录和统一调用协议。MQTT 与 RabbitMQ 服务设备连接和平台消息流，MCP 服务外部 AI 客户端。三者解决的问题不同，MCP 不替代设备协议，也不绕过既有租户、权限和安全校验。

外部 Agent 可以通过 tools/list 动态发现可见能力，并按顺序调用多个 Tool 完成“查设备→查位号→读历史→生成建议”等多步任务。但每一步仍是独立的受控调用，不能因为使用了 MCP 就默认获得更高权限或自动执行高风险操作。

从 MCP 到 A2A：智能体之间的互操作（前瞻）。 MCP 解决的是“智能体如何调用工具”，A2A（Agent-to-Agent）解决“智能体之间如何发现彼此、委派任务和交换结果”。A2A 通过 Agent Card 描述能力并支持任务委派，但采用节奏应以真实互操作测试、安全模型和生态成熟度为准，不预设某一年必然规模化。MCP 规范也在快速演进：实验性 Tasks 已在 2025-11-25 规范中出现，2026-07-28 发布候选版又提出无状态生命周期等变化；这些标准能力均不能反推为 IoT DC3 已实现。跟踪演进应对照具体修订版规范。对物联网而言，平台通过 MCP 暴露工具后，不同智能体仍可能需要 A2A 协调分工；完整方案应分别评估 MCP 工具层与 A2A 编排层。IoT DC3 当前只实现 MCP 工具子集，A2A 仍属演进方向，留待第 14 章讨论。

图 7-5 MCP 在物联网平台中的架构示意

准确的工程结论是：IoT DC3 当前通过 MCP 暴露的是经 OAuth 和白名单约束的 Tools，而不是完整实现了 MCP 的所有服务端能力。协议知识与项目实现必须分开描述。

7.1.6 RAG Eval：分层评测检索与生成

RAG 系统能够返回一段流畅回答，不代表它已经具备生产价值。一次回答可能在检索阶段取错设备型号或文档版本，也可能检索正确却在生成阶段添加证据中不存在的结论。要定位问题，评测必须拆成数据集、检索、生成和端到端任务四层，而不能只让人工给最终答案打一个总分。

先固定评测集，而不是先挑指标

物联网知识具有租户、设备型号、固件版本和有效时间等边界。一个可复现的评测样本至少包含：问题、预期证据、可接受答案要点、是否应拒答、租户、设备型号、文档版本和有效时间。评测集应覆盖六类输入：普通可回答问题、知识库中不存在答案的问题、新旧版本冲突、过期操作规程、跨租户相似文档，以及需要组合多段证据的问题。

生产数据不能直接随机拆分后同时进入索引和评测集，否则很容易出现近重复文本泄漏。更稳妥的做法是按时间和文档版本切分，并为高风险写操作单独建立对抗集。评测集本身也要版本化；新增设备、升级固件或替换手册时，应同时更新问题、证据和拒答条件。

检索层：是否拿到了正确证据

检索层不评价回答文风，只评价候选证据。常用指标包括：

• Recall@k：前 k 个结果是否覆盖应命中的证据；
• MRR：第一个正确结果出现得是否足够靠前；
• nDCG@k：多条相关证据的排序质量；
• Context Precision/Recall：送入模型的上下文中，有用内容比例及应有证据覆盖程度；
• 正确版本命中率：答案需要 v4 手册时，是否错误取到 v3；
• 跨租户误检索率：任何不属于当前租户的内容进入上下文都应视为安全失败；
• 空检索率与 P50/P95 延迟：用于识别覆盖缺口和长尾开销。

这些指标应同时报告稀疏检索、向量检索、混合检索和混合检索加 reranker 的基线。若只展示最佳方案，读者无法判断复杂度增加是否真的带来收益。

生成层：回答是否忠实于证据

RAGAS 研究将 RAG 质量拆为检索相关性、回答对检索内容的忠实程度以及最终回答质量等维度。工程评测至少应包含：

• Groundedness/Faithfulness：回答中的事实是否能被给定上下文支持；
• Answer Relevance：回答是否针对问题，而不是复述材料；
• Citation Precision/Recall：引文是否支持对应声明，以及关键声明是否都有引文；
• 无证据回答率：检索不到可靠材料时，模型是否仍编造结论；
• 拒答准确率：本应拒答和本可回答两类样本是否都处理正确；
• 操作步骤完整性：涉及设备维护时，是否遗漏停机、确认、回滚或安全条件。

自动评分器本身也可能偏差，因此高风险样本应由领域专家抽检，并保存评分理由、证据定位和争议记录。自动分数适合做持续回归，不应替代出版或生产验收中的人工判断。

端到端层：是否解决了真实任务

端到端评测把问题、检索、生成和后续动作放在一起。可记录运维问题解决率、专家复核通过率、过期 SOP 使用率、拒答后转人工比例、P50/P95 总时延、token 消耗和单次成功任务成本。对于带 Tool 的流程，还应记录回答建议是否与实际设备状态一致，但不要把 Tool 执行轨迹混进 RAG 指标；Agent 轨迹由 7.5.4 节单独评测。

问题集 v3
  → 检索配置 v8（BM25 + Embedding + Reranker）
  → 检索指标
  → 生成模型与 Prompt v5
  → 忠实性、相关性与引文指标
  → 端到端任务、时延和成本

失败分类比总分更有行动价值

每个失败样本应归入可修复的类别：问题理解错误、检索不到、文档版本错误、上下文互相冲突、有正确证据但生成不忠实，以及本应拒答却给出动作建议。不同失败对应不同修复入口：扩语料、改切分、调过滤、换 reranker、收紧 Prompt 或增加拒答策略。只盯一个综合分数，通常会掩盖这种工程差异。

实验卡 EXP-7-RAG-01

• 对象：物联网运维知识问答；
• 固定项：语料快照与校验和、切分参数、Embedding、reranker、生成模型、Prompt、top-k；
• 基线：无 RAG、BM25、向量、混合、混合加重排；
• 指标：Recall@k、MRR、nDCG、版本命中率、跨租户误检索率、Groundedness、拒答准确率、P50/P95、token 与成本；
• 结果要求：保存逐样本检索结果、回答、引用、评分理由和原始日志；没有完成实测的项标记为 NA，不用示意数字代替。

RAG Eval 的最终目的不是证明某个框架更先进，而是建立一条可重复的证据链：当语料、索引、模型或 Prompt 发生变化时，团队能够知道改善了什么、破坏了什么，以及系统是否仍满足租户隔离和高风险任务的拒答边界。

图 7-6 RAG Eval 分层评测

← 6.4 工程小结与延伸阅读7.2 Spring AI 与物联网集成 →