一个叫GeoSQL的开源项目上线了，能把Claude、Codex、GitHub Copilot变成能写空间SQL的地理分析agent，支持PostGIS、BigQuery、Snowflake和Wherobots。官方给出的最大卖点是：给agent循环加一步"看地图"之后，处理地理空间任务的表现提升了4倍，自带的评测集也跑出了100%通过率。数字很好看，但拆开看，撑起这个结论的测试集只有3个案例、8项断言——放进整个空间数据text-to-SQL的老大难问题里，这更像一次工程层面的巧思验证，离"性能翻四倍"的普适结论还有距离。
让Agent"看地图"纠错，这步棋走对了方向
GeoSQL的定位很直接：分析师不用手写ST_INTERSECTS、ST_DISTANCE这类空间函数，直接用自然语言让agent查PostGIS或BigQuery。安装很轻，pip install geosql或Claude Code里/plugin加载即可，不需要注册SaaS账号，数据库凭证走本地CLI鉴权，不会传给agent——对处理敏感地理数据的团队，这是实打实的加分项。
真正的设计亮点在循环的最后一步。GeoSQL跑五步：探查仓库元数据摸清表结构，生成空间SQL，在BigQuery上先dry-run估算扫描字节数（超过10 GiB默认封顶就自动改写更省的查询），再算面积或长度做一次geometry自检，最后——如果配了开源地图后端Dekart——把结果渲染成地图图片，让agent"看"一眼，纠正文本层面发现不了的几何错误，比如把街区多边形误认成都会区边界。
这个思路不算凭空出现。Dekart本身是围绕Kepler.gl做的开源地图渲染后端，一直在迭代地图交互体验；GeoSQL做的，是把"渲染出的地图"塞进agent的工具调用列表，当成一道自动纠错关卡。创新点是设计模式，不是可视化技术本身。
4倍提升，建立在3个案例上
官方给出的benchmark是这样的：london-boroughs、berlin-create-map、paris-boundaries三个案例，总共8项断言，全部通过，平均每轮对话3085 token、耗时72秒。"4x improvement"对比的是同一套任务在有无地图反馈两种情况下的表现差异。
问题是，这个数字目前只出现在项目自己的仓库里，检索不到任何第三方复现或独立跑分。3个案例、8项断言的规模，撑不起"通用性能提升4倍"这样的结论——它更接近一次内部A/B验证，证明"加一步看地图确实有用"，而不是一个能拿去和其他工具横向比较的性能指标。
4倍提升的真实含金量，取决于8项断言之外还有多少没被测到的坑
空间数据的老坑，地图反馈填上了几个
学术界对text-to-SQL用在空间数据库上的评估一直偏谨慎。今年一篇聚焦GPT类模型的研究就指出，空间join选错key、坐标参照系（CRS）假设出错、几何本身无效、schema grounding不准，是几类尚未真正解决的高风险环节。
GeoSQL的地图反馈能直接看出多边形认错、面积异常这类肉眼可辨的几何错误，但CRS错配这种更底层、更依赖领域知识的问题，靠一张渲染图未必兜得住。原文没给出对照实验，也没列失败案例，这层空白只能读者自己留个问号。
- 风险.4x与100%通过率目前只有项目方自证，尚无第三方复现记录
开源自托管，面对的是已经在做同一件事的商业平台
地理空间AI agent这条路本身不新。CARTO已经把自己定位成面向Spatial SQL、直连数据仓库和湖仓的AI Agent产品，做的是同一件事：自然语言到空间查询到地图。
GeoSQL的差异化，是开源、可自托管、不需要SaaS账号，这对希望把地理数据完全留在自己基础设施里的团队有吸引力，但工程投入和运维责任也留给了自己。这不是同量级的竞争——CARTO是成熟商业产品，GeoSQL是刚发布的开源skill——但方向已经重叠，接下来看社区能不能把eval案例做大、能不能冒出企业级部署案例。
对正在用PostGIS或BigQuery做空间分析的团队来说，眼下更现实的做法，是把GeoSQL当成值得试用、但还需要自己补测的工具，而不是直接替换掉现有的验证流程。
- 建议.拿自己团队真实的CRS混用、跨源join场景去压测，而不是照搬官方那3个案例