从二维码到现实世界 API:AI Agent 如何接入线下世界
从二维码到现实世界 API:AI Agent 如何接入线下世界
移动互联网时代,二维码成为现实世界与网络世界之间最常见的桥梁。
一个商店、菜单、共享单车、支付账户或线下活动,只要贴上二维码,就能够被手机识别并映射到一个网页、App 页面或支付对象。它的成功并不在于技术有多复杂,而在于它提供了一个廉价、统一、低门槛的入口。
但 AI Agent 所需要的桥梁,与二维码并不完全相同。
二维码解决的是:
这个现实对象对应哪个数字地址?
而 AI Agent 真正需要解决的是:
这个现实实体是谁?它能提供什么服务?我能否信任它?我是否有权调用它?调用以后如何确认结果?
因此,AI 时代连接现实与数字世界的基础设施,可能不再只是一个“更先进的二维码”,而是一套完整的现实世界服务协议。
它需要把现实中的机场、酒店、医院、车辆、商店、设备,转化为可以被任意 Agent 发现、理解、验证和调用的能力。
一、二维码连接的是信息,Agent 接口连接的是能力
传统二维码通常只包含一个 URL:
https://example.com/check-in
扫码以后,用户仍然需要:
- 打开网页;
- 阅读说明;
- 登录账户;
- 输入订单;
- 点击按钮;
- 确认结果。
二维码只是把人送到了一个数字界面,实际流程仍由人完成。
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 收到广播后,需要通过可信目录、证书链或政府与行业机构签发的凭证验证:
- 该实体是否真实存在;
- 它是否有权提供这一服务;
- 当前密钥是否有效;
- 服务端点是否被篡改;
- 广播是否过期或被重放。
线下广播本身不是信任来源,它只是信任链的入口。
五、每个实体是否需要一个“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:
- 出示航班凭证;
- 出示有限授权;
- 调用航空公司值机接口;
- 获取可用座位;
- 选择免费过道座;
- 获取数字登机牌;
- 保存带签名的操作回执。
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。