如果让你设计一个能行程规划的旅行Agent,你会如何拆解任务?各子Agent职责怎么划分
P1 · agent_architecture
🏷 标签：multi-agent, task-decomposition, travel-agent, orchestration
1️⃣ 考察意图
面试官想看你能否将模糊的“旅行规划”需求，拆解为可落地的多Agent系统架构。核心考察点：任务分解粒度（是否过度耦合或碎片化）、职责边界（子Agent是否职责单一、可复用）、协作与冲突解决（如何避免死锁或资源竞争）。刁钻点在于：旅行规划涉及大量实时约束（价格波动、时间冲突、用户偏好变化），答好了能展示你系统设计能力（如用协调Agent做仲裁）和工程取舍（如用共享记忆池 vs 直接通信）。这是P1进阶题，答出“为什么用这种架构而非另一种”才算过关。
2️⃣ 标准答
我会将旅行Agent拆解为三层架构：协调层、执行层、数据层。核心原则是职责单一（每个Agent只做一件事）和可插拔（子Agent可独立替换或扩展）。
2.1 协调层：TravelCoordinator（唯一入口）
- 职责：接收用户自然语言输入（如“带父母去东京5天，预算2万，喜欢文化景点”），解析出结构化约束（时间、预算、兴趣点、人数、特殊需求如轮椅友好）。
- 关键方法：用LLM做意图识别+槽位填充（slot-filling），输出JSON schema。为什么不用纯规则？用户输入多变，规则维护成本高，LLM能泛化。
- 坑：用户可能说“预算不限但别太贵”，需映射为“预算=中档”。解法：预定义预算等级（低/中/高）并让LLM映射，而非直接解析数字。
2.2 执行层：4个子Agent，各司其职
- DestinationAgent：基于用户兴趣（如“文化景点”）和预算，调用Google Places API或TripAdvisor API，返回候选城市+必去景点列表。Trade-off：用BM25做关键词匹配 vs 用embedding做语义检索？选后者，因为用户说“文化”可能指“寺庙”或“博物馆”，语义检索更准，但需预计算景点embedding并存入向量数据库（如FAISS）。
- HotelAgent：接收目的地+预算+人数，调用Booking API或Expedia API，过滤出符合价格区间、评分>4.0、距离景点<5km的酒店。坑：API返回价格可能不含税，需在Agent内加税计算逻辑，否则用户预算超支。
- TransportAgent：处理航班/火车/租车。关键约束：时间窗口（如“上午到达”）、预算、中转次数。解法：用A*搜索路径，代价函数=价格+时间权重（用户可调）。
- ItineraryAgent：将景点、酒店、交通按时间线排列，生成每日行程。核心挑战：避免“上午去A下午去B但A和B距离2小时车程”的冲突。解法：用约束满足问题（CSP） 建模，每个活动是变量，时间/距离是约束，用回溯搜索求解。Trade-off：CSP保证最优解但计算量大，可设超时阈值（如2秒），超时则用贪心算法（按距离排序）。
2.3 数据层：共享记忆池（Shared Memory Pool）
- 结构：Redis或内存数据库，存储所有Agent的中间结果（如目的地列表、酒店候选、行程草稿）。为什么不用Agent间直接通信？避免循环依赖（如HotelAgent等TransportAgent结果，TransportAgent又等HotelAgent），共享池解耦。
- 更新机制：每个Agent写结果时加时间戳，协调Agent定期检查一致性。坑：并发写导致脏数据。解法：用乐观锁（版本号），写前检查版本是否被更新。
2.4 冲突解决：协调Agent的仲裁逻辑
- 典型冲突：HotelAgent推荐酒店A，但ItineraryAgent发现A离景点B太远，导致每天多花1小时通勤。
- 解法：协调Agent启动重规划循环。步骤：1）计算冲突代价（如通勤时间>30分钟/天）；2）给HotelAgent发“软约束”（如“优先选景点B附近”）；3）HotelAgent重新过滤，返回新候选；4）ItineraryAgent重新排程。最多重试3次，否则返回次优解并告知用户。
- Trade-off：重规划增加延迟，但提升满意度。实测中，80%冲突可在1次重试内解决（基于模拟数据）。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从架构分层、子Agent职责、冲突解决三个层面回答。架构上，我采用协调层-执行层-数据层三层，协调层负责解析用户意图，执行层有4个职责单一的子Agent（目的地、酒店、交通、行程），数据层用共享记忆池解耦。冲突解决由协调Agent发起重规划循环，最多3次。总结一句：核心是职责单一+共享记忆+仲裁机制，保证可扩展和鲁棒。”
4️⃣ 高频追问 & 应对
追问 1：如果用户中途改变主意（比如从“文化景点”改成“购物”），你怎么处理？
设计增量更新机制。协调Agent检测到意图变化后，不重新跑全流程，而是：1）标记受影响Agent（DestinationAgent需重新搜索，HotelAgent可能需换区域）；2）只让这些Agent重新计算，其他Agent（如TransportAgent）保留已有结果；3）ItineraryAgent基于新结果做局部调整（如替换某天行程）。这样延迟从秒级降到毫秒级。坑：需维护依赖图（DAG），避免级联更新。
追问 2：如何评估这个旅行Agent的好坏？给具体指标。
分三层：1）任务完成率：用户是否获得可执行的行程（如酒店可预订、时间不冲突），目标>90%；2）用户满意度：用NPS（净推荐值）或5分制评分，目标>4.0；3）系统效率：端到端延迟<5秒，重规划次数<2次。此外，可做A/B测试：对比纯LLM生成 vs 多Agent架构，看哪个在约束满足上更优（多Agent通常高20%）。
追问 3：如果子Agent返回空结果（比如目的地无可用酒店），怎么办？
协调Agent执行降级策略：1）放宽约束（如预算+20%、评分>3.5）；2）通知用户并请求确认；3）如果仍无结果，返回“无法满足，建议调整目的地”。坑：不能无限放宽，否则用户觉得不靠谱。设硬边界（如预算上限为原始2倍），超限则报错。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“让一个Agent做所有事，比如用LLM直接生成行程” → ✅ 正确做法是拆分子Agent，因为LLM无法保证约束满足（如时间冲突），且无法调用实时API。
- ❌ 说“子Agent间用自然语言对话协商” → ✅ 正确做法是用结构化数据（JSON）通过共享池交换，自然语言对话延迟高且易误解。
- ❌ 说“冲突时直接报错让用户自己解决” → ✅ 正确做法是自动重规划，只在无法解决时告知用户，提升体验。
6️⃣ 简历呼应
- 如果你有RAG项目：从“检索增强”角度切入，说DestinationAgent类似检索器（用embedding召回景点），ItineraryAgent类似生成器（用CSP排程），共享记忆池类似向量数据库。
- 如果你只做过传统NLP：用“管道（pipeline）架构”类比，说每个子Agent是管道中的一个模块，输入输出是结构化数据，类似信息抽取中的NER+关系抽取。
- 如果你是校招无项目：聚焦论文复现，说参考了“ReAct”模式（Agent思考-行动-观察循环），并简化实现了一个3-Agent原型（目的地、酒店、行程），在模拟数据上验证了可行性。
7️⃣ 延伸阅读
- 《ReAct: Synergizing Reasoning and Acting in Language Models》
- 《AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation》
- 《Constraint Satisfaction Problems in AI》（Russell & Norvig, AIMA 第6章）
- LangGraph官方文档：Multi-Agent Supervisor模式
- Google Places API + Booking API 集成实战博客（Medium系列）