$ show 1sdv/TripStar
TripStar is a full-stack, multi-agent AI travel planning platform. It uses a FastAPI backend with a modular agent system (trip planner, weather, hotel agents) orchestrated by a large language model, and a Vue 3 + TypeScript frontend with a dark glassmorphism UI. The backend provides REST APIs and WebSocket real-time status updates for asynchronous trip generation tasks. It integrates data from multiple sources: Xiaohongshu (via reverse-engineered signed API and SSR scraping), Google Maps, and AMap (with automatic fallback). The LLM extracts structured attractions from scraped text, plans itineraries, and repairs malformed JSON output. The system also includes user preference memory with weighted decay and TOP-K recall, a knowledge graph module, and export to image/PDF. The frontend features interactive maps, a budget panel, multi-city support, and a floating AI chat widget. The application is Dockerized with a multi-stage build and supports Chinese, English, and Japanese through i18n. The architecture is cleanly separated into backend services (agents, API routes, memory, map dispatcher, scraper), and frontend views (Home, Landing, Result, AIChat). The map dispatcher pattern provides a unified interface for geocoding and POI search across Google and AMap, and the memory manager implements a reusable preference-learning system. However, the codebase has technical debt: heavy reliance on Xiaohongshu's undocumented API (fragile), a monolithic 42k-token CSS file from Paper Kit 2 (2017) with deprecated techniques, and a complex ~2000-line Result.vue component. Dependencies are not fully locked, and the scraper's JavaScript signature engine may break with anti-bot updates. Overall, TripStar is a solid, functional application with several reusable patterns, but it carries moderate maintenance risks due to its external dependencies and some aging code. Note: This is a hybrid application with a strong data-crawling component (Xiaohongshu scraping and LLM extraction), but the dominant character is a production-ready web application with a clear user interface and API.
The LLM identified 3 files worth highlighting for reuse:
Provides a unified interface for geocoding, POI search, and weather data across Google Maps and AMap. Automatically selects the active provider based on configuration and falls back to the alternative on failure. Decouples business logic from map provider implementation, making it easy to add new providers. Could be extracted as a reusable library for any multi-map application.
Manages per-user preference memory with weight decay, merging of repeated preferences, and TOP-K recall. Injects preferences into agent prompts via a singleton pattern. The logic is self-contained and could be reused for any personalization system requiring temporal decay and prioritization of user preferences.
Contains a multi-layer JSON repair pipeline (_sanitize_json_str, _fix_unescaped_quotes, _repair_truncated_json, _llm_repair_json) that handles common LLM output errors. This is a highly reusable pattern for any application that relies on LLM-generated structured data, especially when dealing with unreliable or malformed JSON.