1. 项目概述构建生产级智能行程规划Agent的挑战与机遇在当今AI技术快速落地的浪潮中行程规划作为典型的复杂决策场景正从传统的规则引擎向基于大模型的智能Agent演进。我最近主导的一个旅游平台智能化升级项目就深刻体会到从Demo到生产环境的巨大鸿沟。初期我们仅用3天就接入了大模型API实现基础对话功能但随后花了整整6周时间才让系统真正达到线上服务标准。这个过程中最关键的认知转变是真正的业务级Agent不是简单的问-答系统而是一个融合了上下文管理、工具调用、约束求解和异步处理的分布式状态机。以用户询问帮我安排上海三天两夜游为例背后涉及12个关键参数的提取、5个外部服务的协同调用、以及持续多轮的偏好协商。如果只是将对话历史无脑拼接到Prompt中不仅成本会呈指数级增长系统响应速度也会从最初的2秒恶化到15秒以上。2. 核心架构设计2.1 分层记忆系统实现2.1.1 会话工作记忆管理在我们的生产实践中采用Redis的Stream数据结构存储最近5轮对话配合TTL设置实现自动过期。关键实现代码如下public class RedisChatMemoryStore implements ChatMemoryStore { private final RedisTemplateString, Object redisTemplate; public void addMessage(String sessionId, ChatMessage message) { redisTemplate.opsForStream().add( chat:session: sessionId, Collections.singletonMap(content, serialize(message)) ); // 保持最近5条消息 redisTemplate.opsForStream().trim(chat:session: sessionId, 5, false); } }重要提示Stream相比简单的List结构更适合高并发场景其内部的分片机制可以有效避免热点Key问题。我们在压测中发现当QPS超过500时List结构的延迟会明显上升。2.1.2 用户画像记忆建模长期偏好存储采用Redis Hash结构设计时特别注意了字段的版本控制public class UserProfile { private String userId; private MapString, PreferenceCategory preferences; private String version v2; // 结构变更时升级 Data public static class PreferenceCategory { private String source; // explicit|inferred private LocalDateTime updateTime; private Object value; } }这种设计允许系统区分用户明确声明的偏好如不吃辣和系统推断的偏好如常选择4星级酒店支持灰度发布时的数据结构迁移通过version字段实现自动兼容处理2.2 工具调用层的工程实践2.2.1 统一工具接口设计我们抽象出ToolExecutor接口所有外部服务调用都通过该接口进行public interface ToolExecutor { ToolResult execute(ToolRequest request); String toolName(); default boolean isAvailable() { return true; } }典型实现如天气查询工具Slf4j public class WeatherToolExecutor implements ToolExecutor { private final WeatherApiClient client; private final CircuitBreaker circuitBreaker; public ToolResult execute(ToolRequest request) { WeatherRequest weatherRequest parseRequest(request); return circuitBreaker.run(() - { WeatherData data client.query(weatherRequest); return buildSuccessResult(data); }, fallback - buildFallbackResult(weatherRequest)); } }2.2.2 熔断与降级策略每个工具都配置独立的熔断器使用Resilience4j实现关键参数如下表所示参数天气服务POI查询路线规划失败阈值50% (10s窗口)40% (30s窗口)30% (1m窗口)等待持续时间30秒1分钟2分钟慢调用阈值800ms1.5s3s降级策略返回缓存返回精简结果切换算法3. 生产环境优化技巧3.1 Prompt工程实践3.1.1 动态模板组装我们发现直接拼接历史消息会导致模型注意力分散改为使用结构化模板你是一个专业的行程规划助手请根据以下信息为用户制定方案 # 用户基本信息 {{userProfileSummary}} # 当前会话目标 {{currentGoal}} # 最近3轮对话摘要 {{recentSummary}} # 已知约束条件 {{constraints}} 请按以下步骤思考 1. 检查信息是否完整缺失关键参数则提问 2. 调用相关工具获取最新数据 3. 生成包含时间、地点、预算的详细方案 4. 输出Markdown格式结果和结构化JSON通过A/B测试这种模板使平均对话轮次减少2.3轮Token消耗降低42%。3.2 性能优化方案3.2.1 异步处理流水线对于耗时操作我们设计了三阶段处理流程graph TD A[同步阶段] --|即时响应| B[返回初步确认] A --|异步任务| C[详细规划] C -- D[缓存中间结果] D -- E[Webhook通知] E -- F[客户端刷新]具体实现采用Spring的Async注解配合Redis Pub/SubAsync(planningExecutor) public void asyncGeneratePlan(PlanRequest request) { try { PlanContext context buildContext(request); publishProgress(request.getSessionId(), start); DayPlan[] plans new DayPlan[request.getDays()]; for (int i 0; i request.getDays(); i) { plans[i] generateDayPlan(context, i); publishProgress(request.getSessionId(), day- i); } redisTemplate.opsForValue().set( plan:result: request.getSessionId(), serialize(plans), Duration.ofHours(1) ); publishCompletion(request.getSessionId()); } catch (Exception e) { publishError(request.getSessionId(), e); } }3.2.2 缓存策略我们采用三级缓存架构本地缓存Caffeine存储高频访问的用户画像TTL5分钟分布式缓存Redis存储会话状态和临时结果TTL1小时持久化存储MySQL最终方案存档长期保存关键配置示例spring: cache: multi: local: spec: maximumSize1000,expireAfterWrite5m redis: timeToLive: 1h keyPrefix: plan:cache:4. 监控与治理4.1 可观测性设计我们搭建的监控看板包含以下核心指标指标类别具体指标报警阈值性能LLM P99响应时间3s成本每会话平均Token2000质量用户修正率30%稳定性工具调用错误率15%Prometheus配置示例- name: llm_metrics metrics_path: /actuator/prometheus static_configs: - targets: [ai-service:8080] relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - target_label: __address__ replacement: prometheus:90904.2 典型问题排查案例案例1记忆污染问题现象用户反馈系统突然忘记了之前确认的预算限制排查过程检查Redis内存使用率发现达到95%分析Key分布发现大量未设置TTL的临时Key追溯代码发现异步任务未正确清理中间状态解决方案为所有临时Key添加自动过期增加Redis内存监控实现状态清理钩子案例2工具调用雪崩现象雨天大量用户查询导致地图服务不可用根因分析天气工具超时设置过长5s未实施请求排队降级策略不完善优化措施引入Bulkhead模式限制并发添加二级缓存昨天数据预测数据实现智能降级算法5. 演进方向在实际运营中我们持续收集到以下改进需求多模态输出支持生成包含地图截图、景点图片的富媒体方案协作规划允许多人实时编辑同一行程动态调整根据实时交通、天气自动优化已生成方案个性化推荐基于用户历史行为推荐小众景点技术预研发现要实现这些能力需要升级到支持GPT-4级别的多模态模型引入Operational Transformation算法处理并发编辑搭建事件驱动的实时处理流水线完善用户行为埋点与分析体系一个典型的扩展架构如下graph LR A[客户端] -- B[API Gateway] B -- C[实时协作服务] B -- D[AI编排层] D -- E[记忆系统] D -- F[工具集市] C -- G[CRDT存储] F -- H[地图服务] F -- I[天气服务] F -- J[POI数据库]在实现这些高级特性时需要特别注意实时性与一致性的权衡多模态数据的存储成本复杂交互的调试工具链隐私与合规要求经过半年多的迭代我们的系统目前每天处理超过15万次规划请求平均响应时间控制在1.2秒以内用户满意度达到92%。这证明基于Spring AI构建生产级Agent是完全可行的关键在于从一开始就采用正确的架构模式和工程实践。