从 GIS 到 Spatial Agent：MCP 如何重新定义 GIS 的 AI 入口

当 AI 不再只是回答 GIS 问题，而是开始发现数据、理解图层、调用空间分析并生成地图，GIS 与 AI 的关系正在发生什么变化？

近年来，大模型与 GIS 的结合越来越深入。

最初的应用主要集中在知识问答和代码辅助，例如让 AI 解释空间数据、生成 ArcPy 脚本、编写 SQL、分析 GIS 错误日志，或者根据自然语言给出操作步骤。

这些应用降低了 GIS 的使用门槛，但从技术架构来看，它们仍然属于一种比较典型的 "AI 辅助 GIS" 模式。

AI 负责理解和生成内容，真正的数据访问和空间计算仍然由用户或者传统 GIS 应用完成。

而随着 MCP（Model Context Protocol）进入 GIS，另一种架构开始出现：

GIS 能力本身，可以成为 AI Agent 能够发现、理解和调用的工具。

这件事情真正值得关注的地方，并不是多了一个聊天窗口，而是企业 GIS 的能力开始拥有了一种面向 Agent 的标准化表达方式。

从这个角度看，MCP 更像是连接 AI Agent 与 Enterprise GIS Capability 的一层基础设施。

本文将从 MCP、ArcGIS Enterprise 以及 Agent 的关系出发，讨论这种变化可能给企业 GIS 架构带来的影响。

1. GIS 与 AI 的关系正在发生变化

传统 GIS 的工作方式非常明确：

复制代码

用户
  ↓
GIS 应用
  ↓
GIS 服务
  ↓
空间数据
  ↓
分析结果

用户通过 WebGIS、桌面 GIS、移动端或者业务系统访问 GIS。

如果需要进行空间分析，通常需要用户知道：

数据在哪里；
哪个服务包含目标数据；
哪个图层需要查询；
字段代表什么含义；
应该使用什么空间分析工具；
参数如何设置；
分析结果如何表达。

对于 GIS 专业人员来说，这套流程已经非常成熟。

但问题在于，GIS 的能力与 GIS 的使用门槛之间存在明显差异。

空间查询本身并不一定复杂。

真正复杂的是找到正确的数据、理解数据结构、选择合适的分析工具，并按照正确的方式执行。

这恰好是 Agent 可以介入的地方。

2. MCP 到底改变了什么？

MCP 的核心并不是让大模型获得更多知识。

它解决的是另外一个问题：

AI 应用如何以标准化方式发现并调用外部系统提供的能力？

从架构上看，可以把传统 GIS 与 Agent 的关系理解成：

复制代码

传统模式

用户
 ↓
GIS 应用
 ↓
REST API / SDK
 ↓
GIS 服务
 ↓
数据

而增加 MCP 后：

复制代码

Agent 模式

用户
 ↓
AI / Agent
 ↓
MCP
 ↓
GIS Capability
 ↓
GIS Service
 ↓
Enterprise Data

这里最重要的是中间这一层：

复制代码

GIS Capability

它可以是：

数据查询；
地图渲染；
地理编码；
反向地理编码；
路径分析；
地理处理；
空间统计；
自定义 GP Task。

因此，MCP 并没有替代 GIS 服务。

相反，它建立了一种新的调用方式：

让 Agent 能够使用已经存在的 GIS 能力。

3. MCP 与 REST API 并不是替代关系

这是理解 MCP 在 GIS 中价值的一个关键点。

ArcGIS Enterprise 本身已经拥有成熟的 REST API、SDK、Feature Service、Map Service、Geoprocessing Service 和 Network Analysis 等能力。

那么为什么还需要 MCP？

因为二者面向的对象不同。

能力	REST API	MCP
主要使用者	程序员、应用程序	AI Agent
调用方式	Endpoint + 参数	Tool + Schema
能力发现	通常需要预先知道接口	可以动态发现
数据理解	由程序负责	Agent 可以结合描述信息理解
参数组织	开发者编码	Agent 根据工具定义构造
调用结果	面向程序	可以进一步交给模型解释
典型场景	系统集成	Agent 工作流

因此，更准确的理解是：

REST API 解决"程序如何访问 GIS"，MCP 则进一步解决"Agent 如何发现并使用 GIS 能力"。

MCP 并不要求企业重新建设一套 GIS。

它更像是在现有 GIS 服务之上增加了一层面向 Agent 的能力描述和调用机制。

4. 从"发现"开始：Agent 首先要知道 GIS 里有什么

如果让一个 Agent 直接面对企业 GIS，它首先会遇到一个问题：

企业 GIS 里面到底有什么？

传统应用往往已经知道服务地址。

例如：

复制代码

https://server/arcgis/rest/services/Road/FeatureServer/0

但是 Agent 并不知道这个地址。

因此，Agent 需要先进行内容发现。

MCP in ArcGIS Enterprise 提供了 Portal 内容搜索能力，可以搜索企业 Portal 中的相关资源。

这里有一个非常重要的设计：

不是 Portal 中的所有内容都会自动成为 Agent 的可用资源。

当前 MCP 文档中的内容搜索机制使用 mcp 标签来确定哪些 Portal 项目进入 MCP 的内容范围。

这实际上形成了一道数据治理边界：

复制代码

Enterprise Portal
       │
       ├── 普通内容
       │
       ├── 内部业务数据
       │
       ├── 核心数据
       │
       └── MCP 可用内容
                │
                ▼
            MCP Server
                │
                ▼
              Agent

这比简单地把一个数据库账号交给 AI 要合理得多。

因为企业真正需要控制的并不是：

AI 能不能访问 GIS？

而是：

AI 可以发现哪些 GIS 内容？

5. 找到数据之后，还必须理解数据

这是整个架构中非常重要的一步。

假设 Agent 找到了一个 Feature Service：

复制代码

OBJECTID
NAME
TYPE
STATUS
VALUE
DATE

从程序角度看，这已经是一个完整的 Schema。

但对于 Agent 来说，这些字段名称并不一定能够表达完整的业务语义。

例如：

复制代码

TYPE = 1
TYPE = 2
TYPE = 3

Agent 并不知道：

复制代码

1 = 主干道
2 = 次干道
3 = 支路

同样：

复制代码

VALUE

到底代表面积、金额、人口，还是某种评价指标？

如果 Agent 在没有理解 Schema 的情况下直接构造查询，就可能得到一个形式正确、实际错误的结果。

因此，一个更加合理的 Agent 工作流应该是：

复制代码

Search
  ↓
Describe Item
  ↓
Describe Layer
  ↓
Understand Schema
  ↓
Construct Query
  ↓
Execute Query

MCP in ArcGIS Enterprise 中提供的 describe_item 和 describe_layer，正是承担了这一层能力。

其中，describe_layer 可以进一步获取字段、字段类型、别名、描述、示例值、空间范围和空间参考等信息。

因此：

数据描述并不是 GIS 的附属信息，而正在成为 Agent 使用 GIS 的基础上下文。

6. "先理解，再查询"是一个很重要的设计

MCP 中 query_data 与 describe_layer 之间存在明确的调用关系。

也就是说，不应该让 Agent 在不了解图层结构的情况下直接猜字段、猜值域并构造查询。

这其实和传统软件工程中的接口设计非常类似：

复制代码

先获取 Schema
      ↓
理解参数
      ↓
构造请求
      ↓
执行操作

而不是：

复制代码

猜字段
  ↓
猜参数
  ↓
直接执行

对于企业 GIS 来说，这种机制尤其重要。

因为 GIS 数据的业务语义往往比普通结构化数据更加复杂。

同样一个：

复制代码

CODE

在不同系统里可能代表：

行政区代码；
地块编号；
道路编号；
项目编号；
设施编码。

如果没有元数据和业务描述，模型无法可靠地判断。

因此，AI-ready GIS 的第一个前提并不是大模型，而是数据本身足够清晰。

7. GIS 数据治理正在出现一个新的维度

传统 GIS 数据治理通常关注：

数据质量；
数据标准；
空间参考；
元数据；
更新频率；
数据权限；
服务性能；
数据血缘。

进入 Agent 时代以后，还需要增加一个新的问题：

这个数据能不能被 Agent 正确理解？

也就是说，未来的 GIS 数据可能需要同时满足三种可读性：

复制代码

Human-readable
       ↓
人能够理解

Machine-readable
       ↓
程序能够读取

Agent-readable
       ↓
Agent 能够理解并正确使用

这意味着一个成熟的 GIS 数据集，除了字段名称和字段类型之外，还应该尽可能提供：

业务定义；
字段语义；
值域说明；
示例值；
数据时间范围；
空间范围；
更新周期；
数据质量说明；
使用限制；
权限边界。

这并不是为了"迎合 AI"。

而是因为当软件开始自动使用数据之后，数据自身的语义完整性变得更加重要。

8. 从查询数据，到真正执行 GIS

如果 MCP 只能搜索和查询数据，它仍然只是一个更智能的数据访问层。

真正产生变化的是 GIS 能力开始被拆解成 Agent 可以调用的 Tool。

例如：

类型	GIS 能力
内容	Portal 内容搜索
数据	Item / Layer 描述
查询	属性查询、空间查询、统计
地图	Map Image
位置	地理编码、反向地理编码
路径	Route Analysis
分析	Geoprocessing
扩展	自定义 GP Tool

于是，一个 Agent 可以不只是"告诉用户怎么做"。

它可以真正执行操作。

9. 一个 GIS Agent 的典型工作流

假设用户提出：

分析某区域周边 10 公里范围内的学校分布，并按照学校类型进行统计，最后生成一张地图。

这并不是一个简单的问答任务。

Agent 实际上需要完成一系列 GIS 操作。

复制代码

flowchart TD
    A[用户提出空间问题] --> B[Agent 理解任务]
    B --> C[搜索 Portal 内容]
    C --> D[获取 Item 信息]
    D --> E[获取 Layer Schema]
    E --> F[确定空间范围与字段]
    F --> G[执行空间查询]
    G --> H[统计分析]
    H --> I[生成地图]
    I --> J[组织分析结果]
    J --> K[返回用户]

从用户角度来看，整个过程可能只有一句话。

但在系统内部，它已经形成了一条完整的空间工作流。

这就是 Agent 与传统聊天机器人的区别。

聊天机器人主要负责生成回答。

Agent 则需要完成任务。

10. 自定义 GP Service 可能是企业 GIS 接入 Agent 的关键

对于真正的企业 GIS 来说，最有价值的能力往往不是基础查询。

而是已经沉淀多年的专业分析模型。

例如：

洪水淹没分析；
地质灾害危险性评价；
地震影响范围分析；
生态敏感性评价；
土地适宜性评价；
交通可达性分析；
地下管线风险分析；
资源承载能力评价。

这些模型很多已经以 Geoprocessing Service 的形式部署在 Enterprise 中。

MCP 的意义在于：

已经存在的 GIS 专业模型，可以进一步成为 Agent 能够调用的工具。

因此，企业不一定需要重新开发一套"AI GIS 算法"。

完全可以采用另一种思路：

复制代码

已有 GIS 专业模型
        ↓
Geoprocessing Service
        ↓
MCP Tool
        ↓
Agent
        ↓
自然语言任务

AI 负责理解任务和组织参数。

GIS 模型负责真正的空间计算。

这种分工反而更加适合企业生产环境。

11. AI 不应该替代 GIS，而应该调用 GIS

这是整个问题中最容易被误解的一点。

如果让大模型自己"推理"空间分析结果，它可能生成一个语言上非常合理的答案。

但空间分析并不是语言推理。

距离、面积、拓扑关系、空间叠加、路径成本、缓冲区、空间统计等结果，都应该由真正的空间计算引擎完成。

因此，一个可靠的 GIS Agent 应该遵循：

复制代码

AI
负责：
任务理解
意图识别
工具选择
参数组织
结果解释

GIS
负责：
数据访问
空间计算
地图渲染
地理处理
网络分析
结果生成

这是一种非常重要的边界。

AI 不应该替代 GIS 的空间计算能力。

相反，AI 的价值在于降低这些能力的使用门槛。

12. 从 GIS Application 到 GIS Capability

过去，企业 GIS 的建设通常围绕应用展开。

例如：

复制代码

自然资源系统
交通系统
应急系统
规划系统
地质系统

每个系统拥有自己的界面、业务流程和 GIS 功能。

未来可能逐渐出现另一种架构：

复制代码

flowchart TB
    A[AI / Agent]
    B[MCP Capability Layer]

    A --> B

    B --> C[Data Query]
    B --> D[Mapping]
    B --> E[Geocoding]
    B --> F[Routing]
    B --> G[Geoprocessing]

    C --> H[Enterprise GIS]
    D --> H
    E --> H
    F --> H
    G --> H

    H --> I[Spatial Data]
    H --> J[Business Data]
    H --> K[Real-time Data]

在这个架构中：

GIS 不再只是一个"系统"。

而逐渐成为一个：

Spatial Capability Platform

即空间能力平台。

地图只是其中一种能力。

空间查询、地理编码、路径分析、空间统计和专业地理处理模型，都可以成为上层应用调用的能力单元。

13. 这也是 MCP 真正值得关注的地方

如果把 MCP 仅仅理解成：

"让 AI 可以访问 ArcGIS。"

那么它的意义其实比较有限。

更准确的理解应该是：

MCP 为企业 GIS 能力进入 Agent 工作流提供了一种标准化连接机制。

它连接的是：

复制代码

AI / Agent
    │
    ▼
MCP
    │
    ▼
GIS Capability
    │
    ▼
Enterprise GIS
    │
    ▼
Enterprise Data

因此，MCP 的价值并不在于重新实现 GIS。

而在于：

让已经存在的 GIS 能力拥有新的调用者。

过去主要是：

复制代码

人 → GIS

现在逐渐出现：

复制代码

人 → Agent → GIS

甚至进一步发展为：

复制代码

Agent
 ├── GIS
 ├── 数据库
 ├── 文档系统
 ├── IoT
 ├── 业务系统
 └── 工作流平台

GIS 成为整个 Agent 工具体系中的一个专业能力域。

14. 从 GIS Agent 到 Spatial Agent

当 Agent 能够真正调用空间能力之后，一个更大的概念开始出现：

Spatial Agent。

它与普通 AI Agent 的区别并不是"增加了地图"。

而是它具备了空间认知和空间计算能力。

一个完整的 Spatial Agent 至少需要处理以下几个层面：

层面	典型能力
空间认知	位置、方向、距离、邻接、包含
空间检索	查询空间对象
空间推理	附近、沿线、影响范围
空间计算	Buffer、Overlay、Spatial Join
网络分析	Route、Service Area、OD
空间表达	地图、图层、统计图
空间决策	基于空间结果形成业务判断

MCP 本身并不等于 Spatial Intelligence。

但它提供了一条重要的连接路径：

让这些空间能力能够进入 Agent 的工具调用体系。

因此，可以把它理解为 Spatial Agent 基础设施中的一个组成部分。

15. 企业真正需要解决的不是"接不接 MCP"

技术落地以后，真正困难的问题通常不是部署 MCP Server。

而是：

哪些能力应该开放给 Agent？

企业可以建立一个分层的治理体系。

第一层：数据治理

明确哪些数据允许被 Agent 发现。

第二层：能力治理

明确哪些 GIS Tool 可以被调用。

第三层：权限治理

明确不同用户能够调用哪些数据和工具。

第四层：过程治理

明确哪些操作可以自动执行，哪些操作需要人工确认。

第五层：结果治理

明确结果如何验证、记录和追溯。

最终形成：

复制代码

Data Governance
       ↓
Capability Governance
       ↓
Permission Governance
       ↓
Workflow Governance
       ↓
Result Governance

这才是企业 AI GIS 真正需要考虑的问题。

16. AI 进入 GIS 后，日志的重要性反而更高

传统 GIS 系统记录：

复制代码

用户
请求
服务
时间
状态

但 Agent 进入之后，还需要进一步关注：

复制代码

用户提出了什么任务？

Agent 选择了什么 Tool？

访问了哪些数据？

使用了哪些参数？

调用了哪些 GIS 服务？

最终返回了什么结果？

是否经过人工确认？

这实际上要求 GIS 平台逐渐具备：

Agent Observability

即针对 Agent 调用链的可观测性。

这也是企业 GIS 从"能用 AI"走向"能够安全地使用 AI"必须解决的问题。

17. 一个值得关注的架构变化：Dynamic GIS Workflow

传统 GIS 系统中的工作流通常是预先定义的：

复制代码

输入
 ↓
步骤 1
 ↓
步骤 2
 ↓
步骤 3
 ↓
输出

Agent 更接近：

复制代码

任务
 ↓
理解任务
 ↓
发现能力
 ↓
选择工具
 ↓
执行
 ↓
判断结果
 ↓
决定下一步
 ↓
继续执行
 ↓
完成任务

这意味着 GIS 工作流可能从：

Static Workflow

逐渐走向：

Dynamic Workflow

例如：

"分析这次灾害对周边基础设施的影响。"

Agent 不一定预先知道需要哪些步骤。

它可能先查询灾害范围，再发现基础设施数据，然后判断需要进行空间相交分析，最后调用地图服务生成结果。

工作流由任务本身驱动。

这正是 Agent 架构与传统自动化脚本最大的区别之一。

18. GIS 开发人员的角色也会发生变化

如果未来大量 GIS 能力都能够被 Agent 调用，那么 GIS 开发人员的工作重点可能逐渐从：

开发一个又一个页面和按钮

转向：

建设可以被可靠调用的 GIS 能力。

例如：

数据层

建立高质量、语义完整的数据。

服务层

提供稳定、规范的 GIS 服务。

工具层

将专业分析模型封装成标准化能力。

MCP 层

将合适的能力暴露给 Agent。

治理层

控制权限、日志和调用范围。

最终形成：

复制代码

数据
 ↓
服务
 ↓
能力
 ↓
Tool
 ↓
Agent
 ↓
业务

GIS 开发的核心对象，也可能从：

Application

逐渐扩展到：

Capability。

19. 一个更加完整的 Enterprise GIS + Agent 架构

如果将上述内容组合起来，可以得到一个比较完整的技术架构：

复制代码

flowchart TB

    U[用户]

    A[AI Assistant / Agent]

    M[MCP Layer]

    C1[Portal Content]
    C2[Data Query]
    C3[Mapping]
    C4[Geocoding]
    C5[Routing]
    C6[Geoprocessing]
    C7[Custom GIS Tools]

    G[ArcGIS Enterprise]

    D1[Feature Service]
    D2[Map Service]
    D3[Image Service]
    D4[GP Service]
    D5[Network Analysis]

    DATA[(Enterprise Spatial Data)]

    U --> A
    A --> M

    M --> C1
    M --> C2
    M --> C3
    M --> C4
    M --> C5
    M --> C6
    M --> C7

    C1 --> G
    C2 --> D1
    C3 --> D2
    C4 --> G
    C5 --> D5
    C6 --> D4
    C7 --> G

    D1 --> DATA
    D2 --> DATA
    D3 --> DATA
    D4 --> DATA
    D5 --> DATA

这个架构里最重要的一层并不是 MCP 本身。

而是：

复制代码

GIS Capability Layer

MCP 只是把这一层能力连接到了 Agent。

20. MCP 之后，企业 GIS 需要重新思考什么？

从实际建设角度来看，我认为至少有五个问题值得提前考虑。

20.1 哪些数据可以被 Agent 发现？

不是所有数据都应该暴露。

需要建立明确的数据分类和授权体系。

20.2 哪些 GIS 能力适合做 Tool？

并不是所有 REST API 都适合直接暴露。

应该优先选择：

参数明确；
结果稳定；
业务边界清晰；
风险可控；
可以被验证；

的 GIS 能力。

20.3 数据有没有足够的语义？

如果字段只有：

复制代码

F1
F2
F3

而没有业务描述，那么 Agent 很难可靠使用。

因此，元数据和业务语义的重要性会进一步提升。

20.4 分析结果能否追溯？

对于生产业务，不能只保存最终答案。

还应该知道：

复制代码

使用了什么数据
使用了什么 Tool
使用了什么参数
执行了什么分析
生成了什么结果

20.5 AI 是否应该拥有写权限？

这是一个非常值得谨慎处理的问题。

查询和分析属于相对低风险操作。

但如果 Agent 可以：

创建数据；
修改属性；
发布服务；
删除数据；
执行批量更新；

那么权限模型和人工确认机制必须更加严格。

因此，在企业环境中：

Read-only GIS Agent 往往会比完全 Autonomous GIS Agent 更容易首先落地。

21. 从这个角度看，MCP 可能只是一个开始

MCP 真正值得关注的原因，不是它提供了几个 GIS Tool。

而是它让一个更大的问题变得具体：

企业 GIS 能不能成为 Agent 可以调用的基础设施？

如果答案是肯定的，那么未来的 GIS 平台可能同时服务于两类使用者：

复制代码

传统用户
   ↓
GIS Application

智能用户
   ↓
AI Agent

两者最终访问的仍然是同一套：

复制代码

Enterprise Data
Enterprise GIS Services
GIS Capability

变化的是交互方式。

22. 从 GIS 到 Spatial Intelligence

过去几十年，GIS 解决的核心问题是：

如何存储、管理、分析和表达空间数据。

下一阶段可能需要解决的是：

如何让智能系统真正理解和使用空间。

这两者并不矛盾。

GIS 提供：

权威空间数据；
空间计算能力；
专业分析模型；
地图表达；
空间服务。

AI 提供：

自然语言理解；
任务规划；
工具选择；
多步骤编排；
结果解释。

MCP 则承担二者之间的连接作用。

因此可以形成一个比较清晰的技术链：

复制代码

Enterprise GIS
      ↓
GIS Capability
      ↓
MCP
      ↓
Agent
      ↓
Spatial Reasoning
      ↓
Spatial Intelligence

这里需要强调：

MCP 不是 Spatial Intelligence。

它更像是让空间能力进入 Agent 体系的一条基础连接通道。

真正的 Spatial Intelligence，需要数据、模型、空间推理、计算能力和 Agent 协同共同形成。

23. 结语

MCP 的出现，并没有改变 GIS 的核心技术。

Feature Service 还是 Feature Service。

Map Service 还是 Map Service。

Geoprocessing Service 还是 Geoprocessing Service。

空间数据库也依然是空间数据库。

真正发生变化的是：

这些能力开始拥有了新的使用者。

过去，它们主要被 GIS 应用和 GIS 开发人员调用。

现在，它们开始可以被 Agent 发现、理解和组合。

这使企业 GIS 出现了一种新的可能：

复制代码

过去：

用户
 ↓
GIS 应用
 ↓
GIS 服务
 ↓
空间数据


未来：

用户
 ↓
AI Agent
 ↓
MCP
 ↓
GIS Capability
 ↓
GIS Services
 ↓
Enterprise Data

这并不是用 AI 替代 GIS。

更准确地说，是：

让 AI 负责理解问题，让 GIS 负责空间计算，让 MCP 负责连接二者。

如果这一模式进一步成熟，企业 GIS 的价值边界也会发生变化。

GIS 不再只是一个需要用户主动打开、学习和操作的应用系统。

它可以逐渐成为企业智能系统背后的空间能力基础设施。

而真正值得 GIS 从业者提前准备的，并不是简单地增加一个 AI 聊天入口。

更重要的是重新审视：

数据是否足够规范？

语义是否足够完整？

GIS 能力是否能够被标准化调用？

空间分析模型是否可以成为可复用的 Tool？

权限、日志和审计体系是否能够支撑 Agent？

当这些基础条件逐渐成熟之后，AI 助手只是最终呈现出来的一种交互方式。

真正发生变化的，是企业 GIS 开始从：

Application-oriented GIS

走向：

Capability-oriented GIS

并进一步成为：

Agent-enabled Spatial Intelligence Infrastructure

这可能才是 MCP 进入 GIS 之后，真正值得关注的长期价值。

参考资料

从 GIS 到 Spatial Agent：MCP 如何重新定义 GIS 的 AI 入口

1. GIS 与 AI 的关系正在发生变化

2. MCP 到底改变了什么？

3. MCP 与 REST API 并不是替代关系

4. 从"发现"开始：Agent 首先要知道 GIS 里有什么

5. 找到数据之后，还必须理解数据

6. "先理解，再查询"是一个很重要的设计

7. GIS 数据治理正在出现一个新的维度

8. 从查询数据，到真正执行 GIS

9. 一个 GIS Agent 的典型工作流

10. 自定义 GP Service 可能是企业 GIS 接入 Agent 的关键

11. AI 不应该替代 GIS，而应该调用 GIS

12. 从 GIS Application 到 GIS Capability

13. 这也是 MCP 真正值得关注的地方

14. 从 GIS Agent 到 Spatial Agent

15. 企业真正需要解决的不是"接不接 MCP"

第一层：数据治理

第二层：能力治理

第三层：权限治理

第四层：过程治理

第五层：结果治理

16. AI 进入 GIS 后，日志的重要性反而更高

17. 一个值得关注的架构变化：Dynamic GIS Workflow

18. GIS 开发人员的角色也会发生变化

数据层

服务层

工具层

MCP 层

治理层

19. 一个更加完整的 Enterprise GIS + Agent 架构

20. MCP 之后，企业 GIS 需要重新思考什么？

20.1 哪些数据可以被 Agent 发现？

20.2 哪些 GIS 能力适合做 Tool？

20.3 数据有没有足够的语义？

20.4 分析结果能否追溯？

20.5 AI 是否应该拥有写权限？

21. 从这个角度看，MCP 可能只是一个开始

22. 从 GIS 到 Spatial Intelligence

23. 结语

参考资料

MCP in ArcGIS Enterprise

Model Context Protocol 官方文档

Model Context Protocol Specification

MCP Tools