基于MCP协议与Dify工作流构建智能旅游规划Agent

国庆前朋友拉了个群让我帮忙排一趟西安的行程，我一边在高德地图里查景点、查餐厅、查路线，一边在Excel里手工整理清单，来回切了十几个页面。折腾到后半夜我才意识到，这个活儿本质上就是“多源检索 + 规则排序 + 结构化输出”，完全可以直接交给AI Agent来做。于是我基于高德API，把地点搜索、路线规划、周边推荐这几类高频能力通过MCP协议接入Dify工作流，搭了一个能自动生成旅游规划清单的Agent，输入目的地和偏好，输出一份按天、按时段排好的行程表。

这个Agent能做到什么程度？你只要说一句“北京3日游，喜欢胡同和老字号”，它会自动把符合条件的景点和餐馆查出来，用路线规划接口算好各点之间的通勤时间，自动过滤掉评分低、与主题无关的POI，最后整理成包含交通方式、建议时长、注意事项的旅行清单。文章会从选型思路、MCP Server编写、Dify工作流编排到实际踩坑排查，完整拆解一遍。如果你正在玩Dify，或者想入门MCP和Agent开发，这篇东西应该能帮你少走不少弯路。

1. 项目整体设计与思路拆解

1.1 一个旅游清单，为什么值得交给Agent来做

旅游规划这件事听起来简单，真正操作起来信息非常分散。景点要看高德上的位置和评分，美食要看榜单和营业时间，路线要算点与点之间的通勤距离，最后还要把所有内容整合成一份有顺序、有时段、有理由的清单。这一整套流程如果靠人工完成，至少半小时起步；如果目的地不熟，查攻略来回折腾一两个小时都是正常的。

拆开来看，这个过程本质上就是“检索信息 → 过滤无关项 → 按规则排序 → 生成结构化文本”，四个环节都非常适合大模型加上外部工具来执行。传统方案的问题在于：地图数据长在高德里，模型自己背不出来；就算背出来，也没有实时路线和评分；就算去调API，每次返回的JSON格式还不一样，写一堆适配代码实在太累。

所以我的核心思路是让Agent负责“理解需求和决策”，让高德API负责“提供事实数据”，两者之间通过MCP协议做一个标准化连接。模型的优势是能听懂“喜欢安静但不想太偏僻”这种模糊表达，高德的优势是有准确的POI数据和路径计算能力，双方互补之后，生成出来的行程清单才是真的可执行、可导航的。

1.2 为什么是Dify + MCP + 高德API这个组合

先说为什么不直接写代码。如果不用Dify，我需要自己实现会话管理、模型调用、工具注册、Prompt模板、结果渲染，还要写一个前端界面给朋友用。这是一整套工程，不是一两天能搞定的。Dify把这些现成功能都内置了，Agent节点自带工具调用的推理循环，我只需要关注业务本身。

再说为什么需要MCP。Dify里其实也可以直接用“HTTP请求”节点调高德API，但对“旅游规划”这种场景来说，高德API不止一个：查景点、查美食、算路线、查周边、地理编码，少说五六个接口。如果用HTTP节点，工作流里要建五六个请求节点，每个都要单独处理鉴权、参数、返回解析，一旦接口有变动改起来很麻烦。MCP出现之后，我可以把高德API封装成一个MCP Server，把多个能力统一注册成tools，Dify只需要连上这个Server，就能自动发现所有工具。后续想加一个天气接口，直接在这个Server里加一个函数，Dify里同步一下就能用，不用动工作流主体。

整体选型对比可以看这张表：

另外，选高德而不选其他地图服务，主要是两点考虑：一是高德的POI数据在城市级的覆盖深度确实够，二是Web服务API的个人配额足够支撑日常测试和小规模使用，申请流程也比较快，不需要商务审核。

2. 核心细节解析与实操要点

2.1 高德API里真正会用到的那几个接口

高德开放平台接口很多，但旅游规划Agent核心只需要四类。第一类是地点搜索，接口路径是/v3/place/text，通过关键词找POI，返回结果里有name、location（经纬度）、rating（评分）、address、type等字段。比如我想找“北京的胡同”，传keywords=胡同&city=北京，就能拿到南锣鼓巷、五道营胡同这些结果。这个接口是整个Agent最常用的，任何候选POI都从它来。

第二类是周边搜索，/v3/place/around，给定一个经纬度坐标，搜索附近指定类型的POI。这个在“晚上到了酒店之后附近有什么可逛”这个场景下很实用，模型拿到用户酒店的坐标后，可以直接查周边美食和夜间去处。第三类是路径规划，/v3/direction/walking、/v3/direction/driving、/v3/direction/transit对应步行、驾车、公交三种方式，返回信息里最重要的是distance（距离）和duration（耗时），这两个字段是行程排序时的核心依据。

第四类是逆地理编码，/v3/geocode/regeo，把经纬度坐标转成可读的地址描述。这个接口主要用来校验POI坐标的合理性，或者在最终清单里给用户一个“位于XX路附近”的参考位置。说句实话，旅游规划用不到地图渲染，所以不需要引入地图JS SDK，只调Web服务API完全够用。

申请高德Key的时候注意一个细节：在控制台创建应用时，服务平台要选“Web服务API”，拿到的是一个Key加一个安全密钥。很多教程只让你填Key，但新版的签名校验会用到安全密钥，建议提前把这两个都拿到，后面写MCP Server的时候都配置进去。Key不要直接写进前端代码，Agent的调用链里所有请求都走服务端，这个习惯能帮你避开不少安全问题。

2.2 MCP在项目里到底是什么角色

MCP（Model Context Protocol）本质上是AI应用与外部工具之间的标准化通信协议，你可以把它理解为“AI应用界的USB-C接口”。没有USB-C之前，每个设备都要配一根专门的数据线，接口协议还各不相同；MCP出来之后，工具发现、工具调用、参数传递、结果返回都定义了统一规范，Dify只要连上MCP Server，就能像插U盘一样自动识别里边的所有工具。

从协议层面看，MCP基于JSON-RPC 2.0，核心抽象有三类：tools（可执行的动作）、resources（可读取的数据资源）、prompts（可复用的提示模板）。在这个项目里，我们用到的绝大多数都是tools，每个tool对应一个高德API能力。Dify作为MCP客户端，会调用MCP Server的tools/list方法获取工具列表，然后在Agent的推理循环里，根据用户意图选择具体tool执行。

当初我也想过不引入MCP，直接在Dify里建一堆“HTTP请求”节点。后来对比下来的感受是：如果项目只需要接一两个接口，HTTP节点足够简单直接；但要像旅游规划这样同时接搜索、路线、周边、地理编码四五个接口，MCP的收益就非常明显。所有工具在一个Server里统一管理，Dify侧只需要接入一次，后面就是直接使用的问题。而且MCP Server本身是一个独立进程，不依赖Dify，我可以单独测试高德API的返回，也可以用单元测试来验证参数组装逻辑，调试体验比绑在Dify工作流里舒服太多。

2.3 Dify侧的准备：模型、应用类型、变量

在Dify里创建Agent应用之前，有几个准备工作要确认。第一个是模型配置，Dify本身不提供模型，需要接入第三方模型服务。要跑Agent并调用MCP工具，模型必须支持工具调用（Function Calling）能力，目前国内的Qwen、DeepSeek、GLM这些主流模型都支持，我实际用下来Qwen系列在“按格式输出结构化清单”这件事上表现不错，DeepSeek也不错，寒暑假高峰期偶尔会慢。选模型时不用盲目追最新最大，Agent场景对推理能力有一定要求，但对吞吐和成本更敏感，中等规模的模型已经够用。

第二个关键点是应用类型要选“Agent”，而不是“工作流”或“Chatbot”。工作流模式适合固定步骤的确定性流程，比如“先查天气再查路线再输出”，每步都安排得明明白白；Agent模式则让模型自己决定什么时候调用哪个工具、调用几次、返回结果怎么解读。旅游规划这类任务，用户输入千变万化，有的是“三日游”，有的是“亲子游”，有的是“只要摄影点”，你不可能把所有分支都写进工作流，交给Agent自动决策反而更稳。

第三个是变量的设计。Dify里有会话变量和系统变量，我的做法是：会话变量存“目的地”“出行天数”“偏好主题”，用户在对话开头填一次，后面Agent后续追问的时候做上下文参考；系统变量则由Dify自己管理，包括聊天历史、工具返回值这些。一定要在Agent节点里勾选“对话轮次中的历史记录”，否则模型可能会丢失前面已经确定的行程安排，出现“刚定好的第三天下午行程，下一轮对话又问一遍”的尴尬情况。

3. 实操过程与核心环节实现

3.1 Dify本地部署和插件环境准备

Dify官方推荐用Docker Compose部署。先去GitHub把dify源代码仓库拉到本地，进到docker目录，看一眼.env文件，把需要的密钥配置好，然后直接执行docker compose up -d。首次启动会拉不少镜像，网速不好可能会有超时，耐心等或者换镜像源就能解决。起来之后打开浏览器访问本地端口，创建管理员账号，进入工作台。

要接入MCP，需要在Dify的“插件”市场里安装MCP类型插件。Dify的插件机制支持在线安装和离线安装两种方式，在线装的话直接在插件市场搜索MCP就行；如果Dify部署在公网受限的环境里，可以离线下载插件包再手动导入，文件放到插件目录后会提示安装。根据我之前踩坑的经验，Dify版本不要太老，1.x以上对MCP的支持才算稳定，太老的版本连MCP插件都搜不到。

3.2 高德MCP Server的实现代码

实现高德MCP Server，我用的Python生态，核心依赖是mcp官方SDK和httpx异步请求库。先安装依赖：

pip install "mcp[cli]" httpx

然后新建一个amap_mcp_server.py文件，代码结构大概是这样的：

from mcp.server.fastmcp import FastMCP import httpx # 创建MCP Server实例，名称为gaode-travel mcp = FastMCP("gaode-travel") # 高德Web服务API的Key，正式使用时建议从环境变量读取 AMAP_KEY = "你的高德Key" async def call_amap(api_path: str, params: dict) -> dict: """统一的高德API请求封装""" params["key"] = AMAP_KEY async with httpx.AsyncClient() as client: response = await client.get( f"https://restapi.amap.com{api_path}", params=params ) return response.json() @mcp.tool() async def search_places(city: str, keywords: str, types: str = "") -> list[dict]: """关键词搜索指定城市的POI，适合用来查景点、美食、酒店等。 city: 城市名称，如'北京' keywords: 搜索关键词，如'胡同' types: POI类型编码，可选，如风景名胜、餐饮服务 """ params = {"keywords": keywords, "city": city, "offset": 10} if types: params["types"] = types result = await call_amap("/v3/place/text", params) pois = result.get("pois", []) # 裁剪字段，只保留Agent真正需要的 cleaned = [] for poi in pois: cleaned.append({ "name": poi.get("name"), "location": poi.get("location"), "address": poi.get("address", ""), "rating": poi.get("biz_ext", {}).get("rating", ""), "type": poi.get("type"), }) return cleaned @mcp.tool() async def plan_route(origin: str, destination: str, mode: str = "walking") -> dict: """计算两个坐标点之间的路线，返回里程和预计耗时。 origin: 起点坐标，格式为'经度,纬度' destination: 终点坐标，格式为'经度,纬度' mode: 出行方式，可选walking/driving/transit """ api_path = f"/v3/direction/{mode}" result = await call_amap(api_path, { "origin": origin, "destination": destination, "strategy": 0 }) paths = result.get("route", {}).get("paths", []) if not paths: return {"error": "路线规划失败，请检查坐标是否合法"} path = paths[0] return { "distance_km": round(int(path.get("distance", 0)) / 1000, 2), "duration_min": round(int(path.get("cost", {}).get("duration", 0)) / 60, 1), "steps": [step.get("instruction", "") for step in path.get("steps", [])] } if __name__ == "__main__": mcp.run(transport="http")

运行python amap_mcp_server.py，MCP Server默认监听8000端口。FastMCP这个封装层给开发者省了很多事，工具注册就是一个装饰器的事，类型标注会自动转成JSON Schema供模型识别，这一点非常重要，因为Dify的Agent就是靠工具描述来决定“什么时候该调用什么工具的”。

如果嫌Python环境麻烦，也可以用Dify社区里其他人封装好的现成高德MCP插件，但自己写一遍的好处是能完全控制字段裁剪逻辑。比如高德搜索返回的JSON里有很多字段是Agent根本用不到的，像pcode、adcode、timezone这些，直接一股脑塞给模型既浪费token，又可能干扰模型判断。我在MCP层就把返回结果精简成name、location、address、rating、type五个字段，模型拿到手就是干净的候选清单。

3.3 在Dify里接入MCP并编排Agent应用

MCP Server跑起来之后，回到Dify工作台，进入“插件”页面，添加一个MCP类型插件。填写名称gaode-travel，类型选“HTTP”，URL填http://host.docker.internal:8000/mcp。这里要注意：Dify如果是用Docker容器跑的，容器内部访问宿主机的localhost是走不通的，要用host.docker.internal这个特殊域名来指代宿主机。如果不想依赖这个域名，也可以把MCP Server同样跑在Docker里，用容器名称互相访问。

插件接通之后，新建Agent应用，选择模型，然后在工具面板里应该能看到刚才MCP Server暴露出来的search_places和plan_route两个工具，默认是未授权状态，点一下授权启用。这一步完成后，Agent的推理循环就已经能把“查景点”和“查路线”这两个动作和具体工具关联起来了。

接下来是重头戏：System Prompt的设计。我实际调了一版比较好用的，放在这里供参考：

你是一位资深旅行规划师。你的任务是根据用户的目的地和偏好，生成可执行的每日行程清单。 你必须严格按以下步骤工作： 1. 先用 search_places 查询用户提到的核心景点和美食关键词，拿到候选POI的名称、坐标和评分。 2. 对候选POI做筛选：评分低于4.0的剔除；与用户主题无关的类型剔除；政府机关、培训机构、公司类POI一律移除。 3. 用 plan_route 计算前一天最后一个地点到当天第一个地点，以及相邻安排之间的交通耗时。 4. 优先把相邻地点交通耗时小于40分钟的安排在同一天；超时则调整顺序或替换备选POI。 5. 最终输出 Markdown 格式行程清单，必须包含：日期、时段（上午/下午/晚上）、地点名称、坐标、交通方式、预估耗时、建议理由。 注意：坐标必须保留精度，方便用户导航。如果某类信息查不到，直接说明，不要编造。

这段Prompt的核心是把“规则”前置给模型，减少模型自由发挥的空间。一开始我让它自由安排，结果出现了一个上午塞三个景点，最后一段路程要花两小时的情况；加了“交通耗时小于40分钟”的硬性约束之后，输出明显合理很多。不过这些规则不是死的，如果你用户明确说“想去远郊没关系”，可以通过对话覆盖掉。

3.4 一次实际运行的输入与输出

Agent搭好之后，我拿“无锡2日游”做了一次完整的测试，用户输入是：“帮我规划无锡2日游，主要想逛古镇和太湖边的自然风光，吃得清淡一点。”

Agent的执行过程大概是这样的：先调用search_places搜索“无锡 古镇”和“无锡 太湖”，拿到惠山古镇、荡口古镇、南长街、鼋头渚等一批POI，筛选掉评分偏低的，再用plan_route计算“鼋头渚到惠山古镇”的驾车时间约32分钟，最后输出清单。最终结果经过我简化后是这样的：

看起来很像样对吧？但我要坦白，第一次跑出来的结果远没这么顺，出现过把“无锡市第一女子中学”选进景点候选的离谱情况。后来在MCP的search_places返回结果里过滤了POI类型，把“学校”“政府机构”“公司企业”这类明显不是旅游目的地的类型直接剔除，情况才改善。这其实暴露了一个规律：Agent能不能稳定产出好结果，一半靠模型推理，另一半靠你给工具的数据是不是干净。工具侧多做一层过滤，模型侧就能少犯一层错。

4. 常见问题与排查技巧实录

4.1 Dify部署和连接阶段的SSL与凭据校验坑

本地跑Dify接入MCP Server时，最容易碰到两类报错。第一类是dify ssl error，也就是SSL证书错误。原因往往是Dify工具验证默认走HTTPS，而本地MCP Server跑的是HTTP，两边协议对不上。解决办法是把插件配置里的URL写成http://开头，并且确认MCP Server本身没有强制TLS。如果你把MCP Server部署到了远程服务器，那反过来要配好HTTPS证书才能接，本地开发不建议上证书，纯HTTP足够。

第二类是an error occurred during credentials validation，这个是Dify在验证MCP工具凭据时的通用报错。排查顺序我建议是这样：先用浏览器或curl访问一下http://你的地址/mcp/，看能不能拿到JSON-RPC响应；能拿到，说明Server本身没问题，问题出在Dify容器到Server之间的网络；拿不到，检查MCP Server进程是否还活着、端口有没有被防火墙拦截。之前我遇到过一次，MCP Server正常运行，但Dify容器里host.docker.internal解析失败，把URL改成宿主机局域网IP就解决了。这类问题本质是网络拓扑问题，和MCP协议本身关系不大，但报错提示写得比较吓人，容易让人误判。

4.2 文档处理场景的unstructured API报错

旅游规划Agent如果只是依赖高德API，是不需要知识库的，但你如果想把小红书攻略、PDF游记这些资料喂给Agent做参考，就会碰到这个报错：unstructured api url is not configured for doc file processing。原因是Dify处理文档类文件依赖unstructured这个第三方解析服务，如果环境变量里没有配置对应的API地址和密钥，文档解析就会失败。

我踩过一次之后总结了两条路。一是配置环境变量：在docker-compose的.env文件里加上UNSTRUCTURED_API_URL和UNSTRUCTURED_API_KEY，都指向你实际的解析服务地址，重启Dify。二是偷懒方案：直接把PDF或Word文件转成纯文本TXT再上传到知识库，绕开unstructured解析。对于旅游攻略这种内容，转成TXT之后信息损失很小，但省掉了一层依赖，稳定性和速度反而更好。顺带提一句，Dify社区版的离线插件安装也是围绕这套生态做的，遇到“插件装了但加载不出来”的问题，先检查插件版本和Dify版本是否匹配。

4.3 运行期的上下文超长、变量聚合器和工具同步问题

Agent运行起来之后，最常见的质量问题是上下文超长。高德API返回原始JSON比较大的时候，模型一次对话里多次调用工具，很快就把上下文窗口挤爆。解决方式是双管齐下：第一层在MCP Server里做字段裁剪，返回给模型的数据只保留必要信息；第二层在Dify里用变量聚合器，把多个工具返回值合并成一个精简的最终结构，再传给模型的输出阶段。如果还不知道Dify变量聚合器的用法，简单说就是它可以把不同来源的数据“攒”成一段文本或结构化对象，减少后续步骤重复访问原始数据，也能降低token损耗。

还有一类问题是“工具找不到”或“新工具不生效”。MCP Server新增了一个工具函数，但Dify的工具面板里始终看不到。排查逻辑很简单：MCP Server没有重启，Dify拿不到新的tools/list结果。要让改动生效，必须重启MCP Server进程，让Dify重新拉取工具列表。这个坑我也踩过好几次，后来我习惯每次改完工具定义，就顺手刷一下Dify的工具面板，确认数量和描述都对得上再往下走。

4.4 并发和配额问题：Agent能扛住高频调用吗

很多人关心AI Agent怎么扛并发这个问题，其实分两层看。Dify应用本身部署好了，多个用户同时对话基本没问题，真正的瓶颈往往在MCP Server和高德API配额上。高德Web服务API的个人配额并不算高，搜索接口每日调用量有限制，QPS一般也就几十，Agent一个回合里连续调用十几次搜索是很正常的，很容易瞬间把配额打满。

我的应对策略是在MCP Server上做两层防护。第一层是轻量缓存：对相同参数的搜索请求，一小时内的结果直接返回缓存，不重复调高德。旅游Agent的场景里，同一个城市同一个关键词被反复搜索的概率很高，缓存效果非常明显。第二层是做限流：用一个简单的令牌桶算法，限制每秒最多多少次请求，超出的请求排队或快速失败。通过缓存和限流双保险，实际运行中高德配额消耗速度被压下去好几倍。如果你要承接更大规模的生产并发，可以考虑把MCP Server部署成多个副本，前面再加一层负载均衡，但作为个人项目或小团队项目，缓存已经够用。

5. 实操心得与后续扩展

按我自己做完这个项目的体会来说，MCP和Dify这套组合真正适合的场景，就是“模型负责思考，工具负责查证”的信息检索型Agent。旅游规划只是其中一个不错的方向，同样的架构换成查物流、查政策文件、查商品库存，逻辑几乎不需要改，只要把MCP Server里的工具换成对应的业务API就行。最近社区里大家都在讨论Agent框架与编排，经常会提到Agent和Harness的区别——我认为Agent是那个做决策的大脑，Harness是承载工具和执行的“工作台”，Dify工作流负责编排，MCP Server和底层API就是那个执行台。

有几个小技巧分享一下。第一，MCP Server里不要把所有接口都暴露给Agent，暴露得越多模型越容易乱，三四张工具刚刚好；第二，模型的强弱真的影响最终清单质量，弱模型不太会遵循“40分钟内”这种约束，这时候可以把规则下沉到MCP Server里用代码强行过滤，不要让LLM承担它不擅长的计算；第三，给Agent的输出加一层模板校验很有用，我直接在Dify的Agent节点输出前接了一个“格式整理”步骤，确保每条清单都包含坐标字段，这样用户拿到之后可以直接丢进导航。

后续我打算在这个Agent里再接一个天气查询工具，让清单自动避开雨天安排户外景点，还想加入导出ics日历文件的能力，把行程一键同步到手机日历。如果哪天高德API配额不够了，可以考虑在MCP层接一个备份地图服务，协议不变，只换后端实现。最后说句实在话，这类项目并不是要证明Agent比人更会旅游，而是想说明一套好的工具链条能帮我们把重复劳动压缩到很低的程度——我在这个项目里省下的时间，远多于搭它花掉的时间。