先区分三层：已观察事实、我的工程判断、对未来的推测

已观察事实：SMH-Bench 与 SimuHome 都把智能家居 Agent 的评价推进到环境状态、时间、行动和结果，而不只是静态 instruction → API 映射。
我的工程判断：因此 IoT Agent 必须把 Observation、Execution、Verification 放进同一个闭环。
对未来的推测：IoT 平台可能从“设备自动化平台”逐渐转向“面向 Agent 的 Physical Infrastructure”。

1. 已观察：Agent benchmark 正在进入环境闭环

SMH-Bench 将智能家居 Agent 放进可执行、可验证的环境中，覆盖 1,100 个任务、7 个大类和 22 个细分类别，并报告了自动化调度、歧义处理和个性化推理等方面的困难。citeturn0academia61

SimuHome 则提供时间加速的智能家居模拟环境，设备动作会影响环境变量，并要求 Agent 处理时间依赖、状态验证和调度。其论文报告，在统一 ReAct 框架下，Agent 在简单任务之外仍会遇到隐式意图、状态验证和时间调度困难。citeturn0academia62turn0search9

这些 benchmark 只能证明“评价问题正在向环境与结果扩展”，不能直接证明所有 IoT Agent 都已经具备可靠自主控制能力。

过去： 自然语言 → API 调用 更严格的评价： Goal ↓ Environment State ↓ Plan ↓ Action ↓ Observation ↓ Verification ↺

2. 我的工程判断：IoT Agent 的核心不是聊天入口，而是闭环

如果 Agent 的动作会改变现实环境，那么“API 调用成功”并不等于“任务成功”。Agent 需要知道执行前提、动作结果、环境变化以及目标是否达到。

Agent / Goal / Planning ↓ Capability / Tool / Policy ↓ Device Contract ↓ Gateway / Protocol / Edge ↓ Physical World ↓ Telemetry / Observation ↓ Verification ↺ Agent Loop

3. “不是 Layer 消失，而是 Packaging 被解包”

传统 IoT App 做了大量有价值的预包装：按钮、场景、规则、固定联动和导航入口。比如“回家模式”可以把开灯、空调、窗帘和安防预先组合成一个 Workflow。

Agent 可能让用户直接表达更开放的目标，再根据时间、环境、设备状态、偏好和当前可用能力动态组合行动。

  • 联动可能成为 Agent 可以调用的确定性执行器；
  • Workflow可能成为经过验证的高效执行路径；
  • App仍然承担授权、配置、监控、审计、异常处理和人工接管。

因此这里更准确的判断不是“App 会消失”，而是：固定入口在开放式意图中的比重可能下降，而执行、授权和治理界面仍然重要。

4. MQTT、Matter、MHS、MCP：不是一层东西

这里需要把几个概念严格分开。

技术更接近解决什么问题
MQTT轻量级 publish/subscribe 消息传输。OASIS 将其定义为 client/server publish/subscribe messaging transport protocol，并明确面向 IoT/M2M 等场景。citeturn0search2turn0search6
Matter智能家居设备互操作、设备类型、数据模型、交互和安全等更高层语义；它不是单纯的消息传输协议。
MHS目前是研究预览，面向科学研究和先进制造中的物理设备，让 Agent 更容易发现、理解和操作设备，并定义设备能力、状态和安全边界。citeturn0search0turn0search4
MCPAgent/AI 应用访问工具、资源和外部能力的协议层；它可以作为物理能力向 Agent 暴露的一种接入方式。

因此更准确的架构不是“MHS 在 MCP 上面”，而是：

Physical Device / Driver ↓ Device Capability / State / Safety Contract ↓ MHS-style physical capability layer ↓ MCP / CLI / API 等接入方式 ↓ Agent Runtime

MHS 官方目前仍将其定位为 research preview，而不是已经验证完成的通用 IoT 标准。citeturn0search0turn0search4

5. MHS：我的工程判断，而不是既成事实

我认为 MHS 很像“物理世界的 Capability Contract”。但这是我的架构类比，不应该写成“MHS 已经被证明就是通用 IoT 能力契约”。

目前公开资料支持的事实是：MHS 旨在让 AI agents 发现、理解和安全操作物理设备，研究预览覆盖科学研究和先进制造设备；其控制方式可以通过 MCP、CLI 或代码接口等路径实现。citeturn0search0turn0search4

我进一步的工程推导是：如果这种能力契约未来扩展到更多 IoT 场景，那么 Agent-facing Device Model 至少应该表达：

Identity Capability State Preconditions Constraints Permission Safety Boundary Command Semantics Observation Verification Compensation / Recovery

尤其是物理世界里不能只描述“能做什么”，还必须描述“什么时候能做、谁能做、做完怎么确认、失败怎么办”。

6. Capability Contract：从 Device 到可验证的物理能力

因此我更愿意把未来 IoT Agent 的关键抽象写成：

Capability Contract = Identity + Capability + State + Preconditions + Constraints + Permission + Safety Boundary + Command Semantics + Observation + Verification + Compensation

这比简单的 Capability + State + Constraint + Outcome 更完整，因为真实设备还涉及权限、安全联锁、幂等性、超时、中止和失败恢复。

7. 一个可能的 IoT Agent 技术栈

┌──────────────────────────────────────────┐ │ Agent / Intent / Goal / Planning │ ← 动态决策 ├──────────────────────────────────────────┤ │ Tool / Capability / Policy / Verification│ ← Agent-facing ├──────────────────────────────────────────┤ │ Device Contract / MHS-style Capability │ ← 物理能力契约 ├──────────────────────────────────────────┤ │ Matter / MQTT / Gateway / Edge │ ← 连接与运行基础设施 ├──────────────────────────────────────────┤ │ Sensor / Actuator / Device │ ← 物理世界 └──────────────────────────────────────────┘ ↑ Observation / Telemetry └──────────── Agent Loop

这里的分层是我的工程模型，不是某个现有标准已经规定好的统一架构。

8. Kubernetes 类比：有用，但不能过度延伸

Desired State → Actual State → Reconciliation 的类比很适合解释 Agent Loop：

Goal / Desired State ↓ Observe Actual State ↓ Calculate Gap ↓ Action ↓ Observe Again ↺

但物理世界和 Kubernetes 有一个重要区别：物理动作可能不可逆、延迟不稳定、状态观测不完整、设备可能损坏，设备之间还存在物理耦合。因此不能简单地把“失败”处理成软件世界里的无限重试。

我的工程判断是：Physical Agent Runtime 必须把 Retry 变成受约束的 Recovery / Compensation，而不是简单重新执行同一命令。

9. App 不会消失：它会更多承担治理和人工接管

“固定入口会被削弱”是趋势假设，不是必然结论。IoT App 仍然有明确价值：

  • 身份和授权；
  • 设备配网与配置；
  • 批量管理；
  • 状态总览和审计；
  • 故障排查；
  • 高风险操作确认；
  • 紧急停止；
  • 人工接管和多人协作。

因此更准确的未来形态可能是：

Agent：开放式意图与动态决策 App：授权、配置、观察、审批、接管 Workflow：确定性执行路径 Device Contract：能力与安全边界 Protocol / Edge：可靠连接与执行 Physical World：真实反馈

10. 最终推测：IoT 平台可能成为 Physical Infrastructure

对未来的推测：如果 Agent 能够稳定处理目标、状态、能力、执行和验证，IoT 平台的产品定位可能从“连接设备 + 管理设备 + 配置自动化”逐渐转向“让物理世界成为 Agent 可以发现、理解、调用、观察和持续控制的 Runtime”。

这并不意味着现有 IoT 基础设施会被推翻。更可能发生的是：

  • 连接层继续提供可靠的物理世界接入；
  • 设备模型逐渐增加 Agent-facing 的能力与约束描述；
  • Workflow 从唯一的业务编排方式变成 Agent 可以调用的确定性执行路径；
  • App 更多承担治理、授权和人工接管；
  • Agent Runtime 在上层承担开放式目标下的动态决策与验证。

11. 我的暂时结论

已观察事实：智能家居 Agent benchmark 已经开始评价环境状态、时间依赖、行动后的结果和状态验证；MHS 当前是面向物理设备的研究预览；MQTT 是成熟的 publish/subscribe 消息传输标准。citeturn0academia61turn0academia62turn0search0turn0search2

我的工程判断：IoT Agent 真正需要的不是替换底层连接协议，而是在其上增加可发现、可理解、可执行、可验证、可治理的 Capability Contract 和 Runtime Loop。

对未来的推测：如果这种闭环逐渐成熟，IoT 平台可能从面向人类的设备自动化平台，演化为面向 Agent 的 Physical Infrastructure。

契约留下，打包物解包；连接留下，决策上移；规则留下，但越来越像执行器和约束；App 留下，但越来越像授权、配置和人工接管。

参考资料

  • SMH-Bench — Benchmarking LLM Agents for Environment-Grounded Reasoning and Action in Smart Homes
  • SimuHome — A Temporal- and Environment-Aware Benchmark for Smart Home LLM Agents
  • Anthropic — Previewing the Model Hardware Standard
  • Model Hardware Standard — official research preview
  • OASIS — MQTT Version 5.0