每件东西都应该有一个 URL：RFID 如何成为具身智能的物体词典

二十多年前，互联网完成了一次跃迁：每台电脑都有了 IP 地址，每个网页都有了 URL。这次跃迁催生了搜索引擎、社交媒体、云计算——所有我们称之为「互联网经济」的东西，都建立在「每台电脑可寻址」这个前提上。

物理世界还没有完成这次跃迁。

你家里的杯子、钥匙、遥控器，工厂里的零件、工具、半成品，仓库里的每一件商品——它们都没有 URL。它们是物理世界的「暗物质」：存在，但不可寻址、不可查询、不可被程序直接操作。

RFID 有机会改变这件事。但前提是，我们不再把它当成「自动条码」来用。

一、物品互联网的缺失层

互联网的基础设施是 TCP/IP + DNS + HTTP。TCP/IP 让每台电脑可寻址，DNS 让人类可读，HTTP 让每台电脑可交互。这三层加起来，才有所谓的「互联网」。

物理世界对应这三层是什么？

# 物品互联网的三层架构（类比互联网）
physical_internet:
  addressing_layer:
    internet_equivalent: "IP Address"
    physical_equivalent: "EPC (Electronic Product Code)"
    description: "每件物品的唯一身份标识"
    current_status: "已有标准（GS1 EPC），但覆盖率极低"
    gap: "绝大多数物品没有 EPC，即使有也不联网"

  naming_layer:
    internet_equivalent: "DNS / URL"
    physical_equivalent: "物品 URI（如 https://thing.example.com/epc:xxx）"
    description: "让人和程序都能查询物品状态的接口"
    current_status: "EPC/ONS 曾尝试，已废弃"
    gap: "没有统一的物品命名和解析体系"

  interaction_layer:
    internet_equivalent: "HTTP / REST API"
    physical_equivalent: "物品状态 API（GET /status, POST /action）"
    description: "程序可以直接调用物品状态，而不只是读原始数据"
    current_status: "不存在"
    gap: "RFID 读取流是原始数据，不是结构化 API"

二十年前，GS1 推过 EPC/ONS（Object Naming Service），试图建立物品互联网的基础。但那时候标签太贵、读写器太贵、网络太慢，全链路成本太高，这件事没跑通。

现在成本结构变了。UHF 标签几毛钱一个，读写器几百到几千块，网络无处不在。但「物品互联网」这件事还是没人做——因为大家都在用 RFID 做「自动条码」，没想过它能做更多。

二、机器人有视觉无身份

具身智能正在找「结构化 ground truth」。机器人能看见世界，但它看见的是像素，不是语义。

视觉能告诉机器人「这是一个杯子」，但分不清「这是张三的杯子还是李四的」。在家庭场景里，这意味着机器人不知道该把杯子放回谁的房间；在工厂场景里，这意味着机器人不知道该把零件装进哪个盒子。

视觉的盲区，恰好是 RFID 的长项。

# 视觉 vs RFID 的能力边界
comparison:
  vision:
    strengths:
      - "识别品类（杯子、瓶子、工具）"
      - "定位（物体在图像中的位置）"
      - "姿态估计（物体的朝向）"
      - "无需标签，通用性强"
    limitations:
      - "无法区分同类物品（两个一样的杯子）"
      - "无法读取被遮挡的标签"
      - "依赖光照条件"
      - "需要大量训练数据"

  rfid:
    strengths:
      - "唯一身份识别（每个杯子都有独立ID）"
      - "可穿透非金属材质读取"
      - "不依赖光照"
      - "可同时读取多个标签"
    limitations:
      - "无法识别品类（只能读ID）"
      - "无法定位精确位置"
      - "无法估计姿态"
      - "需要预先贴标签"

RFID 不告诉机器人「这是什么」，但告诉机器人「这是哪个」。这两个问题看起来相似，实际上完全不同。

「这是什么」是分类问题，视觉擅长。「这是哪个」是身份问题，只有 RFID 能回答。

三、从读号码到物体词典

传统 RFID 的用法：读到一个 EPC 号码，查数据库，返回商品信息。这是「自动条码」的用法——只是把条码换成了射频。

但如果我们换一个思路：每个 RFID 标签不只是一个号码，而是一个「物体 API」的入口呢？

# 物体词典服务：每个 EPC 都是一个可查询的状态
from dataclasses import dataclass
from typing import Optional, Dict, Any
from datetime import datetime

@dataclass
class ObjectState:
    epc: str                    # EPC 唯一标识
    category: str               # 品类（杯子、工具、零件）
    owner: Optional[str]        # 所有者
    location: Optional[str]     # 当前位置
    status: str                 # 状态（在库、使用中、移动中）
    last_seen: datetime         # 最后读取时间
    metadata: Dict[str, Any]    # 扩展属性

class ObjectDictionary:
    """物体词典：把 RFID 读取流转化为结构化状态 API"""
    
    def __init__(self):
        self.objects: Dict[str, ObjectState] = {}
    
    def on_tag_read(self, epc: str, antenna: int, rssi: int):
        """RFID 读取回调：更新物体状态"""
        if epc not in self.objects:
            # 新物体：从主数据加载
            self.objects[epc] = self._load_from_master(epc)
        
        obj = self.objects[epc]
        obj.last_seen = datetime.now()
        obj.location = self._antenna_to_location(antenna)
        obj.status = self._infer_status(rssi)
    
    def get_status(self, epc: str) -> Optional[ObjectState]:
        """GET /objects/{epc}/status"""
        return self.objects.get(epc)
    
    def query_by_owner(self, owner: str) -> list:
        """GET /objects?owner=xxx"""
        return [o for o in self.objects.values() if o.owner == owner]
    
    def query_by_location(self, location: str) -> list:
        """GET /objects?location=xxx"""
        return [o for o in self.objects.values() if o.location == location]

这个服务的核心变化：RFID 不再只是「读号码」，而是「查询物体状态」。每个 EPC 都变成了一个可寻址的资源，有 REST API，有结构化数据，有业务语义。

这就是物体词典：把物理世界的物品，变成程序可以直接查询和操作的结构化数据。

四、具身智能的物体接入层

回到具身智能的场景。机器人在房间里，看见桌上有三个杯子。视觉告诉它：「三个圆柱形容器，高度约10cm，颜色分别是白色、蓝色、白色。」

但机器人需要知道：白色杯子是张三的，蓝色杯子是李四的。现在它不知道该把杯子放回哪个房间。

如果每个杯子底部都有 RFID 标签，机器人只需要： 1. 读取三个 EPC 2. 调用物体词典 API：GET /objects/{epc1}/status, GET /objects/{epc2}/status, GET /objects/{epc3}/status 3. 返回：epc1 → 张三房间，epc2 → 李四房间，epc3 → 张三房间 4. 机器人知道该把每个杯子放回哪里

视觉提供「是什么」，RFID 提供「是哪个」。两者结合，机器人才真正理解物理世界。

这就是物体词典对具身智能的价值：它填补了视觉的盲区，让机器人从「看见世界」升级到「理解世界」。

五、从数据采集到状态服务

传统 RFID 系统的架构： 读写器 → 中间件 → 数据库 → 业务系统 数据流是单向的：从物理世界到数字世界。业务系统只能查询历史数据，不能实时感知物理世界。

物体词典的架构： 读写器 → 物体词典服务 ← REST API ← 业务系统/机器人 数据流是双向的：业务系统可以实时查询物体状态，也可以下发指令（比如「监控这个物品，当它移动时通知我」）。

这个变化的意义：RFID 不再只是「数据采集工具」，而是「物体状态服务」。它从后台走到前台，从被动记录变成主动服务。

对具身智能来说，这意味着机器人有了一个标准化的接口来查询物理世界。不需要自己处理 RFID 原始数据，不需要自己建数据库，只需要调用 API。

六、技术栈参考

搭建一个最小的物体词典服务，需要这些组件：

# 物体词典技术栈
stack:
  rfid_hardware:
    reader: "KLMB100/200 或任何支持 TCP 协议的 UHF 读写器"
    tags: "UHF EPC Gen2 标签（Inlay: Impinj Monza 或 NXP UCODE）"
    protocol: "TCP/IP，端口 60000（默认）"
  
  backend:
    language: "Python 3.10+"
    framework: "FastAPI（轻量、异步、自动文档）"
    database: "PostgreSQL（主数据）+ Redis（实时状态缓存）"
    orm: "SQLAlchemy"
  
  api_design:
    rest_endpoints:
      - "GET /objects/{epc}/status - 查询单个物体状态"
      - "GET /objects?owner=xxx - 按所有者查询"
      - "GET /objects?location=xxx - 按位置查询"
      - "POST /objects - 注册新物体"
      - "PATCH /objects/{epc} - 更新物体属性"
    websocket:
      - "WS /objects/subscribe - 订阅物体状态变化"
  
  integration:
    robot_interface: "ROS 2 / Python SDK"
    wms_interface: "REST API 或 MQTT"
    monitoring: "Prometheus + Grafana"

这个技术栈的核心：FastAPI 提供 REST API，PostgreSQL 存储主数据，Redis 缓存实时状态。读写器通过 TCP 连接，读取的数据实时更新到 Redis，同时持久化到 PostgreSQL。

七、下一步

物品互联网不是新概念，但现在是第一次有可能真正实现它。标签便宜了，网络无处不在，具身智能需要结构化的物理世界数据。

RFID 有机会成为这个基础设施——但前提是，我们不再把它当成「自动条码」来用，而是把它升级成「物体词典」。

也许下一篇，我们写写怎么用 Python 搭一个最小的物体词典服务。