背景
毕业实习期间在大唐互联科技有限公司参与 AI 应用开发方向的工作。公司希望我独立负责一个完整的 AI 应用原型：既要覆盖用户、内容、审核、管理等常规业务系统，也要做出真正可用的 AI 对话体验，而不是简单的 API 转发。最终交付的 GoTravel 是一个面向旅游规划场景的智能平台。
问题定义
旅游咨询类对话有两个特点：一是需要真实数据支撑（地点、日期、天气等），纯靠模型记忆容易编造；二是回复内容适合结构化呈现（行程、酒店、餐厅卡片），纯文本列表阅读体验差。系统设计要解决的核心问题是：让大模型在对话中主动调用工具获取真实信息，并把结果以可交互的卡片形式流式地呈现给用户。
方案
AI 对话链路。以 DeepSeek 作为推理底座，用 LangGraph 编排对话工作流，管理对话状态与工具调用决策。外部工具通过 MCP（Model Context Protocol）客户端接入：高德地图 MCP 提供地理与 POI 查询，日期工具 MCP 提供时间计算。MCP 的价值在于工具的标准化接入——新增一个工具只需实现一个客户端，不需要改动工作流主干。
实时输出。对话不走普通 HTTP 请求-响应，而是 Django Channels + Redis Channel Layer 的 WebSocket 通道，模型 token 逐字推送到前端，配合打字机效果渲染。消息的发送、接收、阅读状态全程可追踪。
智能卡片。AI 回复中的推荐内容（行程、酒店、餐厅等）被解析为结构化数据，前端渲染成专门的卡片组件，用户可以一键保存到草稿箱，把“聊出来的攻略”变成自己的内容资产。
业务系统。用户侧覆盖注册登录、角色权限（普通/VIP/管理员）、关注与粉丝、行为记录；内容侧覆盖多类型帖子、审核流、点赞评论收藏；管理端提供用户管理、内容审核、聊天记录与 AI 工具执行监控、行为数据分析。数据库用 MySQL，Redis 做缓存与 Channel Layer，Celery 处理异步任务。
我的角色
独立负责从需求拆解、数据库设计、AI 服务层、WebSocket 通道到前端页面的全部实现。印象最深的一次调试是流式对话偶发断连：通过在 Consumer 中加全生命周期日志定位到 Redis 缓冲区在高频广播下的延迟问题，最终调整了消息批量推送策略解决。
结果
系统功能完整跑通，AI 助手能稳定完成地点查询、行程规划、预算估算等任务，流式输出与卡片生成体验流畅，通过了公司的实习验收。
复盘
这是第一个从 0 到 1 独立交付的完整 AI 应用，最大的收获是理解了“AI 应用 = 工程系统”，模型只是其中一个环节，状态管理、工具接入、实时通信、内容结构化，每一环都决定最终体验。后续博客里实现个人知识助手时，这套架构思路直接复用了。