基于JSON的LLM代理设备框架

通过智能手机逐一控制家用设备的时代即将结束。

Matter 已降低墙高，为控制开辟了一条标准化的路径。如今，制造商正面临一个时代：他们再也无法知道是谁向其设备发送了控制请求。不仅谷歌、亚马逊或苹果，就连 Claude、Grok、ChatGPT，甚至某人今晚自己创建的个人助手，都可以通过 Matter 控制器向你的设备发送指令。

在这个时代，制造商为了保护自身和用户，首先必须做出一份“声明”。

直到现在，标签一直被视为用户体验(UX)的一个领域——旨在让应用程序中的用户看到的内容看起来美观且直观。但在一个由人工智能控制物理世界的时代，标签已不再仅仅是姓名标签，而是一种技术声明，是制造商对外界留下的信息。

制造商必须在设备内部提前明确声明以下内容：

•这个端点是什么?

•这个动作在现实世界中意味着什么?

•哪些安全界限绝不可跨越?

•该设备的使用责任范围是什么?

这不仅仅是元数据。它是一份技术性文件，是制造商公开声明：“本设备应如此理解，也应如此使用。”

一旦发生事故，制造商明确声明的内容可能成为讨论责任的关键依据。人工智能代理是否能够读取该声明，以及是否遵守了这些界限，将成为物理控制时代的核心问题。

该平台为制造商提供技术保障，同时通过人工智能提供精确的映射，帮助其理解物理世界。

该设备不适用于单个智能家居应用。任何通过Matter连接的AI代理均可向此设备发送控制请求，但此类控制仅限于制造商声明的标签所授权的范围内进行。

标签并非礼节，而是声明。

首个AI真正能理解的设备

迄今为止制造的每台设备都是为人类操作而设计的。

接下来是专为人工智能设计的设备，用于理解。问题是：哪一种设备能率先实现?

我们如今制造设备的方式存在的问题

设备类型源于人类对设备的理解方式——由人阅读、由人安装、由人操作。对于那个时代而言，这是正确的结构。

人工智能并不理解设备，它只理解行为及其边界。二十年前的架构并非错误，只是时代已经改变。

传统的物联网开发从模板开始。从平台列表中选择设备类型，将您的硬件适配到其中，映射集群，复制参考固件并进行修改。

这对人类有效，但对人工智能来说却是一条死胡同。

AI读取设备类型和集群结构，然后推测该设备的实际功能。它以相同的方式控制厨房灯和电热毯。安全边界已硬编码在固件中，对外不可见。当AI发出指令时，它并不知道哪些操作是被允许的，而是通过推理来判断。

推理成本高昂，且充满不确定性。当推理控制着物理设备时，这种不确定性就会演变为安全隐患。

一个不同的起点

与其问“我该选择哪种设备类型?”，不如先问一个问题：

这是什么操作?

它运行的硬件是什么，映射到哪个集群又是什么，并不重要。真正的问题是：它实际能做什么，以及它的局限性在哪里?

当你明确地回答这个问题——给出一个名称、一个边界和一个语境时，情况就会发生变化。这个行为有了所有者。制造商拥有设备的功能及其所承载的限制。而用户则拥有该行为在其生活中的意义。

将每个事实归还给其 rightful owner，AI 就不再需要猜测了。

Nemo & Anna 正是建立在这一点上的。

工作原理

回答9个关于单个动作的问题。答案将以JSON格式保存。

固件运行时读取JSON并自动生成有效的Matter设备——包括集群映射、调试配置、GPIO冲突保护和状态管理。无需编写任何C++代码。

此 JSON 将成为 Matter 的端点。

制造商定义的安全信息存储在固定标签(0x0040)中，并可传递给用户。

动作身份通过使用用户标签(0x0041)的结构化标记模式来表达。

这可以在现有 Matter 行为中正常工作，无需修改规格说明。

当操作定义发生变化时，更新 JSON。

无需重写固件，无需刷机。

ESP32-C6-DevKitC-1-N8 非常容易获取——Mouser、Digi-Key 以及全球各地的分销商均有销售。进入门槛在于理念，而非硬件。

这对人工智能意味着什么

这样构建的设备能向人工智能明确告知它需要了解的内容——无需推理。

这个动作是什么?名字就说明了。

有哪些限制?Fixed Label 会承载它们，只读。

何时有效?由用户的上下文决定。

AI不会猜测。AI会阅读、映射并执行——在已由其合法所有者划定的边界之内。

声明此结构的设备会立即进入AI生态系统。而未声明的设备则需要等待平台追上进度，或模型变得更智能，或有人编写出合适的提示语。

零配置AI上下文摄取(责任如何界定)

无需复杂的云API来实现安全边界。通过利用原生的Matter协议，制造商的声明会在任何物理操作发生之前自动注入AI的大脑中。

如果平台未能将此声明传递给AI，则责任应由平台承担，而非制造商。

为何现在这很重要

大多数开发人工智能控制物理设备的公司都陷入了困境。技术是可行的，但责任问题却无法解决。“当出现问题时，谁该负责?”这个问题没有明确的答案。

该结构在问题出现之前就已回答了这个问题。制造商明确了边界，用户认可了背景，AI 在既定范围内运行，记录得以保留。

这正是它能发货的原因。

遥控器并未消失，它只是不再处于中心位置。

下一个市场并不在于远程控制设备。

这是关于在规定范围内委派重复性的体力动作。

许多涉及热量、水、压力、锁具、刀片或电机的产品，在传统的遥控假设下难以释放。

但当制造商设定执行边界，用户确认上下文时，一种新型的AI辅助物理产品便得以实现。

一个家不需要一台人形机器人。

它已经拥有数百个按钮、开关、模式和执行器。

每一个都可以成为可被AI读取的操作单元。

该结构背后的设计原则：

→ 物理AI安全：所有权与执行边界

每件产品都配有供人类使用的说明书。

但对于人工智能，我们主要依赖概率性的猜测。

这个项目改变了这一点。

制造商必须制定可读取人工智能的说明书，以离散的操作单元形式进行结构化。

通过 Nemo 和 Anna 框架，每个设备功能都以 JSON 格式在内部声明，然后通过标准的 Matter 协议对外暴露。每项操作均可拥有独立的名称、用途和执行边界，使 AI 系统能够在实际控制开始前了解哪些操作是被允许的。

这消除了人工智能需要猜测的必要性，并为负责任的所有权提供了切实可行的途径。

Nemo & Anna 并非未来的提案。它目前基于现有的 Matter 基础架构，运行在 ESP32-C6 上，且无需任何规格变更。

硬件已经备好，框架今天就能运行。

本文编译自hackster.io