从回答问题到把事办完，消费Agent还缺什么？飞猪新一代 AI 产品 V10 的一次探索

AI摘要 飞猪CTO陈烨指出，AI产业价值仍过度集中于基础模型与算力层，应用层尤其是消费场景的Agent尚未形成稳定PMF。V10是面向“把事情办完”目标的阶段性工程实践，直面实时供给、交易履约等复杂闭环挑战。

价值需向编排层与应用层迁移；消费Agent的核心瓶颈在系统可靠性与多环节协同；Coding的PMF路径不可简单复用于强履约场景。

适合AI应用架构师、消费领域技术负责人、Agent系统工程师阅读。

信息检索和 Coding，是过去两年率先找到产品市场匹配的 AI 应用方向。前者改变了人们获取信息的方式，后者则让模型开始理解目标、调用工具并执行任务。

但类似的突破尚未发生在消费领域。AI 可以完成越来越复杂的代码任务，却仍然很难稳定地处理一次涉及实时供给、交易和后续履约的消费需求。

在上周的飞猪新一代 AI 产品评测会上，飞猪 CTO 陈烨将这种落差放到了整个 AI 产业的价值链中观察。

在他看来，当前行业的注意力和价值仍然高度集中在基础模型、GPU、算力基础设施和 Token 层，应用层尚未出现足够多能够承接价值的产品。这种结构并不是一个可持续的终局。一个更加健康的 AI 生态，价值应该逐渐向下游延伸，进入编排层和应用层。

这也把讨论带向了一个更具体的问题：Coding 已经证明，应用可以在基础模型之上建立独立价值；这种路径能否进一步进入旅行、电商等真实消费场景？

飞猪在评测会上展示的新一代 AI 产品 V10，可以被看作对这一问题的一次阶段性探索：当 AI 从回答问题走向把事情办完，产品和工程体系还需要补齐什么？

陈烨提到，AI 产品正在经历从大模型、Chat、Coding，到 Agent、自进化，再到 PhysicalAI 的发展过程。

当前行业的主要关注点正在进入 Agent 阶段，下一步则可能走向能够利用工具和环境反馈持续进化的 Agent。但消费 Agent 还没有取得与 CodingAgent 类似的进展。

陈烨认为，AgenticCoding 给行业展示了一条重要路径：模型可以理解目标、调用工具，并在执行反馈中修正结果。Coding 的一个特殊优势，是大量问题能够以相对封闭的方式进行验证。代码能否运行、测试能否通过，通常可以得到较为明确的判断。

消费场景则不同。一张机票是否合适，不只取决于价格，还可能涉及出发时间、中转地点、是否需要过境签、能否过夜以及航司偏好。两家酒店都可能真实存在，但哪一家更适合当前用户，还要结合位置、预算、同行人和个人偏好判断。

与此同时，机票和酒店都是高度时间化的商品。日期变化后，库存、价格、房型和可售状态都可能发生变化。交易完成后，还会进入值机、航变、退改和售后等履约环节。

从 Coding 走向消费场景，难点不只是模型能否理解需求，还包括数据能否实时更新、结果能否验证、供应链能否响应，以及交易后的履约能否继续完成。

如果只看界面，飞猪 V10 最直观的变化，是增加了一个可以展开和收起的 AI Panel。

在此前的版本中，用户需要主动进入一个独立的 AI 页面。到了 V10，AI Panel 可以出现在首页、酒店、机票、度假和订单等页面，并根据用户当前所在的场景提供相应的推荐问题和能力。

这不仅是入口位置的变化。更准确地说，飞猪正在尝试让 AI 从一个独立页面，进入搜索、交易和订单履约等具体场景。

V10 将主要能力概括为“帮我想、帮我订、帮我办”。

“帮我想”对应旅行灵感和行程规划。例如，用户可以复制一篇社交平台上的旅行笔记，由系统解析其中的景点、美食和住宿信息，再结合飞猪的相关供给组织行程。

“帮我订”主要处理传统筛选方式不容易覆盖的复杂需求。例如，寻找能够看到故宫金顶、允许携带宠物，或者适合老人且不需要爬楼梯的酒店。

“帮我办”则进入交易之后的服务环节，包括值机选座、酒店升房、开发票、退款，以及处理同一行程中的关联订单。

从产品团队的解释看，这三种能力分别对应旅行过程中的不同服务类型：灵感与规划、搜索与预订，以及交易后的履约服务。其中，值机等任务可能需要等待航司开放办理，持续时间从数小时到数周不等。V10 因此增加了长程任务的状态和进度展示。

这意味着，产品面对的已不只是一次即时问答，还包括需要持续记录和更新状态的任务。产品经理在分享中强调了两条原则：第一，提供给用户的数据和商品要保证“真实可达”；第二，不为了 AI 而 AI，优先处理原有 GUI 难以完成，或者原来需要多步操作、现在可以通过一句话完成的事情。

“真实可达”和“是否真正降低用户操作成本”，构成了 V10 当前选择 AI 场景的两条主要标准。

与产品从独立问答走向跨场景服务同步，飞猪的算法架构也在发生变化。

飞猪早期的“问一问”采用了 Multi-Agent 架构，并在模型能力相对有限的阶段使用较强的 Workflow 编排，以保证结果稳定。

随着模型能力提高，团队开始向 ReAct 式的 AgentLoop 迁移，希望让能力更完整的 Agent 承担更多需求理解、自主决策和工具调用工作。

飞猪策略是： “架构上做减法，模型层面做加法。” 但这并不意味着可以无限增加 Agent 的思考和反思轮次。如果一个杭州五日游规划需要经过多轮思考和反思，五分钟甚至十分钟后才能返回结果，用户很可能已经离开。

因此，飞猪在在线推理中采用较轻的验证方式，优先检查不可接受的错误；一些更复杂的路线和时空合理性问题，则通过离线建设的线路库、规则引擎和后续训练处理。

消费 Agent 的工程问题，不只是如何让模型思考得更多，还要判断哪些问题必须在线计算、哪些结果可以提前验证，以及哪些错误必须由规则和工具拦截。

飞猪算法团队分享的一个具体机制，是商品短别名。

酒店、房型和机票等商品都有真实 ID。尤其是机票，背后连接实时变化的系统，商品标识可能很长。如果直接让模型在推理或训练过程中处理这些 ID，就可能出现字符生成错误。

飞猪的处理方式，是将工具返回的商品映射为 A1、A2 等较短的别名。模型在当前任务中引用这些别名，推理完成后，再由系统回填真实商品 ID、标题、价格和库存。

模型能够选择工具实际返回的商品，但不能在白名单之外凭空产生一个商品。

这一做法体现出一个重要原则：能够由数据库、规则或者工具确定的信息，应尽量由确定性系统提供，而不是依赖模型自行生成。

模型负责理解需求和进行选择，工具与规则负责保证商品信息来自真实供给。

飞猪算法团队将 Agent 能力建设概括为三个阶段：Prompt、机制和训练。

早期 Prompt 往往采用命令式写法，例如要求模型先找目的地、再找交通、酒店和景点。随着任务和规则增加，Prompt 会越来越长，模型对不同指令的注意力也可能变得不稳定。

团队正在尝试将命令式 Prompt 改为声明式 Prompt：不再规定每一步必须怎样执行，而是告诉模型什么是一份好的行程规划、目标是什么、底线是什么，再让模型自主决定具体过程。