遥感 Agent 收到“找一批雨季前后的森林变化影像”时，常被直接要求写 Item Search。真正的第一步却是确认：哪些目录里可能有相符的集合，它们支持什么查询条件，覆盖什么时段、区域与许可。Development Seed 的跨目录 STAC 发现实践把这一步单独做成服务，给 GIS 团队一个清晰的分层：先发现 collection，再检索 item，最后才读取资产和运行分析。

核心机制：把集合发现与具体资产检索拆开

官方文章指出，公开生态中有 hundreds of public STAC APIs，而每个 API 可拥有 dozens to thousands of collections。如果让 Agent 直接面对全部目录，它要么依赖预设网址，要么下载大量元数据后自行猜测，既难以复现也容易遗漏数据源。

文章介绍的 stac-fastapi-collection-discovery 是一个专门面向 collection search 的 STAC API 实现：它把请求转发到 configurable set of upstream STAC APIs，合并结果后返回。服务本身 remains stateless，不维护自己的集合元数据副本；并会检查上游能力，只暴露 parameters that are common across the selected catalogs。这意味着联邦入口可以负责“哪里可能有数据”，却不能声称替代上游目录、覆盖全部参数或永久保存某次结果。

GIS 场景：为洪涝变化分析生成可审计候选数据集

假设团队要比较某流域两次洪涝期间的光学与雷达观测。Agent 先提交研究区域、时间窗、传感器偏好、云量或处理级别等需求给集合发现层，得到候选 collections 及其所在目录、描述、空间时间范围、许可和共同支持的过滤能力。分析人员选择可用集合后，系统才进入 Item Search，固定 collection ID、查询参数、返回 item、资产 URL 与时间戳。

这样，光学被云遮挡时，Agent 可以解释是“候选集合不满足时间或覆盖条件”，还是“集合满足但没有可用 item”，而不把没有结果误写成没有数据。多目录结果也必须保留来源列表，避免把同名 collection、不同处理级别或不同许可的资产混为一组。

可核查事实

  • Development Seed 的文章称，发现地球观测数据时，生态中存在 hundreds of public STAC APIs。
  • 文章称这些 API 各自包含 dozens to thousands of collections。
  • 该工具可在不预先知道目录位置的情况下，同时搜索 NASA, ESA, and other catalogs。
  • stac-fastapi-collection-discovery 是一项专注 collection search 的 STAC API 实现。
  • 它向 configurable set of upstream STAC APIs 转发查询并合并结果。
  • 文中说明该服务 remains stateless，不自建 collection 元数据副本。
  • 服务根据上游能力，只提供 parameters that are common across the selected catalogs。
  • 文中明确建议发现到目标 collection 后，再切换到自己的 Item Search 工具查找具体 items 与 assets。
  • 文章还介绍 STAC Atlas：它通过 periodically scanning all of the registered STAC APIs and static catalogs 建立可搜索的集中 collection 记录。

技术路径：三层记录把“没找到”变成可解释结果

第一层是发现请求：保存自然语言问题转成的空间范围、时间范围、关键词、collection search 参数、所选上游目录和共同参数集。第二层是集合决策：保存每个候选 collection 的 ID、目录 URL、描述、许可、时空范围、传感器或处理级别，以及选择或排除的理由。第三层才是 Item Search：保存 collection ID、查询请求、命中 item、资产链接、版本与执行时间。

Agent 应只把第一层的结果称作“候选数据集”，把第三层成功返回且通过范围、时间、许可和质量检查的结果称作“可用输入”。上游 API 不支持某个过滤条件时，要显示该条件没有被执行，而不是静默降级。集中索引或 STAC Atlas 可用于加快目录发现，但分析运行仍须回到上游或记录清晰的镜像检查当前元数据。

风险边界

联邦 collection search 合并的是目录响应，不会统一各提供方的空间参考、处理级别、重访周期、许可或质量口径。共同参数是可移植性的下限，也可能丢失某个目录特有的检索能力；无状态服务则意味着后续查询可能得到随上游更新而变化的结果。对灾害研判、监管或付费数据使用，仍要核对当前许可、延迟、云量、几何有效性和资产可访问性。

检查清单

  1. 将业务问题明确为 AOI、时间窗、传感器、处理级别和许可约束。
  2. 记录参与联邦发现的上游 STAC API 清单与共同查询参数。
  3. 为每个候选 collection 保存 ID、目录、时空范围、描述和选择理由。
  4. 将 collection discovery 与 Item Search 的请求、响应和运行时间分开留档。
  5. 标明每个过滤条件是已执行、上游不支持，还是需要人工复核。
  6. 在读取资产前检查 item 时间、几何、处理级别、许可和访问状态。
  7. 对无结果、同名 collection 和跨目录重复资产保留可追溯的排除记录。

结论

遥感 Agent 的第一项能力不应是更快地下载影像，而是清楚地区分“发现了哪些数据集”“为何选择这一集合”“哪些具体资产真正可用”。用联邦 STAC Collection Search 处理发现，用 Item Search 处理资产，再把请求和决定逐层留痕，才能让自动化数据入口经得起复查。

参考来源

  1. Development Seed, Finding Earth Observation Data Across STAC Catalogs：https://developmentseed.org/blog/2026-07-30-stac-discovery/