语义与几何的断裂带：LLM Agent空间查询中CRS/投影错误的成因机制与工程防御体系

一、导语与问题定义：一个被“肌肉记忆”掩盖的系统性缺口

设想一个典型的 Agent 任务描述：“读取 boundary.shp 的外接矩形，用它裁剪 sentinel2.tif，输出到 clip.tif。”对人类 GIS 工程师而言，这条指令隐含了一个几乎自动触发的检查：两个数据源的 CRS 是否一致？如果不一致，必须先重投影或统一到同一坐标系，再计算范围。这个检查之所以“肌肉记忆”，是因为它对应着 GIS 软件长期以来的默认行为约束——ArcGIS、QGIS、GDAL 在多数操作中都会对 CRS 不一致给出警告或拒绝执行。

但在 LLM Agent 的工作流里，这一检查并不自动发生。Agent 的“世界模型”由自然语言语义与工具描述共同构成，它知道“裁剪需要范围”，却未必知道“范围是一个带 CRS 语义的几何对象，而非一组裸坐标”。当工具层把 get_extent() 的返回值序列化为 [minx, miny, maxx, maxy] 这样的纯数值数组时，CRS 这一关键语义在序列化过程中被剥离，Agent 看到的只是四个浮点数，自然也就无从判断它们与目标栅格的坐标是否处于同一参考框架。偏移几百米的错误，正是这一“语义剥离”的直接后果。

本文的核心论点由此展开：CRS 错误的本质不是 LLM 缺乏 GIS 知识，而是语义层与几何层之间缺少可执行的契约。知识可以通过 Prompt 注入，但契约必须由工具层强制执行。将治理希望完全寄托于“在 Prompt 里提醒模型检查 CRS”，在工程上等价于把数据一致性保障交给一个概率性的语言模型，其可靠性无法满足空间数据生产的要求。反过来，若只做工具层硬校验而完全忽视 Prompt 的语义引导，Agent 会在校验失败后陷入无意义的反复重试，任务完成率同样受损。因此，正确的工程问题不是“二选一”，而是“如何分层”。

问题定义：本文所讨论的“CRS/投影错误”，指 Agent 在空间查询与处理任务中，因未识别、未传递或未统一坐标参考系语义，导致几何运算在错误的坐标框架下执行，进而产生空间位置偏移、面积/距离失真或结果不可用的失败。其典型表现包括：跨 CRS 直接比较 extent、在经纬度坐标上做欧氏距离计算、混淆投影坐标单位（米）与地理坐标单位（度）、忽略动态基准（如 WGS84 与 CGCS2000 的厘米级差异在特定精度要求下不可忽略）等。

二、背景：LLM Agent 的空间工具调用栈与 CRS 的语义位置

2.1 空间 Agent 的典型调用栈

当前主流的空间 LLM Agent 架构可抽象为四层：意图解析层（将自然语言任务分解为子目标）、规划层（生成工具调用序列）、工具执行层（调用 GDAL/OGR、Rasterio、GeoPandas、PostGIS 等后端）、结果合成层（将执行结果转述为自然语言或结构化输出）。CRS 语义在这四层中的分布极不均匀：意图解析层通常只保留“裁剪”“缓冲区”等操作语义，规划层关注参数与顺序，工具执行层才真正接触 CRS 元数据，而结果合成层又往往将其丢弃。

这种分布不均造成了一个结构性缺陷：CRS 信息在“最需要被推理的层”缺席，却在“不需要被推理的层”存在。Agent 的推理发生在意图层与规划层，而 CRS 元数据恰恰在这两层不可见。工具层虽然持有 CRS，但传统 GIS 库的 API 设计假设调用者是具备领域知识的人类程序员，因此大量函数在 CRS 不一致时仅给出 warning 而非 error，甚至静默执行。本文评述：这一 API 设计哲学在人类主导的交互式分析中是合理的——它保留了灵活性，把判断权交给有经验的操作者；但在 Agent 自主调用场景下，它等价于把安全责任交给了一个不具备该判断能力的主体，属于典型的“责任错配”。

2.2 CRS 作为“带外语义”的脆弱性

从信息论视角看，CRS 是一种典型的“带外语义”（out-of-band semantics）：它不包含在坐标数值本身之中，而依附于数据容器（文件头、数据库 SRID 字段、GeoJSON 的 crs 成员）或上下文约定。一旦数据在工具间传递时被序列化为裸数组、CSV 或 JSON 数值列表，带外语义即告丢失。这与时间戳缺少时区信息、货币金额缺少币种标注属于同一类问题——数值本身自洽，但解释框架缺失。

笔者认为，理解这一点是设计防御体系的前提。既然 CRS 是带外语义，那么任何跨越工具边界的传递都必须显式携带该语义，否则信息必然损耗。这与软件工程中“类型系统防止单位混淆”的思路同构：NASA 火星气候探测者号因公制与英制单位混用而失联，其根因正是单位语义在接口处丢失。空间数据中的 CRS 错误与之在机制上高度相似，只是尺度从航天器轨道缩小到了几百米的平面偏移，因而更容易被忽视。

2.3 为什么“知识注入”不足以解决问题

一个常见的反驳是：既然 LLM 已经读过大量 GIS 文档，为何不直接在系统提示中写明“始终检查 CRS 一致性”？这一思路在短期内可能降低错误率，但存在三重边界条件。其一，注意力稀释：长上下文中，系统提示的约束力随对话轮次增加而衰减，这在多轮工具调用中尤为明显。其二，不可验证性：Prompt 约束无法被程序化验证，Agent 声称“已检查 CRS”与真正执行检查之间没有强制关联。其三，组合爆炸：CRS 检查只是空间数据一致性检查的一个子项，若把所有检查项都写入 Prompt，上下文预算将迅速耗尽。

因此，知识注入应定位为“降低错误概率的辅助手段”，而非“保障正确性的机制”。真正的保障必须来自工具层的强制契约。这一判断构成了后文架构设计的基本出发点。

三、失败模式解剖：CRS 错误如何在 Agent 工作流中生成

3.1 五类高频失败模式

基于对公开 GIS Agent 评测案例与工程实践的归纳，笔者将 CRS 相关失败模式整理为五类。需要说明的是，下表为整合归纳结果（模拟分类框架），其分类依据来自 GDAL 文档、GeoPandas 行为说明及近年 Agent 评测论文中的错误案例描述，并非某一单一数据集的统计。

第一类“跨 CRS 直接比较 extent”是用户问题中描述的核心场景，也是最具欺骗性的一类：它不会抛出异常，不会产生明显的视觉异常（裁剪结果仍是一张合法影像），只是内容整体偏移。这种“静默失败”比显式报错危险得多，因为它绕过了所有基于异常捕获的防御机制。本文评述：在 Agent 系统中，静默失败应当被视为最高优先级治理对象，因为 Agent 缺乏人类那种“看一眼结果就觉得不对”的直觉校验能力。

3.2 失败链的生成机制：一次具体的推演

以“用 Shapefile 范围裁剪影像”为例，推演 Agent 的失败链。假设 boundary.shp 为 EPSG:4490（CGCS2000 地理坐标），sentinel2.tif 为 EPSG:32650（WGS84 / UTM 50N）。Agent 的规划大致为：

step1: extent = ogrinfo_get_extent("boundary.shp")
       → 返回 [112.3, 22.1, 114.8, 24.5]（度，但工具未标注 CRS）
step2: clip_raster("sentinel2.tif", extent, "clip.tif")
       → 栅格 CRS 为 UTM 50N，坐标量级约 [2e5, 2.4e6]
       → 若工具内部直接以 extent 数值构造窗口，窗口落在影像范围外
       → 部分实现会返回空结果或全零影像，部分实现会静默生成错误窗口

关键在于 step1 与 step2 之间的接口：extent 以裸数组形式传递，CRS 语义在序列化时丢失。Agent 在 step2 中看到的是一个数值数组，它没有任何依据判断这些数值属于哪个坐标框架。若工具层在 step2 内部做了“数值范围合理性检查”（例如 UTM 坐标不应小于 1e5），则可能捕获错误；但多数通用工具不做此类检查，因为它们假设调用者已保证一致性。

笔者认为，这条失败链揭示了三个可干预点：其一，step1 的返回值应携带 CRS 元数据，而非裸数组；其二，step2 的入口应强制校验输入 extent 的 CRS 与目标数据一致，不一致则拒绝执行并返回结构化错误；其三，规划层应具备“CRS 统一”这一前置步骤的生成能力。三者分别对应数据契约、工具契约与规划契约，构成后文三层架构的雏形。

3.3 为什么 Agent 特别容易在此处失手

从认知负荷角度分析，Agent 在规划阶段需要同时跟踪任务目标、工具可用性、参数依赖与中间结果状态。CRS 一致性属于“跨步骤的全局不变量”，而非“单步骤的局部前置条件”。人类工程师之所以能自动检查，是因为长期训练形成了模式识别——看到“裁剪”就联想到“坐标系对齐”。LLM 的模式识别来自训练语料中的共现统计，而 GIS 文档中“裁剪”与“CRS 检查”的共现强度远低于“裁剪”与“范围”的共现强度，因此模型更倾向于生成“取范围—裁剪”的直接路径，而非“取范围—检查 CRS—必要时重投影—裁剪”的完整路径。

这一解释与近年关于 LLM 工具使用的研究方向一致：模型倾向于选择“最短可行路径”，而安全性与一致性检查往往增加路径长度，因而在缺乏外部强制时被系统性省略。本文评述：这并非模型的“缺陷”，而是优化目标的自然结果——语言模型被训练为生成高概率的合理续写，而非执行完备的工程检查清单。要求模型自发执行检查，本质上是在要求它偏离其训练目标，这在统计上必然不稳定。

四、评测证据：GIS Agent 基准中的坐标系失配信号

4.1 现有基准的覆盖情况

近三年，面向地理空间任务的 LLM 评测基准逐步出现。较为代表性的包括：评估遥感视觉语言模型在场景理解与定位任务上的基准（如 RSVQA 系列及其后续扩展）、面向地理空间推理的多模态基准（如 GeoBench 类工作）、以及将 GIS 操作封装为工具调用任务的 Agent 评测（如围绕 QGIS/ArcGIS 自动化脚本生成的评测集）。这些基准的共同特点是：任务描述接近真实工作流，评分侧重最终结果的空间正确性。

然而，专门针对 CRS 一致性的细粒度错误分类仍然稀缺。多数基准将“结果偏移”笼统归入“空间定位错误”或“几何错误”，未区分其根因是模型不理解 CRS、工具未传递 CRS，还是规划遗漏了重投影步骤。这种粗粒度归因导致改进方向不明确：若不知道错误发生在语义层还是接口层，就无法判断应优化 Prompt 还是重构工具。

数据说明：本节所述基准的覆盖情况基于公开论文与项目页面的描述性归纳，不涉及对具体数值的复现。由于不同基准的任务设计、评分口径与数据划分差异较大，跨基准的错误率数值不具备直接可比性，本文因此不引用具体百分比，而聚焦于错误类型的结构性观察。如需精确数值，请以各基准原始论文与排行榜为准。

4.2 从错误案例反推的接口缺陷

对公开错误案例的定性分析显示，相当一部分“空间定位错误”在回溯时都可归因于接口层的 CRS 语义丢失。典型情形是：Agent 正确调用了获取范围的工具，也正确调用了裁剪工具，两个调用单独看都“成功”，但组合结果错误。这类错误在单步评分中不可见，只有端到端评分才能暴露。本文评述：这提示评测设计应引入“中间状态可观测性”——不仅评最终结果，还应记录并评估中间产物的 CRS 元数据是否完整、是否被正确传递。否则，评测只能告诉你“错了”，无法告诉你“错在哪一层”。

另一个值得注意的现象是“错误的自洽性”：当 Agent 在错误 CRS 下完成裁剪后，它往往会在结果描述中给出看似合理的解释（例如“已按边界范围裁剪”），而不会意识到偏移。这说明模型缺乏对结果的几何合理性校验能力。工程上，这要求系统在结果合成层之前插入自动化的合理性检查，而非依赖模型自述。

4.3 评测指标的改进建议

基于上述观察，笔者提出三项可操作的评测指标改进方向。第一，CRS 传播完整率：统计任务链中每个中间产物的 CRS 元数据是否完整保留，作为独立于最终结果的诊断指标。第二，静默失败率：统计“工具未报错但结果空间错误”的比例，专门衡量静默失败。第三，重投影必要性识别率：在人为构造的跨 CRS 任务中，统计 Agent 是否主动识别并执行了重投影。这三项指标均可通过工具层埋点自动采集，不依赖人工标注，具备工程可行性。

五、两条治理路线的边界条件：Prompt 约束 vs 工具层硬校验

5.1 Prompt 约束的能力边界

Prompt 约束的优势在于低成本、可快速迭代、无需改动工具代码。其有效场景包括：任务类型相对固定、对话轮次较短、错误后果可容忍、且模型能力足以理解约束语义。在这些条件下，明确的系统提示确实能显著降低错误率。例如，在系统提示中写明“在执行任何几何运算前，必须确认所有输入数据的 CRS 一致；若不一致，先调用重投影工具统一到目标 CRS”，可以让 Agent 在多数情况下生成正确的步骤序列。

但其边界同样清晰。第一，约束不可验证：Agent 可能声称已检查而实际未检查，系统无法区分。第二，长上下文衰减：多轮工具调用后，早期系统提示的影响力下降，这在需要十余步操作的复杂任务中尤为明显。第三，对抗性输入：当任务描述本身包含误导性信息（例如用户声称“两个数据坐标系相同”但实际不同），Prompt 约束无法纠正事实错误。第四，成本：详尽的检查清单会占用可观的上下文预算，挤压其他必要信息的空间。

本文评述：Prompt 约束应被定位为“概率性降错手段”，其价值在于引导 Agent 生成更合理的规划，而非保障执行的正确性。把它当作唯一防线，在数据生产场景中不可接受；把它当作辅助层，则性价比很高。

5.2 工具层硬校验的能力边界

工具层硬校验的核心思想是：在工具入口处强制检查输入的一致性，不一致则拒绝执行并返回结构化错误。其优势是确定性强、可测试、可审计，不依赖模型行为。对于“跨 CRS 比较 extent”这类错误，硬校验可以在毫秒级内拦截，从根本上消除静默失败。

但其边界同样存在。第一，语义不可判定：工具只能校验“声明的 CRS 是否一致”，无法校验“声明的 CRS 是否符合数据真实情况”。若上游数据本身的 CRS 标注错误，硬校验无能为力。第二，灵活性损失：过于严格的校验会拒绝一些合法的“隐式转换”场景，例如某些工具确实支持自动重投影，硬校验反而阻断了正常路径。第三，错误恢复成本：硬校验返回错误后，Agent 需要理解错误并生成修复步骤，若错误信息设计不当，Agent 可能陷入反复重试。第四，改造成本：对既有工具链进行全面改造需要投入，且需保证向后兼容。

笔者认为，硬校验的关键设计原则是“拒绝执行 + 可操作的修复建议”。错误返回不应只是“CRS 不一致”，而应包含“输入 A 为 EPSG:4490，输入 B 为 EPSG:32650，建议先对 A 执行重投影至 EPSG:32650，或对 B 重投影至 EPSG:4490”。这样，Agent 无需自行推断修复方案，只需按建议执行，大幅降低错误恢复的难度。这一设计把“检查”与“修复引导”合并，是硬校验从“阻断器”升级为“协作者”的关键。

5.3 两条路线的对比

结论是明确的：两者不是替代关系，而是分层关系。Prompt 约束负责“让 Agent 想到要检查”，工具硬校验负责“确保检查真的发生且结果正确”。缺少前者，Agent 会在校验失败后不知所措；缺少后者，Agent 的“检查”只是口头承诺。这一分层判断构成了下一节架构设计的直接依据。

六、三层防御架构：契约式中间表示与可验证工具层

6.1 架构总览

本文提出的三层防御架构，核心思想是把 CRS 从“隐式上下文”提升为“显式契约”，并在每一层设置可验证的检查点。三层分别是：数据契约层（中间表示携带 CRS）、工具契约层（入口强制校验与修复引导）、规划契约层（Prompt 引导与规划模板）。三层之间通过结构化错误对象传递信息，形成闭环。

6.2 数据契约层：让 CRS 随数据流动

数据契约层的核心是定义一个带 CRS 的几何中间表示，替代裸数组传递。最小可行设计如下：

{
  "type": "extent",
  "crs": "EPSG:4490",
  "axis_order": "lon,lat",
  "bbox": [112.3, 22.1, 114.8, 24.5],
  "unit": "degree",
  "source": "boundary.shp",
  "validated": true
}

这一表示的关键字段是 crs、axis_order 与 unit。其中 axis_order 常被忽视却至关重要：EPSG:4326 的官方定义轴序为 lat,lon，而大量数据文件实际存储为 lon,lat，这一不一致是轴序混淆错误的根源。显式记录轴序，可以让下游工具明确知道如何解释数值。本文评述：这一设计与编程语言中的“带单位类型”思路一致，其价值不在于增加信息量，而在于让信息在接口处不可丢失——任何接收该对象的工具都必须处理 CRS 字段，否则类型检查即失败。

工程实现上，可通过 Pydantic 模型或 JSON Schema 定义该结构，并在工具函数的类型签名中强制使用。对于必须返回裸数组的遗留接口，可在适配层做包装，确保 CRS 元数据随行。预处理细节方面，若从 Shapefile 读取，需注意 .prj 文件缺失时的降级策略：此时应标记 crs: "unknown" 并触发人工确认，而非默认假定某一 CRS。

6.3 工具契约层：入口校验与修复引导

工具契约层在每个涉及几何运算的工具入口处设置校验。以裁剪工具为例，其伪代码逻辑如下：

def clip_raster(raster_path, extent_obj, out_path):
    raster_crs = read_crs(raster_path)
    if extent_obj.crs == "unknown":
        return error("CRS_UNKNOWN",
                     "输入 extent 缺少 CRS，请先调用 get_extent 获取带 CRS 的范围")
    if not crs_equal(extent_obj.crs, raster_crs):
        return error("CRS_MISMATCH",
                     f"extent CRS={extent_obj.crs}, raster CRS={raster_crs}",
                     suggestions=[
                        f"reproject_vector(source, target='{raster_crs}')",
                        f"reproject_raster('{raster_path}', target='{extent_obj.crs}')"
                     ])
    # 通过校验后执行
    return do_clip(raster_path, extent_obj.bbox, out_path)

这一设计有三个要点。第一，校验发生在执行之前，杜绝静默失败。第二，错误对象结构化，包含错误码、上下文与修复建议，Agent 可直接解析并生成下一步。第三，建议具体到工具调用，而非泛泛的“请检查 CRS”，降低 Agent 的推理负担。本文评述：把修复知识编码进错误信息，实质上是把部分领域知识从模型迁移到系统，这是一种更可靠的“知识外化”策略——模型不必记住所有修复路径，只需学会读取并执行建议。

对于确实需要自动重投影的场景，可提供 auto_reproject=True 显式开关，默认关闭。这样既保留了灵活性，又确保自动转换是“知情选择”而非“隐式行为”。这一设计原则可概括为：默认严格，显式放宽。

6.4 规划契约层：Prompt 引导与规划模板

规划契约层通过系统提示与规划模板，引导 Agent 在生成计划时纳入 CRS 统一步骤。有效的提示设计应遵循三条原则。第一，具体而非笼统：与其说“注意坐标系”，不如说“若两个输入的 CRS 不同，先调用 reproject 工具统一到目标数据的 CRS，再执行几何运算”。第二，给出检查清单的触发条件：明确“涉及两个及以上数据源的几何运算”时才需检查，避免无差别增加步骤。第三，与工具错误信息呼应：提示中说明“若工具返回 CRS_MISMATCH，按 suggestions 执行修复”，形成 Prompt 与工具层的协同。

此外，可为高频任务类型预置规划模板。例如“裁剪类任务模板”固定包含“读取目标 CRS → 读取源 CRS → 比较 → 必要时重投影 → 执行裁剪”五个步骤。模板的作用是降低规划层的自由度，从而降低遗漏概率。本文评述：模板化在任务类型集中的生产环境中收益显著，但在开放式探索任务中可能限制灵活性，因此应作为可选组件而非强制约束。

6.5 结果合成层的合理性检查

即使前三层都正常，仍需在结果合成层设置最后一道检查。可自动执行的检查包括：输出影像的地理范围是否与输入范围在合理误差内重叠、输出是否为空或全零、面积/距离结果是否与坐标单位匹配。这些检查不依赖模型，纯规则即可实现。一旦触发，系统应返回明确的诊断信息，而非直接输出结果。本文评述：这一层的价值在于捕获“上游元数据错误”这类硬校验无法覆盖的情形——当数据本身的 CRS 标注错误时，只有基于结果几何合理性的检查才能发现异常。

七、实施路径：从最小可行校验到组织级规范

7.1 阶段一：最小可行校验（1–2 周）

对于已有 Agent 系统、希望快速降低 CRS 错误率的团队，建议从最小可行校验入手。具体步骤：第一步，梳理当前工具链中所有涉及几何运算的函数，列出其输入输出的 CRS 处理方式；第二步，为最常用的 3–5 个工具（通常是读取范围、裁剪、缓冲区、叠加分析）添加入口校验，不一致时返回结构化错误；第三步，在系统提示中加入与错误码对应的修复指引；第四步，用历史失败案例构造回归测试集，验证改造效果。

这一阶段的投入产出比最高，因为它直接拦截了最高频的静默失败。需要注意的是，改造时应保持向后兼容：对于不传 CRS 的旧调用，可先记录警告而非直接拒绝，给调用方迁移时间。

7.2 阶段二：中间表示标准化（3–6 周）

在最小校验稳定运行后，推进中间表示标准化。核心工作是定义统一的几何/范围数据结构，并在所有工具的输入输出中采用。实施要点包括：用类型系统强制 CRS 字段存在、为遗留接口编写适配器、建立 CRS 元数据的序列化/反序列化规范。此阶段的关键挑战是跨团队协作——若工具由不同团队维护，需先就数据结构达成一致。

笔者认为，标准化时应优先采用业界已有约定（如 GeoJSON 的 crs 成员、OGC API 的 CRS 参数），而非自创格式。这既降低学习成本，也便于与外部系统对接。对于 GeoJSON 中 crs 成员在 RFC 7946 中被移除的历史遗留问题，应在适配层做兼容处理，而非依赖该字段。

7.3 阶段三：组织级规范与持续监控（持续）

长期来看，应将 CRS 一致性纳入组织级的数据与工具规范，并建立持续监控。可落地的措施包括：在 CI 中加入 CRS 传播测试、在 Agent 运行日志中记录每个中间产物的 CRS 状态、定期统计静默失败率并复盘。监控指标建议采用第四节提出的三项：CRS 传播完整率、静默失败率、重投影必要性识别率。

此外，应建立“CRS 错误案例库”，把每次线上失败转化为回归测试用例。这一做法的价值在于把偶发经验固化为可重复验证的资产。本文评述：Agent 系统的可靠性提升，很大程度上依赖于这种“失败驱动”的工程闭环，而非一次性的大规模改造。

7.4 拓展资源

以下资源适合深入理解 CRS 与工具链实现细节（均为外部链接，点击在新窗口打开）：

• GDAL OSR API 教程：坐标参考系与投影变换的官方入门，涵盖 SRS 对象、轴序与转换。
• Rasterio 重投影文档：栅格重投影的工程实践与常见陷阱。
• GeoPandas 投影指南：矢量数据 CRS 管理与重投影操作。
• EPSG.io：CRS 代码查询与转换参数检索。
• PROJ 官方文档：坐标转换引擎的原理与配置。
• OSGeo 中国：中文开源地理空间资源与教程汇总。

八、对比、局限与前沿展望

8.1 与既有治理思路的对比

既有治理思路大致有三类。第一类是“模型能力路线”，寄望于更强的模型自然具备 GIS 检查能力；第二类是“提示工程路线”，通过精心设计的 Prompt 引导检查；第三类是“工具加固路线”，在工具层做防御。本文提出的三层架构属于第三类的扩展，但强调与第二类协同。本文评述：模型能力路线在长期看有潜力，但短期内不可依赖——模型能力的提升是非线性的、不可控的，而工程系统需要可预期的可靠性保障。把正确性寄托于模型能力，等价于把系统可靠性交给外部变量。

8.2 局限

本文架构存在若干局限。第一，无法解决元数据本身错误：若数据文件的 CRS 标注错误，所有基于声明的校验都会失效，只能依赖结果合理性检查。第二，改造成本：对大型遗留系统全面改造代价高，需分阶段推进。第三，对动态基准与高精度场景覆盖不足：WGS84 与 CGCS2000 的差异在多数应用中可忽略，但在厘米级应用中不可忽略，本文未深入讨论动态基准转换的工程细节。第四，评测证据的间接性：本文引用的评测观察多为定性归纳，缺乏大规模定量复现，结论的普适性有待更多独立验证。

8.3 前沿展望

展望未来，三个方向值得关注。其一，空间 Agent 的专用评测基准：需要细粒度到“CRS 传播”“轴序处理”“单位一致性”的评测集，而非笼统的空间正确性评分。其二，工具描述的结构化：当前工具描述多为自然语言，未来可引入机器可读的前后置条件（precondition/postcondition），让 Agent 在规划时即可感知 CRS 约束。其三，形式化验证的引入：对关键空间操作，可探索用轻量形式化方法验证坐标变换链的正确性，这在测绘、应急等高风险场景中价值显著。

笔者认为，CRS 问题只是空间 Agent 可靠性问题的一个缩影。更一般的问题是：如何让语言模型的语义推理与几何数据的严格约束之间建立可验证的桥梁。这一问题的答案不会来自单一技术，而来自“语义引导 + 接口契约 + 结果校验”的系统工程组合。本文的三层架构是这一组合的一个具体实例，其价值不在于架构本身的新颖，而在于它把“肌肉记忆”转化为“可执行、可测试、可审计”的工程机制。

九、结论

LLM Agent 在空间查询中反复出现 CRS/投影错误，其根因不是模型缺乏 GIS 知识，而是语义层与几何层之间缺少可执行的契约。CRS 作为带外语义，在工具间传递时极易丢失；Agent 的规划倾向于最短路径，系统性地省略一致性检查；传统 GIS 工具的“警告而非拒绝”设计在自主调用场景下造成责任错配。这三者共同构成了静默失败的温床。

治理路径不是 Prompt 与工具层的二选一，而是分层协同：Prompt 约束负责引导规划、降低遗漏概率；工具硬校验负责保障执行、杜绝静默失败；数据契约负责让 CRS 随数据流动、在接口处不可丢失。三者通过结构化错误对象形成闭环，并辅以结果合成层的合理性检查作为最后防线。实施上建议分三阶段推进：最小可行校验、中间表示标准化、组织级规范与持续监控。

最终，把“坐标系不匹配”这一肌肉记忆转化为工程机制，其意义超出 CRS 本身。它示范了一种方法论：当语言模型进入需要严格数据一致性的领域时，正确性的保障必须来自可验证的接口契约，而非模型的自觉。这一原则对空间数据之外的诸多领域同样适用。

主要参考文献与拓展资源