1. 从“卖座位”到“卖服务”民航零售的底层逻辑变了干了十几年航空IT和零售系统我越来越强烈地感觉到一件事民航业卖东西的方式正在经历一次根本性的翻转。过去几十年航司的核心商业模式极其简单——把飞机上的座位尽可能多地卖出去围绕这个目标构建了舱位管理、运价体系、常旅客计划这一整套庞大而僵化的系统。但今天这套逻辑正在被“AI Skill Agent”的组合拳一点点撬动一个“按需付费”的智慧零售时代正在到来。先把这个标题拆开说清楚。AI Skill你可以理解为一个一个独立的、可被调用的智能能力单元——比如“识别旅客偏好”“动态生成辅营产品组合”“实时计算升舱意愿价格”等等。Agent则是把这些Skill编排起来、自主决策、面向具体任务去执行的智能体。两者结合本质上是在民航零售场景里搭了一套“能自己思考、自己组合、自己成交”的智能销售网络。它解决的核心问题是航司有海量的旅客数据、有丰富的辅营产品但过去没有能力在正确的时间、用正确的价格、把正确的服务推给正确的人。传统辅营销售靠规则引擎和人工配置颗粒度粗、响应慢、转化低。而AI Skill Agent让“千人千面、按需定价、实时成交”第一次具备了工程上可落地的可能。这篇文章适合谁看如果你是航司电商、辅营、常旅客或收益管理方向的产品经理、研发工程师、数据科学家或者你正在做旅游零售、动态定价、智能推荐相关的系统那这篇内容基本就是给你写的。我会从整体设计思路、核心技术细节、实操落地过程、常见坑与排查四个维度把“AI Skill Agent”在民航智慧零售里的完整打法讲透。即使你之前没接触过Agent架构我也会用生活化的类比让你看懂。2. 整体设计思路为什么是Skill Agent而不是一个大模型2.1 民航零售的特殊性决定了架构选型很多人一上来就想“我接个大模型把所有旅客数据和产品丢进去让它直接推荐不就行了”。我试过这条路在民航场景里基本走不通原因有三个。第一民航零售的决策链条极长从旅客搜索、比价、下单、值机、登机、到机上消费、落地后接送每个环节都有不同的产品可以卖单靠一个通用大模型无法覆盖这么长的链路。第二合规和可解释性要求极高动态定价、个性化推荐涉及消费者权益航司必须能解释“为什么给这个旅客推这个价格”黑盒模型直接出局。第三实时性要求苛刻旅客在App里停留的决策窗口往往只有几十秒系统必须在毫秒级完成偏好推断、产品组合、价格计算和展示。所以正确的思路是把复杂问题拆解成一组可独立开发、独立测试、独立上线的Skill再用Agent做编排和决策。这就像一家餐厅Skill是各个厨师有的擅长炒菜、有的擅长做甜品、有的擅长配酒Agent是餐厅经理根据客人需求调度不同的厨师协同完成一桌菜。而不是指望一个全能厨师包办一切。2.2 Skill的粒度设计原则Skill拆得太粗就退化成单体应用失去灵活性拆得太细Agent编排成本爆炸延迟飙升。我的经验是遵循**“单一业务语义 可独立评估”**原则。具体来说一个Skill应该对应一个明确的业务动作并且有独立的输入输出契约和效果指标。比如偏好识别Skill输入旅客ID和历史行为序列输出偏好标签向量如“偏好靠窗”“价格敏感”“常带行李”。产品组合Skill输入偏好向量和当前航班库存输出候选辅营产品组合列表。意愿定价Skill输入旅客价格敏感度和产品组合输出个性化报价区间。话术生成Skill输入产品组合和报价输出面向该旅客的推荐文案。每个Skill都可以单独用历史数据做离线评估比如偏好识别的准确率、定价的转化率提升。这样出了问题能快速定位迭代也不会互相拖累。2.3 Agent的编排逻辑与决策机制Agent不是简单地把Skill串起来它需要具备目标导向的自主决策能力。在民航零售场景里Agent的核心目标可以定义为“在满足旅客体验约束的前提下最大化单次交互的期望收益”。它会根据当前上下文旅客在哪个页面、停留多久、历史转化情况动态决定调用哪些Skill、以什么顺序调用、是否要放弃推荐。我一般会把Agent设计成**“规划器 执行器 反思器”**三层结构。规划器负责根据当前状态生成Skill调用计划执行器负责实际调用并收集结果反思器负责评估本次交互效果并把结果反馈给规划器用于后续优化。这个结构的好处是Agent不是一次性决策而是能在一次会话内多轮调整。比如旅客第一次没点推荐Agent可以反思“是不是价格太高”然后重新调用定价Skill调整报价再试一次。注意Agent的自主决策必须设置硬边界比如价格不能低于成本线、不能推荐旅客明确拒绝过的品类。这些边界要以规则形式硬编码在Agent的约束层不能交给模型自由发挥。3. 核心细节解析Skill与Agent的关键实现要点3.1 偏好识别Skill从行为序列到标签向量偏好识别是整个链路的地基。数据源通常包括历史订单、搜索记录、点击流、客服交互、常旅客等级、设备信息等。我踩过的一个大坑是直接把这些原始特征喂给模型结果噪声极大效果很不稳定。正确的做法是分两步先用规则做粗筛再用模型做精排。粗筛阶段我会定义一批强信号规则比如“过去12个月有3次以上带行李订单”直接打上“常带行李”标签“搜索时多次按价格排序”打上“价格敏感”标签。这些规则覆盖了大部分常见情况而且可解释。精排阶段用一个轻量级的序列模型比如Transformer的小型变体对粗筛没覆盖到的旅客做推断。模型输出是一个多维偏好向量每个维度取值0到1表示该偏好的强度。这里有个关键细节偏好是有时效性的。一个旅客去年价格敏感不代表今年还敏感。所以我在特征工程里会加时间衰减因子越近的行为权重越高。实测下来加了这个衰减后推荐点击率能提升8%到12%。3.2 产品组合Skill约束条件下的组合优化产品组合不是简单地把所有辅营产品列出来让Agent挑那样组合爆炸且大部分不可行。我的做法是把它建模成一个带约束的组合优化问题。目标函数是期望收益约束条件包括库存约束比如升舱座位只剩2个、旅客偏好约束不推旅客讨厌的品类、合规约束不能捆绑销售某些产品、体验约束一次最多推3个产品。求解上小规模场景直接用动态规划大规模场景用启发式算法比如遗传算法或模拟退火。我实测过在单航班200个旅客、20种辅营产品的规模下启发式算法能在50毫秒内给出接近最优的解。这个延迟对于实时推荐是可以接受的。实操心得产品组合Skill一定要做缓存。同一航班、相似偏好群体的组合结果可以复用能大幅降低计算压力。缓存失效策略我一般设为“库存变化超过10%”或“距离航班起飞不足24小时”。3.3 意愿定价Skill个性化定价的边界与实现个性化定价是民航零售里最敏感也最有价值的一环。核心思路是根据旅客的支付意愿Willingness to Pay动态调整报价。支付意愿的估计可以用历史成交数据训练一个回归模型特征包括旅客价格敏感度、剩余时间、竞争航班价格、库存紧张程度等。但这里必须强调合规边界。个性化定价不能变成“杀熟”必须满足几个条件价格调整要有合理依据如库存、时间不能仅基于旅客身份要给旅客选择权比如展示“标准价”和“优惠价”两个选项要有价格上限保护。我在实际系统里会设置一个价格浮动区间比如基准价的0.9到1.2倍超出这个范围的调整需要人工审核。3.4 Agent的上下文管理与记忆机制Agent要在多轮交互中保持连贯必须有良好的上下文管理。我会把上下文分成三层会话级上下文本次交互的页面、点击、停留时间、旅客级上下文历史偏好、历史交互摘要、全局上下文当前航班状态、库存、时间。会话级上下文用短期记忆存储旅客级上下文用向量数据库做长期记忆全局上下文从业务系统实时拉取。记忆机制上我采用**“摘要 原始记录”**的混合方案。原始记录保留最近N次交互的细节更早的交互压缩成摘要向量。这样既保证了近期交互的精度又控制了存储和检索成本。4. 实操过程从零搭建一套可运行的智慧零售原型4.1 环境准备与技术栈选型先说明下面这套方案是我在多个项目里验证过的通用架构具体组件可以根据你所在团队的技术栈替换。核心原则是解耦、可观测、可回滚。组件选型建议选型理由Skill服务框架FastAPI / Spring Boot轻量、易部署、生态成熟Agent编排引擎自研状态机 规则引擎可控性强便于设置硬边界向量数据库Milvus / pgvector支持旅客长期记忆检索特征存储Redis 离线数仓在线特征低延迟离线特征丰富模型服务Triton / TorchServe支持多模型统一部署监控告警Prometheus Grafana实时观测Skill延迟与Agent决策链路环境准备阶段最容易忽略的是特征一致性。离线训练用的特征和在线推理用的特征必须来自同一套定义否则会出现“离线效果好、线上拉胯”的经典问题。我的做法是建一个统一的特征注册中心所有特征的定义、计算逻辑、更新频率都登记在案离线和在线共用。4.2 数据管道搭建与特征工程数据管道分实时和离线两条线。实时线用消息队列如Kafka接收旅客行为事件经过Flink做窗口聚合后写入Redis供在线Skill调用。离线线用Spark做全量特征计算写入数仓供模型训练和批量推理使用。特征工程上我重点构建了三类特征。旅客静态特征常旅客等级、注册时长、历史总消费等。旅客动态特征最近7天搜索次数、最近30天订单数、当前会话点击序列等。上下文特征航班剩余座位、距起飞时间、当前时段等。这三类特征组合起来能比较全面地刻画一个旅客在特定时刻的支付意愿和产品偏好。注意动态特征一定要做在线更新。我见过太多系统动态特征一天才更新一次导致推荐完全跟不上旅客的实时行为变化。4.3 Skill的独立开发与测试每个Skill独立开发独立测试。测试分三层单元测试验证输入输出契约离线评估用历史数据验证效果指标在线A/B测试在小流量上验证真实转化。我一般要求每个Skill的离线评估指标至少提升5%才允许上线A/BA/B测试至少跑两周且统计显著才允许全量。以偏好识别Skill为例离线评估指标是标签预测的F1值我要求达到0.85以上。意愿定价Skill的离线指标是预估转化率与实际转化率的偏差要求控制在10%以内。这些阈值不是拍脑袋定的是根据业务容忍度反推的。4.4 Agent编排逻辑的实现与调试Agent的实现我用的是状态机 规则引擎的混合方案。状态机定义Agent的生命周期初始化、规划、执行、反思、结束规则引擎定义每个状态下允许调用的Skill和调用条件。这样既能保证灵活性又能保证可控性。调试Agent是最费时间的环节。我的经验是先做单Skill串联再做多Skill编排。先把偏好识别、产品组合、意愿定价、话术生成四个Skill按顺序串起来跑通确认每个环节的输出都符合预期再引入Agent的动态决策逻辑。调试过程中一定要打全链路日志记录每次Skill调用的输入、输出、耗时和Agent的决策理由。没有这些日志出了问题根本无从查起。4.5 灰度发布与效果监控上线必须灰度。我的灰度策略是按旅客维度分批先放1%的旅客观察一周没问题再放5%再观察一周然后20%、50%、100%。每个阶段都要监控核心指标推荐点击率、辅营转化率、客单价、旅客投诉率。其中旅客投诉率是红线指标一旦超过基线就立即回滚。监控上除了业务指标还要监控系统指标Skill平均延迟、Agent决策耗时、模型推理成功率。我遇到过Agent因为某个Skill超时导致整个链路卡死的情况后来加了超时熔断机制才解决。5. 常见问题与排查技巧实录5.1 推荐效果不稳定时好时坏这是最常见的问题。排查思路是先看数据再看模型最后看编排。数据层面检查特征是否有缺失或异常值特别是动态特征是否及时更新。模型层面检查模型是否过拟合离线指标和在线指标是否差距过大。编排层面检查Agent的决策逻辑是否在某些上下文下走了异常分支。我遇到过一次典型案例推荐效果在每天上午很好下午就变差。查了半天发现是动态特征更新任务在下午高峰期延迟导致Agent拿到的旅客行为数据是几小时前的。后来把特征更新改成流式处理问题解决。5.2 个性化定价引发旅客不满这个问题很敏感必须从机制上预防。我的做法是设置价格透明度和选择权。具体来说推荐页面同时展示“标准价”和“为您优选价”并说明优选价的依据如“根据您的偏好推荐”。同时设置价格上限任何情况下不超过标准价的1.2倍。另外对价格敏感型旅客优先推荐优惠而非加价产品。5.3 Agent决策链路过长导致超时Agent调用多个Skill每个Skill又有网络延迟和计算延迟链路一长就容易超时。解决方案有三个并行化能并行的Skill并行调用、缓存高频请求的结果缓存、降级超时后返回默认推荐。我一般会把Agent的总超时设为800毫秒单个Skill超时设为200毫秒超时后走降级逻辑。5.4 常见问题速查表问题现象可能原因排查方法解决方案推荐点击率骤降特征管道中断检查特征更新日志修复管道补跑数据定价明显偏离模型输入异常检查定价Skill输入加输入校验和兜底Agent不决策规则引擎死锁检查状态机日志修复规则加超时旅客投诉增多推荐过于激进分析投诉样本调整推荐频率和品类系统延迟飙升某Skill性能退化看Skill耗时分布优化或降级该Skill5.5 独家避坑技巧第一个技巧永远保留一条规则兜底链路。不管Agent多智能都要有一条基于规则的简单推荐链路作为兜底。Agent挂了、模型挂了、数据挂了兜底链路还能保证基本体验。第二个技巧A/B测试要测长期效果。短期转化率提升不代表长期价值提升有些激进推荐短期转化高但会导致旅客流失。我一般会同时看7日转化和30日复购。第三个技巧定期做人工评审。随机抽取Agent的决策样本人工评估推荐是否合理。我每个月都会抽100条样本做评审发现过不少模型和规则都没覆盖到的边缘情况。6. 影响范围与能力延展这套打法还能用在哪6.1 对航司组织能力的影响这套系统落地后航司的电商和辅营团队的工作方式会发生明显变化。过去产品经理主要在做规则配置和活动策划现在更多在做Skill的效果评估和Agent的策略调优。数据科学家从做离线模型变成做在线模型和实时特征。研发从做功能变成做平台和能力。这对团队的能力结构提出了新要求需要提前做人才储备和培训。6.2 对旅客体验的影响从旅客角度看最直观的变化是推荐更懂自己了。过去航司App的推荐基本是“热门产品”或“猜你喜欢”的粗糙版本现在能做到“根据你这次出行的具体场景推荐真正需要的服务”。比如带小孩的旅客会优先看到儿童餐和优先登机商务旅客会优先看到贵宾厅和快速安检。这种体验提升是实实在在的。6.3 能力延展到其他场景这套“Skill Agent”的架构不局限于民航零售。任何有丰富产品、有旅客数据、有实时决策需求的场景都可以复用。比如酒店的动态房价和辅营推荐、租车公司的车型推荐和保险销售、甚至电商平台的个性化促销。核心逻辑是一样的把复杂决策拆成Skill用Agent做编排用数据做闭环。我在另一个旅游零售项目里直接复用了这套架构只替换了偏好识别和产品组合两个Skill两周就搭出了原型。这说明架构的通用性是经过验证的。6.4 后续演进方向短期看重点是提升Skill的精度和Agent的决策质量。中期看可以引入多Agent协作比如一个Agent负责推荐一个Agent负责定价一个Agent负责风控它们之间通过协商达成一致。长期看可以探索Agent自主学习让Agent在与旅客的交互中不断优化自己的策略减少人工调参。不过我要泼一盆冷水不要为了智能而智能。我见过一些团队为了追求“全自动”把很多本该用规则解决的简单问题也交给模型结果系统复杂度飙升效果反而下降。我的原则是能用规则解决的用规则规则解决不了的用模型模型解决不了的用Agent编排。层层递进不要跳级。最后分享一个我在实际项目里总结的小经验先做窄场景再做宽场景。不要一上来就做全链路的智慧零售先选一个具体场景比如值机时的升舱推荐把Skill和Agent跑通验证效果后再逐步扩展。这样风险可控团队也能在过程中积累经验。我见过太多大而全的项目最后不了了之反而是从小场景切入的项目活了下来并且越做越大。