1. 项目概述为什么“能调用工具”还不够干遥感、环境监测这行的人应该都有过这样的经历卫星影像数据好不容易拉下来了结果光是做预处理就耗掉大半天想算个植被指数得先查某个波段在第几个位置想对比两期数据的变化还得自己写掩膜、裁剪、重投影的脚本。做环境观测很多时候难点不在“拿到数据”而在“处理数据”和“从数据里读出结论”。像很多大模型时代的地理空间工具一样OpenEarth-Agent想解决的就是“少写模板代码、专注于环境问题本身”这件事。但有一点是它和普通工具的关键差别大多数智能代理Agent只能调用预先定义好的工具比如给一个“计算NDVI”的函数它就只会算NDVI数据换了个坐标系、影像多了一个波段它可能就懵了。而OpenEarth-Agent的定位是从工具调用到工具创建——它不仅能调用现成的分析工具还能根据任务需要自己编写新的工具函数把临时性、偶发性的需求就地消化掉。这篇内容我会面向做环境遥感、GIS开发的朋友展开讲讲这个项目的核心思路、功能拆解、实际落地流程以及我踩过的坑。无论你是想在自己的数据上复现类似流程还是纯粹想把“工具创建型Agent”这套设计逻辑用起来应该都能从中找到可以直接参考的部分。2. 整体设计与核心思路让Agent把“分析需求”翻译成“代码动作”2.1 从理解环境任务到拆解执行步骤OpenEarth-Agent并不是一个完全由规则驱动的传统GIS工具链它更像一个“拿着工具箱的分析师”。用户输入一个任务例如“对比分析某区域2023年和2024年夏季的水体面积变化”Agent要做的事情包括明确数据源找到对应时间、对应区域的影像或数据集确认空间范围用边界矢量文件或经纬度坐标确定处理区域选择分析指标水体指数如NDWI、植被指数NDVI、地表温度、亮度值等执行计算用栅格运算、统计聚合等方法得出结果表达结果生成对比数据、渲染差异图、输出面积变化数值在这个流程里最考验设计的是第二步和第三步。越来越多的开放地球观测数据哨兵系列、Landsat系列、Modis产品格式和预处理程度各不相同。用一种“模型满腔热情、工具库一成不变”的方案去处理很容易出现“调用了函数但参数不匹配”“数据格式对了但坐标系统不对”等尴尬情况。工具创建能力就是为了应对这种动态差异。当Agent发现现有工具无法直接完成任务时它可以自行编写一个针对当前场景的小函数比如自动读取影像的投影信息、按正确方式重投影、计算两条时序影像的差值然后输出结果。这意味着它不只是在一个固定的函数列表里做选择题而是具备了一点“造工具”的能力。2.2 为什么选“沙盒执行代码生成”而不是纯API组合在设计这个系统时有一个关键取舍为什么不让Agent直接调用一堆预置API非要让它生成代码来跑原因很实际。环境观测任务的自定义程度太高了。API组合方案适合“工作流固定、数据格式标准”的场景比如固定从某个接口拉取天气数据并做阈值判断。但开放地球观测数据通常是GeoTIFF、HDF、NetCDF等格式影像波段、分辨率、坐标系、单位五花八门硬要用API组合去覆盖所有情况最终会退化成写一个专门处理某一种数据格式的巨大脚本维护成本极高。把代码生成放进沙盒里执行意味着Agent有了一个“写临时脚本”的便利桌面。遇到什么怪数据就直接生成一段Python代码去解析、处理跑了一遍不对就再调整整个过程由Agent自己观察反馈、修改代码。这相当于你身边有一个永远不用睡觉、还熟悉Rasterio和GeoPandas的同事能帮忙把杂活干完。提醒一点沙盒执行不是把生成的代码不管三七二十一直接扔进生产环境跑。Agent的代码生成能力必须配合权限控制、资源限制和超时机制否则会出现脚本跑飞、内存占满的风险。后面第4节我会详细说说实际部署时遇到的问题。2.3 工具调用层的高级封装策略工具调用层是整个能力的基础。OpenEarth-Agent会把常用的环境观测操作封装成一组“原子工具”让Agent可以直接调用。这些工具大致分成五类类别典型功能底层库与思路数据读取读取GeoTIFF、HDF、NetCDF获取波段信息和元数据Rasterio、xarray、netCDF4地理计算裁剪、重投影、范围统计、掩膜提取Rasterio、Fiona、rasterstats指数计算NDVI、NDWI、EVI、地表温度反演等自研公式封装矢量分析多边形叠加、区域统计、形状匹配GeoPandas、Shapely结果输出生成图表、渲染差异图、输出统计表Matplotlib、Pillow、pandas好的封装不是把每个函数写得多高级而是要让Agent“一看函数描述就知道该怎么用”。描述信息里必须说清楚输入参数的类型、坐标系要求、返回结果格式。我见过不少项目把函数写得本身没问题但注释极其简陋Agent调用时全靠猜最后产生大量错误往返。OpenEarth-Agent在函数说明上花了不少精力这一点后面实操时大家也能感受到。3. 核心细节解析工具创建机制是怎么工作的3.1 工具注册表与动态扩展先说说“工具调用”这边的细节。系统内部维护了一个工具注册表Tool Registry每一项工具记录包含函数名称和签名功能描述面向LLM的自然语言描述输入输出的类型注解是否需要特定运行环境Agent在开始任务时会先扫描注册表获取“当前可用的工具清单”然后根据用户需求决定调用顺序。这个过程类似一个程序员打开IDE的代码补全面板只不过这里补全的不是语法而是“能完成哪些空间操作”。工具创建则是动态扩展注册表的过程。当Agent认为缺少某个小工具时它会调用一个专门的“工具创建API”。这个API接收的参数包括目标函数的自然语言描述必要的测试数据样本预期输出样例大模型会生成一段Python函数代码。系统不直接采纳而是把代码放到沙盒里用测试数据跑一遍比对输出是否符合预期通过后再正式注册进工具表。这个“先测试后注册”的机制特别重要它避免了大模型“一本正经地生成一个错误函数”的情况。3.2 提示词设计与上下文管理OpenEarth-Agent在提示词设计上有一个核心技巧把地球观测任务拆解成“环境感知—计划生成—工具调用—结果反馈”四个阶段而不是一股脑让模型写完所有代码。环境感知阶段模型会先检查数据的基本信息比如影像的维度、波段数、投影坐标系、有效的值域范围。这些信息不一定是用户给的而是通过调用“探查数据”工具实时获取的。计划生成阶段模型列出需要执行的步骤每一步尽量对应一个工具调用。工具调用阶段模型逐步执行计划中途如果遇到异常比如某一步报错重新调整计划而不是死板地把流程跑完。结果反馈阶段把最终输出整理成可读的结论和图表。每一步之间都有清晰的结构化上下文传递。这样设计的好处是当你需要排查问题或者改进某一步时不用从一大段混沌的代码里翻找原因直接看某个环节的输出就行。对于工程类项目这简直是救命设计。3.3 一个关键细节让模型“看见”空间数据的元数据环境观测数据的坑很多其中最隐性的一个明明是栅格数据但坐标单位可能是度、米甚至未知。如果你不提前读取元数据直接让模型跑一个需要投影坐标的计算出来的数值会毫无意义。OpenEarth-Agent在每个任务启动时会自动读取数据的CRS和Transform作为上下文注入给模型。模型在生成处理指令时会主动检查这些参数需要重投影时先调用重投影函数再进入后续计算。这一步虽然看起来只是“多了一个读元数据的动作”但实际效果极好大幅减少了因为坐标系混乱导致的错误。4. 实操过程与核心环节实现让Agent完成一次植被变化分析纸上谈兵不重要我结合一个实际任务走一遍完整的流程。这里用一个模拟任务分析某区域两期夏季影像的植被覆盖变化输出总体NDVI均值变化和差异显著性区域。4.1 初始配置数据准备与工具加载首先生成或准备两期模拟影像数据格式为GeoTIFF波段设置为红光波段和近红外波段模拟Landsat或哨兵的结构但这里用随机生成的演示数据代替。数据准备好了把OpenEarth-Agent的沙盒环境跑起来确认工具注册表加载成功。启动时系统会显示当前可用的工具列表。正常情况下应该有数据探查、波段提取、NDVI计算、区域统计、差异分析、出图等工具。如果缺少某个工具Agent会在运行中提示并尝试创建。# 伪代码风格示意启动Agent并指派任务 agent OpenEarthAgent(workspace/project/vegetation_monitor) task 对比2023年7月和2024年7月的两个影像文件计算研究区域内的NDVI均值 并输出变化超过0.2的区域占比。 agent.assign(task)4.2 数据探查与预处理跳过这步后面全是泪Agent收到任务后并没有急着算NDVI而是先调用“数据探查”工具输出两个文件的基础信息。影像波段数是否满足NDVI计算条件坐标系和像素尺寸是否可以直接做像素级比较数据范围是否包含NoData值是否需要掩膜第一次运行环境里我发现生成的模拟数据使用了WGS84经纬度坐标而任务里后续的区域统计需要按面积来计算。Agent识别到这个冲突自动插入了重投影步骤将栅格数据从“度”单位投影到等面积投影模拟代码里用的是Web Mercator的变体真实项目里建议用适合当地纬度的投影如UTM或Albers。这个识别过程并不花哨但非常实用。很多GIS项目里的错误结果都源自“忘了确认坐标系就开始算面积”。有了Agent自动检查这类基础性错误基本可以避免。4.3 核心计算NDVI的工具调用进阶写法植被指数是环境观测的高频需求。NDVI的公式基础是NDVI (NIR - Red) / (NIR Red)工具库里已经内置了“compute_ndvi”工具。如果只需要算单期NDVI直接调用即可。ndvi_2023 call_tool(compute_ndvi, input_filescene_2023.tif, red_band2, nir_band3)但如果用户要求的是“每像素NDVI变化量且要求变化超过阈值的区域以矢量形式输出”就没那么简单了。内置工具可能只输出栅格差异图并不带矢量化的功能。这时候就是“工具创建”发挥作用的时候。Agent会分析需求发现当前工具无法直接完成“栅格差异图转变化区域矢量”的操作于是生成一个新工具# 由Agent根据任务需求生成的新工具函数 # 输入: 两期NDVI栅格路径, 差异阈值 # 输出: 变化区域的范围模拟输出为GeoJSON def detect_change_polygons(ndvi_a_path, ndvi_b_path, threshold0.2): import rasterio from rasterio.features import shapes import numpy as np import json with rasterio.open(ndvi_a_path) as src_a: ndvi_a src_a.read(1) profile src_a.profile with rasterio.open(ndvi_b_path) as src_b: ndvi_b src_b.read(1) mask np.abs(ndvi_b - ndvi_a) threshold results [] for geom, value in shapes(mask.astype(np.uint8), transformprofile[transform]): if value 1: results.append(geom) return json.dumps({features: results})这里有几个重点值得一说Agent生成的代码不是随意发挥它必须基于工具库里已有的“约定”。比如知道栅格数据用Rasterio打开、要素输出用GeoJSON结构这些都是通过工具描述和运行环境上下文学到的。生成完代码后Agent会用测试数据在沙盒里执行一次。如果输出的GeoJSON解析正常且面积占比在合理范围内就正式注册这个工具。这个新工具会缓存下来后续再有类似任务就不再需要重新生成。4.4 结果解读与渲染不只给数字还要给可验证的证据处理完计算Agent会汇总输出两期NDVI均值和变化量变化面积占比大于0.2阈值的区域比例差异热力渲染图新生成工具的调用记录和执行日志我习惯把执行日志也拿来看一眼因为排查问题不能只看最终数字。OpenEarth-Agent保留了每一步的工具调用输入输出摘要能清晰看到从读取影像到生成矢量的全链路。你要是拿到一个异常结果直接顺着日志查哪一步数据范围不对就行。5. 常见问题与排查技巧真实使用中踩过的坑工具创建型的Agent好用但它并不意味着万事大吉。实际部署时我遇到过不少问题挑几个有代表性的分享。5.1 带掩膜的栅格数据导致统计偏差场景某次分析里影像的部分区域被云遮挡数据里有掩膜标记。Agent在计算区域均值时没有排除掩膜区域导致统计值严重偏低。单纯看NDVI公式没问题但忽略掩膜就是脏数据进、脏数据出。解决策略是在工具描述里强制说明如果数据含掩膜波段或NoData标记统计前必须先过滤。后来我在工具注册表里增加了一个“检查NoData和掩膜”工具并规定Agent调用统计函数前必须先调用这个检查工具。虽然多了一步但结果可靠得多。5.2 重投影时的“像素对齐”问题两期影像如果来自不同分辨率或不同投影直接做像素级运算会导致错位重影。比如一期是10米分辨率另一期是30米分辨率两者像素不重叠差值的空间归属就是乱的。在工具创建阶段Agent尝试新写了一个“重投影并重采样”的函数但初始生成的代码默认使用了最近邻插值。在地表连续变化区域还行对边界敏感的任务就不够用。后来我在生成工具的验证逻辑里加了“检查重采样方法是否为双线性或三次卷积”的规则情况明显改善。5.3 工具代码的无限循环与资源失控生成的函数如果设计不当可能在处理大型影像时陷入长时间循环甚至内存溢出的状态。我在一次测试中遇到过Agent生成一个“逐像素遍历整个栅格”的函数数据量一大沙盒直接卡死。解决办法是在沙盒执行层加上硬性约束代码必须限制在固定内存池内执行卡上一定算法循环次数就自动中断。同时在提示词里强调优先使用向量化运算基于NumPy或Rasterio的块读取而不是逐像素循环。给Agent立好规矩比事后清理现场高效得多。5.4 工具IO与上下文长度限制Agent在工具创建时可能需要“看到”数据样本才能写对函数。如果直接把一整个GeoTIFF的内容塞进上下文大模型的上下文窗口很快就会爆掉。实际做法是只向模型展示数据的“小样”读取栅格的前几行像素、部分波段统计值、坐标范围等信息用这些轻量信息指导代码生成。这个技巧对做空间数据的开发者格外有用。不要试图把大数组传给模型而是抽象出特征信息再传。模型写出来的代码针对的也是数据特征而不是像素本身。6. 经验与扩展方向从“工具创建”到“技能沉淀”从工具调用到工具创建表面上是技术上的一步跨越本质上是一套“方法论”的升级让Agent不再只依赖预定义逻辑而是拥有适应新场景的应变能力。用较长一段时间后我有了几点体会。第一工具创建机制的高价值点在于“复用”。Agent每成功创建并验证一个工具之后遇到类似需求时就能直接调用。这些工具沉淀下来会形成一个逐渐丰富的领域工具集越用越顺。团队里甚至可以让不同成员维护不同的工具集比如一个人专攻土地利用分类另一个人专注水体监测各自沉淀技能库。第二生成工具的质量取决于“验证机制”的强度。纯靠大模型生成函数没有严格的验证流程就像不测试就上线早晚出事。OpenEarth-Agent设计的“先测后注册”思路很值得借鉴确保工具生成过程不是一次性输出结果就完事而是通过执行、比对结果、再决定是否采用。我可以负责任地说这套流程在复杂数据场景下是必要的。第三后续扩展可以考虑结合更大范围的地理空间知识库。目前工具创建主要依赖代码库和函数库的上下文如果能额外引入一个“环境观测领域知识库”让Agent在生成工具时参考同类任务的已知做法生成的代码质量会更高。比如针对冻土区域的时序分析可以先查到已有的地表温度反演方案再针对具体数据做调整。第四面向普通用户的界面交互也值得优化。目前Agent的使用主体还是有一定GIS和编程基础的人。如果后续能把工具创建的过程包装成更可视化的方式比如让Agent展示“我想写一个这样的工具”用户只需要确认或修改少量参数这款系统的适用面会一下子拓宽不少。我在实际使用中还有一个很深的体会对任何一个数据科学类的智能Agent来说能力边界其实不取决于模型参数有多大而取决于它“手边的工具是否够用、是否能自己补充不够用的部分”。OpenEarth-Agent把重心放在这个位置是抓到了问题的实质。算不算最成熟的工程方案还有很大迭代空间。但方向我已经验证过了——当Agent能稳准狠地自己造工具搞定新数据时那种“这活总算不用手动写了”的感觉真的很值得追求。