术语表

NeoMind 涉及的概念较多，本文是所有核心术语的集中定义。首次接触某个概念时可以先来这里查。

如果你要看系统整体架构和数据流（而非单个术语），直接跳到核心概念。

怎么用这份术语表

初次浏览：按下面的分类快速过一遍，建立整体印象
遇到陌生词：用页面搜索（Ctrl/Cmd + F）直接查
想理解关系：看末尾的概念关系图

概念分类速览

设备相关

Device（设备）

一个已接入 NeoMind 的物理或虚拟设备。每个设备有唯一 ID、一个设备类型、一组 metrics（遥测指标）和 commands（控制命令）。

例：一台温湿度传感器，metrics 是 temperature / humidity，command 是 reboot。

设备的三个关键属性

唯一 ID — 用于在系统内引用（sensor-01）
设备类型 — 决定有哪些 metrics / commands
连接方式 — MQTT / Webhook / BLE 中的一种

Device Type（设备类型）

某一类设备的"模板"，定义了该类设备有哪些 metrics、commands、连接参数。设备类型以 JSON 定义，存储在 NeoMind-DeviceTypes 仓库。

创建设备时选择一个类型，NeoMind 据此生成默认的 metric / command schema。

示例 — 温湿度传感器类型：

{
  "device_type": "dht22_sensor",
  "name": "Temperature & Humidity Sensor",
  "description": "DHT22-based ambient environment sensor",
  "categories": ["sensor", "environment"],
  "metrics": [
    { "name": "temperature", "display_name": "Temperature", "data_type": "float", "unit": "°C", "min": -40, "max": 80 },
    { "name": "humidity", "display_name": "Humidity", "data_type": "float", "unit": "%", "min": 0, "max": 100 }
  ],
  "commands": [
    { "name": "reboot", "display_name": "Reboot", "description": "Restart the sensor" }
  ]
}

Device Type 的业务价值

Device Type 是硬件与平台之间的契约，在业务系统中承担三个角色：

规范某一类设备 — 所有 DHT22 传感器共享同一个类型定义，无论来自哪个厂商。100 台同类型设备遵循相同的 metric / command schema。
为 AI 提供设备标准 — Agent 读取 metric 定义来理解设备能产生什么数据、支持什么操作。你问"温度多少？"，Agent 知道该查哪个 metric，无需解析原始数据包。
驱动下游配置 — 仪表板组件、自动化规则、数据推送配置都通过名称引用 metric，这些名称来自 Device Type 定义。

自动发现（Auto-Discovery）

NeoMind 对未知设备的自动识别机制：一台未注册的设备通过 MQTT 约定主题（或 Webhook）上报数据时，NeoMind 自动解析出它的类型与指标，并让它进入 Web UI 的 Pending Devices（待审批）列表——不会直接上线。

例：新买的传感器第一次上报 temperature，打开 Devices → Pending Devices 就能看到它的草稿卡片，审批后正式成为设备。

与 Draft 的关系

自动发现是"过程"，Draft 是"结果"——发现未知设备后先生成草稿，等管理员审批。测试环境可用 neomind device drafts config --auto-approve true 跳过人工审批。

详见接入设备。

Draft（设备草稿）

当 NeoMind 通过 MQTT 或 Webhook 自动发现一个未知设备时，不会立即创建设备，而是生成一个"草稿"。管理员审批后草稿才转为正式设备。

为什么不自动接入？

这是安全机制——防止未授权设备自动接入你的系统。自动发现的设备只进草稿队列，你确认后才能正式上线。

例：传感器第一次上报后，Web UI → Devices → Pending Devices 里出现草稿卡片，执行 neomind device drafts approve <DRAFT_ID> --name "客厅传感器" --type temp_sensor 审批后正式上线。

详见接入设备。

Metric（遥测指标）

设备或扩展产生的时序数据点。每个 metric 有名称、数据类型（Integer / Float / String / Boolean）、可选单位。

例：

Metric 名	数据类型	单位	含义
`temperature`	Float	°C	温度
`humidity`	Float	%	湿度
`motion`	Boolean	—	是否检测到移动
`image_data`	String	—	base64 编码的图像

Command（命令）

可对设备下发的控制指令或可对扩展调用的操作。每个 command 有名称和参数 schema。

例：set_temperature(target: Integer)、capture()、reboot()。

DataSourceId（数据源 ID）

NeoMind 中引用任意数据点的统一格式：{type}:{id}:{field}

type	含义	示例
`device`	设备遥测	`device:sensor-01:temperature`
`extension`	扩展指标	`extension:weather-forecast:temperature`
`agent`	Agent 状态	`agent:guard:status`

这是你最常碰到的格式

仪表板组件配置数据源、规则引擎定义触发条件、数据推送配置目标——全部用 DataSourceId。记住 {type}:{id}:{field} 这个三段式就行。

AI 相关

LLM Backend（LLM 后端）

NeoMind 连接的大语言模型实例。支持多种后端：Ollama（本地）、OpenAI、Anthropic、GLM、llama.cpp 等。可配置多个后端，按场景切换。

Agent→Ollama (本地)llama.cpp (本地)OpenAIAnthropicGLM

本地 vs 云端

本地（Ollama / llama.cpp）：零延迟、数据不出局域网、离线可用，但受限于硬件算力
云端（OpenAI / Anthropic / GLM）：模型更强，但需要网络、数据上云、持续计费
可以同时配多个，不同 Agent 用不同后端

详见配置 LLM 后端。

GGUF

llama.cpp 使用的单文件模型格式（.gguf），把权重、分词器、上下文与量化信息打包在一起，本地推理即拖即用。NeoMind 内置模型向导提供「导入本地模型」卡片：拖入 .gguf 文件（流式上传，不占内存）或填写服务器路径，平台自动解析名称 / 上下文 / 量化信息并以 SHA-256 校验落盘；导入模型与精选模型同等参与切换（上下文上限 128K）。

例：把从 Hugging Face 下载的 model-q4_k_m.gguf 拖进向导，稍等片刻它就出现在 LLM Backend 的模型列表里，全程数据不出本机。

详见配置 LLM 后端。

Agent（AI 智能体）

NeoMind 的核心智能单元。Agent 接收自然语言输入（或定时触发），通过 LLM 理解意图，调用工具（CLI 命令、设备控制、扩展命令）执行操作，并从执行结果中学习。

Agent ≠ ChatGPT

Agent 不只是聊天——它能执行操作。你问"温度超 30 度通知我"，它会真正创建规则、配置通知渠道、启动监控。背后是工具调用（Tool Use）能力。

详见 AI Chat 和 AI Agent。

AI Chat（AI 对话）

Agent 的交互模式——用户在对话框输入消息，AI 实时调用工具并流式回复。支持上传图片做多模态分析。使用对话历史 + MemorySnapshot 记忆。

例：在对话框输入"统计这张车间照片里的人数"，Agent 当场调用视觉工具分析图片并流式给出答案。

详见 AI Chat；在 Telegram / 飞书里对话同一个 Agent 见 IM 桥接。

IM 桥接（IM Bridge）

在 Telegram / 飞书 里直接和同一个 Agent 双向对话的接入方式（0.9.14+）——像网页端 AI Chat 一样发消息、传图片、收流式回复，而不只是接收告警。

IM 桥接 ≠ 通知渠道

消息渠道里的 Telegram / 飞书是单向告警推送；IM 桥接是双向对话。两者相互独立，可同时使用。

例：出差时在 Telegram 里给 Agent 发"看一下仓库现在温湿度"，Agent 调用工具查询后把结果回在聊天里。

详见 AI Chat。

Memory（记忆）

跨执行/会话积累的经验，按模式分两套：

模式	记忆结构	存储	作用
AI Chat	对话历史 + MemorySnapshot	`user.md` + `knowledge.md`	跨会话记住用户偏好与关键事实
AI Agent	Journal + Knowledge Files	redb + Markdown 文件	跨执行积累经验：成功/失败、学到的规律、设备身份、任务使命

Journal 是每次 Agent 执行的结果摘要（做了什么、成功/失败、学到了什么）。Knowledge Files 是长期知识（设备身份、任务使命、资源清单、巡检规律）。

MemorySnapshot / Journal / Knowledge Files（记忆内部结构）

Memory 两套记忆体系的具体载体：

结构	属于哪套模式	是什么
MemorySnapshot	AI Chat	对话记忆快照，落盘为 `user.md`（用户偏好）与 `knowledge.md`（关键事实），新会话开始时恢复上下文
Journal	AI Agent	执行日志：每次执行追加一条记录（触发方式、数据摘要、LLM 结论、动作、成功/失败），下次执行读取最近 N 条学习历史模式
Knowledge Files	AI Agent	长期知识文件（Markdown）：首次成功执行后自动初始化一份 `task-understanding`（含角色 / 使命 / 资源 / 计划四节），Agent 之后可通过 memory 工具自行创建更多知识文件，可在 Agent 详情 → Memory 面板手动编辑

例：Agent 对同一设备重复发送了两次告警，Journal 里留下失败记录后，下次执行会跳过已发送的告警并调整阈值——这就是"读 Journal → 改行为"的闭环。

详见 AI Agent。

Think-Act-Observe（思考-执行-观察循环）

Agent 的核心执行模式：LLM 分析当前状态（思考）→ 调用工具（执行）→ 读取结果（观察）→ 循环直到任务完成或达到轮数上限（默认 30 轮，全局超时 5 分钟）。

Skill（技能）

为 Agent 提供场景化指导的知识文件（YAML 元数据 + Markdown 正文，存储在 data/skills/）。Skill 定义了特定场景下的操作步骤、常见错误和最佳实践，Agent 按描述自动匹配相关 Skill（内置技能只读，用户技能可增删改）。

例：Agent 领到"巡检相机"任务时，按描述自动匹配相机巡检类 Skill，照着里面的步骤调用命令、避开文档里记录的常见错误；也可以在 Agent 编辑器里手动固定（pin）某个技能。

详见 AI Agent。

Multimodal（多模态）

LLM 处理图像输入的能力。取决于模型——Ollama 拉取视觉模型（如 qwen3.5:4b-vl / llava）或使用云端视觉模型（gpt-4o / claude-sonnet-4-6 / gemini-2.0-flash）后，AI Chat 支持上传图片进行视觉分析。

VLM（Vision-Language Model，视觉语言模型）

同时理解图像（视频）与文本的多模态模型，能对画面输出自然语言描述而非只有结构化坐标。NeoMind 中两处用到：仪表板的 VLM 视觉组件（图像 + AI 标注），以及 video-vlm（实时视频流 VLM 语义理解，板载 LFM2.5-VL）与 vision-hub（统一视觉管线：检测 / OCR / 人脸 / 定位 / VLM）扩展。

例：video-vlm 扩展接上 RTSP 摄像头后，VLM 输出"一名工人正在进入危险区域"这样的语义事件，可直接触发规则与通知。

详见使用仪表板和扩展管理。

Tool（工具）

Agent 可调用的操作。NeoMind 的 Agent 主要通过 neomind CLI 命令操作设备、规则、仪表板等。工具系统自动把已安装扩展的 commands 也暴露给 LLM。

Agent
  └── neomind CLI
        ├── device 管理
        ├── rule 管理
        ├── dashboard 管理
        └── extension 调用
              ├── YOLO 检测
              ├── OCR 识别
              └── 天气预报

数据处理相关

Transform（数据转换）

在数据写入 Telemetry 后自动执行的 JavaScript 管道，将原始指标转换为更有意义的派生指标。支持三级作用域：Global（所有设备）、Device Type（一类设备）、Device（单个设备）。

例：原始数据 {temperature: 25.6, humidity: 60} → Transform 计算出 dew_point: 16.7°C（露点）和 comfort: "humid"（舒适度）。

派生指标以 transform:{output_prefix}:{field} 格式写入 Telemetry，和原始数据一样被仪表板、规则、Agent 消费。

详见核心概念 — Transform 和自动化规则。

自动化相关

Rule（规则）

事件驱动的自动化逻辑。当条件满足时自动执行动作。

NeoMind 规则用 JSON 定义：

{
  "name": "高温告警",
  "trigger": { "trigger_type": "data_change" },
  "condition": { "condition_type": "comparison", "source": "device:sensor-01:temperature", "operator": "greater_than", "threshold": 30 },
  "actions": [ { "type": "notify", "message": "温度过高" } ],
  "cooldown": 60
}

规则由三部分组成：触发器（trigger，何时评估）、条件（condition，何时满足）、动作（actions，满足后做什么）。

详见自动化规则。

Cooldown（冷却时间）

规则触发后的抑制窗口（单位：秒）。在冷却时间内，即使条件再次满足也不会重复触发，防止告警风暴。例如 cooldown: 60 表示触发后 60 秒内不再重复。

Rule Engine（规则引擎）

NeoMind 内置的自动化评估引擎。在数据写入 Telemetry 时立即评估绑定的规则条件（零延迟，无需轮询）。匹配后执行动作（通知、执行命令、触发 Agent）。

Message Channel（消息渠道）

规则触发通知时的投递通道。共 7 种渠道类型——Webhook、邮件、Telegram、企业微信、钉钉、Slack、飞书，需自行创建并配置。所有通知同时沉淀在应用内消息中心（Messages 页面），无需配置。

Rule 触发→WebhookEmailTelegram企业微信钉钉Slack飞书Console（控制台 · 内置）Memory（记忆 · 内置）

详见消息通知。

Data Push（数据推送）

将遥测数据主动推送到外部系统（Webhook 或 MQTT），区别于被动查询。可配置推送频率、数据格式、目标地址。

Data Push vs Rule

Data Push — 无条件推送原始数据（"每 10 秒把温度推给外部系统"）
Rule — 条件触发动作（"温度超 30 度时发通知"）

例：把 device:sensor-01:temperature 每 10 秒推给运维平台的 HTTP 端点，供外部工单系统消费。

详见数据推送。

扩展相关

Extension（扩展）

通过 FFI（外部函数接口）加载到 NeoMind 的插件模块。扩展用 Rust 编写，编译为动态库（.dylib / .so / .dll），运行在独立进程中。

扩展可以：

提供 metrics（数据流）
提供 commands（可调用操作）
加载 ML 模型（如 YOLO 目标检测）
处理流式数据（如视频帧）

ExtensionRunner
(主进程)

YOLO 检测 (独立进程 · FFI)

OCR 识别 (独立进程 · FFI)

进程隔离的意义

扩展运行在独立进程中——如果 YOLO 扩展因为模型加载失败而崩溃，主服务不受任何影响。其他扩展也不会被波及。这是 NeoMind 稳定性的关键设计。

详见 Extension SDK。

Capability（能力）

扩展启动时必须声明的能力权限。未声明的能力调用会被拒绝。体现最小权限原则。20 种内置能力（含 chat 流式系列）覆盖设备读写、设备控制、存储查询、事件订阅、触发器等，完整清单见扩展 SDK：

类别	Capability	含义
设备数据	`device_metrics_read` / `device_metrics_write`	读/写设备指标（含虚拟指标）
设备控制	`device_control`	向设备下发命令
存储	`storage_query` / `telemetry_history` / `metrics_aggregate`	查询遥测历史与聚合
事件	`event_publish` / `event_subscribe`	发布/订阅系统事件
触发器	`extension_call` / `agent_trigger` / `rule_trigger`	调用扩展、触发 Agent/规则
设备管理	`device_register` / `device_unregister` / `device_template_register`	动态注册设备

也支持 Custom(String) 自定义能力。

安全模型

一个天气扩展只需要 device_metrics_write 能力。如果它试图控制设备，NeoMind 会直接拒绝。这样即使扩展有 bug 被攻击，影响范围也被限制在声明的权限内。

FFI（Foreign Function Interface，外部函数接口）

扩展进程与主进程之间的跨进程通信机制。所有请求和响应用 serde JSON 序列化——没有自定义二进制协议，日志可读，排查简单。这是 NeoMind 选择进程隔离而非 WASM 的关键原因：FFI 可以直接调用 GPU/ML 框架，而 WASM 做不到。

.nep

NeoMind 扩展的分发包格式。一个 .nep 文件是 zip 归档，包含多平台编译产物 + metadata.json + 可选模型文件。

用户在 Web UI 一键安装时，runner 自动选择匹配当前平台的二进制——不需要关心目标系统是 macOS 还是 Linux，是 ARM 还是 x86。

neomind_export!

SDK 提供的宏，将 Rust impl Extension 自动导出为 FFI 入口。扩展开发者只需在代码末尾加一行：

neomind_extension_sdk::neomind_export!(MyExtension);

Process Isolation（进程隔离）

扩展运行在独立进程中，而非主进程内。好处是：扩展崩溃（panic）不会拖垮主服务；扩展之间互不干扰；按 capability 授权的能力边界更清晰。

Lazy Load（延迟加载）

ML 模型不在扩展启动时加载，而是在第一次命令调用时才载入内存。加载后常驻（直到扩展进程退出），避免每次推理重新加载。

为什么不启动时就加载？

YOLOv8n 模型约 12MB，加载需要 1-2 秒。如果扩展启动就加载，但用户可能几小时后才用——白白占用内存。延迟加载 = 按需占用，用完常驻。

基础设施相关

事件总线（EventBus）

NeoMind 的发布/订阅（pub/sub）骨干，由 neomind-core::event_bus 实现。设备、规则引擎、数据转换、仪表板、通知等模块互不直接调用，全部通过事件解耦——多订阅者并行触发，单订阅者内串行处理。

事件源	事件	订阅者
设备数据写入（含 MQTT / Webhook / 扩展虚拟指标）	`DeviceMetric`	规则引擎、数据推送、仪表板 WS
规则触发	`RuleTriggered`	消息通知、Agent
Agent 完成	`AgentExecutionCompleted`	记忆系统、消息通知
扩展输出	`ExtensionOutput`	存储、仪表板

例：一条 MQTT 上报同时"点亮"仪表板曲线、命中高温规则、驱动数据推送——三类订阅者互不知晓，全靠事件总线扇出。

详见产品架构中的"事件总线"一节。

MQTT Broker

NeoMind 内置的消息代理（端口 1883）。设备通过 MQTT 协议连接、上报遥测、接收命令。

零依赖

无需安装外部 Broker（如 Mosquitto）——NeoMind 自带一个完整的 MQTT 实现。启动即可用，设备直连 localhost:1883。

mTLS（双向 TLS）

MQTT 传输层的安全选项：设备与服务端互相校验 X.509 证书（CA 证书 + 客户端证书），既加密传输防窃听，也拦截伪造设备。NeoMind 内置 Broker 支持 mTLS 与 CA 证书（TLS 加密通常走 8883 端口）。

例：产线设备烧录客户端证书后才能连上 Broker——没有证书的仿冒设备在 TLS 握手阶段就被拒绝，根本到不了待审批那一步。

详见接入设备。

Telemetry（遥测存储）

NeoMind 的时序数据库，基于 redb 实现，存储在 data/telemetry.redb。所有 metric 值都写入这里，仪表板和规则引擎从中读取。

例：传感器每 10 秒上报一次 temperature，数据落进 telemetry.redb 后，仪表板曲线、规则条件、Agent 查询读的都是同一份。

详见接入设备。

redb

NeoMind 使用的嵌入式键值存储引擎（Rust 编写）。无外部数据库依赖，数据文件直接落盘在 data/ 目录。

为什么不用 SQLite / PostgreSQL？

redb 是纯 Rust 实现，与 NeoMind 的 Rust 技术栈完美融合——零外部依赖、零跨语言开销、编译进同一个二进制。对时序数据（写多读少、按时间范围查询）做了专门优化。

Webhook

一种 HTTP 回调机制。设备可通过向 NeoMind 的 webhook URL 发送 POST 请求来上报数据，无需 MQTT。也用于接收外部系统的事件推送。

例：没有 MQTT 客户端的小型单片机，直接向设备 webhook URL POST 一段 JSON 就能完成上报。

详见 REST API 参考。

SSE（Server-Sent Events）

HTTP 长连接单向推送协议。NeoMind 用 SSE 向 Web UI 实时推送设备数据更新——数据写入 Telemetry 后立即推送到已打开的仪表板，无需前端轮询。AI Chat 的流式回复也走 SSE。

例：仪表板页面打开期间，新遥测数据毫秒级刷新曲线；AI Chat 的回答逐字出现——两条链路都走 SSE。

详见 REST API 参考。

仪表板相关

Dashboard（仪表板）

由一组 Widget（组件）组成的可视化页面。支持创建多个仪表板、分享（带过期时间的公开链接）、移动端自适应。

仪表板上的单个可视化元素。内置类型：

类型	展示内容	典型场景
数值卡	单个数值	当前温度、湿度
折线图	时序趋势	24 小时温度变化
仪表盘	指针式读数	CPU 使用率
数据表	多列表格	设备列表、历史记录
VLM 视觉	图像 + AI 标注	目标检测结果
流播放器	实时视频流	摄像头画面

以上为常用内置类型，完整组件类型清单见仪表板使用指南；也支持扩展提供的自定义组件与社区组件市场。

详见使用仪表板。

概念关系图

这些概念如何协作？下图展示从设备到可视化的完整数据流（原始数据写入后可先经 Transform 加工为派生指标，再被下游消费）：

数据来源	接入层	遥测存储	数据加工	消费者	输出
Device 相机 · 传感器 · 控制器 Extension YOLO · OCR · 桥接器	MQTT `:1883` Webhook BLE	redb `data/telemetry.redb` 一次写入多路消费	Transform JavaScript 管道原始指标 → 派生指标 `transform:*`	Dashboard / Widget 规则引擎 Agent (LLM)	实时界面 (WebSocket 推送) 通知 (7 种渠道) AI 回答 (自然语言)

→→→→→→

最后更新: 2026-09-09

概念分类速览​

设备相关​

Device（设备）​

Device Type（设备类型）​

自动发现（Auto-Discovery）​

Draft（设备草稿）​

Metric（遥测指标）​

Command（命令）​

DataSourceId（数据源 ID）​

AI 相关​

LLM Backend（LLM 后端）​

GGUF​

Agent（AI 智能体）​

AI Chat（AI 对话）​

IM 桥接（IM Bridge）​

Memory（记忆）​

MemorySnapshot / Journal / Knowledge Files（记忆内部结构）​

Think-Act-Observe（思考-执行-观察循环）​

Skill（技能）​

Multimodal（多模态）​

VLM（Vision-Language Model，视觉语言模型）​

Tool（工具）​

数据处理相关​

Transform（数据转换）​

自动化相关​

Rule（规则）​

Cooldown（冷却时间）​

Rule Engine（规则引擎）​

Message Channel（消息渠道）​

Data Push（数据推送）​

扩展相关​

Extension（扩展）​

Capability（能力）​

FFI（Foreign Function Interface，外部函数接口）​

.nep​

neomind_export!​

Process Isolation（进程隔离）​

Lazy Load（延迟加载）​

基础设施相关​

事件总线（EventBus）​

MQTT Broker​

mTLS（双向 TLS）​

Telemetry（遥测存储）​

redb​

Webhook​

SSE（Server-Sent Events）​

仪表板相关​

Dashboard（仪表板）​

Widget（组件 / 部件）​

概念关系图​

概念分类速览

设备相关

Device（设备）

Device Type（设备类型）

自动发现（Auto-Discovery）

Draft（设备草稿）

Metric（遥测指标）

Command（命令）

DataSourceId（数据源 ID）

AI 相关

LLM Backend（LLM 后端）

GGUF

Agent（AI 智能体）

AI Chat（AI 对话）

IM 桥接（IM Bridge）

Memory（记忆）

MemorySnapshot / Journal / Knowledge Files（记忆内部结构）

Think-Act-Observe（思考-执行-观察循环）

Skill（技能）

Multimodal（多模态）

VLM（Vision-Language Model，视觉语言模型）

Tool（工具）

数据处理相关

Transform（数据转换）

自动化相关

Rule（规则）

Cooldown（冷却时间）

Rule Engine（规则引擎）

Message Channel（消息渠道）

Data Push（数据推送）

扩展相关

Extension（扩展）

Capability（能力）

FFI（Foreign Function Interface，外部函数接口）

.nep

neomind_export!

Process Isolation（进程隔离）

Lazy Load（延迟加载）

基础设施相关

事件总线（EventBus）

MQTT Broker

mTLS（双向 TLS）

Telemetry（遥测存储）

redb

Webhook

SSE（Server-Sent Events）

仪表板相关

Dashboard（仪表板）

Widget（组件 / 部件）

概念关系图