第07章 技术架构：平台、引擎与智能

本章导读

本章紧接第06章的裁决顺序，回答这些数据如何被组织成可调用的能力，也为第08章的场景展开设前提。全章先厘清统一底图、统一门户、应用场景三层的职责边界与失败模式，再说明电子政务外网与四级联通的硬约束及国家、省级节点分工，比较替换、包装、编排三条融合路径的代价，给出六类服务的梯度与接口原则，最后讨论四个技术难点、智能化层“改变调用方式、不改变判断责任”的定位与架构演进的分层共存。最易误读处有三：把三层结构当三块并列工作，把“联通”当“接通”，把智能体当裁决者。读完应能判断本地架构缺某一环时会怎样退化。

学习目标

读完本章，你应当能够：

• 复述统一底图、统一门户、应用场景三层的职责边界，并对任一失败案例指出它属于表7-1 中的哪种失败模式与后果；
• 说出国家级节点“对齐”与省级节点“承压”的分工依据，判断本地四级体系的能力缺口落在哪一级（表7-2）；
• 对比替换、包装、编排三条融合路径的代价分布，判断某地“包装起步、逐步编排”处于哪一步、还欠什么交付物；
• 用调用成功率、数据时效、失败可解释性三项指标验收端到端可用，而不是以链路接通、节点注册作为完成标志；
• 画出地图服务、数据服务、时空分析服务、工具组件、智能体、通用服务的六类能力梯度，判断某项智能应用该先补哪一层（表7-3）；
• 区分“辅助”与“裁决”，用四个技术难点与四个演进阶段的判断标准，说明智能体为何不得代替确定性服务作出管控结论（表7-4）。

讨论“一张图”的技术架构，最常见的方法是把它当成一个大型 GIS 系统的选型问题：用什么数据库、什么地图引擎、什么三维平台、什么云。这类讨论有意义，却回答不了真正的架构难题——在数据分散于数十个机构、系统分属不同建设年代、网络跨越四个行政层级的条件下，如何对外表现为一个统一的门户与一套可核验的空间判断。选型决定单点能力，架构决定这些能力能否被组织起来，以及在部分环节失效时系统是否仍然可用。

权威口径把“一张图”的构成概括为统一底图、统一门户与应用场景三部分，依托国家电子政务外网实现部省市县四级网络联通，面向“一部两局”、省市县自然资源主管部门及其他政府部门提供政务服务。本章按这一框架展开：先说明三层结构的职责边界与各自的失败模式，再讨论网络与两级节点的分工，然后是平台融合的三条路径、服务能力的梯度、关键技术难点的分布，最后给出智能化层的位置与架构演进的方向。贯穿全章的判断是：架构创新不在单项技术，而在“平台融合 + 门户统一 + 分布式”这三件事的组织方式。

7.1 总体框架是三层结构，不是三块并列的工作

7.1.1 底图层解决“一个说法”，门户层解决“一个入口”

把统一底图、统一门户、应用场景理解为三块并列的建设内容，是一种常见的误读。三者构成递进结构：底图层解决数据层面的“同一块地只有一个说法”，门户层解决服务层面的“一个说法只有一个入口”，应用场景层解决业务层面的“一个入口能办成一件完整的事”。层级之间是依赖关系，上层的能力上限由下层决定，下层的价值实现由上层检验。

门户层的职责常被简化为“做一个统一界面”，这会严重低估它的技术含量。真正的门户要完成三件事：服务聚合，把分散在各平台、各系统中的能力聚合成统一目录；统一认证与授权，实现跨部门、跨层级、跨网络的身份与权限贯通；统一入口体验，做到一次登录、一次检索、一次调用。三者之中，服务聚合是技术问题，认证授权是制度问题，入口体验是产品问题，任何一项缺失，门户都会退化为一个导航页。

边界在于，门户不能替代平台。门户聚合服务，平台生产服务；如果底层服务平台本身能力不足、可用性不稳，门户做得再好也只是把问题集中暴露出来。实践中常见的失败形态是“门户先行”：先建门户再补服务，结果是门户上线时没有可聚合的内容，只能把几个既有系统的页面嵌进来，用户点进去仍然回到原来的系统，统一入口名存实亡。

7.1.2 应用场景层是价值出口，也是架构的验收标准

应用场景层是唯一直接面对业务的一层，也是判断架构是否成立的最终标准。部口径列出的场景包括自然资源“大管家”、国土空间规划、保护修复、开发利用（联动审批）、灾害防治、督察执法，同时为政府各部门提供空间底座服务，支撑数字孪生水利、低空经济、智慧交通等。场景清单本身不是架构，但它反向定义了架构必须提供什么：联动审批要求跨部门实时协同，督察执法要求历史时点回溯，灾害防治要求高可用与低延迟。

从架构角度看，场景可以按对底座的要求分为三类。查询型场景（看、查、统计）对性能与覆盖敏感，对一致性要求中等；判断型场景（压占判定、合规审查、冲突识别）对一致性与可追溯性要求最高，性能可以适当让步；协同型场景（联合审批、跨部门会商）对服务编排与权限贯通要求最高。三类场景共用一套底图，但需要不同的服务等级与接口形态；用一套接口应对所有场景，必然在其中两类上不达标。

浙江提供了一个把场景与制度绑定的样本。《省域空间治理数字化平台管理办法（试行）》（2022 年 11 月 24 日印发）第四条确立“唯一空间底座”，第二十条把“规划一张图”审查核对设为专项规划报批的前置条件，未通过原则上不得报批。这一设计的架构含义是：GIS 的比对结论不再是参考意见，而是行政流程中的必经节点。

需要说明效力层级。“一张图”成果在国家层面的法定地位尚在明确过程中，部“一张图”建设工作问答提到正在研究出台《“一张图”总体设计》，以明确其用于日常审批、管理和决策的法定地位。浙江的否决效力来自地方制度安排，属于在特定行政程序中赋予的程序效力，不等于全国层面已普遍具备法定效力。把地方样本当作普适结论，会误判推进难度。当技术输出在特定程序中具备否决效力，系统的可用性、准确性与可审计性要求会同时抬升一个量级：一次错误判定可能导致规划反复，一次服务中断可能阻断报批流程。

法定地位的空缺不是文字瑕疵，它直接构成一条设计约束。既然成果尚不直接构成审批依据，系统输出就必须保留人工确认环节与完整留痕：谁在什么时间看过这条结论、依据哪些数据与规则、最终是否采纳，都要能被追溯。这不是程序冗余，而是把“机器给出建议、人来承担责任”的分工写进系统结构。缺少这一层的系统，在出现争议时无法说明结论是如何形成的。

表7-1 三层结构的职责边界与典型失败模式

资料来源：根据自然资源部“一张图”建设工作问答关于统一底图、统一门户、应用场景构成的表述归纳。

7.2 电子政务外网是硬约束，四级联通是一条链而不是四个系统

7.2.1 联网不只是技术接入，已经与审批简化直接挂钩

“依托国家电子政务外网，实现部省市县四级网络联通”，在一份技术方案里通常写成拓扑图上的几条线，实际却是一个绕不开的硬约束：数据不能随意横跨网络边界，服务不能随意穿透安全域，跨层级的调用必须沿既有的网络通道进行。这一约束决定了“一张图”不可能采用纯互联网产品的架构，也决定了它的服务组织方式必须以政务网络的分段结构为前提。

更值得注意的是，联网已经从技术接入变成了政策条件。《自然资源部 国家林业和草原局关于进一步做好自然资源要素保障的通知》（自然资发〔2026〕38 号，2026 年 3 月 5 日）第二条提出，对支持与部实现“一张图”系统联网的省份，不再办理用地预审和选址手续，许可意见有效期 3 年。这条规定的直接后果是：联网进度与地方项目落地速度绑在了一起，未联网即不享受简化。

这一转变对架构设计有实质影响。当联网成为业务前置条件，系统可用性就不再只是运维指标，而是行政效率指标——一次长时间中断，影响的是一批项目的审批节奏。相应地，接口契约、故障降级、数据补传机制都要按“不可长时间失效”来设计，而不是按“年度考核可用率”来设计。政策把技术系统的可靠性要求向上抬了一档。

还有一条通道约束需要写进架构。据自然资源部办公厅 2026 年 7 月 23 日印发的自然资办发〔2026〕14 号文第八条，非密测绘成果系统须与政务外网“一张图”门户衔接。其架构含义是：可上线对外提供的数据成果并非任意系统都能发布，必须经由门户这条通道。反过来理解，这条规定也给了门户一个明确定位——它不只是服务聚合的界面，同时是成果合规上线的关口。

7.2.2 国家级节点承担对齐，省级节点承担承压

门户体系由国家级节点与省级节点构成。国家级节点是全国“一张图”的总枢纽与总入口，其职责重心不是存储全国数据，而是对齐：统一目录、统一标识、统一服务规范、统一入口，以及跨省数据的衔接与全国性场景的支撑。把国家级节点理解为“全国数据仓库”是常见误解——在“物理分散、逻辑一体”的模式下，全国数据的物理集中既不必要也不可行，总枢纽的价值在于规则与调度。

省级节点是区域承压层。它一方面向上提供本省数据与服务，另一方面向下汇聚市县数据、向市县提供统一支撑能力。这个双重身份决定了省级节点是整套架构中最容易出现能力缺口的位置：向上要满足全国统一的规范要求，向下要适配各市县参差不齐的系统存量。省级节点的建设水平，实际上决定了全国“一张图”能达到的精细度。

四级联通的瓶颈通常在县一级。市县两级系统建设年代不同、技术栈各异、运维力量差距明显，县级往往既缺少专职技术人员，又承担最密集的实地核查任务。架构上可行的应对是把复杂度上收：市县只做数据采集与业务办理，空间分析、大数据量渲染、跨库比对等重能力由省级节点以服务形式提供。若反过来要求每个县自建完整能力，结果必然是参差不齐，且难以统一升级。

7.2.3 联通的验收标准不是“接通”，而是端到端可用

四级联通的验收长期存在一个偏差：以链路接通、节点注册成功作为完成标志。这类指标容易测量，也容易通过，但与业务感受往往不一致。链路上通，不代表服务可调；服务可调，不代表数据是新的；数据是新的，不代表调用方能正确解析。真正需要验收的是端到端可用：从市县终端的业务操作发起，到跨层级取回数据并完成判断，整条路径是否可用、耗时是否可接受、失败时是否有明确提示。

端到端可用可以拆成三项可测指标：调用成功率、数据时效、失败可解释性。调用成功率反映服务是否稳定；数据时效反映汇聚是否及时，尤其是调查与登记这类高频更新的数据；失败可解释性反映接口契约是否完备——调用失败时返回的是“系统繁忙”，还是具体的失败原因与建议动作，直接决定了基层能否自行处置。三项之中，第三项最容易被忽略，却最影响实际使用体验。

验收标准反过来影响建设方式。若验收只看链路，建设方就会把资源投在联调与注册上；若验收看端到端可用，建设方就必须把服务可靠性、数据同步、接口文档一并做扎实。这也是为什么一些地区年年有“联通率”的进展通报，基层却仍然要靠电话与邮件协调数据——指标测的是接通，业务要的是可用。

需要补充一条边界。跨部门共享不等于无差别打通：《政务数据共享条例》（国令 809 号）第三条明确政务数据不含国家秘密、工作秘密数据。这意味着门户聚合的对象始终是政务数据范围内的可共享资源，涉密成果走另一套管理与审批路径，不能以“共享”为名进入统一门户。架构上必须把这两条通道分开设计，否则门户越便利，越容易成为违规汇聚的入口。

表7-2 国家级节点与省级节点的职责分工

资料来源：根据“一张图”门户含国家级节点与省级节点、依托国家电子政务外网实现部省市县四级网络联通的公开表述，以及自然资发〔2026〕38 号第二条归纳。

7.3 平台融合有三种做法，代价差别比技术差别更大

7.3.1 替换最彻底也最危险，包装最快也最易积债

“一张图”门户要融合国土空间基础信息平台、地理信息公共服务平台（天地图）、卫星遥感云平台等已建平台能力。融合的技术做法大致三种：替换、包装、编排。三者的差别不在技术难度，而在代价的分布——替换把代价集中在切换期，包装把代价推到后期，编排把代价压在前期的服务化改造上。

替换是用新系统覆盖旧系统功能并下线旧系统。它最彻底，能一次性消除技术债与架构分歧，适合旧系统能力明显落后、业务集成关系简单的情形。风险在于切换期的业务中断与能力回退：新系统在某个细分能力上不如旧系统，业务会直接受损，而这种缺口往往在上线后才被发现，且发现时已错过回退窗口。替换的隐性代价还包括既有集成关系被切断——原系统与不动产登记、审批、执法系统的对接要重新做一遍，这部分工作量常被低估。

包装是在旧系统外层加统一入口，内部仍调用旧系统。它上线快、风险低，适合存量系统数量多、短期内无法改造的情形。代价是形成“壳”与“核”两层：门户是一层壳，能力仍散在各系统中，用户体验的改善有限，且每增加一个系统就多一层适配。长期运行后，适配层会累积成新的技术债，最终仍需回到替换或编排。

编排是按业务能力重新组合，把旧系统能力拆成服务，由新的编排层调用。它最理想，代价也最明确：要求旧系统具备可用的服务接口，而多数存量系统的服务化程度不足，需要先做接口改造。编排的收益在长期：能力可复用、可组合、可替换，新场景的开发从“接系统”变成“接服务”。多数地区的现实路径是包装起步、逐步编排，而替换只在局部能力上使用。

7.3.2 共享工具箱与应用池把平台变成了货架

融合的产物被表述为共享工具箱与应用池，对外提供地图服务、数据服务、时空分析服务、智能体、工具组件、通用服务。这个表述的架构含义值得展开：它把平台的定位从“一个系统”改成“一组可被挑选和组合的能力”。用户不再需要进入某个系统完成全部工作，而是从货架上取用所需能力，在自己的业务流程中组合使用。

货架化的前提是能力被标准化封装。同一类能力必须有统一的调用方式、统一的返回结构、统一的错误码，否则“可组合”就无从谈起。这一步在工程上体现为服务规范与服务目录：前者定义接口形态，后者声明有哪些服务可用、由谁维护、服务等级如何。缺少服务规范，工具箱就是一堆互不兼容的零件；缺少服务目录，货架上的东西没人知道存在。两者都属于典型的“看不见的投入”，验收时难以计量，运行中却决定成败。

福建的实践提供了一个可参照的量化样本。据省自然资源厅 2025 年 12 月 25 日公开的信息，其用途管制系统内置 34 项自检规则，审批时限由 30 个工作日压减至 15 个工作日，实际约 4 个工作日完成。34 项规则的价值不在数量，而在它们被做成了系统可执行、结果可复现的检查项——这正是“工具箱”从概念落到业务的形态：把审查经验转成规则，把规则转成服务，把服务嵌进流程。

7.3.3 融合的阻力在权责划分，不在技术兼容

三种路径的技术难度都可以评估，真正难评估的是组织成本。一个既有平台通常对应一个建设主体、一笔运维经费、一套考核指标；融合意味着这些要素需要重新分配。技术上把一个系统“包装”进门户只需数月，但要让原建设主体接受“我的系统成为别人的一个服务”，往往需要更长时间。多数融合项目延期，原因不在接口调不通，而在责任边界谈不拢。

权责划分的核心是三个问题：融合后由谁承担运维责任，出故障时由谁响应；数据更新责任是否随能力一起转移；原有考核指标如何调整。三个问题不解决，融合就会停留在“物理拼接”层面——门户上挂着入口，实际点击仍跳回原系统，因为原系统的主体不愿承担被替换后的风险。这解释了为什么一些地区的门户看起来完整，实际使用率却很低。

可行的推进方式是把融合拆成可独立验收的步骤：先做服务注册与服务目录，让能力可见；再做统一认证与单点登录，让调用可行；最后做场景重构，让能力被真正使用。每一步都有独立交付物，也都能在出现争议时停下来而不影响全局。相比之下，一次性推倒重建的方案在组织层面几乎不可执行，因为它在开始阶段就要求所有相关方同时让渡权责。

关键判断：平台融合的成败，不取决于选了多少新技术，而取决于既有能力被服务化的比例。替换、包装、编排三条路径没有绝对优劣，但有一条共同底线：任何一条路径都必须产出可被外部调用的服务，而不是又一个封闭系统。判断融合是否真实发生，看一个指标即可——新场景的开发是否需要重新对接既有系统。需要，说明融合还停在包装层；不需要，才说明能力真正变成了货架上的商品。

7.4 六类服务构成能力梯度，接口形态决定能不能被用起来

7.4.1 从地图服务到智能体，抽象层级逐级升高

门户对外提供的六类服务——地图服务、数据服务、时空分析服务、智能体、工具组件、通用服务——不是并列的功能菜单，而是一条能力梯度。地图服务解决“看得到”，数据服务解决“取得到”，时空分析服务解决“算得出”，工具组件解决“拼得起来”，智能体解决“问得清”，通用服务提供身份、目录、消息、日志等公共支撑。逐级向上，抽象程度升高，可复用性下降，对下层能力的依赖上升。

梯度的现实含义是：上层能力不能跳过下层直接落地。没有稳定的数据服务，时空分析服务就只能依赖本地缓存的数据副本，结论随时间失真；没有可靠的分析服务，智能体只能做文本层面的问答，一旦涉及空间判断就无法给出可核验的答案。实践中不少“智能选址”“智能审查”项目效果不佳，根因不在模型，而在下层的数据与分析服务尚未成型。

服务分级也决定了建设次序。合理的次序是先打通地图与数据服务、再做分析服务、最后叠加智能体；颠倒次序的代价是每一层都要重复解决下层问题。对于能力有限的地区，更务实的策略是直接使用省级节点提供的分析服务，本地只做数据接入与业务界面，避免在低层级能力上重复投入。

7.4.2 接口选择的第一原则是“别人接得进来”

每类服务都有多种可选接口形态。地图服务可用 OGC 的 WMS、WMTS，也可用矢量瓦片；数据服务可用 WFS、OGC API - Features，也可用自定义 REST 接口；三维成果通常以 3D Tiles 形式发布；分析服务多采用异步任务加结果下载的形态；智能体则多以对话式或函数调用式接口暴露。选择哪一种，技术优劣只是次要因素，首要因素是调用方能否低成本接入。

这条原则在实际工程中常被忽视。一些项目为了性能选用私有格式的瓦片或私有协议的分析接口，短期内确实快，代价是第三方无法复用，每接入一个部门就要重写一次适配。公开的技术规范之所以值得遵守，不是因为它们最优，而是因为它们把接入成本降到了最低——WFS、OGC API - Features、3D Tiles 都已有成熟的客户端与工具链，任何一方都不需要为对接重新造轮子。

接口形态还与安全合规相关。跨网调用需要经过安全域边界，接口的粒度、认证方式、返回数据量都会受到约束。粗粒度的“一次取全量”接口在跨网场景下往往不可行，需要改为按范围、按图层、按需分页的调用方式。这一点在设计阶段不定下来，上线后会在联调环节集中爆发，而那时改接口的成本远高于改设计。接口不是纯粹的技术选择，它同时是一项对外承诺。

需要提醒的是，服务能力的完备程度与业务满意度并不同步。能力清单齐全，但若缺少统一的检索入口、缺少清晰的能力说明、缺少可用的样例数据，调用方仍会绕开门户自行另建。电子政务系统的使用习惯往往由一次成功接入的经验形成，也由一次失败接入的经历打消；第一批接入方的体验，很大程度上决定了后续能否形成规模化的调用。

表7-3 六类服务的能力定位与典型接口形态

7.4.3 服务目录与服务分级是门户的骨架

门户要能被用起来，前提是调用方知道有什么可用。服务目录承担这一职能：登记每项服务的名称、能力描述、接口地址、数据范围、更新频率、责任单位、服务等级。目录本身不提供能力，但它决定了能力能否被发现。缺少目录的门户，本质上仍是一组链接的集合，用户只能靠熟人打听某个功能在哪。

服务等级需要分级设定，不能一刀切。核心服务（统一认证、底图服务、权限校验）应当按不可中断设计，具备冗余与故障转移；辅助服务（专题查询、统计报表、历史回溯）可以按可降级设计，在资源紧张时优先保障核心。分级的直接价值是在容量规划与故障处置时有明确的取舍依据，而不是等故障发生时才临时决定停掉哪个。

版本管理是另一个容易被忽略的环节。服务接口一旦对外发布就进入长期维护状态，任何变更都可能影响调用方。可行做法是接口版本号显式化，新版本与旧版本并行一段时间，旧版本设定下线时间并提前公告。电子政务系统的生命周期通常以年计，接口随意变更造成的适配成本，往往超过新功能带来的收益。

资料来源：根据“一张图”门户通过共享工具箱、应用池提供地图服务、数据服务、时空分析服务、智能体、工具组件、通用服务的公开表述归纳；接口形态为业界通行做法，非官方指定。

校订说明：本行“资料来源”在原报告中位于表 7-3 之后，但中间已插入 7.4.3 节正文，读者容易误认为它是 7.4.3 的注释。教程版保持原位置不动，此处明确其归属为表 7-3 与本节关于六类服务的讨论；表 7-3 的题注与内容未改。

7.5 关键技术难点大多不在算法，而在一致性

7.5.1 坐标与投影统一最便宜，也最容易漏

坐标系统一在技术上是最简单的一件事：统一采用 2000 国家大地坐标系，高程统一采用 1985 国家高程基准。难的是一致性被长期保持——历史数据来自不同年代，早期成果可能基于 1954 北京坐标系或 1980 西安坐标系；外部接入的数据可能未声明坐标系；三维模型与二维矢量之间还可能存在局部偏移。据部公告 2018 年第 55 号，2019 年 1 月 1 日起已全面停供 1954 北京坐标系与 1980 西安坐标系成果，这为统一提供了制度基础，但历史存量数据的转换与核验仍需逐批完成。

坐标系问题的隐蔽性在于它不报错。数据能入库、能显示、能出图，只是位置偏了一点；偏差在小比例尺下看不出来，在局部放大或跨图层叠加时才暴露。更麻烦的是，一旦带有偏差的数据进入分析流程，偏差会被后续运算继承并放大：压占判定多算或少算一块面积，汇总统计出现系统性偏移，而这些结果往往已经进入行政流程。

治理办法有三条。其一是入库校验，任何数据入库前必须声明坐标系并抽样核验控制点，声明不全的不得入库；其二是转换留痕，坐标转换的参数、方法、执行时间要随数据保存，便于回溯；其三是定期抽检，用首版全国几何基准影像这类统一基准做套合检查，发现偏移即倒查来源。三条都不复杂，难的是把它们固化为制度而不是项目阶段的一次性动作。坐标系一旦在源头写错，后面所有精修都是在错误的位置上做美化。

7.5.2 性能问题多数是数据组织问题，联邦查询的代价要提前认

在 252 个图层、数十亿条记录的规模下，性能问题几乎是必然的，但多数性能问题的根因不是硬件不足，而是数据组织不当。典型情形包括：把不同比例尺、不同粒度的数据放在同一图层，导致索引效率下降；把只需展示的图层与需要参与运算的图层混在一起，让渲染请求拖垮分析服务；缺少按范围与按图层的分区策略，使每次查询都全表扫描。这些问题靠加机器解决不了，只能靠重新组织数据。

空间索引与瓦片策略是两条主要手段。空间索引解决“给定范围快速取数”，适用于分析与查询；瓦片预生成解决“给定视图快速出图”，适用于浏览与展示。二者的取舍取决于数据更新频率：更新频繁的图层不适合大量预生成瓦片，否则缓存失效频繁、重建成本高；更新少的图层则应当尽量预生成，把计算开销前置。实践中常见的错误是对所有图层采用同一种策略，结果是既没省下算力，也没换来体验。

联邦查询的代价需要提前承认。跨节点实时查询会引入网络延迟与节点可用性问题，更麻烦的是部分失败的处理：一个查询涉及多个节点，部分返回、部分超时，结果是否可用、如何标注不完整，必须在接口契约中事先约定。可行的做法是分级返回，核心图层同步查询并要求完整，辅助图层异步或走缓存并标注数据时点。把完整性要求写进契约，比事后向用户解释“数据可能不全”要可靠得多。

7.5.3 二三维一体化的难点是同一对象的两种表达

三维成果与二维矢量在“一张图”中并存，工程上常见的做法是各建一套、各用一套引擎，需要时在同一屏幕上叠加显示。这种做法能应付演示，应付不了业务：同一个地块在二维图层里是一个面，在三维模型里是一组三角面片，二者没有对应关系，任何跨维度的分析都只能靠人工判读。实景三维与行业专题数据以地理实体码为纽带关联，正是针对这一问题的制度设计。

技术上的关键是把“同一对象”的识别做成可计算的关系，而不是靠图层叠加时的视觉吻合。这要求三维模型在采集与建模阶段就带上实体标识，而不是在成果入库后临时匹配；也要求二维图层与三维模型共享同一套位置基准，否则即使在视觉上吻合，几何位置仍可能存在系统性偏差。据 2026 年 8 月的发布会信息，浙江嘉兴在“人工智能 + 实景三维”试点中攻克了三维高斯向网格模型转换的关键技术，这类工作的意义在于让三维成果具备可被业务系统复用的几何形态。

渲染层面的取舍则更现实。矢量、栅格、三维模型各有适合的渲染方式，强行统一到单一引擎，通常会牺牲其中一方的性能。可行的架构是分层渲染、按需加载：二维矢量走矢量瓦片，影像走栅格瓦片，三维模型走三维瓦片，由统一的空间视图组织调度。用户看到的是一个场景，系统内部是多个渲染通道，这种“对外一体、对内分工”的结构，比追求单一引擎的绝对统一更可持续。

7.5.4 高可用设计的关键是承认部分失败

跨层级、跨网络的系统不存在“永不失败”的方案，可行的目标是在部分环节失败时仍能提供有限服务。这要求架构在设计阶段就承认部分失败，并为每种失败定义降级行为：源节点不可用时返回最近一次缓存结果并标注时点；分析服务超时降级为异步任务并告知预计完成时间；跨网链路中断时先本地暂存、恢复后补传。降级行为必须写进接口契约，而不是等故障发生时临时商量。

缓存策略要与数据的更新节拍匹配。更新频繁的数据不适合长周期缓存，否则缓存失效与重建的开销会抵消收益；更新缓慢的数据则应尽量缓存，把计算前置。判断依据不是技术偏好，而是业务对“最新”的敏感程度：审批判定要求最新，历史查询可以接受滞后。把这两类需求用同一套缓存策略处理，结果必然是两头都不满意。

容灾与备份的边界也要说清。备份解决数据可恢复，容灾解决服务可延续，二者的投入差别很大。对于“一张图”这类以查询与分析为主的系统，优先保障数据可恢复、服务可降级，比追求双活更有性价比。真正需要双活的是那些中断即影响行政流程的环节，例如统一认证与核心审批服务。按业务影响分级设定恢复目标，比按系统重要性笼统设定更可执行。

7.6 智能化层改变的是调用方式，不是判断责任

7.6.1 三十多个智能场景说明智能应用已进入生产，但未进入裁决

江苏的公开数据给出了智能化层落地程度的参照：接入人工智能大模型后，已有智慧选地、数据得地、高效用地等 30 多个智能应用场景，服务规划统筹、要素保障、资源保护、灾害防治、执法监管、政务服务 6 大类核心业务；南京江宁某项目在 2 平方公里范围内输入用地性质、建筑高度、容积率、建筑密度等控制要求，几分钟内自动生成符合条件的选址方案。这些数字说明智能应用已经越过演示阶段，进入日常业务。

需要区分的是“辅助”与“裁决”。智能选址生成的方案是候选，仍需人工按规划、权属、审批条件复核；智能审查输出的意见是提示，最终是否通过由行政程序决定。这条界线在架构上必须显性化：智能能力的输出要标注来源、置信度与依据，要能被追溯，也要允许被推翻。把智能输出直接当作行政结论，等于把可追责的判断交给了不可追责的组件。

智能化的效果高度依赖下层数据质量，这一点常被低估。选址方案的质量取决于底图精度、现状现势性、规划数据完整性；这三项任一项不足，模型输出的方案看起来合理，实际无法落地。因此智能化层的建设次序应当在数据治理之后，而不是与之并行，更不应前置。

7.6.2 智能体编排的技术位置在服务层之上、业务规则之下

智能体在架构中的位置容易被放错。它既不是一个新的数据源，也不是一个替代业务系统的入口，而是服务层之上的一层编排：用户用自然语言表达意图，智能体把意图拆解为对若干服务的调用，汇总结果并给出解释。它的能力上限由可调用的服务决定，它的可靠性由业务规则约束。

这个位置决定了三件事。其一，智能体必须先有服务可用，才有编排价值；服务目录不全、接口不统一的地区，智能体只能做问答而不能做业务。其二，智能体调用的每一个服务都要保留调用记录，否则结果无法复核。其三，涉及管控规则（压占红线、突破边界、违反用途管制）的判断，必须由确定性服务给出结论，智能体只负责组织与解释，不得代替规则作判断。

编排层的价值在于降低使用门槛，而不在于提高判断精度。同一个分析方法，过去需要专业人员操作五步，现在可以一句话触发；但方法本身的精度没有变化，也不会因为加了智能体而提高。把这两件事混为一谈，会导致对智能化的期望失准：以为上了模型就能解决数据不一致、规则不明确的问题，实际上这些问题一个都不会自动消失。模型能降低使用门槛，不能替代口径统一。

7.6.3 变化检测与要素提取的收益集中在“发现”，不在“定性”

遥感智能解译在“一张图”中的落地场景主要有两类：变化检测与要素提取。前者比对两期影像，找出地表发生变化的区域；后者从影像中提取建筑、道路、水体、耕地等要素。两类技术都已进入生产应用，效益最明显的环节是“发现”——把人工逐幅比对的工作量降下来，把可疑变化的清单推给核查人员。

“定性”环节则仍以人工为主。影像上新增的一处硬化地表，究竟是新建设、临时堆场，还是翻耕后的晾晒场，取决于用途、审批状态与现场情况，仅凭影像难以判定。把变化检测结果直接作为违法认定依据，在多数地区都不可行；合理的做法是把结果作为核查线索，进入外业核实与举证流程。这一点决定了智能解译在业务流程中的位置：它是调查监测的前置筛选，不是执法认定。

技术边界还包括误报与漏报的成本不对称。误报多了，基层核查负担上升，久而久之会降低对系统的信任；漏报多了，问题积累到后期暴露，处置成本更高。因此变化检测的参数设置不是纯技术问题，而要结合当地核查能力与问题类型确定。这也是为什么同一套算法在不同地区的实际效果差异明显——差别往往不在算法，而在阈值、样本与业务流程的匹配程度。

智能解译的产出如何进入业务闭环，也决定了它的实际价值。若检出结果只停留在“变化图斑清单”，需要人工逐条转成业务任务，效率提升有限；若能与调查监测、执法督察的受理环节直接对接，自动生成待核任务并分派到岗，才真正减少环节。这条链路的技术门槛不高，难的是把检出的空间对象与业务对象建立对应关系——这正是前文所述标识体系在智能层的延续。

7.7 架构演进变的是耦合方式，不是替换关系

7.7.1 四个阶段的划分依据是“谁在编排谁”

从技术形态看，“一张图”的架构大致经历四个阶段：单体 GIS、服务化、云原生、智能体编排。划分依据不是用了什么技术，而是系统之间谁在编排谁。单体阶段，一个系统包办数据、分析、出图，系统之间靠数据拷贝衔接；服务化阶段，能力被拆成服务，系统之间靠接口调用衔接；云原生阶段，服务按需伸缩、按域隔离，系统之间靠编排与调度衔接；智能体编排阶段，调用由意图驱动，服务组合在运行时生成。

每个阶段解决的核心问题不同。单体解决“有没有”，服务化解决“能不能复用”，云原生解决“能不能弹性与隔离”，智能体编排解决“能不能降低使用门槛”。阶段之间不是替代关系，而是叠加关系：进入云原生阶段，仍需要服务化阶段的接口规范；进入智能体编排阶段，仍需要确定性的分析服务作为基础。跳过某个阶段直接跃迁，通常会在下一个阶段遇到结构性障碍。

从全国范围看，四级体系中的不同层级处在不同阶段，这种落差会长期存在。省级节点多数已进入服务化并向云原生过渡，市县两级相当一部分仍停留在单体或早期服务化阶段。这种不均衡是架构设计必须接受的现实约束：国家级与省级的架构可以按较高阶段设计，但对市县的接入要求必须按较低阶段设定，否则接口再先进也没人接得进来。

7.7.2 分层共存是长期状态，不是过渡期的妥协

把架构演进理解为“旧架构将被新架构取代”，是一种线性的想象。更接近现实的判断是分层长期共存：核心的空间数据管理与确定性分析仍然是稳定、低抽象的服务，不需要频繁变化；上层的场景应用与智能体则会快速迭代。稳定的下层与活跃的上层，是成熟架构的常态，也是它能够长期运行的原因。

分层共存对治理的直接含义是：投资重点应当分层配置。下层的投入以获得稳定性为目标，一旦建成不宜频繁重构；上层的投入以获得灵活性为目标，应当允许试错与快速替换。实践中常见的错误是把大量资源投在上层的应用创新，下层底座却年久失修；或反过来，底座反复重构，上层应用刚上线就要改接口。两种做法都会让整体效益打折。

演进过程中最需要守住的是接口契约。只要服务接口保持稳定，下层如何重构、上层如何替换，都不会影响全局；接口一旦随意变动，任何局部的技术升级都会传导为全局的适配成本。这也是电子政务系统建设中一条被反复验证的经验：技术可以换，标准不能乱。至于“一张图”最终会演进成什么形态，公开表述给出的方向是数智化转型与更广泛的社会化服务，但具体形态取决于数据治理的深度，而不是取决于某一代技术的出现。

表7-4 架构四个阶段的特征、瓶颈与治理重点

资料来源：根据公开技术资料与“一张图”数智化转型的公开表述归纳，阶段划分为分析框架，非官方分期。

7.7.3 演进路径上的三个决策点比技术选型更影响结果

第一个决策点是门户与平台是否分建。分建的优点是职责清晰、门户可以快速迭代而不触动底层；缺点是两套运维、两套预算，长期容易失衡。合建的优点是资源集中、协同成本低；缺点是一旦平台重构，门户随之停摆。判断依据是本地是否已有稳定的基础信息平台：已有则宜分建，避免推倒重来；没有则宜合建，避免重复投入。

第二个决策点是能力集中在省级还是分散到市县。集中有利于统一升级、统一质量，也便于把复杂能力（大范围空间分析、三维渲染、跨库比对）做成共享服务；分散有利于贴近业务、响应快，但对县级技术力量要求高。多数地区的合理形态是“数据在市县、能力在省级”，即市县负责采集与办理，重能力由省级以服务形式提供，这也与 7.2 节的承压层分工一致。

第三个决策点是智能体自研还是接入。自研可控性强、可深度贴合业务，但需要长期的模型与数据投入；接入成熟产品上线快、迭代快，但可控性弱、定制空间有限。更务实的判断是看场景性质：涉及内部管控规则、要求结果可复核的场景，宜以确定性服务为主、智能体为辅；面向公众咨询、材料预审一类容错较高的场景，接入通用模型即可。三个决策点都不存在普适最优解，但它们比选哪家数据库、哪个引擎更影响五年后的架构形态。

关键判断：判断“一张图”的技术架构成熟度，最省事的办法是看系统在缺一个环节时的表现：源节点停机，门户是否还能给出带时点标注的旧结果；某个市县未改造升级，业务是否仍能继续；模型判断失误，结论是否可被人推翻并留痕。三个问题都答“能”，说明架构具备韧性；有一个答“不能”，说明架构仍建立在“假设一切正常”的前提上。政务系统运行的真实环境从不满足这个假设。

本章小结

“一张图”的架构难点不在单项技术选型，而在组织方式：在数据分散、系统分属不同建设年代、网络跨越四个层级的条件下，对外表现为一个统一门户与一套可核验的空间判断。本章给出的判断是，这一组织方式由三件事构成——平台融合、门户统一、分布式管理，缺一件，另外两件的价值都会打折。

三层结构是递进关系而非并列关系。统一底图解决“一个说法”，统一门户解决“一个入口”，应用场景解决“一件事能办完”。三者之间存在明确的依赖：下层能力不足，上层只能靠人工补位；上层不落地，下层投入难以体现价值。判断架构是否成立，最直接的办法是看新场景的开发是否需要重新对接既有系统。

网络与节点分工是架构的硬约束。国家电子政务外网与部省市县四级联通决定了服务组织方式，也决定了智能化的部署位置。自然资发〔2026〕38 号把联网与用地预审、选址手续的简化直接挂钩，使系统可用性从运维指标变成了行政效率指标。国家级节点承担规则对齐与调度，省级节点承担区域承压，四级体系中的薄弱环节通常在县级，应对之道是把复杂度上收、让市县轻量接入。

平台融合的三条路径各有代价：替换代价集中在切换期，包装代价推到后期，编排代价压在前期的服务化改造上。多数地区的现实路径是包装起步、逐步编排，判断融合是否真实发生的标准只有一个——新场景开发是否还需要重新对接旧系统。服务能力的六类梯度则提醒一件事：上层能力无法跳过下层直接落地，智能体的效果由可调用服务的完备程度决定。

智能化层改变的是调用方式，不是判断责任。三十多个智能场景进入生产，说明技术已可用；但选址方案是候选、审查意见是提示，涉及管控规则的判断必须由确定性服务给出，智能体只负责组织与解释。架构演进也不存在替代关系，四个阶段是叠加而非替换，稳定的下层与活跃的上层长期共存，最需要守住的是接口契约——技术可以换，标准不能乱。

思考与练习

1. 表7-1 把三层结构的失败模式并列列出。某地先建门户、后补服务，结果把几个既有系统页面嵌了进来。请指出这属于表中哪一行的哪一种失败模式，并沿“下层能力不足—上层人工补位”的链条说明其后果。
2. 自然资发〔2026〕38 号第二条把联网与免办用地预审、选址手续及许可意见有效期 3 年挂钩。据此判断：地方架构的可靠性要求应当从“年度考核可用率”换成哪一种验收口径？若仍按前者设计，一次长时间中断会在哪些环节造成后果？
3. 某县对外通报联通率 100%，基层取数仍靠电话与邮件。请用 7.2.3 的调用成功率、数据时效、失败可解释性三项指标，设计一次端到端验收，并说明三项之中哪一项最容易被漏测、后果是什么。
4. 辨析题：有说法称“只要接入大模型和智能体，‘一张图’的判断问题就解决了”。请用 7.6.2 关于智能体位置的三条约束与 7.4.1 的能力梯度反驳，并说明为什么模型能降低使用门槛、却不能替代口径统一。
5. 表7-3 给出六类服务的能力定位。某市智能选址效果不佳，方案“看起来合理、实际无法落地”。请按能力梯度判断它最可能缺的是哪一类服务，并结合 7.6.1 说明建设次序应如何调整。
6. 动手题：按表7-4 的四个阶段（单体 GIS、服务化、云原生、智能体编排），为本地“一张图”画一张定位图，标注现状阶段、阻塞项与下一阶段必须补齐的一项治理重点；再写三条“缺一环”自检题，供评审时使用。

接下来：第08章 应用场景（上）：规划与用途管制 与第09章 应用场景（下）：调查、产权、执法、防灾 会把三层结构的价值出口逐条落到具体业务——本章讨论的平台融合与服务梯度，正好在那里接受“新场景是否需要重新对接旧系统”的检验。