做 AI PM 的朋友，可以看看这个产品的反思。 一个特别明显的感受是，几乎所有移动互联网时代发展起来的产品，现在都在思考同一个问题：怎么把成熟产品进一步 AI 化。 这件事挺难的。 AI 化稍微激进一点，用户可能会疯狂吐槽。因为很多产品大家已经用了十几年，原来的交互方式和使用习惯早就形成了。你一下子改变使用方式，很多用户肯定会不适应。 但反过来，完全不做 AI 探索也不行。AI 带来的新交互和新能力，会直接影响产品未来的竞争力。 今天看起来用户还习惯原来的方式，但哪一天习惯真的发生变化了，再追可能就晚了。 前段时间我跟飞猪的朋友聊了一下他们最近在做的事情，感觉还挺有启发。 飞猪同样也是移动互联网时代发展起来的旅行产品，现在也在重新思考刚才那个课题。他们之前的问一问也有过一段时间的热度，现在最新的 AI 叫飞猪帮帮。 具体产品我就不展开介绍了，大家感兴趣可以自己去看。 目前看这个产品形态肯定也不是终局。但我觉得他们探索过程中的思考还是很有价值。 一个成熟产品真的开始往 AI 方向优化的时候，很多以前只停留在概念里的问题，都会变成非常具体的产品和技术问题。 他们在这个过程中积累的一些经验，我觉得挺值得记录下来。 乍一看，飞猪是在一个成熟产品上做 AI 化，但它的底层逻辑，和今天的 Coding Agent 非常像，都是模型 + Harness + Memory。 Coding Agent 调用的工具是文件系统、终端、浏览器，旅行 Agent 调用的工具是机票报价引擎、酒店库存系统、景区数据接口等等。工具不同，架构是同一套。 我们看到的所有成规模的 Agent 产品，最后都会收敛到这个结构上来。 没聊之前觉得这事很简单，不就是在已有接口上接一下模型 API 嘛，聊完之后才发现远远不止于此。 他们甚至连模型都是自己在开源模型基础上微调的。因为只靠调用通用模型的 API，有很多问题没办法解决。通用模型不能理解具体的业务逻辑，需要加很多规则做限制。 而且更麻烦的是数据安全没办法保证，没有谁愿意把自己的业务数据交给通用模型，这对用户也不负责。 所以，他们搭建了自有的训练环境和数据管线来做后训练，在开源模型的基础上训练出面向旅行场景的自有模型。这一点我完全没想到。 旅行产品本身有自己的表达方式和业务经验。比如一个用户跟 AI 说我周末想出去放松一下，模型如果机械地理解周末，可能会安排周六一早出发。 但对一个上班族来说，很可能想的是周五晚上下班直接走，或者周六睡个懒觉再出发。这些是这个行当里默认的经验，需要通过后训练固化到模型层面。 如果靠规则来约束，推理的时候效果就会差很多。 作为一个成熟的产品，飞猪手里本来就有大量旅行场景的数据和任务，通过后训练让模型慢慢理解这些需求，效果就会好很多。所以，他们在后训练上花了非常多功夫。 具体的做法是把真实的旅行场景建模成智能体编程的任务，让模型在真实工具调用的环境里学习。 而且因为旅行和电商不太一样，价格和库存都在快速变化，差一分钟问同一个问题正确答案可能完全不一样，所以训练环境必须是在线的、实时的。 这类模型也不需要追求智能的上限，甚至不需要做那么多轮次的推理，毕竟用户等不了那么长时间。要不然用户着急买机票呢，还得等 50 秒的推理，谁能有这耐心。 跟上一代做移动互联网产品一样的逻辑，每慢一秒，用户就会流失一批。 模型是大脑，但光有大脑根本不够。真正做成产品，还需要在模型外面加一层 Harness，负责工具调用、规则约束和结果校验。 比如像刚才说的旅行场景里，机票价格和库存一直在变化，这些信息不能让模型凭记忆生成。 模型理解完用户需求之后，必须去调用真实的机票库存和交易系统，最后展示给用户之前还要做一次校验，确保价格、库存这些关键信息仍然有效。 所以我现在越来越觉得，很多垂直 Agent 的技术路径，其实跟 Claude Code、Codex 这类 Coding Agent 非常像。 底下是模型，上面是 Harness。真正的产品能力，很多苦活累活都在 Harness 这一层。所有的 Agent，架构应该都会趋同：模型 + Harness + Memory。 有一些规模不大的 Agent 可能模型可以直接用通用模型 API，但上层的 Harness 和记忆肯定是得自己做。 所以 Agent 产品真正的苦活累活都在 Harness 这一层。模型解决的是理解和推理，但现实世界里的数据校验、异常处理、兜底逻辑，全得靠 Harness 来扛。 哪怕是规模不大的垂类 Agent，模型直接用通用的也能凑合跑起来，但 Harness 和记忆这两层一定得自己做。 Agent 的架构上，他们之前的思路更偏 Multi-Agent，把功能拆得非常细。 酒店一个 Agent、机票一个 Agent，每个 Agent 负责一件事，上层有一个总 Agent 负责编排和调度。 这个思路问题是 Agent 一多，上下文需要在不同 Agent 之间不停传递，容易出现信息丢失，调用链路也非常长，产品出了问题还非常难排查。 现在，他们结构精简了很多。随着模型能力快速进化，在做好 Harness 的前提下，一个 Agent 现在可以同时负责几件事。 即便是面对机票、酒店、门票这些库存性质和使用规则截然不同的品类，一个 Agent 也可以灵活调用机票查询、酒店查询、门票查询、Web Search 等工具来包办。 最后是 Memory。飞猪在记忆这块做了三层：长期记忆、中期记忆和短期记忆，能够把用户跨时间的行为和偏好整体关联起来。 用户喜欢住高档酒店，喜欢坐某个航空公司的航班，这些东西跟 Agent 说一次就好了，如果每次都要重复，用户就很毛躁。 我理解他们三层记忆的分工是这样的。长期记忆是用户画像和长期偏好。中期记忆解决跨会话的问题，比如这几天已经讨论过一次去日本旅行的事，下次再聊 AI 还是知道的。 短期记忆就是当前会话的信息。 这套机制和 ChatGPT 的记忆逻辑也类似。大家感兴趣的话，也可以查查。 另外，我想再说下对于交互的思考。几年前经常看到一种判断，有了大模型之后，LUI 也就是自然语言交互会慢慢替代 GUI。现在来看这个判断过于乐观了。 在一个成熟产品里，用户惯性非常大，而且 LUI 在很多场景里其实比较低效。包括 ChatGPT，我们看到它自己也在 LUI 里融合 GUI，说明这两种交互各有擅长的场景。 需求已经非常明确、追求精确的时候，GUI 很好用。打车就是一个典型例子，已经知道去哪了，地图上输两个字，选一个位置，弹出列表，点一下，选择车型，搞定。 如果这些步骤全部改成对话，体验反而更差，速度也会慢很多。 但碰到模糊需求或者条件非常多的时候，LUI 的优势一下子就出来了。比如想找一张机票，要求从迪拜中转，最好是过夜航班，不需要过境签，两段航班尽量是同一航司。 这种需求在 GUI 里不停地筛选，整个过程非常痛苦，但用自然语言一句话就能说清楚。 飞猪帮帮的做法就是把 LUI 和 GUI 融合在一起。用 LUI 来驱动 GUI，达到更丝滑的搜索和筛选效果。 到现阶段，客观地看，对于大部分产品来说，GUI 才是主体，LUI 是给用户增加一种以前没有的表达需求的方式。直接一把梭哈纯 LUI，实在是为了 AI 而 AI。 很多人觉得做 AI 原生应用就得是纯 LUI，这完全没有 get 到要点。原生不原生只是一个概念，最终还是要以满足用户需求为基础。 所有成熟产品，都得重过 AI 这一关。