UC 2026 之后，Esri 希望 AI “使唤”GIS吗？

不是不要软件的界面，而是界面不再拥有系统的主权。

一、今年的 Esri UC，没有我预想的答案

2026 年的用户大会于 7 月 13 日至 17 日在圣迭戈举行。老时间，老地点。每年的会议第一天，Jack Dangermond 老先生会在 Plenary 上展示 ArcGIS 的最新进展：更大的数据、更漂亮的地图、更完整的数字孪生。还有这四年了，都绕不开的 AI。不管AI 不 AI 的，祝愿Jack好身体，好精力，继续在台上行走20年！

Esri UC 2026 官方 banner

图：Esri UC 2026 官方活动 banner。

Jack Dangermond 在 Esri UC 2026 Plenary 上演讲

图：Jack Dangermond 在 Esri UC 2026 Plenary 演讲现场。（来源：Esri 官方社交媒体）

Esri UC 2026 把 Agentic GIS、MCP 和智能助手都摆上了台面；但现场和社交媒体上的真实反应，更像是“听到了，但还没被说服”。

今年最值得我注意的，不是又多了几个聊天框，几个影像识别的模型（多少有点老生常谈）进化与否，而是三个变化。

第一，6 月 29 日，Esri 为 ArcGIS Location Platform 推出了 MCP 支持 beta。外部 Agent 已经可以发现和调用地理编码、路径规划、高程和静态地图服务，还能在一次对话里串联多个位置服务（这个MCP支持实在是有点太慢）。

第二，ArcGIS Maps SDK for JavaScript 新增了面向“agentic mapping applications”的 AI components。开发者可以把导航 Agent、数据探索 Agent、帮助 Agent 和自然语言界面装进一个 Web 地图应用。ArcGIS Instant Apps 也推出了 Data Explorer beta，让用户直接对着地图提问、筛选和做空间关系查询。

第三，ArcGIS Pro Assistant 3.7 beta 不再只是查帮助文档。它可以执行一批受支持的桌面操作，生成 ArcPy、SQL Query Layer 和 OpenCypher，还允许开发者通过 Pro SDK 增加 Custom Actions。

所以，如果还说 Esri “没有看到 Agent”，显然不准确。它已经看见了，而且开始认真建设。

不过，如果把 Plenary 上真正落到具体模型名称、演示画面和参数细节的 AI 内容列出来，会发现它们大多仍集中在影像和地图识别工作流：GeoVLM 连接卫星影像与自然语言做目标检测和分割，Global Location Encoder 从 Sentinel-2 生成位置嵌入，Vivid Mosaic AI 做变化检测，Prithvi EO 2.0、Clay、DOFA 等开源遥感模型被集成进来。这些当然很有价值，但它们本质上是“让 GIS 分析师更快看懂影像”，而不是“让外部 Agent 把 GIS 当作可编排的基础设施”。Agent Builder、MCP beta、Pro Assistant 更像是在既有产品边缘开出的交互入口，还没有进入工程文件、许可模型和桌面核心能力的主干线。

社交媒体上对 Agent Builder、MCP 和 Pro Assistant 的反应，也比 Esri 期待的更冷淡。一部分人觉得“终于有点现代感”，更多人则在问：“这和我用 ArcPy 写脚本有什么区别？”“我的工程文件、复杂模型和桌面许可什么时候能被外部 Agent 真正访问？”

但仔细看这三条路线，会发现一个共同点：

AI 被请进了 ArcGIS 的房子，却还没有拿到重新设计这栋房子的权力。

Location Platform 的 MCP 目前开放的是少量云端位置服务，不是企业 GIS 的全部数据、分析、业务状态和审计能力；JavaScript Agent 围绕预先配置好的 Web Map 工作；Pro Assistant 则被嵌入 ArcGIS Pro 的 Pane、Action 和 SDK 扩展体系。Esri 官方也明确说明，复杂多步骤工作流目前还不能靠一次请求完成。

这不是技术落后，而是路径选择。

Esri 的优势恰恰来自 ArcGIS Pro、Map Viewer、Experience Builder、Instant Apps、Web Map、Portal Item 和整套用户许可体系。Ta当然不会轻易告诉客户：“这些界面和操作流程以后都不重要了。”

Salesforce 可以在今年大声呐喊：“你为什么还要再次登录 Salesforce？”因为它决定把能力暴露为 API、MCP 工具和 CLI，让界面变成一种可选渠道。所以Salesforce敢拥抱headless。

这里先解释一下 Headless。

它不是“没有界面”，而是把核心能力从固定界面里拆出来：数据、分析、权限、流程这些真正重要的东西，先作为可被程序调用的服务或工具存在；界面只是其中一种入口，可以有，也可以按需临时生成。

放到 GIS 里，意思就是：地图、分析、数据访问和业务流程，不再只能在某个固定工作台或 Web 页面里完成，而是可以被 Agent、CLI、API、其他业务系统甚至临时生成的小应用直接调用。

“你为什么还要打开ArcGIS pro？”对 Esri 来说，这句话更难说出口。

二、两种范式：给旧软件加 Agent，还是为 Agent 重建底座

今天大家都在谈 Agent，但其实存在两条完全不同的技术路线。

第一条路线，是Assistant-first（助手优先，或者副驾优先）：

• 保留原来的软件、菜单、工程和内容体系；
• 在 Map Viewer、ArcGIS Pro、StoryMaps 等产品里加入助手；
• 让 AI 帮用户找命令、写表达式、生成代码、触发已有操作；
• 用户仍然在产品预设的界面和流程里工作。

这条路线很现实。它能保护既有用户习惯、许可体系和产品资产，也更容易控制风险。Esri 现在的主线明显偏向这里。

第二条路线，是Headless-first（我翻译成能力优先）：

• 数据、分析、地图、流程和权限先成为独立、稳定、机器可调用的能力；
• CLI、OpenAPI、SDK、MCP 都只是它的不同入口；
• Agent 可以根据任务临时生成一个界面，也可以根本不生成界面；
• 传统 GIS 工作台只是众多客户端之一，不再是业务逻辑唯一的容器。

这两条路线表面都用了 AI，背后的权力结构却完全不同。

Assistant-first 是“AI 帮你操作软件”。

Headless-first 是“软件把能力交给 Agent 编排”。

前者主要提高操作效率；后者会改变 GIS 应用的生产方式。

三、真正的变化：以后不是先建应用，再让用户使用

过去做一个企业 GIS 应用，通常是这样的：

先做需求调研；
设计数据库；
配置服务和图层；
开发一套 Web 界面；
上线后培训用户；
需求一变，再走一轮开发。

这套方式最昂贵的部分，经常不是空间分析，而是把一个临时业务需求固化成一套长期维护的页面。

Agent 出现后，顺序可能反过来。

用户先说：

“把昨晚更新的管线和施工红线做一次空间相交，按风险等级着色，给项目经理做一个能筛选、能点查、能导出清单的内部应用。每天早上自动更新，有新增冲突就通知我。”

Agent 随即完成：

• 查询用户有权访问的管线和红线图层；
• 执行 select-by-location 或 spatial join；
• 保存分析参数、输入版本和输出图层；
• 生成专题样式、图例和地图配置；
• 生成一个 React/MapLibre Web 应用，或者一个无需界面的定时工作流；
• 通过组织内部的 Docker 环境部署；
• 把每次运行和结果变化写进审计链。

如果用户使用 WorkBuddy、Codex 或其他桌面 Agent，这个过程甚至不必发生在一个 GIS 工作台里。Agent 可以通过 CLI 先探测能力、运行工作流，再按需生成：

• 一个带地图和筛选器的内部 GIS SaaS；
• 一个手机端巡检小程序；
• 一个只有命令行和定时任务的无界面流程；
• 一个嵌进现有 OA、资产系统或项目门户的地图组件；
• 一次性的分析页面，用完即关；
• 一个长期运行、可交接、可审计的业务协作应用。

当然，“瞬时生成”不等于“无需测试即可生产上线”。Agent 可以在几分钟内搭出可运行应用，但正式发布仍然需要权限确认、验收、部署和运维。

真正被压缩的，是从业务意图到可运行软件之间那段重复劳动。

四、这才是 GIS 底座的价值：应用可以临时，事实不能临时

如果 Agent 已经会写 React、会调用地图 SDK、会生成工作流，企业还需要什么平台？

答案不是再买一个低代码页面编辑器，而是一套 Agent 不能随意篡改、也不能绕过去的 GIS 底座。

我们把它概括成一句话：

应用可抛，事实不可抛。

一个临时应用今天生成、明天删除，没有关系。但下面这些东西不能跟着消失：

• 权威空间数据和原始文件；
• 图层、字段、坐标系、来源与版本；
• 地图样式、图例和发布记录；
• 空间分析的输入、参数、输出和执行者；
• 业务对象的状态变化；
• 多人协作中的草稿、冲突、提交与责任主体；
• 哪个用户或 Agent 在什么时间访问、分析、导出过什么数据；
• 恢复系统所需的数据库、对象资产和配置备份。

这也是我们开发极海 GIS 底座时，真正想解决的问题。

它不是又一个员工每天登录的 GIS 工作台，而是隐藏在临时应用、Agent、业务系统和地图界面背后的空间数据与过程责任底座。

在这套底座里：

• PostGIS （开源的）保存权威空间对象和业务关系；
• 本地对象存储保存原始文件、瓦片、附件和导出资产；
• MapLibre （开源的）与矢量瓦片服务负责 Web 可视化；
• 空间分析以白名单工具和可复现工作流运行；
• 观测记录、状态变更事件和过程账本分别保存现场事实、业务状态变化与全过程责任链；
• 多人可以离线编辑草稿、同步、发现冲突，再原子提交为正式业务记录；
• 所有能力默认可以在客户本地 Docker 环境部署、备份和恢复；
• Agent 只能通过受控契约工作，不能直接拿数据库万能钥匙。

这套能力组合起来，才可能让 Agent 快速生成不同形态的 GIS 应用，而不把企业的数据安全和责任链一并“生成掉”。

五、ArcPy 和 PyQGIS 为什么仍然不等于 Agent 底座

ArcPy、ArcGIS API for Python、PyQGIS 都非常强。它们当然是 Headless GIS 的重要能力池。

问题不在于它们能不能运行 buffer、overlay 或空间连接，而在于：一个能运行算法的库，不自动等于一个可以放心交给 Agent 的企业契约。

传统脚本通常继承运行账号能够访问的资源。企业完全可以通过操作系统、数据库角色和服务账号限制它，但这些限制并不会自动变成“这个 Agent 此刻只能读取某两个图层的三个字段，只能执行一种分析，输出最多一万条，并且每一步必须审计”的工具契约。

传统脚本也可以写日志，但日志不天然等于业务账本。你仍然需要回答：

• 谁授权了这次执行？
• 它使用的是哪一个版本的数据？
• 中间步骤是否成功？
• 输出图层从哪些输入派生？
• 结果有没有被人复核？
• 同一个请求重试，会不会重复写入？
• 权限中途被撤销后，长任务会不会继续？

这些不是 GIS 算法问题，而是身份、权限、幂等、事务、血缘和审计问题。

Agent 时代真正稀缺的，不是再提供一个“万能函数”，而是把专业能力变成边界清楚、失败可控、过程可追踪的动作。

ArcGIS Pro Assistant 生成 ArcPy 代码

图：ArcGIS Pro Assistant 3.7 beta 生成 ArcPy 代码的界面示例，说明传统脚本能力仍在核心位置。

六、MCP 还有没有必要？

这可能是今年最容易被说过头的话题。

一边是越来越多的平台推出 MCP；另一边，Codex 这样的桌面 Agent 在真实开发中，经常直接使用 shell、CLI、原生工具、插件或 API，并不一定依赖 MCP。

那 MCP 会不会只是一个过渡协议？

我的判断是：

MCP 有价值，但 MCP 不是底座。

Esri 在 2026 年推出 Location Services MCP beta，至少说明它已经成为主流平台愿意支持的一种 Agent 接入方式。对于需要动态发现工具、跨厂商连接远程服务的 Agent，MCP 确实降低了适配成本。

ArcGIS Location Platform MCP beta 官方博客配图

图：Esri 官方博客宣布 ArcGIS Location Platform 支持 MCP（beta），覆盖地理编码、路径、高程和静态地图服务。

但对一个本地运行的编码 Agent 来说，CLI 往往更直接、更稳定，也更容易调试；对传统 Web 应用来说，OpenAPI 仍然自然；对强类型工程项目来说，SDK 更好用；在封闭内网中，有时任务队列或消息接口比 MCP 更合适。

所以，一个可靠的 GIS 底座不应该押注“未来所有 Agent 都必须说 MCP”，而应该先拥有一套与协议无关的核心契约：

• 工具叫什么，输入输出是什么；
• 谁在调用，权限如何判定；
• 哪些动作会改变状态；
• 如何限流、幂等、取消和重试；
• 大文件和瓦片如何通过引用传递；
• 每次执行如何审计；
• 失败时暴露什么，不暴露什么。

在这套契约之上，MCP、CLI、OpenAPI 和 SDK 都只是适配器。

协议会变，Agent 产品会变，今天流行的桌面工具也会变。真正不能反复推倒重来的，是底层数据、业务规则、权限和过程事实。

换句话说：

MCP 是插头，不是电网。

七、Esri 的犹豫，恰恰说明 Headless GIS 不是可选项

回到今年的 Esri UC。

ArcGIS Pro Assistant、Data Explorer、JavaScript AI components 和 Location Platform MCP，说明 Esri 已经不能不回应自然语言和 Agent 的趋势；但这些回应目前更像是“在现有产品上开接口”，而不是“把 GIS 重构为 Agent 基础设施”。

ArcGIS Pro Assistant 3.7 beta 的 Assistant Pane

图：ArcGIS Pro Assistant 3.7 beta 的 Assistant Pane 界面，展示自然语言交互入口。

ArcGIS Pro Assistant 的 Focus 与 Action 能力

图：Pro Assistant 通过 Focus 模式定位地图内容，并列出可执行的 Action。

ArcGIS Pro Assistant 生成 SQL Query Layer

图：Pro Assistant 根据自然语言请求生成 SQL Query Layer 代码。

ArcGIS Pro Assistant SDK Custom Actions

图：Pro Assistant 支持开发者通过 ArcGIS Pro SDK 扩展 Custom Actions。

但目前公开产品仍有明显边界：

• 大量 Assistant 仍处于 beta 或 preview；
• Pro Assistant 主要执行受支持的离散动作，复杂多步骤工作流尚不能一次完成；
• agentic mapping app 依赖预先准备好的 Web Map、Feature Layer 和 metadata；
• Location Platform MCP 目前集中在地理编码、路径、高程和静态地图；
• 这些能力仍主要围绕 ArcGIS Online、Location Platform 和既有 ArcGIS 产品体验展开。

因此，更准确的判断不是“Esri 不会做 Headless”，而是：

Esri 正在把 ArcGIS 变得 Agent-friendly；但它还没有把整个 ArcGIS 重构为 Agent-native。

一个直观的对比是：当 Jack Dangermond 在台上展示 GeoVLM 时，台下欢呼的是“分析师以后用自然语言就能做遥感解译”；但 MCP 和 Agent Builder 的演示，更多是“Agent 可以调用几个 Location Platform 服务”。前者解决的是“人怎么更高效地使用 GIS”，后者才指向“GIS 怎么成为 Agent 的工具箱”。目前 Esri 的掌声明显更多落在前者。这不是批评——影像 AI 确实成熟、可 demo、对客户立竿见影；但它也说明，Agent/CLI/大语言模型与 GIS 底座的结合，目前还只是信号，不是主线。

这两者之间，还有一段很长的路。

Agent-friendly 是让 AI 更容易使用现有产品。

Agent-native 则要求系统从一开始就把人和 Agent 都视为调用者：同一套身份、权限、工具契约、工作流、协作和审计，不依赖某个固定界面才能成立。

这正是新一代 GIS 底座的机会。

它不必在每一个算法上超过 ArcGIS，也不必重新造所有轮子。PostGIS、GDAL、MapLibre、成熟的空间分析库和开源协作组件都已经存在。

真正需要重新组织的是它们之间的关系：

把数据变成权威资产，把算法变成受控工具，把工具变成可组合工作流，把工作流变成可审计业务过程，再把这些能力交给任何 Agent 和任何界面。

八、未来的 GIS 应用，可能不再有固定形状

过去我们问：“这个 GIS 系统有几个模块？”

以后更重要的问题可能是：

“这座底座允许 Agent 安全地完成哪些事情？”

同一套底座，上午可以生成一个领导驾驶舱，中午变成一个外业采集页面，下午运行一条无界面的空间核查流程，晚上由 Agent 自动汇总异常并生成审计报告。

这些界面彼此不同，生命周期也不同，但它们使用同一份权威数据、同一套权限、同一组空间工具和同一条责任链。

GIS SaaS 也因此不再只是一个固定网站，而可能成为一种按任务生成、按权限运行、按事实留存的应用形态。

地图当然不会消失。专业工作台也不会消失。复杂制图、数据治理、模型设计和专家判断仍然需要成熟界面。

真正变化的是：界面不再垄断能力入口。

人可以点菜单，Agent 可以调用工具，业务系统可以走 API，工程师可以用 CLI。它们最终都回到同一个可信底座。

九、结语：Headless 争夺的不是“有没有脸”，而是谁拥有主权

Headless 经常被翻译成“无头”，听起来像是把界面砍掉。

其实它真正重新分配的是软件的主权。

在传统 GIS 中，界面定义用户能做什么，工程文件保存上下文，操作流程掌握在熟练用户手里。

在 Agent-native GIS 中，数据、权限、工具和过程事实定义系统能做什么；界面只是系统根据人、场景和时间临时呈现出来的一种形态。

所以，Headless GIS 最重要的并不是“让 AI 会跑一个缓冲区”。

真正的目标是：

让 Agent 能够在几分钟内生成一个有界面或无界面的 GIS 应用，同时确保企业的数据没有失控、权限没有绕过、流程可以复现、责任可以追踪、系统可以在本地恢复。

Esri UC 2026 已经把行业推到了门口。

下一步的问题，不再是 GIS 要不要接入 AI，而是：

我们是把 AI 塞进旧的 GIS 界面，还是把 GIS 重新组织成 AI 可以安全使用的基础设施？

这可能才是未来几年 GIS 行业真正的分水岭。