01
一张图管理整个规划过程
- 问题
- 旅行规划不是一次文本生成，而是需求补全、工具采集、行程设计和质量验证的连续状态变化。
- 动作
- 用 8 个 LangGraph 节点、26 个 State 字段和 3 条条件路由组织流程，并以 checkpoint 保存会话状态。
- 价值
- 每个阶段的输入、输出和失败路径可以追踪，前端也能展示当前执行进度。
← 返回项目总览
02 · 本科毕业设计 · 独立全栈开发
洛阳智能旅游系统
用 MCP 标准化工具能力，让 Agent 调用、校验并修正行程。
一个基于 LangGraph 的单协调器、多节点旅行规划 Agentic Workflow：地图、天气、路线和文旅检索能力封装为 MCP Server 工具，模型组织需求与行程，确定性规则负责检查结果。
交付状态完成真实高德与 DashScope 链路验证
本人职责
独立完成需求分析、后端、Agent 工作流、前端与地图、模型服务联调。
核心交付
将地图与文旅能力封装为 MCP Server 工具，接入可追踪工作流并生成带路线信息的逐日行程。
工程重点
规则检查时间与路线，校验失败后携带原因有限重规划；服务失败时标记估算结果。
核心使用流程
从输入到结果，每一步都承担明确职责
- 01
理解需求
协调器分析天数、预算、兴趣和必去地点，缺少关键条件时先追问。
- 02
调度工具
地图、天气、路线与文旅检索能力以 MCP Server 工具对外暴露，协调器完成选择、参数校验和执行。
- 03
设计行程
结合工具结果和本地知识资料生成逐日安排，并补全相邻活动路线。
- 04
校验与修正
规则检查开放时间、时间冲突和路线合理性；失败原因回到规划节点，默认最多修正 2 次。
关键实现
业务问题、技术方案与实现结果
02
把地图与文旅能力封装成 MCP 工具
- 问题
- POI、天气、路线与本地知识检索分散在不同服务中，直接耦合在规划节点里难以复用和治理。
- 动作
- 将 9 项地图与文旅能力封装为 MCP Server 工具，统一输入输出和错误边界；协调器侧保留参数校验、执行历史和最多 15 步的工具循环。
- 价值
- 规划流程可通过标准化工具接口组合外部能力，也便于独立测试、替换数据源和复用。
03
提示词之外，再加一层规则门禁
- 问题
- “写得像攻略”不代表时间不冲突、路线不绕行或开放时间可行。
- 动作
- 用 16 个校验方法、21 个约束编号检查方案，并把具体失败原因映射为修复指令回传规划节点。
- 价值
- 不合格方案进入有限重规划；达到上限仍保留风险说明，而不是无限循环或假装通过。
界面证据
经过脱敏的真实运行界面
我的职责
我负责的工作与交付内容
本科毕业设计，由本人独立完成需求分析、产品结构、后端、AI 工作流、前端与外部服务联调。
完成过高德地图与 DashScope 真实链路运行，静态展示使用脱敏合成数据。
项目用于证明 LangGraph 状态编排、MCP 工具化、规则校验和失败重规划，而不是多个自治 Agent 协作。
实现取舍
真实与估算
高德路线成功时保留道路路径，失败时用 Haversine 估算并显式标记，不把估算伪装成实时导航。
停止条件
重规划有明确上限；超过次数后以带风险状态结束，防止图循环失控。
引用边界
RAG 保存来源元数据，但当前不是逐句 citation 闭环。
实现范围与运行说明
- 系统是单协调器、多节点工作流，不是多个自治 Agent。
- MCP 负责工具服务化与标准化暴露；规划器内部的模型决策仍是结构化协议与应用层执行，不包装成原生 Function Calling。
- 不声称实时人流、实时票价、全局最优路线、生产上线或规划准确率。
Evidence-based Q&A
继续核验这段经历
直接追问职责、取舍、失败处理和能力边界。回答只使用已确认可公开的项目证据，并提供对应页面来源。
继续了解