企业官网建设流程全解析

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 环境准备与技术栈选型

先说明，下面这套方案是我在多个项目里验证过的通用架构，具体组件可以根据你所在团队的技术栈替换。核心原则是解耦、可观测、可回滚。

环境准备阶段最容易忽略的是特征一致性。离线训练用的特征和在线推理用的特征必须来自同一套定义，否则会出现“离线效果好、线上拉胯”的经典问题。我的做法是建一个统一的特征注册中心，所有特征的定义、计算逻辑、更新频率都登记在案，离线和在线共用。

4.2 数据管道搭建与特征工程

数据管道分实时和离线两条线。实时线用消息队列（如Kafka）接收旅客行为事件，经过Flink做窗口聚合后写入Redis，供在线Skill调用。离线线用Spark做全量特征计算，写入数仓，供模型训练和批量推理使用。

特征工程上，我重点构建了三类特征。旅客静态特征：常旅客等级、注册时长、历史总消费等。旅客动态特征：最近7天搜索次数、最近30天订单数、当前会话点击序列等。上下文特征：航班剩余座位、距起飞时间、当前时段等。这三类特征组合起来，能比较全面地刻画一个旅客在特定时刻的支付意愿和产品偏好。

注意：动态特征一定要做在线更新。我见过太多系统动态特征一天才更新一次，导致推荐完全跟不上旅客的实时行为变化。

4.3 Skill的独立开发与测试

每个Skill独立开发，独立测试。测试分三层：单元测试验证输入输出契约；离线评估用历史数据验证效果指标；在线A/B测试在小流量上验证真实转化。我一般要求每个Skill的离线评估指标至少提升5%才允许上线A/B，A/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 常见问题速查表

5.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跑通，验证效果后再逐步扩展。这样风险可控，团队也能在过程中积累经验。我见过太多大而全的项目最后不了了之，反而是从小场景切入的项目活了下来并且越做越大。