GeoSQL：3 个 case 吹出 4x，这届科幻小说又更新了

先说结论：这个「4x」是水分。这个项目本身，不冤。

官方通稿原话：「4x improvement on geospatial tasks when a map is included in the agent loop」。听起来像从文本切到看图模式，效率直接翻两番。

实测呢？仓库拉下来，跑它自带的 evals/run.py。三分钟出结果，三组 case——london-boroughs、berlin-create-map、paris-boundaries——8 条断言，100% pass rate。

数据没撒谎。但这数据撑不起「4x」！

就三个 case！三个。

全是欧洲城市的边界、行政区划，规则规整。没有脏数据，也没有一个 shapefile 里混三种投影的那种烂摊子。跑三次全过，只能说明它在自己定义的任务上表现良好。拿这个样本量去宣传「4x」，跟拿一张及格卷子说全班都是学霸有什么差别？

更值得掰扯的是，这「4x」连定义都没给。省的是 token 还是轮次？快的是正确率还是耗时？没说。它只亮了两行数字：平均每轮 3085 token、72 秒耗时。问题是没对照组。不开地图的时候跑多少轮、错多少个、烧多少 token？不知道。

一张没有坐标轴的折线图，画得再漂亮也只是美术作品。

不过。把话说回来。

这个项目有经得起实测的地方，最打脸的是成本护栏。官方说：「BigQuery 上每条查询先 dry-run 估算字节扫描量，默认 10 GiB 计费上限，超了自动重写查询。」我当时心想：又是那种写了等于没写的摆设吧，顶多弹个 warning。

实测它来真的。我在 london-boroughs 那个 case 里，手动把一条聚合查询改成不加过滤条件的全表扫描——理论上该爆掉上限。结果 agent 真自己改写了，换成分区裁剪版本，硬生生把估算扫描量压回限额以内。

estimated_bytes_processed: 11.2 GiB  →  1.8 GiB
status: REWRITTEN (cost guardrail triggered)

不是嘴上说说的护栏，是真在管账的！这个分，我给它加上。

官方那句「本地或自托管运行、不需要任何 SaaS 账号」，也属实。装完翻了一遍设计：agent 调的是本地 CLI 认证——bq、snow、dekart——仓库凭据根本不经手。数据面和控制面分开，隐私边界是架构上长出来的。就凭这一条，跟那些把 credential 直接塞进 system prompt 的玩意儿，就不是一个物种。

最后留半句：地图闭环我还没全测完。手动跑了两个 case，Dekart 渲染、agent 读图、修正几何错误，链路是通的。但我手头的真实项目是 H3 网格聚合，只过了浅层测试，没到实战深度。这条先别信我的半句。

锐评评分卡：这钱花得冤不冤？不冤——冲着成本护栏和本地自托管去，这两个点值回票价。冤不冤？冤——你要是真信了「4x」，指望手里那些脏乱差的生产任务效率翻四倍，落差能把你噎死。

厂商下次发通稿，建议把「4x」改成「我们在三个精心挑选的 case 上跑赢了纯文本模式」。

至少这样，还不算骗人。