基于多智能体LLM的可持续旅行推荐系统TRACE设计与实现

1. 项目概述：一个能“劝”你环保旅行的智能聊天机器人

如果你和我一样，既热爱探索世界，又对过度旅游带来的环境压力感到不安，那么每次规划行程时，内心多少会有些纠结。传统的旅行推荐，无论是OTA平台还是社交媒体的种草，核心逻辑几乎都是“什么火推什么”，算法拼命把我们往巴黎、罗马、京都这些热门地赶，结果就是人挤人、物价飞涨、当地生态不堪重负。我们真的没有更优的选择吗？

最近，我和团队深入研究了慕尼黑工业大学等机构在SIGIR‘26上发布的一个开源项目：TRACE。这不仅仅是一个旅行推荐聊天机器人，更是一个精巧的、由多个大语言模型智能体驱动的“可持续旅行顾问”。它的目标很明确：在不强迫、不说教的前提下，通过一场自然的对话，巧妙地引导你发现那些同样精彩但更环保、更小众的目的地。想象一下，当你输入“想去一个欧洲的海边城市度假”，它不会直接甩给你巴塞罗那，而是会先问你几个问题，比如“是否愿意为了更独特、人更少的体验，尝试一个不那么知名的地方？”，然后根据你的回答，向你推荐瓦伦西亚，并告诉你：“这里也有很棒的海鲜饭和夜生活，但相比巴塞罗那，它能给你更地道的、不那么拥挤的体验。” 这就是TRACE在做的事情——将可持续性作为一种可协商的偏好，融入对话的每一个环节。

这个框架的价值，远不止于做一个“绿色版”的旅行助手。它实际上为我们提供了一个可复现的蓝本，展示了如何用当前最前沿的多智能体LLM技术，去解决推荐系统中一个经典的“价值观对齐”难题：如何在满足用户显性需求（如预算、兴趣）的同时，潜移默化地促进更负责任的消费行为？接下来，我将结合论文与开源代码，为你深度拆解TRACE的设计精髓、实现细节，并分享我们在复现和思考过程中收获的经验与坑点。

2. 核心设计思路：模块化智能体如何协同“说服”

TRACE的聪明之处，在于它没有把“可持续”作为一个生硬的过滤条件，而是将其设计成一套由多个专业智能体（Agent）协作完成的、动态的推理流程。这就像组建了一个专业的旅行顾问团队，每个成员各司其职，共同完成一次个性化的咨询服务。

2.1 Orchestrator-Worker架构：清晰的三层分工

整个系统的骨架是一个典型的三层微服务架构，职责分离得非常清楚：

1. 用户交互层（前端）：基于Chainlit构建的聊天界面。它负责最表层的自然语言交互，收集用户最初的查询和后续对澄清问题的回答。它的目标是让对话体验流畅自然。
2. 编排层（中间件）：这是系统的大脑和中枢神经，用一个中央协调器（Orchestrator）实现。它不直接处理复杂的推理，而是负责会话状态管理（用了Google Firestore进行持久化）、控制流逻辑，以及根据对话阶段，调度不同的智能体工人（Worker）来干活。它确保整个对话流程有序推进。
3. 智能体推理层（后端）：这是系统的肌肉，由四个专门的LLM智能体组成，基于Google的Agent Development Kit (ADK)在Vertex AI上构建。它们才是真正干活、动脑筋的“专家”。

这种架构的好处显而易见：高内聚、低耦合。每个智能体可以独立开发、测试和优化；编排层让整个流程可控；前端则可以灵活替换。对于想要复现或基于此进行二次开发的团队来说，这种设计极大地降低了复杂度。

2.2 四大智能体的角色与协作流程

整个对话推荐过程，被形式化为一个在用户会话状态空间上的顺序转换管道。我们来扮演一次用户，走一遍这个流程，看看每个智能体是如何工作的：

第一步：意图澄清与用户画像构建（由ACQ和AIC智能体完成）当我输入“我和男朋友想去欧洲找个湖边或海边的地方度假，有什么推荐吗？”这个初始查询后，系统并不会急于给出答案。

• 澄清问题智能体（ACQ）首先登场。它的任务不是闲聊，而是进行有目的的探查。它会生成最多5个有针对性的澄清问题，例如：

  • “这次旅行的预算是多少？（例如经济型、中档、豪华）”
  • “除了湖边或海边的景色，您还希望有什么样的活动或氛围？（例如夜生活、美食体验、安静放松）”
  • 关键一击：“您是否愿意为了获得更独特、更少拥挤的体验，尝试一个不那么知名的湖边或海边地点？” 最后一个问题至关重要，它是间接探询用户对可持续性（具体表现为“去过度旅游化”）妥协意愿的钩子。ACQ的设计提示词（Prompt）被精心构建，以确保问题既覆盖旅行规划的基本面（预算、兴趣），又必然包含可持续性维度的探询。

• 意图分类智能体（AIC）在我回答了所有问题后接手。它就像一个分析师，将我和机器人的这段对话文本（初始查询+我的所有回答）进行消化理解，并输出两个结构化的结果：

  • 结构化用户旅行画像：例如，“一对寻求浪漫欧洲度假的情侣，钟情于湖畔或海滨目的地，重视美食和夜生活，偏爱中档至豪华旅行，看重地道、小众、人少的体验。”
  • 妥协意愿向量：这是一个量化的指标，表示我在“碳排放”、“拥挤度”、“季节性”等可持续性维度上，愿意做出妥协的程度。比如，我对“拥挤度”妥协意愿很高，但对“交通方式”（是否愿意放弃飞机坐火车）妥协意愿较低。

实操心得：智能体提示词工程是关键在复现时，AIC智能体的提示词设计是难点也是重点。你需要明确告诉LLM：1）需要从对话中提取哪些结构化字段（如旅行类型、预算、兴趣点）；2）如何定义和量化“妥协意愿”。论文中采用了类似评分的方式，例如，用户回答“当然愿意”可能对应高分，模棱两可的回答对应中分，明确拒绝则对应低分。这部分逻辑需要固化在给AIC的少样本提示（Few-shot Prompt）中，确保其输出稳定、可解析。

第二步：双路径推荐生成（由ARec智能体完成）拿到我的画像和妥协意愿后，推荐智能体（ARec）会同时走两条路，生成两套候选推荐：

• 基线推荐集：只考虑我的原始查询和基本偏好，以“相关性”为最高准则。这模拟了传统推荐系统的行为，结果很可能指向巴塞罗那、阿姆斯特丹这类超级热门地。
• 可持续推荐集：在满足我基本偏好的前提下，融入从对话中推断出的可持续性信号。例如，我的画像中提到了“看重小众体验”，妥协意愿向量显示“拥挤度”妥协意愿高，那么系统就会优先推荐那些符合我兴趣（有美食夜生活的海滨城市）但相对冷门、游客压力小的目的地，比如瓦伦西亚、里斯本（相比巴塞罗那）或意大利的五渔村（非旺季时）。

第三步：说服性解释与最终决策（由AEG智能体完成）这是TRACE最具创新性的环节。解释生成智能体（AEG）扮演了最终决策者和沟通者的角色。它接收前两步的所有信息（两套推荐、我的用户画像、妥协意愿向量），并输出三项内容：最终推荐、解释文案、一个反事实替代方案。

它的决策逻辑基于我的“妥协意愿”动态切换，堪称一场精妙的沟通策略选择：

• 策略一：直接对齐。如果我的妥协意愿向量显示，我在某些可持续维度上持开放态度（比如明确表示愿意去人少的地方），那么AEG会果断选择可持续推荐集中的目的地作为最终推荐。它的解释文案会重点强调这个选择带来的可持续性收益，例如：“为您推荐瓦伦西亚。它同样拥有迷人的海滩、 vibrant的美食和夜生活，但相比巴塞罗那，它能提供更独特、更少拥挤的地中海体验，这正符合您对‘小众体验’的重视。”
• 策略二：反事实助推。如果我的妥协意愿向量显示，我对可持续性相关妥协比较抗拒（比如坚持要去“最出名、最经典”的地方），那么AEG会以不破坏用户信任为首要原则。它会选择基线推荐集里的热门目的地作为最终推荐。但是，它不会就此罢休！它会同时生成一个反事实解释，提供一个可持续推荐集里的替代方案。解释的措辞会是条件式的、启发式的，例如：“根据您的偏好，我们为您推荐巴塞罗那。同时我们也注意到，如果您对降低环境影响、体验更原生态的当地文化感兴趣，瓦伦西亚会是一个出色的替代选择，因为那里游客相对较少，能更好地感受本地生活氛围。” 这种“如果……那么……”的句式，就是反事实解释的核心。它没有否定用户当前的选择，而是巧妙地拓宽了用户的选项视野， planting a seed for future consideration，实现了“非强制性的助推”。

3. 技术实现深度解析与复现指南

理解了设计理念，我们来看看如何把它从论文变成代码。TRACE团队选择了Google Cloud生态作为技术栈，这是一个非常务实且高效的选择。

3.1 技术栈选型与架构部署

• LLM与智能体框架：Google Vertex AI + Agent Development Kit (ADK) + Gemini 2.5 Flash。选择Gemini Flash模型是因为它在响应速度与成本间取得了良好平衡，适合多轮、多智能体的串联调用。ADK则提供了构建、编排和管理智能体的标准化工具，大大简化了开发流程。
• 后端与编排：FastAPI。这是一个高性能的现代Python Web框架，非常适合构建API驱动的中间件。中央协调器（Orchestrator）就是一个FastAPI应用，它接收前端请求，按顺序调用各个智能体服务，并管理会话状态。
• 状态持久化：Google Cloud Firestore。这是一个NoSQL文档数据库。为什么不用内存？因为需要持久化会话状态（用户查询、生成的用户画像向量、妥协意愿值），以便在对话中断或长时间对话中保持上下文。Firestore与GCP其他服务集成性好，适合此类应用。
• 前端：Chainlit。这是一个专门为构建LLM聊天应用设计的开源框架，类似于Gradio但更专注于对话交互。它可以轻松创建包含聊天历史、复杂消息类型（如卡片、按钮）的界面，非常适合TRACE这种需要逐步澄清问题、展示对比推荐的场景。
• 部署：Docker容器化 + Google Cloud Run。将整个应用（前端、后端、依赖）打包成Docker镜像，部署到Cloud Run上。Cloud Run是Serverless的，意味着你不需要管理服务器，它可以根据流量自动缩放，并且只在处理请求时计费，对于这种间歇性使用的对话应用来说成本效益很高。

避坑指南：Chainlit的安全性与版本锁定论文中提到，因为2026年1月21日发现的一个Chainlit安全漏洞，他们的线上演示应用暂时下线了。这给我们提了个醒：在复现或生产中使用开源框架时，必须密切关注其安全公告，并考虑锁定依赖版本。在本地开发或部署时，建议使用经过验证的、稳定的版本，并确保网络隔离。此外，对于关键业务逻辑，要有绕过前端直接测试后端API的能力。

3.2 核心智能体的提示词设计剖析

智能体的“智商”高低，很大程度上取决于给它的“工作说明书”——也就是提示词。TRACE的提示词设计是其成功的关键。

1. 澄清问题智能体（ACQ）提示词要点：

   • 角色定义：“你是一个专注于可持续旅行的专业顾问。”
   • 核心指令：“根据用户查询，生成最多5个澄清问题。问题必须涵盖：1. 旅行基本要素（预算、兴趣、时间）。2.至少一个旨在探索用户对‘小众目的地’、‘低碳交通’或‘本地体验’接受度的问题，以评估其可持续旅行妥协意愿。”
   • 输出格式：严格要求以JSON列表格式输出问题，方便后端解析。
   • 护栏设置：通过少样本示例，明确限制推荐范围仅为“欧洲单一城市旅行”。对于超出范围的查询（如“推荐周末电影”），要求智能体礼貌地拒绝并引导回主题。

2. 意图分类智能体（AIC）提示词要点：

   • 输入：完整的对话历史。
   • 任务：“分析对话，提取结构化用户画像，并评估其在‘目的地拥挤度’、‘交通方式碳排放’、‘旅行季节性’三个维度上的妥协意愿，每个维度评分1-5分。”
   • 结构化输出模板：提供明确的JSON Schema，要求输出必须包含user_profile(文本描述)、willingness_to_compromise(字典，包含各维度分数) 等字段。这是后续智能体能正确工作的前提。

3. 解释生成智能体（AEG）提示词要点：

   • 输入：两套推荐、用户画像、妥协意愿分数。
   • 决策逻辑内化：在提示词中明确写入决策规则：“如果‘拥挤度’妥协意愿分数>=4，则选择可持续推荐作为主推荐，并生成强调其小众、独特性的解释。否则，选择基线推荐作为主推荐，并为可持续推荐生成一个以‘如果您也考虑……’开头的反事实解释。”
   • 解释风格要求：要求解释必须友好、信息丰富、具有说服力，并直接引用用户画像中的关键词（如“您提到喜欢小众体验”）。

3.3 会话状态管理与智能体间通信

在多轮对话中，保持上下文一致至关重要。TRACE的实现方式很典型：

1. 每个用户会话在Firestore中有一个唯一文档ID。
2. 编排器在收到用户消息后，首先从Firestore加载该会话的完整历史（包括之前的查询、已回答的问题、已生成的用户画像等）。
3. 编排器根据当前对话阶段（是首次提问、回答澄清问题、还是请求新推荐），决定调用哪个智能体，并将完整的上下文会话历史作为输入的一部分传递给智能体。
4. 智能体处理完成后，输出的结果（如新的澄清问题、生成的用户画像、最终推荐）会被更新回Firestore中该会话的文档里。
5. 前端从编排器获取响应，并展示给用户。

这种设计确保了无论对话进行到哪一步，每个智能体都能基于完整的对话历史做出决策，避免了信息割裂。

4. 效果评估与实战中的挑战

论文通过用户研究和语义对齐分析验证了TRACE的有效性，这些数据背后反映出的设计哲学，对我们构建类似的交互系统极具启发性。

4.1 用户反馈揭示了什么？

在107次有效对话中，有79.1%的用户最终选择了系统给出的主推荐。而这其中，有75.5%的会话里，主推荐就是那个更可持续的选项。这说明，当系统通过对话巧妙地探知到用户的开放态度后，其推荐的可持续选项接受度非常高。

更有意思的是，在那些用户妥协意愿较低、系统因此将热门目的地作为主推荐的会话中，仍有16.7%的用户主动选择了作为替代方案出现的可持续选项。这证明了反事实解释策略的有效性——它确实能在不引起反感的情况下，让一部分用户重新考虑自己的选择。

超过60%的用户报告说，这次交互让他们“重新考虑”了最初的选择。这达到了TRACE设计的核心目标：促进反思，而非强制改变。

4.2 系统内部对齐的量化验证

为了确保智能体们“心往一处想”，论文采用了语义相似度度量。他们使用sentence-transformers库中的all-MiniLM-L6-v2模型，计算了不同环节文本之间的余弦相似度。

• 解释与对话的相似度高达0.70，说明生成的解释确实紧扣了之前的聊天内容，不是凭空捏造。
• 用户画像与对话的相似度高达0.79，说明AIC智能体准确地从对话中提炼出了用户意图。
• 解释与用户画像的相似度也有0.74，这表明AEG智能体在生成解释时，确实是以结构化用户画像为依据的。

这些高相似度分数验证了管道中信息传递的一致性，说明整个多智能体系统在语义上是连贯的、对齐的。

4.3 性能与延迟：现实世界的考量

多智能体系统的一个常见担忧是延迟。TRACE在澄清问题阶段之后，生成完整推荐和解释的平均延迟是23秒，最长38秒。这个时间对于一次复杂的旅行规划对话来说，是可以接受的，类似于等待人工客服为你详细查询和撰写建议。论文也提到，这个速度与当前其他多智能体框架相比具有竞争力。这得益于其模块化设计，使得一些步骤可以并行化或优化。

4.4 可持续性悖论与未来挑战

TRACE的设计也引发了一个更深层次的思考，论文中称之为“可持续性悖论”：如果我们成功地将大量游客从巴塞罗那“助推”到了瓦伦西亚，那么瓦伦西亚会不会成为下一个巴塞罗那，从而只是转移了过度旅游的问题，而非解决了它？

这是一个非常深刻的洞见。它指出了当前基于静态数据或单一用户视角的推荐系统的局限性。未来的可持续推荐系统，可能需要：

• 动态数据集成：实时接入目的地承载力数据、酒店入住率、航班碳排放指数、社交媒体实时人流热度等。
• 群体智能与博弈：不仅考虑单个用户的偏好，还要模拟推荐策略对目的地群体的潜在影响，实现某种意义上的“流量调度”。
• 自适应策略：当系统检测到某个小众目的地热度快速上升时，能自动调整推荐策略，转而推荐其他潜力地点。

5. 复现与拓展：从理论到实践的步骤

如果你想亲手搭建一个类似的系统，或者基于TRACE的思想做自己的项目，以下是一个可行的路线图：

第一步：环境搭建与基础服务配置

1. 在Google Cloud Platform上创建项目，启用Vertex AI, Cloud Run, Firestore API。
2. 申请API密钥，配置好计费和服务账号权限。
3. 本地安装Docker，Python环境建议使用3.10+。

第二步：克隆代码与理解结构TRACE的代码是开源的。克隆仓库后，重点研究以下几个目录：

• agents/：包含了四个核心智能体的具体实现（通常是Python类或函数），以及它们的提示词模板。这是核心逻辑所在。
• orchestrator/：FastAPI应用的主要代码，定义了API端点和智能体调用流程。
• frontend/：Chainlit应用的界面代码。
• docker-compose.yml和Dockerfile：定义了容器化部署的配置。

第三步：本地开发与调试

1. 在本地.env文件中配置你的GCP凭证和Vertex AI模型参数（如使用gemini-1.5-flash替代gemini-2.5-flash，因为后者可能尚未广泛可用）。
2. 使用docker-compose up在本地启动服务。这会构建并运行所有容器。
3. 通过localhost:8000访问Chainlit前端，开始测试对话。
4. 关键调试点：使用日志详细记录每个智能体的输入和输出。特别关注AIC输出的JSON格式是否严格符合预期，以及AEG的决策逻辑是否正确触发。

第四步：定制化与拓展这是最具创造性的部分。你可以：

• 更换领域：将“可持续旅游”换成“可持续消费”、“绿色金融产品推荐”。你需要重新定义“可持续性”的维度（如产品碳足迹、企业ESG评分），并设计相应的澄清问题和妥协意愿向量。
• 丰富智能体：增加一个“信息验证智能体”，在推荐前调用外部API（如Tripadvisor、Skyscanner）验证目的地开放时间、实时价格。
• 优化解释风格：针对不同文化背景的用户，设计不同说服策略的解释模板。例如，对某些用户群体，数据（如“预计减少碳排放XX公斤”）可能比情感描述（“更独特的体验”）更有说服力。
• 解决悖论：尝试集成简单的动态数据源，比如从公开API获取城市实时游客指数，让推荐逻辑具备初步的“防过热”能力。

最后一点个人体会：TRACE项目最打动我的，不是它用了多少酷炫的技术，而是它体现了一种负责任的技术设计观。它没有试图用算法“教育”用户，而是通过精巧的对话设计，将选择权和反思的空间还给用户。在AI能力日益强大的今天，如何让技术不仅“有用”，而且“向善”，引导更可持续的生活方式，TRACE为我们提供了一个扎实的、可操作的范例。它的开源，更是一次慷慨的邀请，邀请我们所有人一起，思考并构建更具同理心和责任感的智能系统。