Osgearth的环境验证数据发布服务的加载能力，是我在GIS数据处理与发布这个大块里的一块重要拼图，之前做过EarthFile Agent的小工具，只是临时解决earth文件发布验证的闭环。这次结合Agent编排的能力，打通Osgearth各个版本下，加载GIS服务发布数据的开发测试环境。
我在 GIS 生态里的那块拼图
GIS 数据从原始文件走到用户眼前的三维地球处应用，大致要经过三段路，该Agent位于第二、三段的交界处:验证「服务发布 → 引擎加载」的最后一公里，加载结果反哺发布配置。
第一段是数据处理。影像、DEM、矢量、海图这些原始数据，要经 GDAL、QGIS、切片工具做清洗、转换、切块，变成「发布就绪」的数据。
第二段是服务发布。GeoServer 把处理好的数据按标准协议暴露成网络服务：WMS 影像、WMTS 瓦片、TMS / XYZ，以及 Cesium quantized-mesh 高程等。
第三段是引擎可视化应用。渲染引擎按服务协议把瓦片和高程拉下来，拼成可交互的三维地球。osgEarth 是 C++ 桌面侧的主力地球引擎之一，基于 OpenSceneGraph 生态，在本地化部署、仿真推演这类场景里很常见。它用一份 earth 文件(XML)描述「这颗地球由哪些图层装配而成」，引擎按图索骥去加载服务。
GIS Server Agent已帮我把处理数据、发布服务搞定。但服务发布出去不代表事情结束------它能不能被引擎正确加载、渲染出来对不对、不同版本引擎下表现是否一致，必须真机验证才知道。这「发布 → 加载」的最后一公里，就是我这块拼图里最后缺的一环。
介绍
**结合 Agent 编排能力，把「给一个服务地址 → 在指定 osgEarth 版本下加载验证出来」做成一个完整的开发测试环境，**让编译、加载、扩展、验证、沉淀五件事都在同一条闭环里。
仓库：https://gitee.com/being_xyk/osgearth_for_gis_server
三大核心功能
给一个服务地址和目标版本，三条功能线分别解决「引擎从哪来、earth 怎么写、内置不支持怎么办」；配套能力让流程自动收口。
1. osgEarth 各版本的编译打通
3.6 / 3.7 / 3.8 三套官方源码树，Windows + VS2022 + CMake + vcpkg 逐一编译。
2. earth 文件生成与加载验证
给一个服务地址，产出一份能加载它的 earth 文件，并在指定版本下验证通过。
3. 扩展 Layer 插件：引擎不认识的服务，自己写层接进来
osgEarth 内置支持 WMS / TMS / XYZ / GDAL / MBTiles，但没有 WMTS、WCS，也不认 Cesium quantized-mesh 高程(三版源码逐一 grep 实证)。解法走官方 Layer 扩展机制。
配套：让闭环自己转起来
服务接入的工作流：给定一个 GIS 发布服务地址，生成 earth 文件并让指定版本的 oe_viewer 加载出来；原生不支持的服务先走扩展 Layer 再回到同一条主线。验证、交付、知识沉淀都在闭环内。
让这套环境「活」起来的三样配套。
-
端到端测试。 上面提到的 verify-earth.sh 就是冒烟抓手。
-
知识的自动积累与使用。 这是 Agent 编排里我最看重的一环。所有实证结论沉淀在 `SourceCode/Knowledge/` 下。
-
基于 osgEarth 的扩展小工具。 oe_viewer(auto-fit + 截图)、snapshot(无交互定点截图，A / B 对照用)、env.sh 运行时环境、run-viewer / start-server 一键起服务。
用起来是什么样：意图表达，Agent 执行
整套环境被编排进一个项目级 SKILL(`osgearth-service-load`)，使用方式是自然语言表达意图，Agent 走完整闭环:
-
++「接入++ ++http://localhost:18890/geoserver/taihai/wms，3.8++ ++验证」++→ 识别服务 → 生成 earth → 截图验证 → 交付看图指令;
-
++「这个 WMTS 地址配一下，三个版本都要」++→ 走扩展路径，逐版本构建插件再逐一验证;
-
++「加载 china_dem_cesiumterrain.earth，用 3.7 看看」++→ 已有 earth 直接进加载验证，截图交付。
闭环内部是七步：服务识别 → 原生支持判定 → 配置服务层(原生直配 / 扩展插件双路径)→ 生成 earth → 指定版本加载验证 → 交付看图 指令 → 知识沉淀。第七步的沉淀又反哺第一步：案例结论、调试范式、插件复用依据，全部进入下一轮。验证失败不交付，进调试回路修好为止。
对用户来说，过程中不需要记任何命令；流程结束后拿到一条「看图指令」(桌面地球或浏览器瓦片 URL)，想亲自交互查看时才动手。
工作区成果
如图为一个实际的工作结果展示：从用户输入指令开始，到layer扩展编译、生成earth，加载出图验证，中间Agent完成了整个编排。
个人总结
这套环境对我来说，意义不只是「能验证服务」本身。更重要的是把 GIS 链路里，发布的数据在引擎侧到底对不对------变成了可重复、可自动化、有知识积累的固定动作。
Agent 编排的价值，也不在于替我写了多少代码，更重要的是把「识别 → 配置 → 验证 → 沉淀」这一整套流程变成了肌肉记忆：我只管表达意图，闭环自己转，经验自己长。EarthFile Agent是「工具辅助我」，这次是「流程带着我的领域知识生长落地」。
其它
原始文章内容在我的飞书知识库：OsgEarth For GIS Server Agent
我的AI积累笔记也包含了其它的学习知识、思考笔记、实践记录：Being的AI积累。有兴趣可以关注，后续该Agent也会持续更新。
