Agent 的设备发现与配对：Agent 自动识别和连接周围的智能设备

我刚搬进新住处时，把智能插座插到客厅的墙脚。手机 App 打开的一瞬间，那个插座已经在列表里了——没有扫码，没有输 IP，甚至没等搜索转圈。那一刻我有点发怵：它是怎么认出我这里的？

后来做物联网相关的开发，被设备发现和配对折腾了几个星期，才把这件事弄清楚。这里的 Agent 不单指手机上的语音助手，也包括那些能替你管理设备的程序。它要完成两件事：发现设备，和安全地配对设备。前者是“你在这”，后者是“我信你”。

发现：设备是喊一嗓子，还是等指认？

我最早以为所有设备都在不停广播：“我在这！快来连我！”就像商场里发传单的玩偶。后来翻了协议才知道，智能设备大多数时候很安静，真正的广播只发生在少数场景。

设备发现大体分成三条路：

1. 主动广播。典型是蓝牙低功耗（BLE）。设备每隔几十或几百毫秒向外发一个数据包，里面装着设备地址、名称和服务 UUID。你打开手机蓝牙，Agent 扫描这些广播包，就知道周围有设备。这是最接近“喊话”的一种。
2. 组播查询与应答。典型是 mDNS/DNS-SD。设备接入局域网后，不主动打扰别人，而是在别人问“谁提供空调服务”时，用组播消息回答“我是客厅空调，我叫 ac-livingroom”。这套机制记录在 RFC 6762 里，没有中心服务器，靠组播地址 224.0.0.251 把消息送到同一个子网里的所有设备。
3. 中心节点汇报。典型是 Zigbee 和 Matter-over-Thread。设备先通过网关加入网络，Agent 问网关“挂了哪些子设备”，网关把列表交出来。这里的设备不会自己跟 Agent 吱声。

三条路的工程权衡很不一样。BLE 广播的周期决定了两件事：周期越长，设备越省电，但 Agent 要等更久才能发现它；周期太短，电能和无线电频谱就浪费了。mDNS 则反过来，设备平时不耗电，只有查询时才有人应答，所以很多 Wi-Fi 设备喜欢它。

你可能注意到，mDNS 的工作方式更像“被点名”：设备加入网络后并不会满世界喊“我是灯”，而是等有人查询“有灯吗？”时才通过组播应答。这样既省带宽，又不会吵到别人。这里藏着第一个反直觉事实：很多设备发现的本质是你先发问，它再回答。

配对：把“认识你”变成“信得过你”

发现了设备，不等于能控制它。你家里的音箱扫描到一个未知的“智能门锁”，它绝不能直接说“开门请进”。配对是设备发现之后的信任建立环节，核心是回答一个问题：你真的是你吗？

我最早以为配对就是把设备连到 WiFi，顺手输入密码。后来读 Matter 规范，发现自己错得离谱。Matter（由 CSA 推出的智能家居互操作标准，官网）的配对流程是这样的：

1. 设备上印着一个二维码，扫描后得到两个数字：discriminator（区分标识）和 passcode（配对码）。
2. Agent 用这两个数字向设备发起配对，但不直接发送 passcode。
3. 双方执行一种叫 SPAKE2+ 的 PAKE（Password Authenticated Key Exchange）协议。设备端不传输 passcode 本身，而是向 Agent 证明“我知道这个码”。即使中间有人窃听，也拿不到码。
4. 验证通过后，Agent 验证设备搭载的证书（DAC），确保它真的是认证过的设备，而不是假冒硬件。
5. 双方建立加密会话，之后才能控制。

这套设计最让我意外的点在于：密码本身在线上从来没有出现过，但双方都证明了自己知道它。对比之下，经典蓝牙的“Just Works”配对模式几乎是裸奔——它假设配对那一刻周围没有中间人，于是直接交换密钥，代价是如果有人坐在你旁边做中间人攻击，他就能截获全部通信。

用一句话概括配对：把一条可能被监听的信道，升级为双方互相认证的保密信道。

Agent 多出来的那一层：把设备翻译成工具

对传统 App 来说，发现并配对一台灯泡，屏幕上多了一个开关项。对 Agent 来说，设备是一个可以被调用的大脑接口。

Matter 把设备抽象成端点（Endpoint）和 cluster（集群）。比如一个智能灯有“开关”cluster 和“亮度”cluster。Agent 拿到这些信息后，会格式化为工具描述：一个叫 turn_on(light_id)，另一个叫 set_brightness(light_id, percent)。就这么两个函数，背后映射到 Matter 的属性。

# 这是我在 Home Assistant 里给 Agent 定义的“开灯”工具
def turn_on(light_id: str):
    # 通过 Matter 协议设置 OnOff cluster 的 OnOff 属性为 true
    return device_clients[light_id].send_command("OnOff", "On")

这时候 Agent 的自然语言能力才派上用场。你说“把客厅灯调暗”，它先通过语音识别和意图理解，把“客厅灯”映射到之前发现的设备 ID——这个过程叫语义定位；然后把“调暗”映射到 cluster 里的 brightness 属性。整个链路和 MCP 想要统一的事情是同一类：给 AI 一个标准化的“外部世界接口”。

MCP 的本质是让 Agent 不用为每一家智能设备单独写适配器。就像 USB-C 统一了充电接口，Matter 和 MCP 试图在各自领域统一“设备的操作语言”。这点很重要，因为如果每个品牌都发明一套专有协议，Agent 永远只能处理它见过的设备。

边界：它不是什么魔法雷达

如果只看上面那些，你可能会以为 Agent 有超能力。但你真去写一个发现的 Agent 就会碰壁。我踩过最大的坑是：在公司办公室写 mDNS 扫描，同一个局域网，怎么都扫不到树莓派。后来网络管理员告诉我：开了 AP 隔离（AP Isolation），每个设备只能跟网关通信，设备间广播被直接丢弃。

这不是代码问题，是网络策略问题。mDNS 依赖组播，组播能到达的范围受物理和逻辑网络边界限制。Wi-Fi 客户端的隔离、多 VLAN、路由器防火墙都会把“周围的设备”拦在外面。

再看范围限制：BLE 广播只能覆盖十米左右；mDNS 只能覆盖同一个二层网络；Zigbee/Thread 只能覆盖本地 mesh。Agent 如果跑在云端，压根无法直接看到家里的设备，必须靠本地网关中转。这也是为什么很多智能音箱的 Agent 其实是在云端运行，却委派家庭网关做“眼睛”。

安全上同样有边界。发现协议本身通常不加密，广播是公开的：任何在附近的攻击者都能扫到“客厅有智能门锁”这类信息。应对手段是依赖配对层的加密和认证，但这也意味着如果攻击者拿到了你的扫码画面（比如你拍的照片已经泄露），PAKE 也保护不了你。证书体系又依赖复杂的 PKI 运维，对小厂并不友好。

FAQ：你可能想问的三件事

为什么我在公司发现不了家里的设备？

因为 mDNS/BLE 都有物理范围限制。设备发现依赖你当前位置所在的网络和无线电范围，互联网上没有统一的全局设备目录。跨地域的智能家居控制，靠的是每个设备的云账号，而不是 Agent 自身。

Agent 发现设备会不会泄露隐私？

会。BLE 广播包里的设备名和服务 UUID 在物理范围内可被任何人监听。许多设备厂商会把产品型号、甚至用户设定名称放在广播里，最好用非标识性名字，并优先支持带认证的配对。

Matter 能做到“扫码即用”是因为所有设备都预置了证书吗？

是的。设备出厂时会被签发设备认证证书（DAC），根 CA 由 CSA 管理。验证证书链的成本很高，但保证设备不是伪造硬件。不过这要求你把根源 CA 的根证书装入你的信任库，这也成了生态系统的权力中心。

现在回头看开头的问题：为什么那个智能插座能自动出现在列表里？答案并不玄幻——它通过 BLE 广播启动，或者通过 mDNS 应答了网络中的查询。而 Agent 之所以敢控制它，是因为它们之间完成了一次严谨的密码学握手。

我的判断是：设备发现与配对的技术早已成熟，但它在 AI 时代被赋予了新的意义——给了 Agent 一条连接物理世界的通道。当下最要紧的短板不在“识别”，而在统一标准这件事上。Matter 把家居设备拉到了同一条起跑线，MCP 则把交互方式归一。但生态碎片化仍然是现实：你周围可能还混着 Zigbee、蓝牙 Mesh、红外、甚至老旧的 UPnP。未来的 Agent 不会只靠一种发现协议，它会像多语言者一样，先探测网络支持哪些“方言”，再决定用哪一种。真正的进步，是让发现与配对的信任模型变得更简单——最好简单到用户无感，而密码学又足够可靠。到那时，Agent 才真正配得上“你的智能管家”这个称呼。