Device Agent 集成 Jev：面向低时延、低成本的设备智能决策

原作者：EMQ中文社区 · 优化改写：WorkBuddy · 2026-10-01 原文链接：微信原文

Device Agent 集成 Jev，把轻量决策放到设备现场

当设备越来越多地接入 AI，真正棘手的问题往往不是「能不能理解一句话」，而是如何在告警、控制、记录这些高频场景中，快速、稳定、低成本地做出可执行的判断。

在即将推出的 Device Agent 0.5.0 版本中，将直接集成 Jev——一个更轻量的 System One 模型，可以把告警分流、自然语言快捷控制等日常决策交给它处理，再由 Agent 承接复杂分析与后续执行。本文通过一个工业检测设备示例，看看 Jev 如何帮助 Device Agent 在设备现场更快做决定、更少打扰人、更容易落地自动化。

目录

  1. 一、为什么设备现场需要「轻量决策」
  2. 二、Jev 是什么：System One 模型如何做决策
  3. 三、在 Device Agent 中落地：工业检测终端实战
  4. 四、告警分流：用 Jev 判断故障是否恢复
  5. 五、自然语言快捷控制：用 Jev 下发设备命令
  6. 六、更少的等待与 Token 消耗：Jev vs LLM Agent
  7. 七、结语：把高频判断交给 Jev

一、为什么设备现场需要「轻量决策」

设备接入 AI 之后，很多团队的第一反应是「让模型听懂人在说什么」。但真正的高频需求往往不是理解一句话，而是：在告警、控制、记录这些反复发生的场景里，快速、稳定、低成本地给出一个可执行的判断。

这类判断通常有典型特征：

  • 触发频率高（告警、状态变化、人工备注）；
  • 需要的输出很窄（一个选项、几个参数）；
  • 对时延和成本敏感（每一次都走重型大模型不划算）；
  • 结果要能被程序直接使用（直接进工作流、下发命令）。

即将发布的 Device Agent 0.5.0 把 Jev 直接集成进来，正是为了解决这一类问题：把告警分流、自然语言快捷控制等「轻决策」交给更轻的模型，把复杂分析与后续执行留给 Agent。

二、Jev 是什么：System One 模型如何做决策

Jev 是 TypeSafe AI 推出的首个 System One 模型。它能够理解自然语言和结构化数据，根据开发者定义的问题与判断标准，快速返回程序可以直接使用的结果。开发者可以用它完成内容分类、意图识别、评分、业务分流和动作选择等任务。

以包装产线的输送带为例：设备停机时，系统需要判断这是正常换料，还是出现了需要排查的异常。把设备状态和操作员的现场备注放进 Jev API 请求：

{
  "state": {
    "device": "包装线输送带",
    "status": "已停止",
    "operator_note": "这批货已输送完，正在换料，换好后继续生产。"
  },
  "model": "jev-latest",
  "questions": {
    "action": {
      "type": "choice",
      "instructions": "这次停机是否需要安排人员排查？",
      "criteria": {
        "record": "已确认是正常换料或计划停机，仅记录事件",
        "notify": "意外停机、出现故障迹象或原因不明，通知现场人员排查"
      }
    }
  }
}

其中 state 包含设备状态和现场备注，instructions 定义要判断的问题，criteria 给出可选的处理方式。上面这条备注说明停机是正常换料，预期选择为 record。响应同时返回置信度和各选项的概率（数值为示意）：

{
  "answers": {
    "action": {
      "type": "choice",
      "choice": "record",
      "confidence": 1.0,
      "probabilities": {
        "record": 1.0,
        "notify": 0.0
      }
    }
  }
}

几个字段的含义：

  • choice：选中的处理方式；
  • probabilities：各选项的概率分布；
  • confidence：根据该分布计算出的置信度，范围为 0–1，反映模型对选择的确定程度，不代表判断一定正确。

完整响应还包含 model 和 usage，分别记录实际使用的模型和输入、输出 Token 用量。

如果把现场备注改成「输送带突然停了，电机有异响，原因还不清楚」，预期选择就会变为 notify，工作流据此执行相应的处理动作。对于这类需要理解自然语言、最终只用到一个选项或几个参数的设备任务，Jev 可以直接提供程序可用的判断结果，衔接后续操作。

相关链接：

三、在 Device Agent 中落地：工业检测终端实战

下面以一台「工业检测采集终端」为例，完成设备创建、上线、告警分流和指令控制。整个过程使用浏览器模拟器，可在没有实体硬件的情况下完成。开始前，确保控制台已配置好 MQTT 连接和智能体模型。

点击首页的 创建设备智能体，或左侧边栏的 +，输入以下设备描述：

创建一个「工业检测采集终端」设备智能体，用于上报产线检测异常，并用文字描述故障现象和恢复情况。支持调整采集间隔，范围为 1–60 秒、取整数，以及开启或关闭诊断日志。模拟设备的采集间隔默认为 10 秒，诊断日志默认关闭。收到控制指令后，更新相应状态，并上报当前采集间隔和诊断日志的开关状态。

创建设备智能体

发送后，在右侧预览中确认已包含采集间隔设置、诊断日志开关和检测异常告警，以及对应的设备状态。点击 创建，再点击 进入设备智能体。

在左侧 设备 面板点击 接入设备，填写设备名称和 ID，点击 创建设备。本例创建的设备为 industrial_inspection_collection_terminal_01。

接入并创建设备

选中这台设备，在状态面板点击 连接。浏览器模拟器会建立连接并上报初始状态。连接成功后，设备应显示为 在线；在 当前数据 中，确认采集间隔为 10 秒、诊断日志为 关闭。

保持这台设备处于选中、在线状态，后续的模拟上报和控制请求都针对它进行。

打开 设置 → 模型 → 决策模型，启用决策模型，选择 TypeSafe，填写 API Key，模型使用 jev-latest，保存配置。

启用 Jev 决策模型

四、告警分流：用 Jev 判断故障是否恢复

回到刚才的设备页面，在对话框中输入：

为当前设备创建并启用「检测异常处理」工作流。收到检测异常告警时，使用 Jev 判断故障是否已经恢复：已恢复且后续检测正常，只记录设备、告警原文和处理结果；仍未恢复或反复发生，向 factory/maintenance/inspection-alerts 发布 MQTT 通知，包含设备和故障描述。如果信息不足，无法判断是否恢复，则交给 Agent 列出缺少的信息和建议检查的项目。

Agent 创建完成后，打开左侧 工作流，找到「检测异常处理」，确认已启用，并查看生成的流程：

检测异常告警 → Jev 决策
              ├─ 已恢复 → 记录事件
              ├─ 未恢复 → 发布 MQTT 通知
              └─ 证据不足 → Agent 整理排查建议

工作流生成结果

这里通过对话完成工作流配置；设备后续上报告警时，由 Jev 决策节点判断走哪条分支。需要调整判断标准，可以在工作流中点击 编辑，双击决策节点，修改问题和选项说明。

查看与编辑决策节点

这次告警来自产线上的焊接检测工位：检测发现焊接点偏移，设备已自动暂停送料，等待人工复核。工作流需要进一步判断这次故障是否仍需运维处理，并决定发送通知、仅记录事件，还是交给 Agent 整理待确认的信息。

回到设备状态面板，点击 模拟上报，选择检测异常告警事件 inspection_abnormal，填入以下事件数据：

{
  "fault_description": "3号产线视觉检测工位连续出现焊接点偏移报警，偏移量约0.8mm，超出工艺公差±0.5mm，已自动暂停该工位送料，等待人工复核。"
}

选择并填写告警事件

点击 上报事件，告警会触发工作流。打开该工作流的 执行记录，展开本次执行，查看 Jev 的判断和后续动作。

告警中的「连续出现偏移报警」和「等待人工复核」表明问题仍待处理。本次执行中，Jev 1.13 选择了 not_recovered（未恢复），工作流随即向 factory/maintenance/inspection-alerts 发布 MQTT 通知，并记录处理结果，供订阅该主题的运维系统接收和跟进。

执行记录显示，此次判断的置信度为 0.91，未恢复选项的概率为 0.94；整个工作流耗时 841 ms，其中决策步骤耗时 821 ms，模型用量为 860 个输入 Token、55 个输出 Token。

执行记录：决策与耗时

保持事件为 inspection_abnormal，只修改 fault_description，还可以验证另外两条分支：

  • 已恢复：上报「已调整焊接定位，连续三次检测通过，偏移量均在工艺公差内，已恢复正常送料」。预期进入 recovered 分支，仅记录事件。
  • 信息不足：上报「检测异常」。如果 Jev 选择 insufficient_evidence 分支，工作流会交给 Agent 整理缺少的信息和建议检查的项目。

对于只有文字说明、没有明确恢复状态字段的告警，这种分流可以减少逐条人工判断和已恢复告警带来的无效通知，让运维集中处理尚未解决的问题。日常分类只需 Jev 返回一个选择结果，需要进一步梳理信息时再调用 Agent。

五、自然语言快捷控制：用 Jev 下发设备命令

收到这类尚未恢复的告警后，运维可以缩短采集间隔、开启诊断日志，为后续排查收集更密集的数据和日志。保持 industrial_inspection_collection_terminal_01 在线并处于选中状态，点击对话输入框旁的 Jev 快捷指令 按钮（鼠标悬停时会显示「打开 Jev 快捷指令」）。

在面板中输入：

把采集间隔改为 2 秒，开启诊断日志。

Jev 从设备已有能力中选择两个命令，将「2 秒」和「开启」分别转换为参数，再由 Device Agent 依次下发：

set_collection_interval(interval_seconds=2)
set_diagnostic_log(enabled=true)

快捷指令下发两条命令

本次请求完成了 2 步操作，总耗时 2,736 ms。两条命令均显示已执行，左侧 上报状态 中的采集间隔由 10 秒变为 2 秒，诊断日志由 关闭 变为 开启，命令记录也显示执行成功。

同样的操作也可以通过 LLM Agent 对话完成。对于调整采集间隔、开关日志这样的日常控制，Jev 快捷指令将自然语言转成设备已有的命令，直接返回执行结果；LLM Agent 则会继续查询状态并生成回复。

六、更少的等待与 Token 消耗：Jev vs LLM Agent

在 Device Agent 中，我们用 Jev 快捷指令和 LLM Agent 分别将同一台模拟终端的采集间隔改为 2 秒，对比两种处理方式的响应时间和 Token 用量：

Jev 与 LLM Agent 的时延与 Token 对比

对于这一个操作，Jev 返回完整结果约需 0.95 秒，LLM Agent 约需 2.70 秒，总 Token 用量减少约 96.6%。命令下发后的设备响应均为几十毫秒，差异主要来自模型处理和结果返回环节。Jev 围绕当前命令和参数完成判断，减少输入上下文；LLM Agent 还会查询状态并生成回复。用户同样只需说一句话，Jev 可以用更少的模型用量完成这类目标明确的控制。

指标 Jev 快捷指令 LLM Agent
响应时间 ~0.95 秒 ~2.70 秒
Token 用量 显著更低（减少约 96.6%） 基准
下发后设备响应 几十毫秒 几十毫秒
处理方式 围绕当前命令/参数判断，减少输入上下文 查询状态并生成回复

测试中使用本地模拟设备及真实模型 jev-1.13.0、deepseek-flash，每组 5 次，初始状态一致，LLM Agent 使用新会话；结果中延时取中位数，Token 取平均值（累计全部调用，含缓存输入）。两种调用入口不同，计时不含页面渲染，结果仅代表本次配置。

另外需要考虑网络延迟带来的影响：Jev 走海外网络，而 deepseek-flash 走国内网络，因此在本次测试中，deepseek-flash 在时延指标上具备一定的网络环境优势。

七、结语：把高频判断交给 Jev

在这个工业检测场景中，Jev 负责判断告警是否恢复、识别控制意图并选择参数，Device Agent 则把判断接入工作流和设备操作，提供命令下发、状态反馈和执行记录。开发者可以沿用已有设备模型配置处理策略，减少自行整合模型 API、事件处理与设备控制的工作，执行范围也由设备能力和参数约束限定。

实测显示，目标明确的控制请求可以用更少的上下文完成，减少模型用量和等待完整结果的时间。将这类高频判断交给 Jev，需要查询历史、梳理信息或深入分析时再调用 Agent，开发者便能按任务安排模型能力，在保留自然语言交互的同时，控制设备智能化的持续调用开销。

原文结尾

EMQ 中文社区

EMQ中文社区 —— 专注 MQTT、边缘计算与物联网消息基础设施。点击阅读原文，可咨询更多方案内容。