SA 设备控制：Agent 设计方案 (Semantic/AI Layer)

文档目的：描述设备控制专家（IoT Specialist）如何通过多轮对话完成槽位提取、意图澄清，并结合后端实时回传的产品级聚合能力（Product-Level Capabilities）实现精准控制。映射配置已上浮至产品层，Agent 上下文按产品聚合注入，大幅减轻 LLM 负担。

术语澄清：Stage 流程阶段 vs L 信息深度

维度	命名	含义	出现位置
流程阶段	Stage 1 → 2 → 3 → 4	串行处理步骤：提取 → 检索 → 推理 → 渲染	§2, §3, §4, §5
信息深度	L1 → L2 → L3	注入层级：按数据量递增，Step 1(默认) 送 L1+L2，Step 2(按需) 送 L3	§4.1

快速记忆：Stage 是"第几步"，L 是"给多少料"。Stage 3（推理阶段）内部又分 Step 1（默认注入 L1+L2）和 Step 2（按需注入 L3）。

1. 核心业务流程 (Happy Path Sequence)

IMPORTANT

开发阶段说明：空间级控制与感知能力（如：空间级 SSOT 映射、群控分发等）目前深度依赖 自控平台的空间逻辑信号升级。在信号底座完成升级前，系统将以“物理实体资产直控”作为主要交付路径。

本流程描述在 “多空间干扰” 与 “感知渐进式披露” 背景下，如何通过两阶段工程检索实现精准控制的标准路径。

2. 第一阶段：槽位提取 (Stage 1: Slot Filling)

单节点设计：意图分类与槽位提取合并为一个 LLM 节点，一次性输出 { site, device, intent_type }。下游 Agent 节点通过 chat history 拿到完整 user query。

2.1 槽位定义

字段	类型	说明
`site`	String	地点，如 "305"、"3楼"、"VIP室"。无法提取时 null。
`device`	String	设备关键字，如 "空调"、"灯"、"二号门"。无法提取时 null。
`intent_type`	Enum	`CONTROL`（控制指令）或 `QUERY`（查询指令）。Master Agent 路由至此子 Agent 时必为二者之一。

判定规则：

CONTROL：包含"打开/关闭/开启/关掉/调到/设为/切换/调整"等操作动词
QUERY：包含"多少/状态/查/看/显示/告警/有没有/是否/监测"等查询动词

示例输出：

User: "3楼空调调到18度"
→ { "site": "3楼", "device": "空调", "intent_type": "CONTROL" }

User: "305空调多少度"
→ { "site": "305", "device": "空调", "intent_type": "QUERY" }

User: "查一下1楼告警"
→ { "site": "1楼", "device": null, "intent_type": "QUERY" }

User: "打开大厦的二号门"
→ { "site": "大厦", "device": "二号门", "intent_type": "CONTROL" }

2.2 澄清追问与拦截策略

根据 site + device + intent_type 的填充情况判断是否直接进入 Stage 2 检索：

场景	条件	策略
1. 完整路径	site + device 均非空	直接进入 Stage 2 检索
2. 缺设备	仅 site 非空	CONTROL 进入隐式嗅探检索（按能力标签匹配）；QUERY 返回该空间全部设备
3. 缺空间	site 为空	强制追问"请问您要操作/查询哪个区域？"

flavor 设计分歧：target_flavor（BOOLEAN/NUMERICAL/ENUM）作为 CONTROL 场景原语，理论上可在 Stage 1 提前过滤属性类型，减轻 L3 上下文压力。当前 MVP 阶段暂不落地，与工程侧实现存在差异，此处保留分歧、暂不纠正。

2.3 当前 Dify 实现（MVP 阶段）

当前 Dify Slot Filling 节点提示词未包含 intent_type，仅提取 site + device。CONTROL/QUERY 的区分由下游 Agent 节点根据用户 query 自行判断。

# 角色：Slot提取器
严格按照Slot规则从用户text中提取Slot。仅输出JSON，无额外文本。

# Slot规则
- site: 地点
- device: 设备

# 输出要求
1. 如果是对设备的指令请求，如获取状态，控制，设置等。根据Slot规则，提取对应的字段，必须从user的原始text中获取，禁止任何修改，如果没有或者无法提取则设置成null。最终组成json返回。
2. 如果是其他的请求，直接返回slot字段全部设置成null。

# example
1. user text："3楼空调调到18度"
result: { "site": "3楼", "device": "空调" }

2. user text: "打开大厦的二号门"
result: { "site": "大厦", "device": "二号门" }

3. user text: "实验室的湿度为30%"
result: { "site": null, "device": null }

3. 第二阶段：工程化分层检索 (Stage 2: Composite 3x3 Search)

IMPORTANT

双轨复合检索：Stage 2 必须并联拉取"空间逻辑层"与"物理实体层"骨架，为 Agent 提供完整的脑手上下文。

3.1 检索逻辑

Engine 根据 site + device 召回匹配的设备列表：

search_entities(site, device?)
  → [{ device_id, device_name, product_id, cap_tags }]

参数	说明
`site`	目标空间，支持递归子空间
`device`	设备关键字，为空时返回该空间全部设备

返回结果仅为设备骨架（ID、名称、产品 ID、能力标签），不含属性详情。标准语义的筛选与校验在 Stage 3 完成。

约束：最多返回 3 个空间 × 每个空间 3 个设备 = 9 个设备。

3.2 缺设备时的隐式嗅探

当 device 为空时（如"305 调到 18 度"），Engine 返回该空间下所有具备 CONTROL 能力标签的设备，由 Stage 3 的 LLM 根据用户原始 query 自行匹配目标属性。

4. Stage 3 — CONTROL 推理 (CONTROL Reasoning)

本章定义了 CONTROL 场景下，在推理阶段（Stage 3）如何通过两阶段信息注入，解决上下文压力与决策精度之间的矛盾。

4.1 渐进式信息注入协议 (L1-L3)

层级	信息类别	包含内容示例	注入阶段	目的
L1	环境感知摘要	空间代表温度、灯光状态 (来自 SSOT)	后续优化点，当前未注入	提供空间的"单一真相"现状。暂不实现，待自控平台空间逻辑信号就绪后接入。
L2	复合实体骨架	ID、名称、角色、能力标签；[核心] MCP 标准语义描述 (llm_desc)	Step 1 默认注入	用于初步意图对齐（如：基于标准语义理解"调冷"该找哪个点位）。
L3	产品级聚合描述	产品级点位映射 + 每 capability 独立挂 enabled_device_count + current_values[]	Step 2 按需注入	针对锚定产品执行精准物理计算与边界校验。同产品设备共享一份映射，消除重复上下文。LLM 在推理阶段根据 mapping 计算精确目标值。

L2 注入结构（复合实体骨架 — Step 1 默认注入）：

L2 是从当前检索范围内所有设备的 capability 中汇总去重的标准语义描述集合，按能力标签（key）聚合，不涉及设备实例。LLM 依赖此结构理解每个能力标签的自然语言含义，完成用户意图到语义 key 的映射。

json

{
  "llm_desc": {
    "light_power":       "控制照明设备的开关状态。指令识别关键词：打开、关闭、开灯、关灯。",
    "hvac_target_temp":  "用于设置或调节暖通空调的目标温度。指令识别关键词：温度调到、热一点、冷一点。",
    "hvac_mode":         "切换空调的运行模式，具体模式值见产品映射。指令识别关键词：模式、制冷、制热、除湿、送风、自动等。",
    "hvac_fan_speed":    "调节空调的风速档位，具体档位值见产品映射。指令识别关键词：风速、风量、大风、小风。",
    "room_temp":         "读取室内环境的当前回风温度（只读传感器）。",
    "alarm_status":      "查询设备的故障与告警状态。指令识别关键词：告警、故障、异常、状态。"
  }
}

设计要点：
llm_desc 来自标准语义库（管理员后台配置），描述每个标准语义 key 的意图与关键词，不包含具体产品的映射约束（如 bool label、enum value label、num range/step）
同一检索范围内的重复 capability 自动去重，LLM 收到的是一份语义全集
Stage 3 LLM 根据 llm_desc 将用户自然语言映射到标准语义 key（如"调冷" → hvac_target_temp）
产品层面的具体映射（量程、枚举值、步进等）在 L3 中按需注入
L2 驱动 L3：LLM 在 Stage 3 可以挑选多个语义 key（如"温度调低 2 度+风速调大"），选中的 key 集合决定了 Engine 在 Step 2 要拉取哪些 capabilities 的 L3 数据。未被选中的 key 不注入 L3，实现渐进式按需加载

L3 注入结构（产品级聚合描述 — Step 2 按需注入）：

json

[
  {
    "product_id": "prod_ac_daikin",
    "product": "大金空调",
    "capabilities": [
      {
        "key": "hvac_mode",
        "name": "运行模式",
        "data_type": "enum",
        "access": "rw",
        "semantic_desc": "切换空调运行模式",
        "mapping": {
          "values": { "0": "制冷", "1": "制热", "2": "送风", "3": "除湿" },
          "ai_instruction": "制冷模式降温，制热模式升温"
        },
        "enabled_device_count": 4,
        "current_values": [1, 0, 1, 2]
      },
      {
        "key": "hvac_target_temp",
        "name": "设定目标温度",
        "data_type": "number",
        "access": "rw",
        "semantic_desc": "设置空调目标温度",
        "mapping": { "min": 10, "max": 25, "step": 1.5, "unit": "℃" },
        "enabled_device_count": 3,
        "current_values": [24, 26, 22]
      }
    ]
  },
  {
    "product_id": "prod_ac_midea",
    "product": "美的空调",
    "capabilities": [
      {
        "key": "hvac_mode",
        "name": "运行模式",
        "data_type": "enum",
        "access": "rw",
        "semantic_desc": "切换空调运行模式",
        "mapping": {
          "values": { "0": "自动", "1": "制冷", "2": "制热", "3": "送风" },
          "ai_instruction": "自动模式根据温差自动选择"
        },
        "enabled_device_count": 5,
        "current_values": [0, 2, 0, 1, 0]
      },
      {
        "key": "hvac_target_temp",
        "name": "设定目标温度",
        "data_type": "number",
        "access": "rw",
        "semantic_desc": "设置空调目标温度",
        "mapping": { "min": 15, "max": 30, "step": 1, "unit": "℃" },
        "enabled_device_count": 5,
        "current_values": [25, 28, 24, 22, 26]
      }
    ]
  }
]

设计要点：
enabled_device_count 与 current_values.length 对齐，LLM 知道"大金4台都开了 hvac_mode，但只有3台开了 hvac_target_temp"
每个 capability 独立挂 current_values（不含设备 ID），结构紧凑
控制输出时 Engine 根据 product_id + 语义值拆解为逐设备物理指令

业务背景：同一产品部署在不同空间时，管理要求可能不同。disabled_signals 机制支持这种差异：

空间	设备	允许操作	disabled_signals
CEO 办公室	大金空调_01	开关 + 温度 + 风速 + 模式	—
开放办公区	大金空调_02	仅开关	`hvac_target_temp`, `hvac_fan_speed`, `hvac_mode`
会议室	大金空调_03	开关 + 温度	`hvac_fan_speed`, `hvac_mode`

设备级 disabled_signals 详见设备语义管理 PRD §6.3。

4.2 LLM 输出示例与推理逻辑

HITL 说明：LLM 不负责生成用户话术。输出 renderSAControl 驱动前端控制卡片，由用户手动确认后执行。以下示例只展示 LLM 输出的结构化数据。

基于上述 L3 结构（大金空调 4 台 + 美的空调 5 台），以下为三个典型用户意图的 LLM 输出对比：

4.2.1 场景 A：制热模式（跨产品兼容）

用户: "帮我把305的空调调整到制热模式"
LLM 推理:
  ├─ 大金 hvac_mode.values 中包含 "制热=1" ✅
  ├─ 美的 hvac_mode.values 中包含 "制热模式=2" ✅
  └─ 结论: 所有空调都可调至制热

LLM 输出 (renderSAControl):
{
  "intent": "hvac_mode",
  "target_value_text": "制热模式",
  "targets": [
    { "product_id": "prod_ac_daikin", "semantic_value": 1 },
    { "product_id": "prod_ac_midea",  "semantic_value": 2 }
  ]
}

前端展示效果：

┌──────────────────────────────┐
│ 执行动作：设定为 制热模式     ← target_value_text
├──────────────────────────────┤
│ ── 大金空调 ──               │
│ ☑ 空调(左) (当前 自动)       │
│ ── 美的空调 ──               │
│ ☑ 空调(右) (当前 制热)       │
└──────────────────────────────┘

4.2.2 场景 B：除湿模式（仅部分产品兼容）

用户: "帮我把305的空调调整到除湿模式"
LLM 推理:
  ├─ 大金 hvac_mode.values 中包含 "除湿=3" ✅
  ├─ 美的 hvac_mode.values 中无 "除湿" ❌
  ├─ 美的可选值: 自动, 制冷, 制热, 送风
  └─ 结论: 仅大金可调至除湿，美的跳过

LLM 输出 (renderSAControl):
{
  "intent": "hvac_mode",
  "target_value_text": "除湿",
  "targets": [
    { "product_id": "prod_ac_daikin", "semantic_value": 3 }
  ]
}

4.2.3 场景 C：温度调低（标准语义输出绝对值）

用户: "帮我把305的空调温度调低一点"
LLM 推理:
  ├─ 当前各设备温度分布:
  │   大金: [24, 26, 22]  → 偏高, 需降低
  │   美的: [25, 28, 24, 22, 26] → 部分偏高
  ├─ range: 大金[10,25], 美的[15,30]; step: 大金1.5, 美的1
  └─ "调低一点"→ 平均值约 24.6℃，下调至 22℃ (在交集[15,25]内 ✅)

LLM 输出 (renderSAControl):
{
  "intent": "hvac_target_temp",
  "target_value": 22,
  "targets": [
    { "product_id": "prod_ac_daikin" },
    { "product_id": "prod_ac_midea" }
  ]
}

LLM 输出标准 Key hvac_target_temp 和绝对值，不关心产品的物理信号标识符和 step。Engine 收到后根据 product_id 查产品映射，自动按各产品的 step 做值对齐（如大金 22 对齐到最近 step 1.5 → 22.5 或 21）。

4.2.4 边界场景示例：越界处理

Context: 大金 range[10,25], 美的 range[15,30]

全越界: "调整到 5度"

LLM 推理:
  ├─ 5 < 大金 min(10) ❌ 且 5 < 美的 min(15) ❌
  └─ 两产品均不支持

LLM 输出 (renderSAControl):
  → targets: []（空，不执行）

部分越界: "调整到 11度"

LLM 推理:
  ├─ 11 >= 大金 min(10) ✅, 11 <= 大金 max(25) ✅ → 大金可用
  ├─ 11 < 美的 min(15) ❌ → 美的不可用
  └─ 仅大金可调至 11℃

LLM 输出 (renderSAControl):
{
  "intent": "hvac_target_temp",
  "target_value": 11,
  "targets": [
    { "product_id": "prod_ac_daikin" }
  ]
}

全部兼容: "调整到 20度"

LLM 推理:
  ├─ 20 在大金[10,25]内 ✅, 在美的[15,30]内 ✅
  └─ 两产品均可用

LLM 输出 (renderSAControl):
{
  "intent": "hvac_target_temp",
  "target_value": 20,
  "targets": [
    { "product_id": "prod_ac_daikin" },
    { "product_id": "prod_ac_midea" }
  ]
}

4.3 前端渲染与共享量程

当前端需要展示一个跨产品的控制卡片（如温度滑动条）时，Engine 在返回 renderSAControl 的同时应附带共享量程信息：

json

{
  "shared_range": {
    "min": 15,        // max(各产品min)
    "max": 25,        // min(各产品max)
    "step": 1.5       // max(各产品step)，暂定策略
  }
}

step 处理说明：共享 step = max(各产品 step)。Engine 收到 LLM 的 target_value 后，按各产品的 step 独立做值对齐。例如 LLM 输出 22 → 大金 step=1.5 对齐到 22.5，美的 step=1 对齐到 22。前端滑动条使用共享 step 保证交互边界内所有值至少能被一个产品支持。步长精度问题待后续优化。

4.4 跨产品控制推理策略 (Cross-Product Reasoning)

当用户意图命中多个产品（如同时控制大金和美的空调、灯和灯带），LLM 需根据各产品的 mapping 枚举值做兼容性判断。

4.4.1 枚举值推理逻辑

用户意图	产品 A enum	产品 B enum	Agent 决策
"制热"	有 `制热=1`	有 `制热=2`	全部下发，Engine 按不同值拆解
"除湿"	有 `除湿=3`	无	仅选产品 A 的设备
"全关"	有 `0=关`	有 `0=关`	全部下发
"开灯" (同一语义 Key)	灯: `0=关/1=开`	灯带: `0=关/1=开`	全部下发

核心规则：

LLM 根据各产品的 values 字段判断语义值是否在所有目标产品中存在
全部存在的语义值 → 跨产品统一执行
部分存在的语义值 → Agent 仅选中支持该语义的产品设备子集
不存在于任何产品的语义值 → Agent 告知用户不支持并建议替代

4.4.2 前端渲染影响

Agent 输出的 renderSAControl 包含 target_value_text（卡片顶部统一展示文本）。Engine 根据 product_id 将语义值拆解为该产品的物理值：

json

{
  "intent": "hvac_mode",
  "target_value_text": "制热模式",
  "targets": [
    { "product_id": "prod_ac_daikin", "devices": ["dev_1","dev_2"], "physical_value": 1 },
    { "product_id": "prod_ac_midea",  "devices": ["dev_3","dev_4"], "physical_value": 2 }
  ]
}

同语义 Key 跨产品控制（如灯开关）不受影响，bool 的 0/1 在所有产品中一致。不同产品的 llm_desc 用于引导 Agent 理解能力差异。

4.5 语义对齐与筛选逻辑 (Reasoning Task)

边界校验：对比用户要求的 18度 与 L3 注入的 min: 20。
数值计算：利用 L3 回传的实时值完成相对调节（如"调高 2 度" -> current + 2）。
语义执行 (MCP Logic)：参考由后台 llm_desc 注入的指令参考。例如用户说"再冷点"，Agent 需匹配 llm_desc 中定义的数值负向调节逻辑。
产品级上下文轻量化：L3 按产品聚合注入，同产品设备共享一份 mapping。device_count 代替全量设备 ID，LLM 感知到"5 台灯设备"而非逐设备注入完整 mapping。Engine 最终根据 product_id + disabled_signals 拆解为逐设备指令。
跨设备关联 (Cross-Device)：当用户意图命中 A 类设备（如投影）时，Agent 自动检查与其具备语义关联的 B 类环境指标（如 Lux）。若 B 指标异常，则在回复语中加入对 B 的操作建议。(规划中)

4.6 异构设备逻辑代偿 (CONTROL 专有)

此章节仅适用于 CONTROL 场景。QUERY 只读当前值，不涉及代偿逻辑。

4.6.1 设计背景

在真实项目交付中，暖通空调（HVAC）等设备的物模型存在严重的碎片化，Agent 必须处理以下三种典型的异构控制逻辑：

类型 A：标准分离型（如大金/主流多联机）：具备独立的 power (BOOLEAN) 属性，开关逻辑清晰。
类型 B：模式聚合型（如约克/部分中央空调）：无独立开关属性，开关机逻辑被合并入 mode (ENUM) 枚举中。例如：0=关机，1=制冷，2=制热。此时，"开启"意图需要转换为对特定模式的选择。
类型 C：边界模拟型（如老旧非标设备）：无开关也无模式，通过物理数值的极端边界来模拟开关。例如：target_temp = 0℃ (或 1℃) 约定为关机。

这是一个真实的美的空调例子，关机 = 8

由于底层物模型的"杂乱"，Agent 绝对不能死板地寻找 hvac_power 点位，否则会导致大量异构设备无法被 AI 驱动。因此，必须引入"逻辑代偿"机制。

4.6.2 核心实现路径

为了在不修改物理驱动的前提下支持此类设备，Agent 采取 "弱化前期 Key 过滤，强化后期能力发现" 的策略：

意图兼容性搜索 (Search Broadening)：
- 在 Stage 2 阶段，若按 BOOLEAN 过滤后无命中实体，工程侧应放宽过滤条件，拉取该空间下匹配关键字（如"空调"）的所有 CONTROL 角色能力。
语义描述引导 (MCP Description)：
- 利用 Standard Semantic Hub 中 hvac_mode 或 hvac_target_temp 的 llm_desc 进行逻辑埋点。
- 注入信息示例："该设备通过运行模式控制启停。当需执行关闭意图且无独立开关时，请将本属性设为 0。"
LLM 逻辑推理代偿：
- Agent (Stage 3) 在感知到产品级全量 Capabilities（非逐设备注入）后，通过 LLM 逻辑推演寻找替代路径：
  - 路径 A (Mode 代偿)：Intent: Off -> Search: No Power -> Reason: Mode(0=Off) -> Action: hvac_mode=0。
  - 路径 B (Temp 代偿)：Intent: Off -> Search: No Power -> Reason: Temp(0=Off) -> Action: hvac_target_temp=0。

4.6.3 交互渲染一致性

即便物理层由 mode 承载开关功能，后端在 Stage 4 组装 renderSAControl JSON 时，应根据 Mapping 关系，虚拟出一个 power 状态字段 给 UI 组件。确保用户在前端看到的依然是标准的"开关拨码"或"电源按钮"，维持交互直觉。

4.7 环境感知的决策增强场景（规划中，当前未实现）

当前状态：L1 环境感知信息当前未注入，待自控平台空间逻辑信号就绪后接入。

以下为未来规划的场景列表：

场景类型	逻辑判断	Agent 反应 (示例)
联动辅助建议	[控 A 察 B] 用户控制投影仪，Agent 感知环境光强 (Lux)。	"已为您准备好投影仪，当前环境光线较强，建议为您关闭并拉帘以获得更佳观看效果？"
空间能效闭环	[控 A 察 B] 用户开启空调，Agent 感知窗户状态。	"空调已准备就绪，但 305 的窗户目前处于开启状态，建议先关闭窗户以提升制冷效率？"
动态步进感知	[综合判定] 用户要求"305空调再冷点"，Agent 结合 `室温-设定值` 差值计算步进。	[室温 28℃, 设定 26℃] "当前室温较高，已为您将温度下调至 23℃ 以快速降温。"
环境引导建议	基于室温播报，向用户推荐最合理的下一步操作。	[室温 28℃] "当前室内 28℃ 较热，建议开启制冷。已为您准备好开关卡片。"
操作矛盾预警	在渲染控制卡片前，先对物理矛盾进行口语化播报。	"当前室温已是 20℃，若执行制冷 26℃ 压缩机可能无法启动，建议改为自动？"
感官纠偏引导	针对体感与数据不一致，引导用户确认目标。	"传感器显示当前已是 16℃ 极低温度，您确定还要继续调低温度吗？"
无人节能	[未来规划] 需接入占用传感器	(待硬件就位后开发)
自动逻辑	[未来规划] 需多传感器联动	(待硬件就位后开发)

5. 第四阶段：前端组件渲染 (Stage 4: Rendering)

Agent 决策完成后，不直接执行物理指令，而是输出渲染协议至前端。

5.1 渲染协议

场景	协议	前端表现
CONTROL	`renderSAControl`（含语义目标值 + product_id + 共享量程）	HITL 控制卡片（滑块/开关/确认按钮）

均通过 Engine 组装后下发前端，不直接由 LLM 输出。

交互原型 (UI Reference): device-control.html
交互规范 (PRD): 微信小程序_SA_设备控制_交互设计PRD.md

6. 异常场景处理 (Exception Path)

TIP

检索沙箱化策略：由于 Stage 2 已过滤无权资产，Agent 层仅需处理位置/实体客观缺位的场景。

6.1 异常处理时序图

6.2 状态冗余与逻辑背离 (Status Awareness & Logical Conflicts)

当 Agent 收到 Stage 2 注入的深度状态或 Stage 4 物理层的语义状态回传时，执行以下反馈：

冲突分类	物理/语义特征	Agent 反馈策略	话术示例
状态冗余 (开关)	物理层返回 `ALREADY_ON` / `ALREADY_OFF`	直接告知现状: 不执行物理动作，仅同步状态。	“空调已经是开启状态了，无需重复执行。”
状态冗余 (数值)	物理层返回 `ALREADY_AT_VAL`	拒绝并引导: 告知已在目标值。	“当前已处于 [26℃]，无需重复设置。”

7. 语义状态消费协议 (Feedback Protocol)

Agent 不处理原始物理错误码，仅消费工程侧在《物理执行逻辑》中映射出的 语义状态：

语义状态	Agent 预期话术响应
SUCCESS	"好的，已经帮您处理好了。"
ALREADY_ON	"空调（设备名）已经是开启状态了哦。"
ALREADY_AT_VAL	"当前环境已经是设定目标，无需调整。"
BOUNDARY_HIT	"已经为您调到允许的极限值（[边界值]）了哦。"
OFFLINE	"设备目前处于离线状态，建议检查网关。"
PERMISSION_DENIED	"抱歉，由于策略限制，该操作目前无法完成。"

8. TODO 列表

[ ] 多模态异常反馈：针对离线设备在 UI 上的置灰渲染逻辑。

9. 相关设计参考

管理后台: 标准语义管理 PRD
产品语义管理: 产品语义管理 PRD
设备语义管理: 设备语义管理 PRD
原型对齐: 标准语义管理 UI
底层底座: 空间语义管理
执行协议: SA_设备控制_物理执行逻辑

SA 设备控制：Agent 设计方案 (Semantic/AI Layer) ​

术语澄清：Stage 流程阶段 vs L 信息深度 ​

1. 核心业务流程 (Happy Path Sequence) ​

2. 第一阶段：槽位提取 (Stage 1: Slot Filling) ​

2.1 槽位定义 ​

2.2 澄清追问与拦截策略 ​

2.3 当前 Dify 实现（MVP 阶段） ​

3. 第二阶段：工程化分层检索 (Stage 2: Composite 3x3 Search) ​

3.1 检索逻辑 ​

3.2 缺设备时的隐式嗅探 ​

4. Stage 3 — CONTROL 推理 (CONTROL Reasoning) ​

4.1 渐进式信息注入协议 (L1-L3) ​

4.2 LLM 输出示例与推理逻辑 ​

4.2.1 场景 A：制热模式（跨产品兼容） ​

4.2.2 场景 B：除湿模式（仅部分产品兼容） ​

4.2.3 场景 C：温度调低（标准语义输出绝对值） ​

4.2.4 边界场景示例：越界处理 ​

4.3 前端渲染与共享量程 ​

4.4 跨产品控制推理策略 (Cross-Product Reasoning) ​

4.4.1 枚举值推理逻辑 ​

4.4.2 前端渲染影响 ​

4.5 语义对齐与筛选逻辑 (Reasoning Task) ​

4.6 异构设备逻辑代偿 (CONTROL 专有) ​

4.6.1 设计背景 ​

4.6.2 核心实现路径 ​

4.6.3 交互渲染一致性 ​

4.7 环境感知的决策增强场景（规划中，当前未实现） ​

5. 第四阶段：前端组件渲染 (Stage 4: Rendering) ​

5.1 渲染协议 ​

6. 异常场景处理 (Exception Path) ​

6.1 异常处理时序图 ​

6.2 状态冗余与逻辑背离 (Status Awareness & Logical Conflicts) ​

7. 语义状态消费协议 (Feedback Protocol) ​

8. TODO 列表 ​

9. 相关设计参考 ​

SA 设备控制：Agent 设计方案 (Semantic/AI Layer)

术语澄清：Stage 流程阶段 vs L 信息深度

1. 核心业务流程 (Happy Path Sequence)

2. 第一阶段：槽位提取 (Stage 1: Slot Filling)

2.1 槽位定义

2.2 澄清追问与拦截策略

2.3 当前 Dify 实现（MVP 阶段）

3. 第二阶段：工程化分层检索 (Stage 2: Composite 3x3 Search)

3.1 检索逻辑

3.2 缺设备时的隐式嗅探

4. Stage 3 — CONTROL 推理 (CONTROL Reasoning)

4.1 渐进式信息注入协议 (L1-L3)

4.2 LLM 输出示例与推理逻辑

4.2.1 场景 A：制热模式（跨产品兼容）

4.2.2 场景 B：除湿模式（仅部分产品兼容）

4.2.3 场景 C：温度调低（标准语义输出绝对值）

4.2.4 边界场景示例：越界处理

4.3 前端渲染与共享量程

4.4 跨产品控制推理策略 (Cross-Product Reasoning)

4.4.1 枚举值推理逻辑

4.4.2 前端渲染影响

4.5 语义对齐与筛选逻辑 (Reasoning Task)

4.6 异构设备逻辑代偿 (CONTROL 专有)

4.6.1 设计背景

4.6.2 核心实现路径

4.6.3 交互渲染一致性

4.7 环境感知的决策增强场景（规划中，当前未实现）

5. 第四阶段：前端组件渲染 (Stage 4: Rendering)

5.1 渲染协议

6. 异常场景处理 (Exception Path)

6.1 异常处理时序图

6.2 状态冗余与逻辑背离 (Status Awareness & Logical Conflicts)

7. 语义状态消费协议 (Feedback Protocol)

8. TODO 列表

9. 相关设计参考