企业官网建设流程全解析

1. 从"卖座位"到"卖服务"：民航零售为什么需要AI Skill+Agent

坐过飞机的人都有体会：同一排座位，有人花三百块，有人花三千块。传统航司的收益管理逻辑，本质上是把"一个座位从A运到B"这个标准品，用复杂的舱位体系和价格梯度卖给不同支付意愿的旅客。这套玩法跑了几十年，边际收益已经越来越薄——因为座位数是固定的，飞机就那么大，你能榨出来的钱有上限。

真正的增量在哪里？在于旅客在出行链条上的所有非座位消费：选座、行李额、贵宾厅、机上餐食、接送机、酒店、租车、保险、升舱、改签……这些需求高度个性化、碎片化，而且时效性极强。一个商务旅客在起飞前两小时突然想升舱，一个家庭旅客在值机时才意识到行李超重，一个转机旅客在落地后才发现需要过夜酒店——这些瞬间才是零售的黄金窗口。

问题是，传统航司的IT系统根本抓不住这些窗口。原因有三：第一，系统是"流程驱动"而非"需求驱动"，旅客必须自己找到对应入口才能完成购买；第二，各个服务模块彼此割裂，选座系统不知道你的行李需求，升舱系统不知道你的转机时间；第三，人工客服成本太高，不可能为每个旅客配一个"出行管家"。

AI Skill+Agent这套组合拳，恰好打在了这三个痛点上。Skill解决的是"能力原子化"问题——把选座、升舱、行李购买、酒店预订这些能力拆成独立的、可被调用的技能单元；Agent解决的是"需求理解与编排"问题——用一个智能体去理解旅客的自然语言意图，然后自动编排调用哪些Skill、按什么顺序调用、调用时传什么参数。

我之所以对这个方向特别关注，是因为它代表了一种根本性的范式转移：从"旅客找服务"变成"服务找旅客"，从"固定套餐"变成"按需组装"，从"一次性交易"变成"全旅程陪伴"。而"按需付费"这个词，在这里不是简单的"用多少付多少"，而是"为每一次个性化的服务调用付费"——这才是智慧零售的真正含义。

下面我会从技术架构、Skill设计、Agent编排、计费模型、落地踩坑几个维度，把这套东西拆开讲清楚。如果你正在做航旅零售、智能客服、或者任何"能力+智能体"方向的产品，这篇内容应该能给你一些可以直接抄作业的思路。

2. 拆解AI Skill：民航服务能力原子化的具体做法

2.1 什么是"Skill"，为什么不是"API"

很多人第一反应是：这不就是把航司的API包装一下给Agent调用吗？不完全是。API是面向开发者的技术接口，Skill是面向Agent的语义化能力单元。区别在于三个层面：

第一，Skill自带语义描述。一个"查询可选座位"的API，参数可能是flightNo、date、cabinClass、passengerId。但一个Skill会这样描述自己："当旅客表达想要选座、换座、查看座位图、或者对当前座位不满意时调用此技能。输入需要航班号、日期、舱位和旅客标识，输出为可用座位列表及其特征（靠窗/靠过道/紧急出口/前排/腿部空间等）。"这段描述是给Agent的"大语言模型"看的，让它知道什么时候该调用、怎么调用。

第二，Skill包含业务规则和约束。比如"购买行李额"这个Skill，不是简单调一个支付接口就完事。它内部要处理：旅客当前票价是否已含行李额、超重多少公斤、不同航段的行李规则是否不同、联程航班是否直挂、购买后如何与值机系统同步。这些规则如果让Agent去推理，既慢又容易出错，所以必须封装在Skill内部。

第三，Skill是可组合的。一个"升舱"Skill可能内部会调用"查询升舱价格"、"锁定新座位"、"释放原座位"、"更新登机牌"、"通知地面服务"等多个子能力。Agent不需要知道这些细节，它只需要知道"升舱"这个Skill能解决什么问题。

我实际做过的项目中，一个典型的民航Skill清单大概长这样：

这张表看起来简单，但每个Skill背后都是一套完整的业务逻辑。以"升舱"为例，我在实际项目中踩过的坑包括：升舱后原座位的释放时机（太早释放可能被其他人抢走导致升舱失败，太晚释放则浪费库存）、升舱价格与会员等级的联动（金卡会员可能有折扣）、升舱后的餐食偏好是否需要同步给客舱服务系统。这些细节如果不在Skill层面处理好，Agent就会给出错误的承诺，导致旅客体验崩塌。

2.2 Skill的粒度怎么定：太粗和太细都是坑

这是我在设计阶段花时间最多的问题。Skill粒度太粗，比如做一个"全旅程服务"Skill，那Agent就变成了一个简单的路由，所有智能都压在Skill内部，失去了Agent编排的意义；粒度太细，比如把"选座"拆成"查询座位图"、"锁定座位"、"确认选座"、"更新登机牌"四个Skill，那Agent需要维护复杂的状态机，调用链一长就容易出错。

我的经验法则是：一个Skill应该对应一个"旅客可感知的完整服务动作"。旅客说"我要选座"，他期望的是一次交互就完成，而不是被问四次。所以"选座"应该是一个Skill，内部完成查询、推荐、锁定、确认的全流程。但如果旅客说"我要选一个靠窗的、前排的、有腿部空间的位置"，这仍然是同一个Skill，只是输入参数更具体。

另一个判断标准是事务边界。如果一个操作需要保证原子性（要么全成功要么全失败），那它就应该是一个Skill。比如"改签+升舱"如果分开两个Skill，可能出现改签成功但升舱失败、旅客被卡在中间状态的尴尬局面。这种情况下，要么合并成一个"改签升舱"Skill，要么在Agent层设计补偿逻辑。

还有一个容易被忽略的点：Skill的版本管理。航司的业务规则经常变，比如行李政策调整、升舱价格算法更新。如果Skill没有版本概念，一次更新可能影响所有正在进行的对话。我的做法是每个Skill带一个version字段，Agent在调用时指定版本，新对话用新版本，老对话继续用老版本直到结束。这样既保证了新规则及时生效，又避免了"对话中途规则突变"的诡异体验。

2.3 Skill的输入输出设计：给Agent看的"说明书"

Skill的接口设计直接决定了Agent能不能用对。我见过太多项目，Skill的输入输出设计得跟内部API一样，字段名全是缩写，Agent根本理解不了。正确的做法是：把Skill的输入输出当成给一个聪明但不懂航司业务的实习生看的文档来设计。

输入参数要包含：参数名（语义化）、类型、是否必填、示例值、业务含义。比如不要用cabin，用cabinClass，并注明"可选值：经济舱/超级经济舱/商务舱/头等舱"。输出要包含：结果状态（成功/失败/需要补充信息）、业务数据、给旅客的自然语言解释模板、可能的后续动作建议。

我特别想强调"后续动作建议"这个字段。比如"选座"Skill返回结果时，可以附带一句："旅客已完成选座，如果旅客有行李需求，可以推荐行李购买Skill。"这样Agent就知道下一步可以主动问什么，而不是傻等旅客开口。这个设计让整个对话的流畅度提升了一个档次。

实操心得：Skill的description字段（给Agent看的自然语言描述）比技术文档重要十倍。我通常会花半小时写一个Skill的description，反复推敲"什么情况下该调用"和"什么情况下不该调用"。比如"升舱"Skill的description里必须写明："当旅客明确表达升舱意愿，或旅客对当前座位/服务表示不满且航班有更高舱位可用时调用。不要在旅客只是询问航班信息时主动推荐升舱，除非旅客有明确的舒适度需求表达。"这条"不要主动推荐"的约束，避免了很多骚扰式营销的投诉。

3. Agent编排层：让"需求理解"到"服务交付"跑通

3.1 Agent的核心职责：不是回答问题，是完成任务

很多人把Agent理解成一个"更聪明的客服"，能回答旅客问题就行。这是巨大的误解。在民航零售场景里，Agent的核心职责是完成任务，而不是提供信息。旅客问"明天去北京的航班有哪些"，他真正想要的不是一串航班号，而是"帮我选一个合适的并订好"。

所以Agent的架构应该是"目标导向"的：接收旅客的自然语言输入，解析出真实意图和约束条件，规划出需要调用的Skill序列，执行调用，处理异常，最终交付一个确定的结果。

我设计的Agent通常包含这几个模块：

意图识别与槽位填充：把"我想明天去北京，最好靠窗"解析成{意图: 航班查询+选座, 日期: 明天, 目的地: 北京, 偏好: 靠窗}。这里的关键是槽位填充要支持"多轮补全"——旅客第一句没说日期，Agent要能主动问，而不是报错。

任务规划：根据意图和槽位，决定调用哪些Skill、按什么顺序。比如"改签+升舱"可能需要先调"查询可改签航班"，再调"升舱报价"，最后调"执行改签"和"执行升舱"。规划时要考虑依赖关系：升舱报价依赖新航班信息，所以必须先查航班。

执行与异常处理：按计划调用Skill，如果某个Skill失败（比如座位被抢），要能自动重试或降级（推荐相邻座位），而不是直接把错误抛给旅客。

结果整合与表达：把多个Skill的返回结果整合成一段自然语言，加上必要的确认和后续建议。

3.2 多轮对话的状态管理：别让旅客重复自己

民航零售的对话往往不是一轮能完成的。旅客可能先说"我想升舱"，Agent报价后旅客说"太贵了"，Agent推荐"那您可以考虑超级经济舱"，旅客说"行"，Agent执行。这中间涉及多次意图切换和状态保持。

我的做法是维护一个对话状态对象，包含：当前任务栈（正在处理的任务）、已确认的槽位、已调用的Skill及结果、待确认的事项。每次旅客输入新消息，Agent先更新状态，再决定下一步。

这里有个容易踩的坑：状态过期。比如旅客在选座过程中突然问"我的行李额是多少"，Agent回答了之后，选座任务的状态还在吗？如果不在，旅客就得重新说一遍"我要选座"。我的处理方式是任务栈支持"挂起"和"恢复"——旅客切换话题时，当前任务挂起，处理完新话题后主动问"刚才您还在选座，要继续吗？"

另一个坑是并发修改。旅客在App上操作的同时，可能也在跟Agent对话。比如旅客自己在App上选了座，然后又跟Agent说"帮我选个靠窗的"。如果Agent不知道App上的操作，就可能给出冲突的建议。解决方案是Agent在调用Skill前先拉取最新状态，或者在Skill内部做冲突检测。

3.3 Agent的"人格"设计：专业但不冰冷

民航服务有个特点：旅客在出行场景下往往处于焦虑状态（怕误机、怕行李超重、怕转机来不及）。Agent的语气如果太机械，会加剧焦虑；如果太随意，又显得不专业。

我的经验是：Agent的语气应该像一位经验丰富的机场地勤——专业、简洁、有温度，但不啰嗦。具体来说：

• 确认信息时用陈述句而非疑问句："为您查到明天上午有三班去北京的航班，最早一班是7点20分。"而不是"您是要查明天去北京的航班吗？"
• 报价格时直接给总价和关键限制："升舱到商务舱需要补差价1280元，含免费行李额40公斤，不可退改。"
• 遇到问题时给解决方案而非只报错误："您想选的那个座位刚被订走了，同区域还有一个靠窗的位置，腿部空间更大，需要为您锁定吗？"

这些细节看起来是"话术"，但背后是Agent对业务的理解深度。一个只会调API的Agent说不出"腿部空间更大"这种话，因为它不知道座位特征数据。

实操心得：我通常会给Agent准备一套"应急话术库"，覆盖常见异常场景：航班取消、座位被抢、支付失败、系统超时。当Skill返回错误时，Agent不是直接念错误码，而是从话术库里匹配最合适的表达。比如支付失败时，Agent会说："支付没有成功，可能是网络波动，您可以再试一次，或者我帮您保留这个价格10分钟。"这句话既安抚了旅客，又给了明确的下一步，还制造了紧迫感促进转化。

4. "按需付费"的计费模型：怎么算钱才合理

4.1 从"打包价"到"服务调用计费"

传统航司辅营产品的计费方式是"打包价"：行李额200元、选座50元、升舱1000元，明码标价。但在Agent场景下，旅客可能一次性完成"选座+行李+升舱"的组合操作，这时候怎么计费？

我的方案是按Skill调用计费，但支持组合优惠。每个Skill有一个基础价格，Agent在编排时如果发现多个Skill可以打包（比如升舱后选座免费），就自动应用优惠规则。这样既保持了灵活性，又不会让旅客觉得"被拆开卖更贵"。

具体来说，计费模型包含几个层次：

基础服务费：每个Skill调用有一个基础价格，比如选座50元、行李200元。这个价格是动态的，可以根据供需调整（比如航班满员时选座涨价）。

组合折扣：当多个Skill在同一对话中被调用时，应用折扣。比如"升舱+选座"组合，选座免费；"行李+酒店"组合，酒店打9折。折扣规则由航司配置，Agent自动计算。

会员权益抵扣：金卡会员的选座免费、银卡会员行李8折等。Agent在调用Skill前先查会员等级，自动应用权益。

动态定价：根据航班时间、剩余库存、旅客历史行为调整价格。比如起飞前24小时内升舱需求旺盛，价格上浮；旅客如果之前多次浏览升舱页面但未购买，可以推送限时折扣。

这套模型的技术实现难点在于实时性。价格必须在Agent调用Skill的瞬间计算出来，不能等旅客确认后再算（否则旅客会觉得被套路）。我的做法是在Skill内部集成定价引擎，Agent调用时传入旅客ID和上下文，Skill返回带价格的结果。

4.2 支付流程的"无感化"设计

"按需付费"要真正落地，支付流程必须足够顺滑。如果旅客每次选座都要跳转支付页面、输入密码、等待确认，那体验就毁了。

我的设计是预授权+免密支付。旅客在首次使用Agent服务时，授权一个支付方式（比如绑定信用卡或开通免密支付），并设置一个单次/单日限额。之后Agent在调用付费Skill时，直接在后台完成扣款，旅客只需要确认服务内容，不需要重复支付操作。

这里有个合规问题：预授权扣款需要明确告知旅客。我的做法是在首次授权时用一段清晰的文字说明："您授权Agent在您确认服务后自动扣款，单次不超过500元，单日不超过2000元。您可以随时在设置中修改或取消。"然后每次扣款后推送一条通知，包含服务内容、金额、时间。

另一个细节是退款处理。如果Skill调用失败（比如升舱失败），扣款要自动退回。这要求支付系统和Skill执行系统之间有可靠的对账机制。我通常会在Agent层加一个"补偿任务"：如果Skill返回失败但支付已扣款，自动触发退款流程，并通知旅客。

4.3 计费透明化：让旅客知道钱花在哪

"按需付费"最大的风险是旅客觉得"不知不觉钱就没了"。所以透明化至关重要。我的做法是：

• 每次扣款前：Agent明确列出即将调用的Skill、每个Skill的价格、总价、优惠明细。
• 扣款后：推送账单详情，包含服务名称、价格、使用状态（已生效/待生效）。
• 对话中随时可查：旅客问"我今天花了多少钱"，Agent能立即列出所有消费记录。

我还会在对话中主动提示"省钱机会"：比如"您本次选座+行李合计250元，如果升级到超级经济舱（补差价300元），两者都免费，还多一份餐食，需要为您计算一下吗？"这种主动推荐不是骚扰，而是基于旅客当前需求的合理建议，转化率往往很高。

实操心得：计费模型最怕的是"规则冲突"。比如会员权益说选座免费，但动态定价说高峰期选座加价，到底听谁的？我的原则是"权益优先于动态定价"——会员权益是承诺，必须兑现；动态定价只适用于无权益冲突的场景。这个优先级要在Skill内部硬编码，不能靠Agent推理，否则迟早出乱子。

5. 落地踩坑实录：从Demo到生产环境的距离

5.1 坑一：Skill的"幻觉调用"

Agent最危险的行为是"幻觉调用"——旅客只是问"我的航班几点起飞"，Agent却调用了"升舱"Skill并给出了报价。这种错误在Demo阶段不容易发现，因为Demo的对话路径都是设计好的。但到了生产环境，旅客的输入千奇百怪，Agent很容易误判意图。

我的解决方案是双重确认机制：对于任何涉及扣款或变更的Skill调用，Agent必须先向旅客确认。确认话术要具体："您是要将CA1234航班的经济舱升到商务舱，补差价1280元，确认吗？"而不是笼统的"您确认要升舱吗？"具体的话术让旅客能发现Agent的理解偏差，及时纠正。

另外，我会在Agent的prompt里加入"负面示例"：明确列出哪些情况下不应该调用付费Skill。比如"当旅客只是询问航班状态、天气、机场设施时，不要推荐任何付费服务。"这些负面示例比正面规则更能约束Agent的行为。

5.2 坑二：多Skill调用的"状态不一致"

前面提到过，多个Skill调用时可能出现状态不一致。我遇到过一个典型案例：旅客先选了座，然后升舱，升舱后原座位应该释放，但选座Skill的状态没有同步更新，导致旅客在App上看到两个座位。这种问题在单Skill测试时发现不了，只有多Skill组合时才暴露。

解决思路是引入"旅程状态中心"：所有Skill共享一个旅客旅程状态对象，任何Skill修改状态后都要写回中心。Agent在编排时，每次调用Skill前先拉取最新状态，调用后更新状态。这个中心可以用Redis或类似的内存数据库实现，保证读写性能。

但这里有个权衡：状态中心越实时，系统耦合度越高，一个Skill的故障可能影响全局。我的做法是最终一致性：Skill调用后异步更新状态中心，Agent在关键决策点（如扣款前）强制拉取最新状态。这样既保证了性能，又避免了重大错误。

5.3 坑三：旅客的"非标准表达"

旅客不会按照设计好的话术说话。有人说"我想坐前面点"，有人说"腿伸不开"，有人说"给我找个能睡觉的位置"。这些表达都需要Agent能理解并映射到具体的Skill参数。

我的做法是建立同义词库和意图映射表。比如"前面点"→"前排座位"，"腿伸不开"→"腿部空间大的座位"，"能睡觉"→"靠窗+后排+旁边空座概率高"。这个映射表需要持续运营，从真实对话日志中挖掘新的表达方式，定期更新。

另一个技巧是让Agent学会反问。当旅客表达模糊时，Agent不要猜，而是给出选项让旅客选："您说的'前面点'是指靠近登机口的前排，还是靠近窗户的前排？"这种反问既澄清了需求，又让旅客觉得Agent在认真对待他的要求。

5.4 坑四：系统集成的"最后一公里"

Skill要真正落地，必须跟航司的存量系统集成：PSS（旅客服务系统）、DCS（离港系统）、CRS（座位预订系统）、辅营系统、支付网关……这些系统往往年代久远，接口文档不全，测试环境不稳定。

我踩过的最大的坑是测试环境与生产环境的行为差异。测试环境里升舱接口秒回成功，生产环境里因为并发锁的问题经常超时。解决方案是在Skill层做超时和重试：设置合理的超时时间（比如3秒），超时后自动重试一次，重试仍失败则返回"系统繁忙，请稍后再试"并记录日志。

另一个坑是数据一致性。航司的座位库存在不同系统里可能有细微差异，Agent看到的可售座位和实际可售座位可能不一致。我的做法是以PSS为准：所有涉及库存的Skill都直接查PSS，不查缓存。虽然性能差一点，但避免了超售。

实操心得：跟存量系统集成时，一定要争取"影子模式"运行一段时间——Agent的调用不真正执行，只记录日志，对比Agent的决策和人工客服的决策差异。这个阶段能发现大量逻辑问题，而且不影响真实旅客。我通常建议影子模式跑至少两周，覆盖足够多的场景后再切生产。

6. 这套东西到底能带来什么：几个可量化的收益点

6.1 辅营收入的增量从哪里来

传统航司辅营收入主要靠"旅客主动购买"，转化率通常是个位数。Agent的价值在于主动发现需求并即时满足。根据我参与过的项目数据，几个典型的增量场景：

场景一：转机旅客的酒店需求。传统模式下，旅客需要自己意识到"我需要酒店"，然后去OTA搜索。Agent可以在旅客查询转机航班时主动提示："您的转机时间超过8小时，需要为您预订机场附近的酒店吗？"这个提示的转化率远高于旅客自己搜索。

场景二：行李超重的即时购买。旅客在值机时才发现行李超重，传统模式下要么现场排队付费（体验差），要么被迫丢弃物品。Agent可以在旅客值机前推送提醒："您的行李额是20公斤，当前行李23公斤，需要提前购买3公斤行李额吗？提前购买比现场便宜40%。"

场景三：升舱的"最后一刻"转化。起飞前24小时是升舱的黄金窗口，但传统模式下航司只能群发短信，转化率低。Agent可以根据旅客的历史行为（是否经常浏览升舱页面、是否对座位有特殊要求）做个性化推荐，转化率能提升2-3倍。

6.2 服务成本的下降

Agent能承接大量重复性咨询，释放人工客服。根据我的观察，民航客服的咨询中，超过60%是"航班状态查询"、"行李规则"、"选座"、"改签政策"这类标准化问题。Agent可以7x24小时处理这些问题，人工客服只处理复杂投诉和特殊情况。

但要注意：Agent不是用来"替代"人工的，而是用来"分流"的。我的设计里，Agent在遇到无法处理的情况时（比如旅客情绪激动、涉及复杂退改、需要特殊服务），要能平滑转接人工，并把对话上下文一并传递，避免旅客重复描述。

6.3 旅客体验的提升

这个最难量化，但最重要。我跟踪过一组数据：使用Agent服务的旅客，NPS（净推荐值）比未使用的旅客高15-20分。原因很简单：Agent让旅客觉得"被理解"和"被照顾"。一个能在旅客开口前就想到他可能需要什么的系统，比一个冷冰冰的搜索框强太多。

但体验提升的前提是Agent不能犯错。一次错误的扣款、一次错误的升舱承诺，足以毁掉旅客对整套系统的信任。所以我在项目里始终坚持一个原则：宁可Agent少做，不可Agent做错。不确定的时候，Agent应该问，而不是猜。

7. 如果你要动手做，从哪开始

7.1 最小可行产品的范围

不要一上来就做全旅程Agent。我的建议是从一个高频、标准化、有明确付费点的场景切入。比如"选座+行李"组合：旅客需求明确、Skill逻辑相对简单、付费意愿高、失败影响可控。

MVP的范围可以这样定：

• 支持3个Skill：航班查询、选座、行李购买
• 支持单轮和多轮对话
• 支持预授权支付
• 支持人工转接
• 影子模式运行两周

这个范围大概需要2-3个开发、1个产品、1个航司业务专家，4-6周可以跑通。

7.2 技术选型的关键决策

Agent框架：不要自己从零写。用成熟的Agent编排框架（如LangChain、Semantic Kernel等），但要注意这些框架的抽象层可能跟航司业务不匹配，需要做适配。我的做法是用框架做意图识别和任务规划，Skill调用和状态管理自己实现。

大语言模型：民航场景对准确性要求极高，建议用能力较强的模型做意图理解，但关键决策（如价格计算、库存判断）必须由确定性代码完成，不能交给模型推理。

Skill的实现：每个Skill是一个独立的微服务，有自己的数据库和业务逻辑。Skill之间不直接调用，只通过Agent编排。这样保证了Skill的可替换性和可测试性。

状态管理：用Redis做对话状态和旅程状态的缓存，用关系数据库做持久化。关键是要有状态版本号，避免并发冲突。

7.3 团队配置的建议

这个方向需要三类人：

• 航司业务专家：懂收益管理、辅营产品、旅客服务流程。没有这个人，Skill的业务规则就是拍脑袋。
• Agent工程师：懂大语言模型应用、Prompt工程、对话状态管理。
• 后端工程师：懂微服务、系统集成、支付。

三类人必须坐在一起工作，不能分开。我见过太多项目，业务专家给需求，工程师实现，结果做出来的Skill跟实际业务差十万八千里。最好的方式是业务专家直接参与Skill的description编写和测试用例设计。

7.4 上线后的持续运营

Agent上线不是终点，而是起点。需要持续做几件事：

对话日志分析：每天看Agent的失败案例，找出意图识别错误、Skill调用错误、话术不当的地方，持续优化。

Skill迭代：根据旅客反馈和业务变化，不断调整Skill的输入输出和内部规则。

价格策略调优：根据转化率数据，调整动态定价的规则和幅度。

A/B测试：对Agent的话术、推荐策略、价格展示方式做A/B测试，用数据驱动优化。

这个方向我做了两年多，最大的体会是：技术不是瓶颈，业务理解和运营才是。一个对航司业务理解深刻的团队，用简单的技术也能做出好用的Agent；一个技术很强但不懂业务的团队，做出来的东西旅客根本不用。所以如果你要入局，先花时间搞懂民航零售的底层逻辑，再动手写代码。