地理空间数据访问服务

问题：地理空间数据的「可发现性」难题

地理空间数据正在以前所未有的速度增长。Source Cooperative 上的数据集已超过 800TB，分布在 94 个以上的组织账户中。问题在于：这些数据虽然公开存在，却很难被真正「找到」和「取用」。

• 传统目录式检索往往无法覆盖所有已发布和未发布的数据集
• 即使你知道了某个数据集的存在，获取其文件结构、元数据、更新状态也并非易事
• 对于 AI 客户端而言，直接与对象存储交互需要处理 S3 协议、路径拼接、权限认证等复杂细节

这就是本技能要解决的问题。

路由层设计：让大模型做决策，代码做执行

这个技能的核心架构非常清晰：大模型负责理解意图、选择工具、提取参数，代码只负责调用 API 并返回结果。

工作流程分为四个步骤：

1. 检查 API 密钥：如果未配置 XBY_APIKEY，通过交互询问用户获取
2. 选择工具：根据用户意图从工具列表中匹配最合适的函数
3. 提取参数：解析用户请求中的关键信息
4. 调用工具：使用关键字参数调用 scripts.tools 中的函数

这种设计的优势在于：LLM 不需要理解底层的 S3 路径规则或 API 参数细节，它只需要知道「有什么工具可用」和「怎么调用」。

工具函数：从搜索到取用的完整链路

这个技能提供了 6 个核心工具函数，覆盖了从「发现数据」到「访问数据」的完整路径：

• list_accounts：列出 Source Cooperative 上的所有组织账户
• list_products：列出某个账户下的数据集，支持两种模式

- S3 模式（默认）：快速扫描所有产品（含未发布），返回基本信息
- API 模式：获取已发布产品的丰富元数据

• get_product_details：获取某个产品的完整元数据，包括账户信息、存储配置、标签，以及根目录下的 README 内容
• list_product_files：列出产品内的文件，支持 show_tree 模式生成目录树，并自动检测分区数据
• get_file_metadata：获取单个文件的元数据（大小、类型、更新时间），不下载文件本身
• search：跨账户智能搜索，支持模糊匹配和拼写纠错（60% 相似度阈值）

特别值得一提的是 list_product_files 的 tree 模式。它会自动检测分区数据（如 year=1995、format=ixi），并将多个文件智能聚合成一条分区摘要，可以节省 70% 以上的 token。

适用边界与注意事项

这个技能并非万能：

• 需要 API 密钥：必须在 .env 中配置 XBY_APIKEY，否则无法使用
• Token 消耗需关注：虽然 tree 模式能显著节省 token，但返回完整文件列表或 README 内容仍可能消耗较多 token
• 搜索性能：search 工具需要约 5-8 秒，因为要并行扫描 94 个账户和 354 个产品
• 数据范围：S3 模式可以访问未发布产品，但这些产品的标题和描述字段为空