[控场AI]
· 5 分钟阅读· 2,801 字

用MCP工具让AI代理规划波特兰步行路线

用MCP工具让AI代理规划波特兰步行路线

一条提示词经由MCP工具调用,让AI代理自主规划出真实的波特兰步行路线。

文章记录了开发者通过 Claude Code 接入 GeoAppify 的 MCP 服务,仅用一条提示词便生成完整波特兰步行路线的实验。代理共发起七次工具调用,GeoAppify 负责地点搜索与步行时间计算,模型则自主决定站点顺序和主题编排,总成本约 13 个 credits。实验的一个亮点是路线中同时包含 Mill Ends 公园(曾被称为世界最小公园)和一个宽度仅两英尺的公园,显示出模型基于地点语义属性做主题化组合,而非简单按距离排序。文章据此指出,MCP 协议让“模型编排 + 专业工具执行”的分工范式变得可行,降低了构建旅行规划代理的门槛。

当AI代理学会在现实世界里散步

你给AI一条提示词,它还给你的不再是文字或图片,而是一条真实存在于波特兰街头的下午散步路线。这条路线上的每一个地点都是真实的,每一段步行时间都是计算出来的,甚至连停留的顺序都不是人类安排的。

这正是MCP(Model Context Protocol)工具正在带来的变化。一位开发者通过Claude Code接入GeoAppify的MCP服务,只输入了一条提示词,就生成了一份完整的波特兰步行计划。整个过程只涉及几次工具调用,消耗约13个credits,却串联起了四个真实地点之间的空间逻辑。

One prompt in Claude code with GeoAppify MCP connected.

一次提示词,七次工具调用

这次实验的核心并不复杂:在Claude Code中连接GeoAppify的MCP服务器,然后让AI代理去搜索四类真实地点。代理一共发起了七次工具调用,GeoAppify负责查找地点位置和步行时间,而模型自己决定这些地点的参观顺序。

这种分工值得关注。地理位置和通行时间属于硬数据,交给专门的MCP工具处理;而行程编排、地点组合、先后顺序属于软决策,留给语言模型发挥。两者的边界清晰,各自做自己擅长的事。

最终结果是一条真正可走的步行路线。不需要人工在地图上一一标注,也不需要手动估算两个地点之间要走多久。一条提示词变成了一个真实空间里的行走方案。

MCP(Model Context Protocol) 是 Anthropic 于 2024 年底开源的一项协议,可以粗略理解为“AI 模型与外部工具之间的 USB-C 接口”。它定义了一套标准的客户端—服务器通信规范,让任何支持 MCP 的模型都能以统一方式调用文件系统、数据库、API 等外部能力。在 MCP 出现之前,开发者往往要为每个模型单独编写插件或函数调用适配层,模型之间的接口互不兼容。MCP 把工具发现(tools/list)、工具调用(tools/call)等动作抽象成协议原语,模型端只需实现一次客户端,工具端只需实现一次服务器,双方即可自由组合。本案例中的 GeoAppify 就是这样一个 MCP 服务器,它把“地点搜索”和“步行时间计算”包装成标准工具暴露给 Claude,模型据此完成了七次调用。

波特兰的奇怪公园们

这条路线里有个很有意思的站点:Mill Ends公园。代理自己检索到的数据显示,这里曾经被称为“世界最小的公园”。

The unusual park, Mill Ends.

但故事还没完。路线的第三站也是一个公园,而它的宽度只有两英尺。一个下午的散步路线里塞进了两个以“小”闻名的公园,而且还是一前一后,这种组合方式显然不是随机的,而是模型在理解地点特征后做出的选择。

Stop three is a park, two feet across.

这说明当AI代理拥有了结构化的地理数据访问能力后,它能够基于地点的语义属性进行筛选和串联,而不是简单地按照距离远近排列。Mill Ends的“前世界最小公园”标签和第三站“两英尺宽”的特征之间形成了一种主题上的呼应。

GeoAppify MCP在做什么

GeoAppify在这套流程中承担的是地理数据层的角色。它向AI代理暴露了地点搜索和步行时间计算的能力,让模型可以在推理过程中随时查询真实世界的位置信息。

GeoAppify found the places and walking times.

从技术架构上看,MCP协议的价值在这里体现得很清楚:它把外部工具的能力标准化,让Claude这样的模型能够以统一的接口去调用地理服务。开发者不需要为每个模型单独适配,也不需要在地图API和语言模型之间写大量胶水代码。

七次调用、约13个credits的成本结构也说明,这类任务的资源消耗是可控的。对于想要构建旅行规划代理的开发者来说,这是一个可以实际落地的参考方案。

文中提到的“约 13 个 credits”指的是 MCP 工具调用的计费单位。大多数第三方 MCP 服务(如 GeoAppify)按调用次数或返回数据量收费,credits 即其计费代币。一次地点搜索、一次步行时间查询通常各消耗一个或几个 credits,因此七次调用约 13 个 credits 属于典型量级。这种按用量计费的模式意味着代理式应用的运行成本与它实际调用的工具次数直接挂钩,开发者可以通过优化提示词、减少无效调用来控制开销。相较于调用大模型本身按 token 计费,工具侧的 credits 通常单价更低,但对于需要反复查询地理数据的规划类任务仍不可忽视,这也是评估一个 AI 代理方案能否规模化落地时必须考虑的因素之一。

对AI旅行代理的启示

这次波特兰步行实验展示的模式可以延伸到更广泛的旅行规划场景。关键不在于某个具体工具的优劣,而在于MCP协议让“模型编排 + 专业工具执行”这个范式变得可行。

地点搜索、路线计算、时间估算这些任务交给专门的MCP工具,模型专注于理解用户偏好、组合地点、生成叙事。这种分工比让模型直接处理所有事情要可靠得多。

另一个值得注意的点是模型在顺序安排上的自主性。它没有按照最简单的“最近优先”策略排列站点,而是根据地点特征做了主题化的组织。这意味着当AI代理拥有足够的工具支持时,它的规划能力可以超越机械优化,呈现出某种接近人类导游的编排思路。

对于正在探索AI代理应用边界的开发者来说,波特兰这条两英尺宽的公园路线或许比任何技术文档都更能说明问题:当模型能够接触真实世界的数据和工具,它能做的事情远比生成文本要多得多。

“模型编排 + 专业工具执行” 是当前 AI 代理设计中的一种主流范式,也被称为 orchestrator–worker 模式。核心思路是:语言模型不直接“硬算”事实性问题(例如两点间步行几分钟、某公园具体在哪条街),而是负责理解意图、拆解任务、决定调用哪个工具、再对返回结果进行组合与叙事。事实性、可验证的计算交给确定性工具完成,模糊的、需要权衡的决策留给模型。这种分工的优点是可靠性高——工具不会“幻觉”,模型则专注于它真正擅长的语义理解与规划。旅行规划正是这一范式的理想场景:地理数据要求精确,行程编排又需要人性化取舍,两者天然适合拆分到不同层级执行。

#MCP工具#AI代理#Claude Code#GeoAppify#旅行规划#Model Context Protocol#步行路线
分享:

相关推荐