Agent 成大厂新“战场”？从同程旅行 DeepTrip 看垂类 Agent 的设计与落地实践

作为大模型最早落地应用的行业之一，旅游行业正经历一场由技术驱动的深度变革，并迅速在年轻人群体中，掀起了一场风暴。

这背后折射出的深层原因是，大家在做旅行决策时，真的疲于应对铺天盖地的信息——大到买车票、定酒店，小到搜景点、找美食，每一件都是如此的费时费力。甚至从某种程度上来说，做决策花费的时间和精力，不亚于写一篇攻略文章。

也因此，垂类旅行 Agent 得以迅速落地应用。凭借对用户需求的深刻洞察，以及对信息的深度整合能力，成为年轻人的首选。

但在技术实现上，要想设计出一个能真正解决用户实际需求的 Agent 并非易事。正如 Anthropic 在《Building Effective Agents》一文中所言，真正的 Agent 应当能够自主决策和调整执行方式。这也意味着，Agent 与传统的 Workflow（预定义工作流）存在本质上的区别：后者仅仅是按部就班地执行预定义路径，而真正的 Agent 则能够根据环境反馈灵活调整策略。

在信息爆炸的时代，旅行规划往往让人“又爱又恨”。一方面，海量的信息为出行提供了更丰富的选择，从出行方式到酒店住宿，从美食到景点，总能在网上找到详细的攻略帖。另一方面，过载的信息也让决策变得更加困难，比如，要在不同的平台上来回比价，要从海量的广告帖中辨别真假。

这与旅行的初衷背道而驰——旅行应该是轻松、自由的，而非在各项选择中精疲力尽。

在这一背景下，包括 DeepTrip 在内的垂类旅行 Agent 应运而生。其为用户带来最大的价值在于，能真正地省时省心，解决用户在旅行场景中遇到的各类问题。

比如，在过去，机票、酒店、景点这些不同的产品都有各自的入口以及对应的检索逻辑。而 DeepTrip 能通过强大的智能决策能力，精准理解用户需求并灵活调用各项服务能力，为用户提供简单、统一、高效的访问入口。

作为旅游资深爱好者，笔者也对 DeepTrip 进行了一番实测。以找酒店为例，输入提示词“帮我推荐一家成都市区能看雪山的酒店，500 元左右”后，DeepTrip 开始进行一系列思考，最终推荐出相对合理的酒店，并且每个酒店都可以点进去直接预定。这个需求比较难，DeepTrip 既没有直接硬给出一个不合理的酒店，也没有直接放弃，而是根据工具结果不断优化调用方案，通过迭代给出相对合理的答案。

除了这种查询具体场景下的单点能力，DeepTrip 也具备做完整旅行规划的综合能力。

输入提示词“想在 8 月份去重庆玩三天，两大一小（小孩一岁），帮我做一份旅行规划，行程不要安排太满”，DeepTrip 用了不到一分钟的时间，就给出了一份安排合理的三天行程安排规划，甚至在游览贴士中也考虑到了亲子注意事项。

通过智能化的服务整合与精准的需求匹配，DeepTrip 有效降低了用户在旅行规划过程中的决策成本。目前，DeepTrip 已全面接入酒店预订、机票购买、火车票查询、景点推荐、美食、购物、生活服务、交通设施等核心功能模块，构建了一个完整的旅行服务生态体系。

可以说，DeepTrip 这些垂类旅行 Agent 的出现，既改变了传统的旅行决策流程，也让生活中的琐事处理变得更加高效从容。但正如前文所言，设计出这样一个能真正解决用户实际需求的 Agent 并非易事。

从业务场景来看，作为公司旅行服务的智能中枢，DeepTrip 需要对接多样化的内部资源，并适应高度不确定性的复杂业务场景。以行程规划为例，用户需求高度不确定，存在需求组合维度爆炸（如时间、预算、偏好等变量的排列组合）、实时资源变动频繁（如航班延误、房态变化等）以及个性化程度高（如特殊饮食要求、无障碍设施等）的特性。这些特性使得穷举所有可能场景的 Workflow 方案在工程实现上几乎不可行，而具备自主决策能力的 Agent 架构能更灵活地应对这种复杂性。

从技术可行性来看，项目决策时恰逢以 DeepSeek 为代表的新一代推理模型取得突破性进展，为 Agent 架构的实施提供了坚实的技术基础。

站在更长远的演进优势角度，Agent 架构具有独特的进化特性，比如，能够直接受益于基座大模型持续升级所带来的模型能力红利。此外，Agent 架构的简洁性能显著降低系统复杂度，同时在运维层面具有明显的成本优势。

确定采用 Agent 架构后，同程旅行技术团队围绕整体目标“整合公司主要资源，为用户提供简单、统一、有效的访问入口”，从强化学习的几个核心维度来定义 DeepTrip 的 Agent 系统，主要包含五个核心维度：

• Agent 本体：由经过工程化设计的 Prompt 大语言模型构成；

• 环境：包括用户侧的实时需求表达和资源侧的旅行服务生态系统；

• 动作空间：涵盖工具调用、信息呈现和信息保存；

• 奖励信号：包含显式反馈（工具执行结果、用户反馈）和隐式反馈（模型自我反思）；

• 状态表示：对话和推理上下文。

具体来看，整个方案的核心主要包括 Agent Loop、Tool Using，以及在模型训练层面的技术实践三部分。

Agent Loop 即大语言模型与环境之间形成的动态交互循环，其主要包括四个关键环节：接收并理解环境反馈、基于反馈进行自主决策、生成下一步最优动作、将动作作用于环境。这种持续优化的交互机制，也是 Agent 技术区别于传统 Workflow 方案的本质特征。

在代码层面，Agent Loop 实际是一个 while 循环，核心的伪代码如下：

action = call_llm()while action != "answer" :  if action == "function_call": call_functions() if action == "save_info": save_info() update_context() action = call_llm()answer_question()

要想实现这个 while 循环，最具挑战性的环节是 update_context（上下文状态维护），即如何维护好模型的状态，这个状态必须完备并且能高效地被大模型理解。更进一步而言，大模型通常被训练为一次性回答用户 query，而在 Agent 框架的 while 循环中，当前任务仅为整个流程中的一个步骤。因此，在每个步骤中，都需精心维护前面步骤的 context 信息，并向后续步骤传递必要信息。

针对这一问题，目前行业内并没有形成成熟的通用解决方案，不同基座模型对应不同的最佳实践。根据同程旅行技术团队的实践经验，这一过程的关键在于目标和行动纲要的传递，以及前序动作信息的传递。

在多步推理中，必须将总体目标和宏观计划有效传递到后续模型推理的 prompt 中，以确保各推理 step 步调一致。若处理不当，可能出现多步推理后答非所问的情况。对于复杂任务，若未传递总体规划信息到后续步骤，可能导致各次推理行动不一致。

由于当前的大模型本质上是对话模型，而非专为 Agent 设计，因此需要采用多种工程技术手段进行适配。比如，在初始推理步骤要求模型生成结构化宏观计划，并在后续推理中显式传递该计划；或是完整保存模型的整个思考过程，直接作为下一轮推理的输入；也可以通过设计特殊工具来中介模型间的信息传递，将输出伪装成工具调用结果，确保大模型在多步推理过程中保持目标一致性。

随着底层技术的进步，特别是面向 Agent 的训练方式的发展，未来，有望用更优雅的方式实现目标传递，减少对工程技巧的依赖。

在前序动作信息的传递方面，在推理过程中，需要感知之前 action 的信息，若感知不明显，可能出现循环推理情况。例如在酒店搜索中，用户要求“再给我推荐些更贵的酒店”，若模型感知不到前序动作，且目标为比较型，模型会一直搜索“更贵的”而无法停止，因为它未意识到已执行过搜索更贵酒店的操作。

总之，这里的关键在于“承上启下”，需有机制将必要信息有效传递到当前推理步骤，同时精心设计 prompt，激发模型按要求进行下一次推理。

此外，多步骤推理中上下文长度的管理至关重要。比如，规划多天行程时，大模型在多步工具调用中会产生大量数据，过多数据加入 context 会使上下文过长，干扰信息增多，影响模型效果，甚至超过模型上下文长度导致调用失败。为此，同程旅行技术团队专门设计了 save_info 动作，在流程合适时机保存重要信息，使 context 保持在合理长度。

现阶段，提示词的设计需要一定的技巧性。不同的基座模型有着各自独特的特点，这也对应着不同的处理方式。例如，DeepSeek 的 system prompt 对整体流程的影响相对较小，而 message 的最后一句却对整个流程有着较强的控制力。随着 Agent 的训练数据逐步融入模型训练中，Agent 方案的 prompt 设计将不再是难以跨越的门槛。目前，同程旅行技术团队也在利用 Agent 的数据对基座模型进行微调，以期获得更加易用的模型。

在模型选择上，一个常见的问题是：是否一定要选用推理模型？这类模型具备自动对每个问题进行充分思考的能力，进而给出最终答案。非思考模型则缺乏自动思考的流程，其思考过程需要通过设计 prompt 进行引导。那么，思考模型是否更适合于 Agent 方案呢？

同程旅行技术团队认为，这两类模型各有利弊。思考模型的推理效果往往更佳，且 prompt 设计更为简单，但其思考过程不可控，有时会对简单问题进行过度思考，导致响应时间延长、成本增加。此外，同程旅行技术团队还观察到，DeepSeek 在思考过程中经常做出一些假设，这可能导致模型在后续过程中将假设当作事实，从而产生一些不必要的幻觉。而对于非思考模型，可以运用一些 prompt 技巧，引导模型进行合理的 Chain-of-Thought（COT）思考，使思考过程更加可控、简练，但这需要投入精力精心设计对应的 prompt。综合来看，目前思考模型更适合用于冷启动阶段，而非思考模型则更适合用于降低成本和延时。

Tool Using（工具调用）是 Agent 方案的核心能力之一，大模型必须通过 Function Calling 机制才能实现与外部系统的交互。目前，DeepTrip 已完成同程旅行内部核心服务接口的标准化对接，包括酒店、机票、火车票、景点门票等模块，并持续扩展工具生态，以提供更完整的旅行服务闭环。

随着 MCP 协议的爆火，工具的可插拔性也得到了大幅提升，但考虑到业务场景适配性以及效果优先原则，DeepTrip 并未直接采用 MCP 协议，而是借鉴了类似的工具注册机制，实现了灵活的工具管理和标准化接入流程：通过注册中心动态调整工具集，支持不同业务线按需组合；简化工具接入与下线流程，确保系统可扩展性。这一设计在保证业务适配性的同时，也具备了类似 MCP 的灵活性，为未来兼容外部协议奠定基础。

在 Agent 架构中，Tool Using 的核心差异在于服务对象的变化——传统接口面向人类或程序，Agent 工具需要适配大模型的交互方式。相较于人类，大模型能处理更复杂的接口逻辑；相较于程序，它更依赖自然语言而非严格的代码规范。因此，一套大模型友好接口的设计原则尤为必要。同程旅行技术团队总结了以下五条大模型友好接口设计原则：

1. 语义清晰的接口定义

工具名、参数名、描述应尽可能自然、无歧义，避免技术术语或缩写。

例如，get_flight_info 优于 query_flt，departure_city 优于 src。

2. 灵活的输入参数设计

减少硬编码枚举，支持模糊输入。例如：若接口仅支持地级市（如“成都市”），但用户输入“新都桥”，系统应自动关联到上级城市（如"甘孜藏族自治州康定市"），而非直接报错。

3. 自然语言优先的返回结果

结构化数据 → 文本描述：大模型处理结构化数据（如 JSON）时，Token 消耗更高，且推理效果不如自然语言。

例如，返回“上海浦东机场至北京首都机场，航班号 CA1838，起飞时间 08:00”而非 {departure: "PVG", arrival: "PEK", flight: "CA1838", time: "08:00"}。

4. 错误处理的自然语言引导

错误反馈应具备可行动性，帮助大模型自主修正。例如：

案例 1：查询“成都→苏州航班”，返回“苏州无机场，建议查询上海”。大模型可据此调整查询目标。

案例 2：输入英文城市名（如“New York”），返回“仅支持中文输入，请尝试‘纽约’”。大模型会自动翻译后重试。

避免无意义的空返回或错误码，如 404 或 {"error": "invalid_input"}。

5. 检索类工具

召回优先，大模型辅助排序，传统检索类工具需要精排（如电商 SKU），但大模型可承担部分逻辑因此接口应更侧召回和粗排。

随着 Agent 技术门槛不断降低，底层接口的“大模型友好化”将成为竞争关键。目前，DeepTrip 正推动内部接口向 LLM-Friendly API 演进，这一过程不仅涉及技术改造，更需重新定义服务边界的协作方式，让接口更“像人”一样思考，而非让大模型更“像程序”一样解析。

此外，通过原则四中提及的案例可以看出，在 Agent 框架中，工具不仅能与外部系统连接，还能通过反馈参与到 Agent 的整个决策过程。原因在于，工具本身具备功能，如搜酒店、搜机票，能通过反馈引导大模型工作。比如，当用户搜索“成都→苏州航班”，工具会告知大模型，苏州没有机场，查不到航班，可以推荐附近机场。因此从一定程度上来说，这里的工具已经不是传统意义上的简单工具，而是本身具有完成一个子任务能力、可以和主 Agent 交互的子 Agent，它能够辅助主 Agent 更好地决策，并且减轻主 Agent 的推理负担。

在 Agent 技术落地的过程中，模型训练是提升核心能力的关键环节。当基座大模型的通用能力达到瓶颈时，监督微调（SFT）和强化学习（RL）成为进一步优化模型行为的重要手段。

相较于 prompt 工程在调控某些行为特征时存在的局限性，SFT 凭借针对性训练，能够实现对模型行为的更精准控制。例如，针对基座模型长文本生成能力不足的问题，可以采用数据蒸馏和合成技术，构建高质量的长文本数据集用于微调。

值得注意的是，采用规模更小的模型进行微调，不仅能大幅降低计算成本、提升推理速度，还能在模型性能上保持相当水准。不过，在实施 SFT 的过程中，需要特别关注模型的泛化能力。特别是在 Agent 架构中，要确保微调过程不会对模型的核心推理能力造成损害，这是评估微调效果的重要指标。

强化学习作为 Agent 技术的核心环节，其关键挑战在于环境建模和奖励机制设计。为了突破这一瓶颈，同程旅行技术团队正在构建 DeepTrip 的评估体系，具体包含两个维度：

• Rule-Based 评估：聚焦基础能力验证，包括

• 幻觉检测（事实一致性）

• 工具调用的完备性（API 覆盖与参数正确性）

• 规划路径的合理性（逻辑连贯性与可执行性）

• Model-Based 评估：衡量整体智能水平，如

• 用户需求满足度（意图理解与任务完成质量）

• 交互流畅性（多轮对话的连贯性）

评估能力的精准度直接决定强化学习的成败——只有建立起科学、可量化的评估体系，并将其作为未来 Reward Function 的核心，强化学习才能有效优化模型行为，进而推动智能体技术取得实质性进步。

随着 DeepTrip 的持续迭代，SFT 和 RL 的结合将进一步提升 Agent 的自主决策能力。未来，团队计划引入在线学习（Online RL），让模型在真实用户交互中持续优化，最终实现更智能、更个性化的旅行规划体验。

据同程旅行技术团队介绍，未来，DeepTrip 将进行多维度的能力拓展。一方面，提高思考过程的可解释性，让用户了解系统调用了哪些工具、获取了哪些结果。另一方面，新增餐饮、演唱会等功能，并接入同程旅行各类活动，如“周五出逃计划”等，为用户提供更统一的体验。同时，提升机票、酒店、火车票等基础功能的能力，优化搜索引擎对一些复杂 query 的处理。此外，DeepTrip 计划后续还将接入更多模态。

DeepTrip 这类垂类旅行 Agent 的爆火说明，AI 在旅游行业大有可为。毫无疑问，AI 已经成为旅游行业必须拥抱的“游戏规则改变者”。但就目前而言，垂类旅行 Agent 仍处于进化阶段。

比如，在复杂需求的响应能力以及推荐内容的准确性等方面，Agent 仍有待进一步提升，甚至仍存在不少 bad case。但不可否认的是，部分案例已经展现出超越传统接口搜索引擎的优势，这也证明了垂类旅行 Agent 存在的价值。

展望未来，Agent 有望走到前台，直接与用户进行交互。而传统的接口和工具则会退居后台，由 Agent 进行调用。正如 Transformer 论文《Attention Is All You Need》的标题所言，Agent 的核心价值在于节省用户的“注意力成本”。注意力是人类的稀缺资源，AI 的价值正是帮我们高效分配它——而这，或许才是 Agent 技术的终极意义。

DeepTrip 体验地址

• 小程序：“同程旅行”小程序首页上方“程心 AI”入口，或小程序搜索“DeepTrip 智选”

• 网页端：https://deeptrip.ly.com/#/

同程旅行招聘邮箱（大模型应用与工程相关）

• wwr5406@ly.com