结论：这一轮最值得单独深挖的是 SpatialClaw: Rethinking Action Interface for Agentic Spatial Reasoning。它不是遥感原生论文，也没有在卫星影像 benchmark 上报告结果；但它给遥感 VLM 一个很直接的启发：空间推理不应只靠一次性文本回答，也不应只靠固定 schema 的工具调用，而应该让模型在一个有状态 Python kernel 里逐步写代码、调用感知工具、查看中间证据、修改分析路径，最后再提交答案。对大幅遥感影像、矢量图层、DEM、时间序列和 GIS 证据链来说，这个“代码即动作接口”的设定比普通 VQA prompt 更接近真实工作流。

我按 2026-06-13 23:00 +08 检索公开来源，过滤 SAR、PolSAR、InSAR、radar-only、microwave-only 和 SAR-optical fusion 主线。本篇选择 2026-06-11 提交 arXiv 的 SpatialClaw。论文和官方 GitHub 均已公开，仓库说明包含 agent runtime、LangGraph workflow、persistent Jupyter kernel、AST safety check、planning/reflection loop、20 个 benchmark loader、perception tool wrappers、FastAPI GPU tool server、vLLM 发现与负载均衡、SLURM 复现实验管理。本文把它作为 CV-to-RS 迁移方向，而不是当作已有遥感 SOTA 结果引用。

这篇适合放进“遥感基础模型与多模态理解”。原因是它研究的是 VLM agent 的空间推理接口，而遥感 VLM 的很多关键失败都来自空间接口不足：模型看不清局部证据、不会把 tile 和全图坐标对齐、不会把 mask/box/polygon/DEM 统一计算、不会记录跨步骤证据，也不会把中间计算交给可验证工具。SpatialClaw 不直接解决遥感问题，但它给了一个可复用的系统骨架。

结论：这一轮最值得单独跟踪的是 TerraBench。它的价值不在于又给 LLM Agent 做了一个排行榜，而是把地球科学任务里的真实困难放进了评测：卫星影像、格网物理量、GIS 上下文、仿真器、外部文档和数值容差必须在同一个可执行流程里协同。结果也很直接：强模型并不是不会选工具，而是经常把参数、单位、空间范围、时间窗口和数值证据链做错。

我按 2026-06-13 03:00 +08 检索公开来源，过滤了 SAR、PolSAR、InSAR、radar-only、microwave-only 和 SAR-optical fusion 方向。本篇选择 2026-06-11 提交的 TerraBench: Can Agents Reason Over Heterogeneous Earth-System Data?。论文有 arXiv、HTML 版本和 GitHub 仓库；它的主线是 Earth-system / geospatial agent benchmark，不是单一遥感视觉模型。

这篇适合放进“多源数据融合、效率部署与应用落地”。原因是它把遥感 AI 从“看懂一张图”推进到“能不能把图像、GIS、环境变量、仿真和文档组织成可审计计算”。对遥感大数据来说，这个方向比普通 VQA 更接近生产系统：用户真正需要的不是模型说一句“这里可能有洪水风险”，而是它能否调用正确数据、设定正确区域、运行正确工具、保留中间产物，并给出容差内的数值答案。

背景

过去一年地理智能体和遥感 VLM 的热度很高，但很多评测仍然偏窄。常见任务是图像问答、caption、单图 grounding、地图工具问答或简单 GIS 操作。它们能测模型是否会读图、会不会调用地图 API，却很难测真实地球科学工作流里最麻烦的部分：数据异构、单位不一致、空间投影、时间窗口、仿真参数、文档约束和结果可追溯性。

TerraBench 的问题意识很明确。天气和气候基础模型擅长预测物理场，但不擅长用自然语言交互式推理；LLM 擅长语言规划，但不能直接处理高维地球系统数据。真实分析往往处在两者之间：研究者要从遥感影像、栅格变量、矢量边界、模拟器输出和论文表格中重建一个可信结论。

这类任务对遥感 AI 很重要，因为遥感应用的终点通常不是单个 mask 或类别标签，而是一个带行动含义的决策：某个县未来几天水资源压力如何，某片作物在指定气候情景下是否减产，某段道路中断会造成多大通勤延误，某个城市热风险是否超过阈值。模型要回答这些问题，必须把视觉、地理和科学计算接起来。

从 CV/ML 到遥感的迁移路径也很清楚。通用 Agent 研究里的 ReAct、工具调用、代码执行、artifact 管理和过程评测，可以迁移到遥感大数据系统；但遥感场景必须额外处理坐标、尺度、时序、空间自相关、物理单位、数据来源和科学容差。TerraBench 正是在这些地方把普通 agent benchmark 拉回地球科学现实。

方法/框架

TerraBench 建在 TerraAgent 之上。TerraAgent 是一个 ReAct-style executable framework，也就是让 LLM 在推理过程中交替进行思考、工具调用和观测，再把环境检索、地理处理、仿真和 artifact-backed computation 连接起来。这里的关键不是“给模型更多工具”，而是把工具调用变成可检查的执行轨迹。

结论：这一轮最值得单独跟踪的是 Earth-Agent / Earth-Bench。它的价值不在于又训练了一个更会描述遥感图像的 VLM，而在于把遥感智能体的评测对象从“回答一句话”推进到“能否选择工具、传递参数、执行多步定量分析，并让推理轨迹可检查”。

我按 2026-06-12 19:00 +08 检索公开来源，过滤了 SAR、PolSAR、InSAR、radar-only、microwave-only 和 SAR-optical fusion 项。本篇选择 ICLR 2026 Poster Earth-Agent: Unlocking the Full Landscape of Earth Observation with Agents。它覆盖 RGB、光谱数据和加工后的 Earth products，但核心不是雷达或 SAR；公开材料也没有把 SAR 作为主贡献。因此它符合本轮“非 SAR、优先 VLM/可落地 benchmark”的筛选条件。

这篇和已有 GeoChat、VHM、SegEarth-OV、RS-VLM benchmark 的区别很明显：它不再把遥感 VLM 主要定义为图像描述、分类、VQA 或 grounding，而是把 LLM 作为 policy，让它在 Earth observation 工具系统里做多步规划、工具调用、记忆更新和结果判断。对遥感 AI 来说，这个方向比单纯写 prompt 更值得跟踪，因为真正的 EO 任务往往需要传感器选择、时间窗口、指数计算、区域统计、模型推理和误差检查，而不是只看一张 RGB 图回答“这里有什么”。

背景

遥感 VLM 这两年发展很快，但主流评测仍偏向单步感知：给一张遥感图像，让模型分类、生成 caption、回答 VQA、定位目标或做开放词表分割。这类任务当然重要，但离真实 Earth observation 工作流还有距离。一个研究人员或业务人员真正要问的问题常常是：某个地区过去三个月植被是否异常下降，某次灾害前后建筑损毁是否集中在河道附近，城市热岛是否和不透水面扩张有关，或者某个产品的空间统计能否支持一个科学判断。

这些问题的难点不只是视觉识别。模型需要知道该用哪个数据源、哪个时间段、哪个空间范围、哪个指数或产品；还要能调用外部工具，处理多张影像或栅格产品，最后给出定量结果。单纯的 MLLM 即使能描述图像，也容易在这类任务上产生三类问题：凭视觉印象下结论、编造不可执行的分析步骤、无法复现中间证据。