ACL 2026 Main | 不只是调用地图API，Spatial-Agent让大模型生成可执行地理分析工作流

大语言模型在地图、城市、交通等空间领域的应用越来越广泛。对于这些场景来说，问题往往不只是 “查一个地点” 或 “调用一次路线 API” 就能解决的，而是需要把用户的自然语言问题组织成一段可执行、可验证的地理分析流程。

比如，用户问的可能已不再是 “附近有什么餐厅”，而是 “在某个区域内，哪些餐厅同时满足距离、评分、营业时间和路线约束”；也不再只是 “从 A 到 B 怎么走”，还可能包括多站点行程、时间窗口和交通方式限制。这类问题通常没有现成答案，需要先确定空间范围，再组织对象、关系、度量和工具调用。

Spatial-Agent 讨论的正是这一类地理空间分析任务。它希望 LLM agent 在调用地图、搜索和路线工具之前，先形成一套可以检查的分析工作流：问题中有哪些空间对象？哪些是条件？哪些是最终要计算的指标？这些步骤应该按什么顺序组织起来？

• 论文标题：Spatial-Agent: Agentic Geo-spatial Reasoning with Scientific Core Concepts
• 论文链接：https://arxiv.org/abs/2601.16965
• 代码：https://github.com/ecerybao/Spatial-Agent

1. 为什么地图问答不等于地理空间分析？

单步地图 API 通常适合回答事实型问题。例如输入一个地点名，返回地址、评分、经纬度等信息；或者输入起终点，返回两点之间路线。这些能力有用，也是大多数地图应用的基础。

但如果遇到稍微复杂一点的地理空间分析问题：以 “某个区域内某类设施的比例是多少” 为例，如果先对全城数据做聚合，再把结果拿去套一个空间范围，和先筛出目标区域、再在这个范围内计算比例，得到的结果完全不同。LLM 可能给出两种看似合理的分析流程，但从地理分析角度看，只有其中一种计算得到的答案和用户问题匹配。

LLM 直觉流程与正确空间流程对比

这也是通用 Agent 在这类任务上容易出错的原因。它可以生成一串 thought-action-observation，也可以顺利调用 geocoding、place search、routing 等工具；但问题在于，工具调用本身不出错并不能保证分析顺序正确。对于复杂 POI 检索、空间过滤、多点路线规划和时间约束任务，组织顺序一旦出错，后面的结果再完整也会偏离原问题。

2. Spatial-Agent：

把自然语言问题转成 GeoFlow Graph

Spatial-Agent 的做法，是在自然语言问题和工具调用之间加入一个中间层：GeoFlow Graph。这个图不是普通的思维链文本。图中的节点对应空间概念，边表示概念之间的转换关系；Agent 随后按图上的依赖关系去调用对应工具。这样一来，Agent 不会直接从一句话跳到答案，而是会先把问题拆成一组有地理含义的分析步骤。

可以把它理解为一种 “先搭分析骨架，再执行工具” 的方式。地图 API 仍然很重要，但它只负责完成工作流中的某些操作；决定答案是否正确的，是这些操作是否围绕这个空间问题被有序的组织起来。

3. 理论根基：来自 GIScience 的 

core concepts 与 functional roles

这篇工作借用了 GIScience 里两类长期积累下来的东西：一类用来描述空间信息本身是什么，另一类用来描述这些信息在分析过程中起什么作用。

第一类对应 core concepts of spatial information。Goodchild 在 1992 年提出 Geographical Information Science 时，已经把 GIS 从单纯软件系统问题推进到科学问题层面。Kuhn 在 2012 年进一步整理出 location、field、object、network、event 等空间信息核心概念，用来描述地理现象的基本组成。

第二类更接近 “分析流程里的角色”。Scheider 等人的 core concept data types 工作，把这些空间概念和有效的数据转换联系起来；后续 geo-analytical question-answering 研究则强调，很多地理问题的答案要通过 GIS workflow 计算出来。Xu、Scheider 等人进一步把地理分析问题解释为 concept transformations，并用 functional roles 描述一个概念是在限定范围、充当条件、提供支撑对象，还是作为最终度量。

Spatial-Agent 沿用了这条线索。它会识别问题中的 Location、Object、Field、Event、Network、Amount、Proportion 等概念，也会标出 Extent、Temporal Extent、Sub-condition、Condition、Support、Measure 等角色。前者回答 “问题里有什么”，后者回答 “它们在这次分析里负责什么”。

4. 方法：从概念抽取到工具执行

GeoFlow Graph 之所以必要，是因为很多地理问题的难点不在某一个工具的执行，而在工具及其执行结果之间的依赖关系。系统需要知道先找地点还是先筛范围，先构建路线还是先判断候选 POI，最后的 measure 又依赖哪些中间结果才能得到。

在 Spatial-Agent 中，处理流程大致有四个环节。首先，系统会从自然语言中找出地点、对象、事件、网络和度量目标，并为它们分配功能角色。这样，问题不再只是若干文本片段，而被整理成可以进入地理分析的单元；然后，系统会参考一组预先验证过的 macro-templates。这些模板对应地理任务中频繁出现的模式，例如 “筛选 - 聚合 - 度量”“对象到距离场”“路线优化”“位置到方位分类”。模板不替模型写答案，主要作用是帮助它避开明显不合理的转换顺序；有了概念、角色和候选模板后，系统构建 GeoFlow Graph。这个图需要满足操作顺序、类型兼容性、数据可用性和连通性等约束。图必须既符合语言问题，也能落到后续工具执行；最后，图上的转换关系会被映射到 geocoding、place search、routing、distance matrix、spatial filtering、trip optimization 等操作。系统会记录中间状态，并基于工具返回的结果生成最终回答。

Spatial-Agent 框架

这种设计能够支持执行后的检查：系统到底识别了哪些空间概念，哪些条件先被处理，最终答案依赖了哪些中间结果。对于地图类 agent，这比只看一段自然语言推理更容易定位问题。

5. 实验：工作流约束带来

更稳定的 agent 表现

论文在 MapEval-API 和 MapQA 两个 benchmark 上评估了 Spatial-Agent。前者覆盖 Place Info、Nearby、Routing 和 Trip 四类 API-based 地图任务，涉及 54 个国家的 180 个城市；后者来自 OpenStreetMap，包含开放域地理空间问答。实验结果可总结为以下三点：

实验结果速览：

第一，MapEval-API 上的提升很明显。Spatial-Agent + GPT-4o-mini 的总体准确率达到 45.15%，相比 MapEval API baseline 的 23.00% 有 96.30% 的相对提升。换成 GPT-5 模型后，整体准确率进一步达到 71.88%。这说明在需要多步规划的地图任务里，给 agent 一个地理分析工作流的范式，比直接让模型边想边调工具更可靠。

第二，MapQA 上的结果说明方法不只依赖某一个闭源模型。Spatial-Agent + GPT-4o-mini 取得 61.45% 的总体准确率；开源模型设置下，LLaMA-70B 版本达到 62.45%，Qwen2.5-72B-Instruct 版本达到 61.45%。这组结果说明系统的设计可以迁移到不同模型家族。

第三，GeoFlow template 不是可有可无的工程细节。消融实验中，去掉模板组合后，Spatial-Agent + GPT-4o-mini 在 MapEval-API 上的准确率从 45.15% 降到 39.32%。也就是说，预先验证过的地理分析模式确实在帮助模型少走弯路，生成更多正确的 GeoFlow Graph。

图：不同方法在 MapEval-API 各类任务上的平均查询延迟，所有方法均使用 GPT-4o-mini。Direct LLM 延迟最低，但缺少工具 grounding；在 agentic 方法中，Spatial-Agent 在 Routing 上最快，在 Nearby 和 Trip 上与 ReAct 接近。

错误分析指出：系统的失败更多集中在执行层，例如同名地点误匹配、POI 信息缺失、营业时间或路线数据不完整。这个结果说明，当空间分析流程被正确构建之后，外部地理数据和 API 质量会成为新的瓶颈。

图：论文人工分析了 68 个 MapEval-API 错误样例。Data Quality Issues（45.6%）和 Search Result Mismatch（33.8%）占主要比例，均发生在执行阶段；Concept & Role Assignment 和 Response Generation 各占 10.3%。

6. 结语：不要把它理解成

泛化的 “空间推理” 口号

Spatial-Agent 的重点不是宣称大模型突然学会了所有意义上的空间推理。视觉、机器人、3D 理解等领域早已有各自的空间问题和技术路线；这篇工作处理的是更具体的一类任务：地理空间问答和 GIS-style analysis workflow。

它的研究价值在于，把 GIScience 中关于 core concepts、functional roles 和 workflow composition 的理论，接到了 LLM agent 的中间表示与执行过程中。这样，agent 在回答复杂地图问题时，不会停留在把若干 API 串起来这一步，而会先形成一张能被验证和执行的 GeoFlow Graph。

当然，这项工作仍然有局限性。外部地理空间 API 的数据质量会影响系统表现，模板库也不可能覆盖所有地理分析模式；细粒度概念和图结构标注仍需要人工成本。后续值得继续推进的方向包括：更多语言环境、更专业的地理任务，以及和复杂空间分析工具链的结合。

总的来说，Spatial-Agent 给出的启发是：当 agent 进入一个有成熟理论和工具体系的领域时，单靠通用规划能力往往不够。真正需要处理的是，如何把这个领域里已有的理论和分析方法，变成模型可以理解和使用的中间表示。

相关参考文献：

• Goodchild, M. F. (1992). Geographical information science. International Journal of Geographical Information Systems, 6 (1), 31-45.
• Kuhn, W. (2012). Core concepts of spatial information for transdisciplinary research. International Journal of Geographical Information Science, 26 (12), 2267-2276.
• Scheider, S., Meerlo, R., Kasalica, V., & Lamprecht, A. L. (2020). Ontology of core concept data types for answering geo-analytical questions. Journal of Spatial Information Science, 2020 (20), 167-201.
• Scheider, S., Nyamsuren, E., Kruiger, H., & Xu, H. (2021). Geo-analytical question-answering with GIS. International Journal of Digital Earth, 14 (1), 1-14.
• Xu, H., Nyamsuren, E., Scheider, S., & Top, E. (2023). A grammar for interpreting geo-analytical questions as concept transformations. International Journal of Geographical Information Science, 37 (2), 276-306.

文章来自于"机器之心"，作者 "Riyang Bao, Cheng Yang, Dazhou Yu, Zhexiang Tang, Gengchen Mai, Liang Zhao"。