从二维码到现实世界 API:AI Agent 如何接入线下世界

移动互联网时代,二维码成为现实世界与网络世界之间最常见的桥梁。

一个商店、菜单、共享单车、支付账户或线下活动,只要贴上二维码,就能够被手机识别并映射到一个网页、App 页面或支付对象。它的成功并不在于技术有多复杂,而在于它提供了一个廉价、统一、低门槛的入口。

但 AI Agent 所需要的桥梁,与二维码并不完全相同。

二维码解决的是:

这个现实对象对应哪个数字地址?

而 AI Agent 真正需要解决的是:

这个现实实体是谁?它能提供什么服务?我能否信任它?我是否有权调用它?调用以后如何确认结果?

因此,AI 时代连接现实与数字世界的基础设施,可能不再只是一个“更先进的二维码”,而是一套完整的现实世界服务协议。

它需要把现实中的机场、酒店、医院、车辆、商店、设备,转化为可以被任意 Agent 发现、理解、验证和调用的能力。


一、二维码连接的是信息,Agent 接口连接的是能力

传统二维码通常只包含一个 URL:

https://example.com/check-in

扫码以后,用户仍然需要:

  1. 打开网页;
  2. 阅读说明;
  3. 登录账户;
  4. 输入订单;
  5. 点击按钮;
  6. 确认结果。

二维码只是把人送到了一个数字界面,实际流程仍由人完成。

AI Agent 需要的则更接近下面这种结构:

entity: airport-terminal-3
service: airline-check-in
capabilities:
  - check_in
  - select_seat
  - issue_boarding_pass
authentication:
  - passenger_identity
  - valid_booking
authorization:
  - user_confirmation
endpoint:
  - https://airport.example/agent/check-in

这里暴露的不再是“网页在哪里”,而是:

  • 当前实体是谁;
  • 它能够执行哪些动作;
  • 调用这些动作需要什么凭证;
  • 哪些操作需要用户确认;
  • Agent 应该连接哪个正式接口。

二维码把现实对象变成一个地址。

Agent 接口则把现实对象变成一个可调用的能力集合。


二、为什么需要线下自动发现

AI 当然可以通过搜索引擎、官网或 App 获取机场信息。

但官网提供的通常是全局、长期、面向人的信息,例如:

  • 航站楼地图;
  • 值机规则;
  • 行李政策;
  • 商店目录;
  • 交通方式;
  • 开放时间。

这些信息可以帮助 Agent 规划,却难以准确表达用户此刻所在位置的实时状态。

例如官网可能写:

自助值机设备位于二层出发大厅。

但现场广播可以告诉 Agent:

当前位置:T3 二层东侧
附近自助值机设备:4 台
可用设备:3 台
预计等待:2 分钟
西侧设备:维护关闭

二者的区别并不只是信息更多,而是信息与现实中的具体时间、空间和设备绑定了起来。

官网回答的是

这个机场通常有什么?

线下广播回答的是

你现在在哪里,这里此刻有什么,哪项服务当前可用?

这就是线下服务发现的核心价值。


三、Wi-Fi、BLE、NFC 和 RFID 各自承担什么角色

未来的现实世界 Agent 接口,很可能不会依赖一种单独技术,而是由多种感知和通信方式组合完成。

1. Wi-Fi 或 BLE:发现环境

Wi-Fi、BLE Beacon 或 Wi-Fi Aware 更适合承担“附近有哪些服务”的发现任务。

机场可以在一定范围内广播:

entity: airport:HND:T3
zone: departure-east
services:
  - check-in
  - baggage-drop
  - navigation
  - accessibility-assistance
directory: https://airport.example/services/T3-east
signature: ...

Agent 进入范围后,不需要用户主动扫码,就能发现:

  • 这里是哪个航站楼;
  • 当前区域由谁运营;
  • 有哪些可用服务;
  • 应该从哪里获取完整服务描述。

这种广播不应携带大量业务数据,而更适合充当“现实世界 DNS”。

它告诉 Agent:

当前环境中有哪些可信服务,以及到哪里找到它们。

2. NFC:近距离确认

NFC 更适合需要用户主动靠近的高可信操作:

  • 确认当前柜台;
  • 打开门锁;
  • 读取设备身份;
  • 领取物品;
  • 确认支付终端;
  • 与自助托运设备建立短距离会话。

它的价值不是广播范围,而是空间接近性和主动性。

例如用户将手机靠近托运设备时,设备发出一次随机挑战,手机和机场后台共同完成身份验证,可以降低误连到远处或伪造设备的风险。

3. RFID:物品身份与物流状态

RFID 更适合给物品建立持续身份:

  • 行李;
  • 包裹;
  • 医疗器械;
  • 仓储资产;
  • 租赁设备;
  • 商品和零部件。

在机场场景中,行李可以拥有独立身份:

bag_id: bag:2026:8F31A
owner_reference: encrypted
flight: NH841
status: loaded
location: sorting-zone-B

Agent 不只是知道“行李已托运”,还能够订阅行李状态。

4. UWB 与视觉:精确位置和环境对齐

Wi-Fi 或 BLE 适合发现某一区域,但不一定能准确判断用户面前是哪台设备。

UWB、视觉识别和环境地图可以进一步完成:

  • 厘米级或米级定位;
  • 判断用户正在注视哪个设施;
  • 将数字服务叠加到现实空间;
  • 区分相邻设备;
  • 支持室内导航。

因此,完整系统可能是:

Wi-Fi / BLE:发现附近服务
NFC:近距离确认
RFID:标识物品
UWB:精确定位
视觉:理解环境
Agent 协议:调用服务
数字身份:完成授权与签名

四、为什么线下广播不能被天然信任

一个非常危险的误区是:

既然服务是在机场附近广播的,它就一定属于机场。

现实中,攻击者完全可以创建一个名为:

Airport_Free_Checkin

的 Wi-Fi 或 BLE 节点,诱导 Agent 提交:

  • 护照信息;
  • 航班订单;
  • 支付凭证;
  • 登录 Token;
  • 生物识别数据。

因此,现场发现只能证明:

附近存在一个声称自己是机场服务的节点。

它不能直接证明:

这个节点真的属于机场。

合理的原则应当是:

发现可以匿名,信任必须验证,执行必须授权。

广播信息至少应包含:

  • 实体标识符;
  • 服务类型;
  • 临时服务地址;
  • 有效时间;
  • 随机数;
  • 数字签名。

个人 Agent 收到广播后,需要通过可信目录、证书链或政府与行业机构签发的凭证验证:

  1. 该实体是否真实存在;
  2. 它是否有权提供这一服务;
  3. 当前密钥是否有效;
  4. 服务端点是否被篡改;
  5. 广播是否过期或被重放。

线下广播本身不是信任来源,它只是信任链的入口。


五、每个实体是否需要一个“AI 身份证号”

从工程上看,为机场、企业、设备、服务节点和 Agent 分配唯一数字标识符是可行的。

例如:

entity:airport:HND:T3
entity:airline:NH
device:baggage-terminal:BX-018
agent:personal:9c31...

但编号本身不能完成数字签名。

编号回答:

你声称自己是谁?

数字签名回答:

这条消息是否由持有相应私钥的主体签发?

可信凭证回答:

谁证明这个编号对应现实中的机场、企业或设备?

因此,一个可用的实体身份系统需要至少五层:

稳定实体编号
+ 可轮换公钥
+ 权威机构凭证
+ 代理授权关系
+ 可审计签名记录

为什么不能让编号直接等于公钥

密钥可能:

  • 泄露;
  • 过期;
  • 被替换;
  • 因算法升级而迁移;
  • 因设备报废而吊销。

实体身份需要长期稳定,密钥则必须能够轮换。

因此,合理设计是:

实体编号
  ↓
可信身份目录
  ↓
当前有效公钥和凭证
  ↓
验证签名

六、Agent 不应伪装成用户本人

当 AI Agent 代替用户办理值机时,实际上存在三个不同主体:

委托人:旅客
执行者:个人 AI Agent
设备:手机、眼镜或可信终端

系统不应该简单记录:

旅客本人执行了值机。

更准确的记录应是:

旅客 P 通过设备 D,授权 Agent A 在指定时间内,为航班 F 执行 check-in 和免费选座。

授权凭证可以写成:

{
  "principal": "traveler-pseudonymous-id",
  "actor": "personal-agent-id",
  "actions": ["check_in", "select_free_seat"],
  "resource": "flight:NH841:2026-08-04",
  "max_cost": 0,
  "expires": "2026-08-04T13:00:00+09:00"
}

Agent 的签名表达的不是:

我就是用户。

而是:

我是 Agent A,目前依据授权 C,代表用户 P 执行操作 X。

这对于审计、责任划分和争议处理非常重要。


七、未来的 AI 现实终端会是什么形态

未来的“AI 终端”很可能不是一台固定设备,而是一套围绕个人运行的分布式系统。

手机:可信核心

手机仍然可能长期存在,但角色会发生变化。

它不再主要是 App 启动器,而是:

  • 身份钱包;
  • 权限管理中心;
  • 支付与签名设备;
  • Agent 主机;
  • 操作日志存储;
  • 本地隐私控制中心。

眼镜:感知与现实叠加

眼镜负责:

  • 识别环境;
  • 展示导航;
  • 标注可用服务;
  • 翻译文字;
  • 呈现 Agent 即将执行的动作;
  • 将数字状态与现实物体对齐。

耳机:持续但低打扰的交流

耳机适合:

  • 实时语音交互;
  • 翻译;
  • 航班和排队提醒;
  • 风险提示;
  • 在用户不方便看屏幕时反馈信息。

手表或戒指:高风险确认

涉及支付、签约、开门、改签等动作时,可以通过:

  • 指纹;
  • 双击;
  • 特定手势;
  • 生物认证;
  • 触觉反馈;

完成明确确认。

最终形态更像:

手机保存权力,眼镜理解环境,耳机负责交流,手表负责确认,Agent 负责协调。


八、机场中的完整交互过程

假设游客进入机场。

1. 自动发现

机场 Wi-Fi 或 BLE 广播:

entity: airport:HND:T3
zone: international-departure
services:
  - check-in
  - baggage-drop
  - security-navigation
  - boarding-status
directory: https://airport.example/agent-directory
signature: ...

个人 Agent 验证机场身份后,结合用户行程得出:

你已到达羽田机场 T3,航班两小时后起飞,目前尚未值机。

2. 用户表达目标

用户说:

帮我办理值机,选过道,不要额外付费。

Agent 将自然语言转换成结构化约束:

action: check_in
seat_preference: aisle
max_extra_cost: 0
flight_scope: current

3. Agent 获取授权

如果用户已预先允许免费值机,Agent 可以直接执行。

如果没有,则在手表上弹出:

允许 Agent 为 NH841 办理值机并选择免费过道座?

用户轻触确认。

4. 调用航空公司服务

个人 Agent:

  1. 出示航班凭证;
  2. 出示有限授权;
  3. 调用航空公司值机接口;
  4. 获取可用座位;
  5. 选择免费过道座;
  6. 获取数字登机牌;
  7. 保存带签名的操作回执。

5. 现场导航

Agent 根据当前位置和机场实时状态提示:

东侧自助托运等待约 3 分钟,西侧等待约 14 分钟,已为你规划东侧路线。

6. 行李托运

用户靠近托运设备,通过 NFC 或 UWB 确认具体终端。

设备验证:

  • 旅客身份;
  • 航班状态;
  • 行李额度;
  • Agent 授权;
  • 当前终端合法性。

行李标签生成后,Agent 自动订阅后续状态。

整个过程中,用户可能没有打开任何航空公司 App,也没有手动填写表格。


九、官网和现场广播应如何分工

官网不会消失。

二者更可能形成明确分工。

维度 官网 现场广播
信息范围 全局 当前区域
时间尺度 长期、稳定 实时、短期
面向对象 人和通用搜索 Agent 和现场设备
主要用途 了解、规划、查询 发现、定位、执行
空间关联 弱 强
网络环境 公网 本地网络或近场
服务入口 页面或统一 API 当前区域正式端点
身份证明 域名和 HTTPS 数字签名、证书链、现场挑战

最合理的流程是:

现场广播发现服务
→ 验证实体身份
→ 从权威目录获取完整能力
→ 必要时读取官网解释
→ 调用正式业务接口
→ 返回带签名的执行结果

官网仍是知识和规则的公开表达。

现场广播则成为现实环境中的服务发现与执行入口。


十、这会不会破坏现有商业模式

会,而且影响可能非常深。

今天大量商业模式依赖:

搜索
→ 点击
→ 页面停留
→ 推荐
→ 广告
→ 转化

当 Agent 直接调用能力接口后,用户可能不再看到:

  • 首页;
  • 广告位;
  • 推荐列表;
  • 弹窗;
  • 交叉销售页面;
  • 复杂操作流程。

例如用户只说:

帮我订一间今晚东京附近、可免费取消的酒店。

Agent 直接比较正式接口并完成预订,OTA、酒店官网和广告页面的控制力都会下降。

但商业不会简单消失,价值会重新分配。

竞争重点可能从:

  • 页面设计;
  • SEO;
  • 用户停留时间;
  • 推荐曝光;

转向:

  • API 质量;
  • 服务可靠性;
  • 价格透明度;
  • 取消政策;
  • 身份可信度;
  • Agent 可访问性;
  • 执行成功率;
  • 售后能力。

这可以看成从“流量经济”向“能力经济”的迁移。

谁控制个人 Agent,谁可能成为新的超级入口。

因此,平台和服务商既有动力开放 Agent 接口,也有动力限制接口,以避免失去用户关系和推荐权。


十一、企业是否愿意为 AI 大规模更新设备

答案取决于 AI 是否能够产生可量化收益。

机场不会因为“AI 很先进”而更换设备。

它们愿意为以下结果付费:

  • 减少柜台人员;
  • 提高旅客吞吐量;
  • 降低误机率;
  • 缩短安检与托运排队;
  • 减少行李差错;
  • 延缓航站楼扩建;
  • 改善无障碍服务;
  • 提高商业转化;
  • 满足监管要求。

因此,最现实的升级路线不是一次性替换所有设备,而是分阶段进行。

第一阶段:软件化

利用现有:

  • 机场 Wi-Fi;
  • 手机;
  • 航空公司后台;
  • 电子登机牌;
  • 自助终端;
  • 闸机和摄像头。

增加:

  • Agent API;
  • 服务目录;
  • 数字签名;
  • 实时状态接口;
  • 权限和审计模块。

第二阶段:增加现场发现能力

在关键位置部署:

  • BLE Beacon;
  • NFC 安全标签;
  • UWB 节点;
  • 可签名的环境广播模块。

第三阶段:改造高价值物理设备

只有当收益明确时,才升级:

  • 生物识别闸机;
  • 自动行李托运;
  • 智能安检;
  • 机器人运输;
  • 无人服务节点。

由此看,AI 现实接口的落地成本主要不在无线模块,而在:

  • 后台系统集成;
  • 数据治理;
  • 身份与授权;
  • 责任划分;
  • 跨机构协作;
  • 长期运维。

十二、现有标准是否已经足够

目前还没有一个统一标准完整覆盖:

现场发现
→ 实体身份
→ Agent 授权
→ 服务调用
→ 支付签约
→ 回滚与申诉

但许多基础组件已经存在。

现实设备与服务描述

  • W3C Web of Things
  • OpenAPI
  • AsyncAPI
  • DNS-SD / mDNS
  • Wi-Fi Aware
  • BLE 服务发现

Agent 调用和协作

  • MCP:Agent 调用工具和数据
  • A2A:Agent 与 Agent 之间发现、委托和协作

身份与凭证

  • PKI 和数字证书
  • DID
  • Verifiable Credentials
  • OAuth 与委托授权
  • Passkey
  • 硬件安全模块

航空行业

  • IATA One ID
  • CUSS
  • CUPPS
  • 无接触旅行和数字旅行凭证体系

这些标准可以拼出一个原型系统,但仍然缺少统一的端到端规则,例如:

  • 机场应广播哪些字段;
  • 如何证明服务确实位于现场;
  • Agent 权限应如何表达;
  • 高风险动作如何分级;
  • 服务价格和条款如何机器化表达;
  • Agent 误操作由谁承担;
  • 失败后如何回滚;
  • 用户如何撤销和申诉。

因此,目前更像互联网早期:

网络、地址、页面、证书和协议分别存在,但还没有形成一个所有参与者默认遵守的完整生态。


十三、真正的瓶颈不是 AI 模型

从技术上看,让 Agent 识别机场广播、读取能力目录、调用 API,并不是最困难的问题。

真正困难的是:

1. 跨机构协作

机场、航空公司、边检、安检、地服、支付和设备厂商分别拥有不同系统。

2. 身份和隐私

旅客不能向所有环境广播永久身份,也不能让不同商业机构轻易拼接完整轨迹。

3. 授权边界

系统必须明确:

  • 哪些动作可以自动执行;
  • 哪些动作需要轻确认;
  • 哪些动作需要强认证;
  • 哪些动作 Agent 永远不得代替用户决定。

4. 责任制度

当 Agent:

  • 订错航班;
  • 误选付费座位;
  • 错误提交证件;
  • 未及时处理登机口变更;
  • 接入伪造节点;

责任应由用户、Agent 厂商、机场还是服务商承担?

如果这些问题没有解决,再聪明的模型也只能停留在“给建议”,难以真正进入签约、支付和现实执行。


十四、最可能的演进路线

第一阶段:AI 阅读现有网页

Agent 仍以官网、App 和搜索结果为主要信息来源,帮助用户理解流程。

第二阶段:网站提供机器接口

企业在网页之外提供:

  • OpenAPI;
  • MCP Server;
  • 结构化能力描述;
  • 正式实时数据接口。

第三阶段:建立可信服务目录

不同实体将自己的:

  • 身份;
  • 能力;
  • 接口;
  • 权限要求;
  • 当前状态;

登记到可信目录。

第四阶段:现实环境广播目录入口

机场、医院、酒店等场所通过 Wi-Fi、BLE 或 NFC 广播:

这里是谁
当前区域是什么
可信目录在哪里
广播是否有效

第五阶段:有限自动执行

Agent 能在明确边界内自动完成:

  • 免费值机;
  • 获取登机牌;
  • 订阅状态;
  • 导航;
  • 普通预约;
  • 低风险表格提交。

第六阶段:跨服务任务编排

用户只需要表达目标:

把我安全、准时地送到目的地酒店。

Agent 自动协调:

  • 机场;
  • 航空公司;
  • 铁路;
  • 出租车;
  • 酒店;
  • 支付和身份钱包。

这才是完整的现实世界 Agent 网络。


结语:AI 时代需要的不是新二维码,而是现实世界协议栈

二维码的成功,是因为它为现实对象提供了一个廉价、统一的数字入口。

AI Agent 时代需要进一步解决的是:

发现
→ 理解
→ 验证
→ 授权
→ 执行
→ 审计

它最终可能表现为:

无线广播负责发现
数字身份负责确认实体
能力描述负责告诉 Agent 能做什么
授权凭证负责限制 Agent 的权力
API 和 Agent 协议负责执行
签名回执负责审计和追责

机场是一个非常适合率先落地的场景,因为它拥有高人流、标准化流程、昂贵人工、严格身份要求和大量现有数字基础设施。

但真正推动这一变化的,不会是一台更聪明的机器人,也不会是某种新的无线标签。

它更可能是一套逐渐形成的现实世界协议栈。

当这套协议成熟以后,人不再需要寻找 App、学习界面和重复输入信息。个人 Agent 将在用户明确授权的边界内,发现附近的现实能力,并把多个服务组合成一个完整任务。

二维码让现实世界拥有了 URL。

而 AI Agent 可能让现实世界第一次拥有真正可调用的 API。