美联航禁止 AI 代理代订机票：自动化的责任边界浮出水面

发生了什么

美联航确认了一项政策：旅客不能用 AI 代理替自己订票、改签或管理订单。给出的理由是网络安全风险，但没有展开说明风险具体指什么，也没有公布如何识别代理访问、违规会怎样处理。

这不是一家小公司的表态。航空公司是典型的高价值交易场景：账号里有身份信息、里程、支付方式，一次错误操作可能牵动退款、改签和客服工单。代理一旦介入，出问题的环节从「用户点错」变成「不知道该找谁」。

为什么航司会紧张

把代理代订拆开看，至少有四层风险：

• 身份层：代理用的是用户的账号和会话，网站无法区分「本人在操作」和「本人授权的程序在操作」。
• 交易层：自动比价、自动锁座、自动支付，任何一步判断错，都会产生真实扣款。
• 数据层：代理要读订单、证件、联系方式，这些数据的存储与传输是否合规，用户并不清楚。
• 滥用层：同一套代理可以批量刷票、占座、爬价格，航司的库存和风控系统会先承压。

对航司来说，最省事的做法就是「一律不许」，把不确定性挡在门外。这不一定是最优解，但很容易理解。

代理自动化的真问题：授权与责任

这次事件把一个技术圈讨论很久的问题推给了普通用户：当你让代理替你完成一笔交易，授权范围到哪里为止？

现实里，用户给代理的往往是一句模糊的指令——「帮我订下周三去上海的 cheapest 直飞」。代理据此选航班、填信息、付款。如果它选错了时间、买错了舱位、用了不该用的支付方式，责任在用户、在代理开发者、还是在平台？

目前没有共识。平台的做法是禁止，代理开发者的做法是加确认步骤，用户的做法是事后投诉。三方各说各话，中间缺的是一套可验证的授权记录：谁授权的、授权了什么范围、执行时做了什么、结果如何。

网站是怎么识别代理的

报道没有给出美联航的技术细节，但行业里常见的识别手段就那么几类：检查 User-Agent、分析访问节奏与鼠标轨迹、验证浏览器指纹、要求登录态二次验证、以及对高频请求做限流。

这些手段没有一个是可靠的。User-Agent 可以伪造，节奏可以模拟，指纹可以伪装。真正有效的往往是组合判断：一个新账号、异常快的填表速度、大量比价请求、支付信息与账号归属不一致，几个信号叠在一起才触发风控。

这也解释了为什么航司选择「一律禁止」而不是「精准识别」：识别成本高、误伤率高，而规则写清楚以后，至少责任边界是明确的。

对做 Agent 产品的启示

如果你在做能替用户操作网页或调用交易接口的代理，这次事件可以直接转成四条设计要求：

1. 支付与不可逆操作必须人工确认，而且要展示关键字段（时间、金额、退改规则），不能只显示「确认支付」。
2. 授权范围写进日志，包括用户原始指令、代理的解析结果、实际执行的每一步。
3. 给用户一个撤回入口，在交易完成前都能中止。
4. 别把「能绕过网站限制」当成卖点。短期好用，长期会把整个品类推到被集体封禁的位置。

工具调用的边界，最终不是技术问题，而是信任问题。信任建立得很慢，毁掉只需要一次扣错款。