上上个周五我在工位上盯着日历发呆。手头有个两天的空档加上周末刚好凑出三天。研究了大半年MCP协议一直停留在demo和概念验证的层面总觉得不过瘾。我打算用这三天逼自己一把做一个能真跑起来的AI旅游规划产品并且上线到公网让朋友也能真用上。最终结果就是这个标题——一个人3天用MCP做了一个AI旅游规划产品并上线。这里核心的MCP是Model Context Protocol模型上下文协议它让大模型不只会陪你聊天还能真正去调外部工具、读外部数据、执行具体任务。我做的产品说白了就是一个AI旅游规划助理你告诉它想去哪、玩几天、有什么偏好和预算它自己查景点、查天气、查路线然后生成一份完整行程单。这篇文章不是来炫技的更不是来推销哪个框架的。我想把整个项目的真实链路写出来为什么押注MCP、三天时间怎么分配、MCP Server从零怎么搭、旅游规划的每个能力怎么拆成工具、最后怎么接上AI客户端并部署上线以及中间踩过的一堆坑。如果你也对MCP感兴趣想用它快速做个AI Agent应用这篇应该能让你少走很多弯路。1. 为什么押注MCP与其教AI背攻略不如让它自己动手查1.1 传统对话式AI的硬伤先聊聊背景。当时摆在面前的有两条路一条是传统的大模型提示词把旅游攻略写进提示词里让AI照着输出另一条是大模型工具调用让AI自己去查实时景点信息、天气、门票价格。传统方案最明显的毛病就是一本正经地胡说八道。你说想去成都吃三天它可能给你编一个锦里夜市凌晨三点还有小吃的离谱路线。真让它规划行程它连景区是否临时闭园、这几天下不下雨、地铁通没通都不知道。旅游规划恰恰是实时信息密度特别高的场景没有一个工具层去对接外部数据源AI的回答就只能停留在看起来合理的幻想层面。我当时就把需求定死了这个产品必须让AI伸手去查数据。它要能在生成行程之前自己完成景点检索、天气查询、城市信息读取这些动作。这就要求大模型和外部系统之间有一条标准的、可靠的通道。1.2 MCP到底解决了什么——它是AI世界的USB-C说到通道就不得不提MCP协议。我把它类比成USB-C接口以前每个设备都有自己的充电口你出门得带一堆线USB-C统一之后一根线通吃。MCP做的事情类似只不过它统一的是大模型和外部工具之间的插口。在没有MCP之前你要让AI调一个工具得给每个客户端单独写一套function calling适配代码。接Claude写一套接GPT写一套接本地模型又得重写。这在项目规模小的时候还能忍但一旦工具多了、客户端多了维护成本直接起飞。MCP的解决方案很直接规定一个标准的客户端-服务端模型。MCP Server负责把能力以统一格式暴露出来MCP Client负责把大模型连接到这些服务端。你写一次ServerClaude Desktop能用、Codex能用、Dify能用、自己写的Web应用也能用。这就是我最终选择它的核心理由——我不想给每个AI客户端单独适配一遍。如果你对协议本身还有疑问这里顺便说清楚MCP是软件层面的应用层协议和HTTP、WebSocket是同一个范畴的概念不是硬件协议。它基于JSON-RPC 2.0的消息格式来通信。底层传输可以走stdio本地进程管道也可以走Streamable HTTP远程网络后面我会说到这两种方式的选择。1.3 为什么不直接裸调API你可能会问我不就是查个景点和天气吗直接在代码里requests调第三方API然后拼进提示词再调大模型不就行了为什么要套一层MCP这就要回到Agent的本质了。在静态代码里调用哪个API、传什么参数、返回结果怎么用全是你写死的。用户稍微换个问法比如预算2000以内、不想太累、带孩子去你的代码逻辑就得跟着改。而MCP的方案是大模型自己在对话过程中动态决定调什么工具、按什么顺序调、怎么根据返回结果调整下一步。这带来的变化是产品逻辑不再是if用户提到预算then调用预算计算器而是AI理解了用户意图主动去调用景点检索、天气查询、路线规划这些工具再进行综合推理。这就是AI Agent的范式。MCP在这里扮演的角色就是让主动调用这件事变得标准化、可扩展。后面几章我会按时间顺序讲整个实现过程先从我那三天是怎么安排的说起。2. 三天倒计时怎么把需求砍到只剩核心闭环2.1 第1天定边界、选技术栈、搭Server骨架三天的项目最怕的不是写不完是第一天就开始纠结要不要做个App、要不要上React Native。所以第一天上午我直接把产品边界钉死只做Web端的对话式行程规划不做独立App不做用户系统不做支付。功能层面我只保留四个核心能力目的地信息查询、兴趣点检索、天气查询、行程生成。什么机票比价、酒店预订、社区游记统统砍掉。这个决定非常关键。很多人做AI产品失败不是因为功能太少而是因为功能太多最后连闭环都跑不通。技术栈我选了Python这一侧做MCP Server。原因有两个一是FastMCP框架写起来非常轻量装饰器一注册就是一个工具二是Python处理JSON、请求第三方API都顺手将来要接数据分析也不愁。前端我完全没打算做大工程一个很薄的Web页面就够后面细节我会单独说。第1天下午我把FastMCP的Server骨架搭起来注册了前两个Toolget_city_info和get_weather。用MCP Inspector连上调试验证了一下确认工具能被正确发现和调用。到这里骨架已经通了。2.2 第2天补齐工具集让AI真的会规划第2天是强度最高的一天。上午我把第三方POI兴趣点数据源接通写了一个search_pois工具支持按城市、标签、关键词检索景点。下午补了两个更重要的工具build_route路线排序和estimate_budget预算估算。这里有个经验旅游规划的核心不是推荐景点而是在有限时间、预算、体力约束下把景点排成一条合理路线。所以build_route不是简单查数据而是要接收景点列表、游玩时长、交通耗时等参数用贪心打分算法排出一条顺序合理的每日路线。这个工具做完AI生成的行程才不是一堆景点的堆砌。第2天傍晚我开始写Prompt模板。MCP规范里有一种原语叫Prompt我把它用在了行程生成这个场景上。模板负责约束大模型的输出格式要求它必须包含每日行程表、交通建议、预算明细、备选方案。AI调用完工具拿到数据后会用这个模板生成最终结果。2.3 第3天做前端壳、联调、部署上线第3天上午我花了两个小时做了一个极简Web页面。一个输入框、一个按钮、一个结果展示区。页面本身的代码量不大核心逻辑是把用户输入发到后端Agent服务Agent再通过MCP Server调用工具最终把行程返回给前端渲染。为什么是后端Agent服务而不是前端直连MCP因为浏览器的环境限制比较多MCP的官方SDK在纯前端场景支持还不算成熟而且工具调用的密钥也不该暴露在浏览器端。更合理的架构是Web前端只负责交互后端跑一个Agent服务我用的是Dify自建的AgentAgent服务连接MCP Server执行工具调用。这样前端薄、后端厚职责清晰。下午的时间基本花在联调和部署上。Streamable HTTP传输模式的远程MCP Server用Bearer Token做鉴权部署在一台云服务器上。联调中遇到的最典型问题是工具返回的中文内容变成了一串乱码。排查了一会儿发现是响应头缺了charsetutf-8。补上之后整条链路就通了。当天晚上我把产品发给三个朋友试用让他们从用户视角提意见。第一个版本的反馈能用但是不自然——这句话成了我后来优化的方向。2.4 三天内我砍掉了什么回头看砍需求可能是这三天里做得最对的事。我砍掉了语音交互、地图可视化、多语言支持、用户历史行程保存、移动端适配、实时交通拥堵查询。每一项单独拿出来都很有价值但如果塞进这三天的交付任何一个都可能拖垮整个项目。做这种极限交付的项目我给自己定了一条规矩先跑通主链路再做体验优化最后才是外围功能。很多功能等到真正跑起来之后你才会发现根本不需要做得那么重。比如语音交互朋友后来说打字就够了地图可视化直接输出带顺序的文字路线反而比在地图上画点更实用。3. MCP Server从0到1Tool、Resource、Prompt三个抽屉各装什么3.1 技术选型和项目骨架MCP Server的技术栈选择我建议你直接参考生态成熟度。Python这边有FastMCP、官方的mcp-python-sdkNode.js那边也有官方SDK。我选Python的原因前面说了主要是FastMCP把低层协议细节都封装好了写起来非常接近普通Web后端。项目结构很小分三个文件就能跑server.py主入口和工具注册、data_loader.py加载城市和景点数据、providers.py封装天气、POI第三方API调用。用FastMCP起一个Server简单到离谱from fastmcp import FastMCP mcp FastMCP(trip-mcp) mcp.tool() def get_city_info(city: str) - dict: 获取城市的基础信息包括简称、常用标签、建议游玩天数、消费水平。 ... if __name__ __main__: mcp.run()对核心真的就这几行。FastMCP在底层帮你处理了JSON-RPC消息、Method路由、初始化握手、能力协商这些繁琐的协议细节。你不用关心MCP Client发过来的是什么格式的Initialize请求只管注册你的工具就行。3.2 注册Tool让AI能执行动作Tool是MCP里最常用的原语。它本质上是把一个Python函数暴露给AI让大模型在对话过程中自主决定要不要调用。每个Tool需要写清楚函数名、参数、返回值最关键的是描述。这里我要强调一个被很多人忽略的点工具描述是用给大模型看的不是写给人看的。你要用这段描述告诉AI这个工具什么时候用、能解决什么问题。比如我写get_city_info的描述是当用户提到某个城市并希望规划行程时先调用此工具获取该城市的基础旅游信息而POI检索工具的描述是当用户表达对某种类型景点感兴趣时调用此工具查询候选景点列表。描述的措辞直接决定了大模型判断的准确度。描述写得模糊AI就会瞎调用要么不用要么乱用。这是MCP开发里最典型的坑后面我会单独在踩坑章节展开。3.3 Resource与Prompt静态数据和对话模板的分工很多人以为MCP只有Tool这是对MCP Protocol理解不够深。MCP原语一共三种Tool、Resource、Prompt。三者的分工我总结成一句话Tool是动作Resource是数据Prompt是模板。Resource用于向AI暴露数据有点类似文件上下文。比如我把每个城市的固定信息做成ResourceAI需要时可以直接读取而不用每次通过Tool去现查。MCP的Resource支持URI表达最直观的例子mcp.resource(data://cities/{city}/overview) def city_overview(city: str) - str: 返回城市的基础旅游概述包括地理特征、饮食文化、交通概况。 return data_loader.load_overview(city)这样一来当AI需要了解一个城市背景时它会让Client去加载data://cities/chengdu/overview这个资源内容是可直接放进上下文的数据串。Resource的好处是语义清晰适合那些相对静态、不需要参数计算的资料。Prompt则是可复用的提示词模板。它适合那些你希望AI按固定套路输出的场景。我的行程生成模板是一个典型例子mcp.prompt() def itinerary_template(city: str, days: int) - str: return f 请为{city}生成{days}天的旅行计划。 要求严格按照以下结构输出 1. 每日行程表每个景点标注预计停留时间和交通方式 2. 交通建议城市内点对点通勤 3. 预算明细门票、餐饮、市内交通分开列 4. 备选方案天气不佳时的调整 AI拿到这个Prompt模板后会按你希望的格式组织答案再结合Tool查到的实时数据生成内容。三种原语组合起来MCP Server才算是真正完整的而不只是能调函数的架子。3.4 本地调试MCP Inspector是个好东西开发MCP Server阶段最大的痛点是没有一个可视化调试面板你不知道AI客户端实际看到了什么、工具返回了什么。这里强烈推荐MCP Inspector这个官方调试工具。启动之后它会以MCP Client的身份连接你的Server你可以手动调用每个Tool、查看Resource、测试Prompt模板甚至模拟一次AI对话。我第一次用Inspector就发现了三个问题search_pois返回的JSON里有个字段值为null时AI会把它当作没有限制条件天气工具参数我设计成传城市编号后来改成城市拼音才让AI更容易填对还有一次Inspector超时排查发现是第三方POI接口响应很慢做了缓存之后才解决。这些细节如果在联调阶段才发现会特别浪费时间。先用Inspector把每个工具通一遍能省下后面一大半排查时间。4. 旅游规划的元能力拆解每个Tool背后都有可复用的逻辑4.1 景点检索与推荐数据驱动而不是模型胡编旅游规划产品的核心数据是景点POI。我从公开数据源整理了主要旅游城市的基础景点库字段包括经纬度、分类标签美食、自然、人文、亲子、建议游玩时长、参考门票价、热度和是否支持夜间游玩。search_pois工具的输入设计是这套系统的钥匙。它接收city、tags、keywords、limit这些参数返回候选景点列表。关键是它的描述必须写清楚当用户表达偏好时应该怎么映射到标签。比如用户说喜欢小吃Agent就会给tags传[food]说想看古建筑传[culture]说带小孩传[family]。实现上这并不复杂本质就是带过滤条件的数据库查询。但它的价值非常大它把AI想象景点变成了AI从真实景点库中筛选并推理。我用的数据里包含真实的位置和门票区间AI再结合天气和路线工具做后续排序可信度就高很多。4.2 路线排序用贪心权重打分这是整个产品里最有含金量的工具。它解决的问题是你有一堆候选景点和一天的时间怎么排成一个顺路的行程我把它实现成一个贪心算法。输入当前所在位置、候选景点列表、可游玩时间、交通方式偏好输出一个排序后的路线。每选下一个景点时综合四个维度打分方向覆盖率往目标方向加分、距离由近到远、景点热度权重、用户偏好标签加权。mcp.tool() def build_route(origin: str, pois: list, hours: float, transport: str transit) - dict: 根据起点、候选景点列表和可用时间生成一条排序后的游览路线。 # 用贪心策略每一步选择评分最高的下一个景点 # 评分 热度权重 * 0.4 距离邻近度 * 0.3 偏好命中 * 0.2 停留时间匹配度 * 0.1 ...这个工具我的核心设计思想是AI负责选哪几个景点工具负责按什么顺序走。两者一旦分离逻辑就变得清晰。AI不需要懂得计算两点间路程它只需要把候选列表和偏好交给路线工具拿回来一个合理顺序然后组织成自然语言行程。这比让大模型纯靠脑内坐标来排路线靠谱得多。4.3 天气、门票、预算这些外部状态旅游规划的另一个关键是处理外部状态的变化。天气会变、门票会调、交通有实时状况这些信息不能指望AI记忆必须靠工具实时获取。我接入了一个实时天气API暴露成get_weather工具。参数是城市和日期返回当天天气、温度范围、降雨概率、紫外线等级。AI拿到之后如果发现下雨会自动在行程里加入室内备选或者把户外景点挪到不下雨的那天。实际用起来这个机动性是用户能直接感知到的价值。预算工具estimate_budget做的事情更偏向确定性计算。它接收门票价格区间、餐饮标准档位和交通方式输出每日开销估算。设计这个工具时我犯过一个理想主义错误一开始想把预算做得非常精确后来发现旅游开销本来就是个弹性区间。最终改成输出经济/舒适/品质三档区间反而更实用。4.4 把工具组合成一份完整行程有了这些工具之后AI规划一次行程的过程大概是这样的用户输入我周五下午出发去成都待三天喜欢小吃和人文街区预算1500以内不要起太早。Agent会自己拆解意图然后按逻辑调用先get_city_info拿城市基础信息再get_weather查这几天的天气然后search_pois查美食和人文类景点接着build_route把候选景点排成三天的路线最后estimate_budget核对预算。这一整套过程里Agent每一步都可能根据上一步结果做出微调。比如天气工具返回第三天有雨Agent会主动把室外景点往前换再在第三天排进博物馆和室内商圈。这就是AgentMCP组合的真正优势——不是让AI背下一本攻略而是让AI在真实数据约束下动态做决策。5. 接上AI客户端Claude Desktop、Codex、Dify都是怎么调的5.1 stdio和HTTP两种接入方式MCP Server做出来之后要接AI客户端才算真正可用。按MCP协议传输方式分两种stdio和Streamable HTTP。stdio模式适合本地开发。Client和Server是父子进程关系通过标准输入输出流交换JSON-RPC消息。Claude Desktop、Claude Code这类本地客户端默认就支持stdio。你在配置文件里指定command和args它会在本地把你写的Python进程跑起来然后通过管道通信。开发阶段我用stdio模式调试非常丝滑。等要上线给外面的人用就必须切到Streamable HTTP。Server变成独立的HTTP服务客户端通过HTTP请求访问远程地址。我的方案是用云服务器部署加上Bearer Token鉴权。Streamable HTTP还支持SSEServer-Sent Events做服务端推送适合长时间的流式任务。选型时大家在用SSE还是普通POST上容易纠结我的经验是你的Server如果有长时间运行的工具比如调用第三方API超过30秒就考虑SSE如果每个工具都是秒级返回普通HTTP就够。5.2 一个配置文件让客户端认识你的Server接入不同客户端最直接的差异在配置文件写法上。以Claude Desktop为例配置在claude_desktop_config.json里{ mcpServers: { trip-mcp: { command: python, args: [/path/to/server.py], env: { WEATHER_API_KEY: xxx, POI_API_KEY: xxx } } } }Codex的配置稍微有一点不同写在~/.codex/config.toml里格式更接近TOML[mcp_servers.trip-mcp] command python args [/path/to/server.py]Dify这类可视化平台更简单界面里直接填MCP Server的URL和鉴权Token不需要写配置文件。这也体现了MCP协议的好处同服务端一套代码不同客户端配置方式不同但协议通信层是一致的。5.3 实测中发现工具描述词决定AI用不用我在本地把Server接到Claude Desktop之后做了几轮对话测试。第一个发现就让我有些意外AI不是所有工具都会用而是它觉得合适才会用。我先把search_pois的描述写得比较模糊查询景点。结果AI在用户说想看杜甫草堂附近有什么时根本没有调用工具凭自己的训练记忆输出了一段泛泛的介绍。改完之后我把描述扩充为当用户提及具体景点、街区或想了解某区域可游玩项目时调用此工具查询景点列表参数tags支持多个取值如food/culture/nature/family。改动之后AI调用工具的频率立刻上去了。这让我意识到MCP Server开发的一半工作是在写给AI看的说明书。每个Tool的描述、参数名、参数类型甚至参数默认值都在潜移默化地影响大模型的决策准确性。工具描述写得像API文档AI可能理解不到位写得像使用手册AI反而会更聪明地调用。后面我给自己立了个规矩每个Tool写完不急着提交先用Inspector看看站在AI的视角读一遍描述确认它足够自解释。5.4 浏览器端和弱联网场景的取舍还有一个取舍供你参考其实浏览器前端也可以直接做MCP Client现在有实验性的Web MCP Client方案但我不想在核心路径上冒险。给浏览器的方案是让前端通过普通HTTP调用后端Agent网关后端网关负责维护MCP连接。这样做的好处很明显密钥不上浏览器、CORS好处理、后续换认证方式也灵活。坏处是多一跳流式输出时你要做一次代理转发。对于能上线跑通这个目标来说多一跳换来稳定和可维护划算。Dify里的Agent节点可以直接配MCP Server前端对接Dify的API整个链路非常省事这也是我最终选择Dify做Agent编排平台的原因。6. 上线的最后一公里公网部署、鉴权与超时治理6.1 Streamable HTTP跑的Server到底是个什么本地stdio模式跑得很顺部署到公网就是另一回事了。MCP Server变成HTTP服务后本质上就是一个Web服务进程所以你完全可以用平时部署Web API的思路来处理。我用的是FastMCP对Streamable HTTP的内置支持启动方式一句话python server.py --transport http --port 8000它会直接起一个HTTP服务暴露MCP协议所需的端点和SSE通道。这一步比较简单真正麻烦的是后面两点鉴权和超时。6.2 鉴权与Token别把裸奔的Server暴露在外网MCP Server如果没有任何鉴权等于把工具能力暴露给任何人。别人连上你的Server也能查天气、查POI数据甚至调用你后续加的写操作工具。我在第一天踩过的坑这里认真提醒你。部署HTTP传输的MCP Server第一件事就是加Authentication。MCP协议的HTTP传输支持标准的Authorization请求头你校验Bearer Token就行。实现上也简单写一个FastAPI中间件或者直接在入口校验一下Authorization头。配合环境变量管理Token不进Git仓库。这样虽然简单但对个人项目来说已经足够挡住绝大多数误访问。如果你对安全要求更高可以用OAuth 2.0那套但个人项目前期没必要为复杂度买单。6.3 超时治理Agent工具调用的隐形杀手公网部署踩得最凶的坑是超时。本地跑的时候网络快、接口快一切都很完美。一到公网第三方天气API偶尔慢到十几秒我的search_pois工具又会去请求POI服务整条链路串联下来一个工具调用可能超过30秒。AI客户端对工具调用的响应时间是有限度的超时会导致Agent放弃这个工具或者报错中断。我的治理方案分三步第一给第三方请求加超时控制和重试退避第二对POI数据做本地缓存比如天气查询结果缓存半小时城市景点列表缓存24小时第三把长耗时的工具拆成查询提交两步让单次工具调用保持轻量。上线后实测90%的工具调用都在3秒以内Agent规划一次完整行程从用户发起到返回结果大约在15-25秒。这个速度对对话式产品是可接受的。6.4 上线检查清单给准备上线的朋友一份我的检查清单鉴权是否生效没有Token的请求是否被拒绝跨域是否配置如果你的前端要连后端Agent记得处理CORS日志是否落盘MCP Server调用日志、错误栈都要有记录环境和密钥是否隔离所有API Key用环境变量注入反向代理和HTTPS是否配好我用的Nginx加Let‘s Encrypt证书是否做了健康检查给Server加一个/healthz端点是否资源受限导致进程被杀加个进程守护用systemd或者Docker restart策略这份清单是我用一次半夜紧急重启换来的每一项都是真金白银的教训。7. 踩坑实录与复盘哪些弯路你可以直接绕开7.1 最典型的三个问题第一个坑是工具返回的内容过大。有一次search_pois返回了20个景点每个景点包含80个字的中文描述总token接近3000。Agent的上下文窗口一下就被吃掉很大一部分导致后续生成行程时忘了用户说过的预算限制。我的解法是工具默认返回精简字段描述限制在50字以内把详细内容拆成AI主动追问的get_poi_detail工具。这让我深刻意识到工具设计要考虑上下文体量控制。第二个坑是Agent的多工具并行调用。有些客户端支持并行工具调用但MCP Server这边如果对第三方API做了缓存并行请求时锁处理不好会读到旧数据。更严重的是一次测试中天气工具被并行调用了两次触发第三方接口限流。后来我给Server统一加了全局请求熔断和并发控制每个第三方API的单端点并发数限制在3以下。第三个坑是自以为AI理解你的工具。最初我把estimate_budget的参数budget_level设计成数值1到3但AI经常传0或传负数。改成字符串枚举economy/comfort/quality之后出错率显著下降。给MCP工具的枚举参数要尽量选有语义的字符串这是踩过坑之后的深刻体会。7.2 MCP做产品的边界它擅长什么不擅长什么三天做完产品我最大的感受是MCP是AI应用层的集成总线但它不是业务本身。它能让你快速把工具接入多个AI客户端但它不会帮你设计业务逻辑更不会替你搞定数据源。MCP擅长的场景是标准化集成你有能力、有数据想让AI生态里的多个客户端都能消费它。MCP不适合用来做那种完全不需要外部世界的纯对话产品。如果你的功能只是总结文本、改写文案本身就在大模型能力范围内硬套MCP反而增加维护成本。判断标准很简单你的AI需不需要访问外部实时数据或执行外部动作需要就值得上MCP不需要直接用Prompt就行。7.3 给后来者的建议如果你也想用MCP快速落地一个AI产品我给你三条实在的建议。第一条先从工具集设计开始而不是从架构图开始。先列出你的业务领域里AI必须主动知道什么、必须主动做什么把一个一个能力拆成工具函数让每个工具函数你都能在一小时之内写完并验证。工具集设计清楚了架构自然就清楚了。第二条找一个像MCP Inspector这样能让你看见AI视角的调试工具。MCP开发的调试负担超过普通Web开发因为你看不到大模型是怎么理解你的工具的只能通过反馈推断。Inspector能帮你降低很多黑盒感。第三条先把产品边界做小再谈智能化。我这个产品之所以能三天上线正是因为我允许它只能做一件事——生成行程。它不做比价、不做预订、不做实时导航。如果一个Agent产品连一个核心闭环都没跑通就急着加一堆外围功能那它大概率会在开发中就死在复杂度里。最后说说我个人的感受。这三天做下来MCP对整个交付周期的帮助比我想象中大得多。它最大的价值是让我没有去纠缠底层的协议细节能用很轻量的方式把工具交给AI然后专注于业务逻辑的打磨。上线那一刻我自己输入北京两日游偏好胡同和博物馆预算800看到AI自己完成了查天气、查景点、排路线、校预算这一整套动作说实话有种从单独敲代码的人升级成了给AI搭舞台的人的感觉。这个产品还会有后续比如接入更多城市的POI数据、支持多人拼团路线、接入实时公交接口。但就算这些功能都不做单靠当前这套MCP基础它也已经是一个能真正辅助人做旅游决策的工具了。如果你也想动手做点什么不用等一个完整的大项目找一个真实场景给它配上MCP三天之后你会看到和纯聊天完全不同的AI。