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


从二维码到现实世界 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。