每天下班后，你是否也常陷入“想去哪却又不知道去哪”的纠结？本文记录了我如何利用 AI Agent、MCP 协议与腾讯位置服务能力，将模糊的“人话需求”转化为精准的 Top5 推荐，并最终落地为一个可用的微信小程序。全程真实踩坑与工程化复盘，希望能给正在做地图+AI 项目的你一些启发。

为什么我要做这个项目：从“找地方”到“做决定”的痛点

这个项目的起点并非为了打造一个炫酷的 AI Demo，而是源于一个极其高频且真实的日常场景：我们常常不是找不到地方，而是难以决定去哪一个。

想想看，你是否说过这样的话：

  • “想找个安静、能坐两小时、最好有插座的咖啡馆”
  • “今天下雨，想去室内，别太远”
  • “带娃出门，找停车方便、适合小朋友活动的地方”
  • “想散心，但不想走太远，也别太冷清”

这些表达里充满了约束条件和情境偏好。传统地图搜索能解决“检索地点”，却难以一次性解决“决策焦虑”：你需要自己拆解关键词、来回对比候选点、结合距离和氛围做主观判断，最后还得跳转导航。整个过程碎片化且耗费注意力。

因此，我给自己定了一个清晰目标：把“找地点”升级为“帮你做决定”。

这背后涉及自然语言处理（NLP）、意图解析、位置服务编排等一系列技术挑战。而 AI Agent 与 MCP 的出现，让这一切变得可行。

方案总览：将“搜索行为”重构为“决策服务”

我的目标不是做一个“会聊天的地图壳子”，而是构建一条完整的可执行链路：

  1. 用户输入一句话需求
  2. 系统理解意图并检索周边候选
  3. 生成可解释的推荐理由
  4. 在地图上展示并一键导航

在体验上，我将其封装为微信小程序，用户路径极短：

  • 输入自然语言需求
  • 若语义模糊，系统最多追问 1-2 个澄清问题
  • 返回 Top5 候选点（含距离、预计到达时间、推荐理由）
  • 地图标注候选点，一键进入导航

在架构上，我将后端拆分为多个职责清晰的能力模块：

  • 意图解析模块（规则兜底 + LLM 优先）
  • 位置能力模块（腾讯位置服务能力封装）
  • 推荐排序模块（多因素加权）
  • 文案解释模块（让推荐“可理解”）
  • 健康检查与配置模块（保障服务可用性）

这种设计的好处是：后续扩展更多场景（约会、亲子、旅游、校园）时，不需要推翻重做。

腾讯位置服务实战：能力落地的三个关键节点

在本项目中，我并非只调用了单一接口，而是将腾讯位置服务嵌入到决策链路的核心环节。以下是我真实使用其能力的三个关键场景。

地点搜索：把“人话”映射为可检索关键词

用户说的是自然语言，而非标准 POI 关键词。我构建了一个“意图→检索词”映射层，例如将“适合久坐办公”映射到“咖啡馆/书店/共享办公空间”等候选词，再调用腾讯位置服务的地点搜索能力，获取候选 POI 列表。

这里我踩过两个坑：

  • 关键词太宽：返回结果噪声高，不实用
  • 半径太大：候选很多，但实际距离不匹配

最终我采用了“分层检索 + 半径动态收敛”策略：先用主关键词检索一轮，再按用户约束补充次级关键词，最后按距离和场景过滤。

逆地理与位置元信息：补齐用户上下文

很多时候用户不会明确输入当前位置。我通过逆地理能力补齐“用户当前区域语义”，比如商圈、街道、行政区，使推荐文案更贴近真实语境。这一步在体验上至关重要：同样是“离你 1.2km”，和“在你当前商圈步行可达”相比，后者让用户决策更快。

路线规划：把“可去”变成“值得现在去”

许多推荐系统只提供地点，我更关注行动成本。我接入了路线规划能力，支持步行/骑行/驾车三种模式，实时给出预计耗时。这让推荐结果从“信息展示”升级为“决策辅助”：

  • 用户赶时间时，15 分钟内可达优先
  • 用户想放松时，步行可达且路线舒适优先
  • 下雨或夜间场景，室内 + 打车便利加权

我的真实体会是：路线耗时信息显著提升了结果的可用性和说服力。

AI Agent 与 MCP：理解需求与稳定编排的“双引擎”

很多文章会把 AI Agent 写得很玄，我这里用人话解释：它主要解决“理解需求”和“任务编排”两件事。

AI Agent：负责理解“人话需求”

用户表达通常不标准，甚至模糊。AI Agent 在我的项目中负责：

  • 抽取核心意图（找吃饭/学习/散步/亲子）
  • 识别约束条件（安静、人少、室内、可久坐、价格）
  • 判断是否需要澄清提问
  • 产出结构化检索参数

我没有将系统完全绑定在单一模型上，而是采用了“LLM 优先 + 规则回退”的双轨逻辑。当模型不可用或响应异常时，系统不会直接失败，仍能返回可用结果。

MCP：把多能力调用串成可控工作流

在我理解中，MCP 的价值不在于“炫酷”，而在于统一工具调用边界。我将地点搜索、逆地理、路线规划等能力封装成标准工具，Agent 通过 MCP 进行调用编排。这样做的好处很实际：

  • 工具接口统一，后续新增能力成本低
  • 日志更清晰，方便排查问题
  • 可单独 mock 某个工具，做稳定性与回归测试
  • 可做调用策略控制（超时、重试、降级）

一句话总结：AI Agent 决定“做什么”，MCP 保证“怎么做得稳”。

[AFFILIATE_SLOT_1]

核心实现拆解：从一句话到 Top5 推荐的完整链路

以下是项目中的实际处理流程，便于复现：

Step A：接收用户输入并做意图解析

输入示例：“附近找个安静点、能坐两小时办公的咖啡馆”

解析结果（结构化）大致如下：

  • 场景：学习办公
  • 类别偏好：咖啡馆
  • 约束：安静、可久坐、可能需要插座
  • 距离偏好：附近（默认半径）
  • 出行模式：未指定（后续补齐）

Step B：触发腾讯位置服务地点检索

用主关键词先检索，再根据约束补充候选词扩展。通过半径和结果质量阈值控制，筛掉“看起来相关但体验不匹配”的点。

Step C：融合路线信息与场景评分

对每个候选点补齐路程与耗时信息，再按综合分排序。综合分主要考虑：

  • 场景匹配度（约束命中情况）
  • 到达成本（距离/耗时）
  • 结果稳定性（数据完整度）

Step D：生成“可解释推荐理由”

我坚持每个候选结果都要有一句可读理由，例如：

  • “步行约 9 分钟，环境相对安静，适合短时办公”
  • “离你更近，通勤成本低，且周边配套更完整”

这部分看似简单，实际上是用户是否信任推荐的关键。

Step E：地图展示 + 一键导航

最终结果不是停在列表，而是直接落到地图 marker，用户可点选任意候选点发起导航。从“看到推荐”到“开始行动”的路径被尽可能缩短。

工程化策略：稳定性、成本与可维护性

一个能参加比赛、还能长期维护的项目，必须在工程层面有基本盘。我重点做了三件事：

✅ 健康检查与错误分级

通过健康检查接口快速判断：环境变量是否齐全、外部能力是否可达、当前运行模式（mock 还是 live）。错误处理上我采用“可恢复优先”原则：

  • 外部调用超时 → 尝试降级结果
  • LLM 不可用 → 回退规则解析
  • 路线失败 → 保留 POI 结果并提示部分能力受限

✅ 可测性设计

我将意图解析、推荐排序、位置服务封装分开，便于单测覆盖。同时提供端到端烟雾验证脚本，确保核心链路可跑通。

✅ 可扩展结构

我避免将所有逻辑堆在一个路由中，而是拆分为服务层与工具层。这样后续接入更多推荐策略、更多业务场景时，改动范围更可控。

项目：AI 周边决策助手（微信小程序 + Node.js）
核心能力：腾讯位置服务（地点搜索、逆地理、路线规划）+ AI Agent 意图理解 + MCP 工具编排
关键词：真实痛点、真实使用、可解释推荐、工程稳定性、可复现

真实效果与复盘：做对了什么，还要优化什么

做对的部分

  • 聚焦真实痛点场景：没有做成“万能生活助手”，而是先把“周边去哪儿决策”这条链路跑通
  • 强调可解释推荐：用户愿意点导航，不是因为返回了 5 个点，而是因为说清楚了“为什么是这 5 个点”
  • 工程化优先于炫技：mock/live、降级回退、健康检查这些能力，在比赛演示中反而更能体现专业度
  • 把热门话题变成可落地价值：AI Agent、MCP 不是概念堆砌，而是实实在在提升了理解能力与编排能力

⚠️ 仍需优化的部分

  • 个性化还不够：目前更多是“场景推荐”，下一步会引入偏好学习
  • 推荐排序还可更精细：可加入时间段、天气、拥挤度等因子
  • 多轮对话可以更自然：澄清问题应更短更聚焦，减少用户负担
  • 结果反馈闭环待完善：计划加入“本次推荐是否满意”用于在线学习
[AFFILIATE_SLOT_2]

结语

这次项目让我最有收获的一点是：地图能力的价值，不只在于“知道地点在哪”，更在于“帮助用户更快做决定并立刻行动”。腾讯位置服务提供了稳定可靠的位置能力底座，AI Agent 让我能更自然地理解用户意图，MCP 则把多能力调用变成可治理的工作流。

如果你也在做地图 + AI 的项目，欢迎交流你的场景与实现思路。你觉得“周边决策助手”下一个最值得做的方向，是亲子、约会、旅行，还是校园？