自然语言驱动 GDAL、PostGIS 和空间 SQL，能减少重复操作，却把文件改写、数据库查询、数据目录访问和消息发送放进同一条 Agent 执行链。Golem 的开源 README 将自己定位为私有 GIS 分析 Agent，并把工具审批、策略和审计作为内建能力。它提供了一个实用原则：工具越接近生产数据，执行权越不能只由模型的语言输出决定。
可核查事实
- Golem README 将项目称为面向地理空间行业的垂直 AI Agent，以 Go 和 Eino 构建。
- README 说明其通过 WebUI、终端 TUI 或 IM 渠道把自然语言请求转为 GDAL/PostGIS 工作流。
- Agent 循环最多可进行 20 次工具调用，并提供工作区本地 GDAL/PostGIS 工具、流水线复用、工具脚手架和技能遥测。
- 工具层包括数据检查、GDAL/OGR 处理、CRS 检测、格式转换、数据目录、空间 SQL 代码库和 PostGIS 查询。
- 成功的工具序列会保存为可重放流水线；缺失工具可生成待人工补全的 dry-run 脚手架。
- README 提供 strict、relaxed、off 三种策略模式；在 strict 下 exec 和 geo_spatial_query 等敏感工具需要明确人工批准。
- 所有工具执行记录到 state/audit.jsonl，待批准状态存储在 state/approvals.json；文件与命令可限制在工作区，空间查询在支持时默认只读事务。
核心机制：把语言意图与执行权限分开
Agent 可以提出“裁剪影像、重投影、写入数据库”的方案，但这些操作是否允许执行，取决于数据边界、工作区、策略和审批状态。Golem 的策略模式与批准门将这一判断移出模型自由生成的文本：严格模式下，敏感命令和空间查询必须经过人工确认；批准、拒绝和审计记录以独立状态保存。
流水线复用同样需要边界。成功序列能提高效率，但不能因为过去一次成功就默认适用于新数据。参数、CRS、范围、输入版本和输出位置都要重新核验；对缺失工具生成的脚手架应先作为 dry-run 产物接受审核，不能直接注册为可写生产数据的工具。
GIS 场景：把自动化任务划分为读、写与外联三类
部署时可把 geo_info、目录查询和只读空间查询归为低风险读操作；裁剪、格式转换、写入图层、执行 shell 和消息发送归为写入或外联操作。每类配置最小权限、可用工作区和审批人。对于 PostGIS，默认只读事务可用于探索；任何写入、删除或结构修改应走单独变更流程。
最终交付不仅是结果图层，还应包括输入数据版本、工具参数、批准记录、审计摘要和可重放流水线。这样，地图分析师能判断结果从何而来，管理员也能审查谁授权了哪些高风险动作。
技术路径
- 为每个 geo_* 工具定义读写能力、工作区范围、所需审批和输出位置。
- 以 strict 作为生产默认策略，将 relaxed 或临时关闭设计为有时限、自动恢复的例外。
- 将每次工具调用的请求、参数、输入摘要、批准人、结果和错误写入不可变审计日志。
- 对重放流水线先做 dry-run，比较 CRS、范围、输入版本和预期输出，再允许执行。
- 为 PostGIS 分离只读与写入连接，并在写操作前要求变更单与人工批准。
- 定期用审计记录统计失败工具、被拒绝请求、越界尝试和高风险重复操作，优化策略而非放松门槛。
检查清单
- 敏感 GDAL、shell 与 PostGIS 操作是否在执行前需要明确批准？
- 工具是否被限制在指定工作区、数据源和网络边界？
- 每次执行能否回链到参数、输入、批准状态和输出？
- 已学习流水线是否在新数据上重新进行 dry-run？
- 是否默认使用只读空间查询，并为写操作保留独立流程？
风险边界
Golem README 描述的是项目设计与能力，不能保证任何部署的策略配置正确。审批门若被设为 off、审计日志若可被篡改、或工作区边界过宽，都会削弱控制。Agent 的空间推理也不替代数据授权、隐私评估、备份和专业 GIS 审核；尤其是对生产数据库，最小权限和人工变更管理仍是基本要求。
资料依据
本文依据 Golem GitHub README 撰写。工具层、重放流水线、dry-run 脚手架、策略模式、批准门、审计文件、工作区限制和只读事务说明均来自 README；读写分级和变更流程为 GIS 运维建议。
结论
GIS Agent 的可靠性不能只靠“模型更聪明”，而要靠执行权被策略、审批和审计约束。先让每个工具动作可拒绝、可回放、可追责，再扩大自动化范围。