这条讲的是个多智能体地理空间分析系统，叫GeoFaham。出处是Muhammad Sohail Danish领衔的八人团队，做地理空间分析和灾害响应。预印本，前几天挂上arXiv的。
看到"多智能体"三个字我第一反应是关掉——今年这个品类太挤了，十篇有九篇换个壳发一遍"我们发明了agent协作"。但读到失效模式那一节我改主意了。
作者开篇说了句实在话，原文是「真实场景的地理空间决策支持，不是单步检索或代码生成能搞定的」。灾害响应类问题得串联空间数据库、地图衍生特征、卫星影像、栅格产品、可复用中间产物，一堆工作流。这话不新鲜。但后面作者把通用模型在这些任务上怎么死的，列得特别具体，我读到那一段才开始点头。
它处理不了大体积数据产物。模型上下文窗口有限，中间结果一超过窗口容量，它就开始截断，而且截断的时候不告诉你。
它会选错证据来源。模型会抓一张云量很高的影像回来，因为那张影像"看起来能回答"，但没考虑目标区域被云盖住了。
它会丢空间或时间元数据。raster的CRS、矢量数据的投影、时间戳，这些在geoprocessing过程中被模型随手丢了，后面所有运算全错，但模型自己不知道。
它会执行不合法的几何运算。两个不同投影的矢量直接做intersection，程序不报错，结果全是垃圾。
这四条不是我总结的，是作者列出来的。我读的时候一直在点头，因为我跑agent做地信任务，失败几乎全落在这四条里的某一条。第三条尤其扎心——上个月我让一个agent处理modis数据，它把temporal metadata丢了，做出来的时间序列完全错乱，我过了两天才看明白。
GeoFaham的解法，核心不是"多智能体"这个壳，是两个设计。第一个是把复杂工作流拆给几个领域专精的子智能体，一个管矢量运算、一个管地图要素检索、一个管影像发现、一个管栅格分析，上面有Orchestrator统一调度。这个不稀奇。
第二个才是命门：Response Store。这个组件把完整的地理空间输出和带类型标注的元数据存在大语言模型上下文窗口之外，智能体之间只传紧凑的标识符和摘要。注意这句话——「保存在上下文窗口之外」。
通用agent做多步任务，默认把中间结果塞回上下文窗口，因为那是它唯一的工作区。但地理空间中间产物动辄几百MB，塞不进去。GeoFaham的答案是：中间产物存外面，agent之间传指针，需要的时候再按需取用。思路不新，是RAG那一路的，但用在多智能体地理空间工作流上，刚好。
作者还搞了个benchmark，GeoFaham-Bench，40个任务，来自17条真实灾害记录。评测多步推理、跨来源整合、栅格矢量联合计算、中间产物生成、失败时的错误恢复。有些任务的正确答案不止一个，不是合成数据拼出来的"标准答案"基准。
论文说代码和benchmark都公开了。我顺手跑了一下。
没完全跑通。
依赖里有个GIS库跟我系统版本不对付，环境配一半卡住了。退而求其次，把benchmark的任务描述读了一遍，挑了一条洪水淹没范围任务，直接用Claude Code跑，不按GeoFaham架构来。结果和论文说的一致。单agent做多步地理空间推理，基本就是死。那条任务需要先用矢量数据确定目标水系，再抓对应时间窗的水位数据，再算淹没范围。Claude Code第一步就选错了数据源，把河流矢量和水位站点数据搞混了，后面全错，它甚至没意识到自己错在哪。
这让我对论文结果多了几分信任。GeoFaham综合得分0.940，第二名基线0.879，token消耗少7.5倍。0.940对0.879的差距不算夸张，但token少7.5倍这个数字我信——因为Response Store设计的目标就是在上下文窗口里不搬大文件。
不点链接也能带走的一句：让agent做地理空间任务，先把"上下文窗口不是数据仓库"这条原则焊死在架构里。中间产物存外面，agent之间传指针和摘要，别让几百MB的矢量文件撑爆context。
哪怕完全不用GeoFaham这套框架，拿GeoFaham-Bench这40个任务去测你自己的agent，也能看到那四条死法你会在哪一条上栽——这份benchmark本身就是个好的检查清单。
我会继续配环境争取跑通，到时再更新。