让 AI Agent 回答“这个地址附近有哪些建筑或场所”并不等于把整份开放地图数据复制到聊天上下文。Fused 的官方 Overture Maps MCP 示例给出了一条更可审查的路线：Agent 只调用几个输入明确、结果受限的工具；发布索引、Parquet 扫描与几何解码留在数据系统中。对于 GIS 团队，验收重点由“模型会不会回答”转为“它查的是哪个发布、缩小了哪些分区、按哪个标识符定位对象，以及返回边界是否可控”。

数据口径与可核验事实

Fused 的示例把 Overture Maps 开放数据包装成运行在 Fused Canvas 上的 MCP 工具，目标是让 Agent 按地点、地址、边界框或 GERS ID 查询 buildings、places 等数据，而不是向对话传递原始地理数据。示例将两类检索入口明确分开：按地点、地址、bbox、release 或 theme 发现数据使用 STAC catalog；按 GERS ID 做历史或精确对象查询使用 registry。

示例说明，一个 MCP server 由四个 UDF 组成，每个 UDF 对应一个 Fused job。发布后，每个 UDF 有 HTTP endpoint，Canvas 同时提供 OpenAPI specification；工具结果则限制为固定列和有界行数，避免把对象存储扫描和大几何直接塞进 Agent 上下文。

对于目录检索，示例读取 https://stac.overturemaps.org/catalog.json 作为发布索引，而不是把 S3 路径写死。空间查询使用 collections.parquet 作为空间索引，只选择与输入 bbox 相交的 Parquet partitions；它再在选中的文件中读取数据。对于 GERS，示例读取 registry manifest 的 50 个已排序文件，并用 binary search 按 max_id 找到可能包含目标 ID 的单个文件，随后才读取完整 geometry。

地址输入会先交给 Nominatim geocode 成 bbox。示例列出的 Overture 主题为 buildings、places、transportation、addresses、base 和 divisions；导出的工具包含 overture_list_releases、overture_stac_search、overture_bbox_query 与 overture_gers_lookup。其中 bbox 工具默认 max_rows 为 200，正是控制模型上下文与查询成本的一个接口级边界。

研究的八项固定口径

  1. Fused 示例将 Overture 开放数据封装为运行在 Fused Canvas 上的 MCP 工具。
  2. Agent 可按地点、地址、bbox 或 GERS ID 查询 buildings、places 等对象。
  3. STAC catalog 用于按地点、地址、bbox、release 或 theme 发现数据。
  4. GERS registry 用于按 GERS ID 进行历史或精确对象查询。
  5. 一个 MCP server 由四个 UDF 组成，每个 UDF 对应一个 Fused job。
  6. 示例从 stac.overturemaps.org/catalog.json 读取发布索引，不硬编码 S3 路径。
  7. collections.parquet 先筛选与 bbox 相交的 Parquet partitions。
  8. GERS manifest 含 50 个已排序文件，lookup 先按 max_id 二分定位文件；bbox 返回默认最多 200 行。

核心机制：把“查地图”拆成四个可验证步骤

第一步是解析意图，但不让模型直接拼接对象存储路径。地址、地名或坐标范围应先规范化为 bbox，并记录地理编码器、输入文本、坐标系与时间。第二步是发现发布：用 STAC 查询得到 release、theme、collection 与覆盖范围。第三步是缩小读取：用 collections.parquet 确定相交分区，再执行 GeoParquet 查询。第四步才是把紧凑的字段集和明确的行数上限返回给 Agent。

GERS 路径解决的是另一类问题：业务系统已有稳定对象 ID 时，不需要反复做空间搜索。示例先用排序 manifest 的 max_id 选择候选 registry 文件，再取该 ID 的完整 geometry。这种两阶段读取使“从哪里来的对象”可以回到 release 与 registry 文件核验，也避免让每一次问答扫描所有历史文件。

GIS 场景：把可追踪查询交给 Agent，把判断留给人

例如，分析师询问“某地址周边 500 米内有哪些公共场所和建筑”。系统先展示地理编码所得 bbox、选用的 Overture release、主题、字段、行数上限和工具名称；确认后才调用 bbox 查询。Agent 可以据此生成候选清单或摘要，但不得把结果描述为权威的营业状态、产权状态或实时现场情况。

若工单提供 GERS ID，工作流应切换到 registry lookup，并把输入 ID、命中的 registry 文件、release 与返回对象 ID 记入日志。这样，后续发现位置或类别变化时，团队能区分是 Agent 的语言解释问题、地理编码范围问题，还是数据发布版本变化。

技术路径

最低实现可以保持很小：一个只读 MCP server、目录查询、bbox 查询、GERS 查询与 release 列表四个工具足够验证链路。为每个工具固定 JSON schema，要求 bbox、theme、release、返回字段和 max_rows 显式出现。工具层负责限制范围、行数、主题和字段；Agent 层只负责选择工具、解释有证据的结果，并在数据不覆盖问题时说清楚。

上线前做三类回归：同一 bbox 在同一 release 下应给出可复跑的统计；相交分区列表应能解释查询为何只读这些文件；抽样 GERS ID 必须能从 manifest 定位到文件并匹配返回对象。不要以聊天答案通顺替代这些检查。

风险与局限

示例是开发者教程，不是面向所有业务的生产 SLA。Nominatim 的地理编码结果、bbox 的大小、Parquet 分区策略、主题 schema 和 Overture 发布节奏都会影响结果。max_rows=200 能保护上下文，却也可能截断密集区域；工具应返回截断标志、实际 release 和下一步缩小 bbox 的建议。

公开地图数据也不等于适合无约束查询。涉及个人位置、关键设施、敏感资产或受限业务规则时，应使用授权数据源、最小范围、访问控制和审计日志。任何由 Agent 形成的选址、规划、执法或应急建议，都需要专业人员根据完整数据和业务规则复核。

检查清单

  1. STAC discovery 与 GERS lookup 是否被明确分成不同工具和不同证据链？
  2. 每次查询是否保存地址或 bbox、release、theme、字段、行数上限和实际返回条数？
  3. 是否从 catalog 发现数据，而非在代码中固定对象存储路径？
  4. bbox 查询是否先验证相交 Parquet partitions，再读取对象？
  5. GERS ID 是否能回溯到 manifest、候选文件和返回对象？
  6. 工具是否返回截断标志，并限制 geometry 与属性进入聊天上下文？
  7. 高影响业务结论是否保留人工复核、权限和审计？

结论

Fused 的 Overture MCP 示例说明，Agent 接入空间数据并不需要把数据湖变成聊天附件。STAC 负责发现发布，空间分区负责缩小扫描，GERS registry 负责精确定位，MCP 工具负责控制输入输出。GIS 团队应优先验收这条数据与证据链，再扩大 Agent 能解释的业务问题。

资料来源