ARTICLE · 1325434
我让手机帮我订票,购票 App 能说“不”吗?
我让手机帮我订票,购票 App 能说“不”吗?“帮我订明早去上海的高铁，二等座。”假设只剩一等座，手机替你加钱买了票。你大概会问，我什么时候同意买一等座了？ 换个情形思考下～二等座有票，你也明确说了“就买这班”，购票 App 的开发者却没有声明同意智能体调用。你这句话，够不够让手机替你按下“提交订单”？ 自己买票时，我们很少把这两件事分开想。选好座席、看一眼票价、按下按钮，作决定和动手操作的是同一个人。手机智能体接手之后，选座的是乘客，操作的是智能体，购票应用是否接受调用，又取决于开发者。 
11月6日，工业和信息化部办公厅公布《关于加强智能体终端设备进网管理的通知》。这份文件从一台手机怎样获准进网，管到它怎样替人办事。 〔通知原文〕 通知把一项容易被忽略的工作交给了应用分发平台。平台要推动应用开发者用电子签名声明是否同意智能体调用。开发者没有声明同意，智能体就不得强制调用该应用。即使乘客把日期、车次、座席交代得再清楚，他也无法替开发者作出这份声明。反过来，即使开发者已经签名同意调用，这份签名也证明不了乘客愿意多花钱买一等座。 值得细读的是“强制”二字。假设应用开发者已拒绝调用，智能体转而模拟手指点击，照样把订单送进了购票系统。要评价这次操作，得查清它有没有绕过应用对自动操作设置的限制。通知没有逐项列举哪些技术方式构成强制调用。仅凭屏幕上的动作看起来像乘客亲手所为，还判断不了这一步是否越界。 乘客也有理由追问应用为什么拒绝。假如同一家购票服务允许自家助手查票，却拒绝另一款助手执行相同操作，两者在调用频率、接触的数据或账户安全上究竟有什么差别？这个问题需要服务商拿出事实来回答。电子签名可以证明开发者说过“不”，至于这个“不”有没有充分理由，还得另行判断。 打开智能体的设置页面，按通知要求，用户应当能查到它在哪些终端型号、哪些操作系统上完成了适配验证。分发平台也要公示适配列表，并拦住不兼容型号的下载安装。一款手机出现在列表上，说明它与智能体的组合经过验证。至于哪家购票 App 同意被调用，要看应用开发者的声明。通知针对的是预置智能体的手机、平板、可穿戴设备等电信终端及相关主体，仅凭一套企业软件也叫“智能体”，还不足以将它纳入这套进网要求。 设想一款手机在进网检测时只能查余票。后来厂商通过在线升级（OTA），让手机里的智能体也能提交订单。机身和型号都没变，点错一次的后果却变了。以前最多报错一个车次，现在可能真的给乘客订错一张票。原来针对查票做过的测试，凭什么足以说明下单也可靠？ 这正是通知把升级纳入管理的意义。预置智能体的终端须在进网检测中进行适配验证，生产企业要保证获证前后产品的一致性。终端发生重大变化，企业应向工信部报备并按要求开展进网检测。对通过 OTA 等方式开展的智能体现网升级，企业须提交升级方案，升级结束后提交报告，经工信部组织专家评估、征求意见后，方可正式向用户提供服务。至于增加下单功能是否构成“重大变化”，仍要结合产品的具体变化判断。 假设购票 App 的开发者签名时，智能体还只能查票。半年后，有乘客对一张订单提出异议。厂商拿出新版手机的适配列表，分发平台翻出半年前的同意声明，两份材料都是真的。可那份声明当时涵盖哪些操作？出单那天，手机上运行的又是哪一版智能体？如果连这两件事都对不上，双方各自出示一张截图，乘客还是不知道该找谁解释。 一种可行的产品设计，是让应用开发者和分发平台保留声明的内容、版本与变更时间。终端厂商和智能体开发者增加下单能力时，可以据此核对旧声明是否涵盖新操作，重新验证受影响的机型和系统。这样，出现争议时，可以先还原应用当时接受什么调用，再比对乘客选了什么座席、智能体实际提交了什么订单。通知尚未规定声明的保存期限，也没有细化哪些功能变化需要重新声明。这些细节值得在后续标准和产品实践中继续追踪。 对乘客来说，这些区别最后应该体现在手机怎么回答。二等座售罄时，它该问一句“只剩一等座，还买吗？”应用没有同意被调用时，它可以告诉你“这一步需要你自己打开购票 App”，并把入口留给你。前一次停下来，是因为只有你能决定要不要加钱。后一次停下来，是因为即使你已经选定了车票，手机也不能据此绕过应用对调用的限制。
