业务问题：自然语言入口不必等于任意脚本入口
Naksha 的 README 将它描述为一个免费开源的 QGIS AI agent 插件，当前版本标记为 v0.3.0 experimental。它的设计值得关注之处，不是把所有请求都交给模型，而是把“已知 GIS 操作”和“开放式分析请求”分开：道路按属性着色、学校 500 米缓冲、缩放到等高线、统计要素数、查看项目和保存项目等命令，可以不触碰 AI、离线立即执行。
这给桌面 GIS 自动化一个清晰原则：先识别可确定的操作，再决定是否需要模型解释。对团队而言，离线可执行路径也更容易测试、记录和复现。
资料依据：算法来自本机 registry，而不是模型临时发明
README 说明 Naksha 会实时发现并运行已安装的 Processing 算法；开发者机器上示例为 715 个，但实际数量取决于本机的 GDAL、GRASS、PDAL 和第三方 provider。这个数字不应被当作所有安装都具备的能力清单，而应在每台机器上线前重新盘点。
它还列出三种写入审批模式：默认的 Ask before writing、Autonomous 与 Read-only。将它们理解为项目级开关更合适：探索阶段可选只读，批处理草案使用逐次确认，只有经过验证的、可回滚流程才考虑自主写入。
输出校验与 MCP：两条不同的控制线
README 称插件会校验自身输出，例如 0 个要素的“成功”会被标记并修正，而不是直接报告完成。这种检查只能发现一类结果异常，不能证明缓冲距离、CRS、输入图层或业务口径正确。因此，项目验收仍应额外记录算法参数、输入版本、输出路径和抽样地图检查。
对于外部 AI app，Naksha 的 MCP bridge 默认关闭、只监听 localhost、每个会话使用 token，并将每次调用记录到 Naksha 标签页。localhost 和 token 缩小了网络暴露面，日志则让管理员能回看谁调用了什么；它们并不自动替代写入审批。
业务场景：学校缓冲分析先跑离线步骤，再进入解释环节
以“找出易受洪水影响的学校并制图”为例，先离线完成学校图层检查、字段统计、500 米缓冲和项目范围确认。随后再让 agent 帮助提出洪水数据来源、暴露规则和制图方案。执行任何交集或写入前，界面应展示数据时间、坐标系、Processing 算法、阈值、输出 GeoPackage 和覆盖风险。
若结果为 0 个学校，不能只依赖插件的异常提示；应检查 AOI 是否相交、单位是否为米、图层是否选对、以及洪水数据是否覆盖目标区域。这样才能把“工具运行完毕”与“业务结论可信”分开。
技术实施路径
- 在 QGIS 3.40 LTR 或更高版本的副本项目中安装，先枚举本机 Processing providers 与算法数量。
- 默认使用 Read-only 或 Ask before writing，禁止未经验证的 Autonomous 批写入。
- 为每次处理保存算法名称、参数、CRS、输入数据版本、输出位置和要素数。
- 将 0 要素、空输出、覆盖已有文件和 CRS 不一致列为人工复核触发条件。
- MCP 仅在短时会话打开，检查 localhost、会话 token 与调用日志；结束后关闭 bridge。
- 运行项目提供的无 AI key smoke test，再用真实小样本检查输出。
风险边界
README 所述的固定工具、无 exec/eval、无 shell 和无第三方依赖减少了任意代码执行面，却不能保证 Processing 参数和输入数据正确。715 只是某开发环境的示例；不同机器的算法可用性、版本和输出都可能不同。bandit、secrets 与 ruff 检查也不能替代组织的数据访问控制。
结论
可靠的 QGIS agent 工作流，应优先复用本机可见的算法，再以默认写入审批控制项目改动，并把输出校验升级为完整的 CRS、输入和结果复核。离线步骤、调用日志和短时 MCP 会话共同构成比“让模型直接操作地图”更可控的自动化路径。
关键词：GIS 是地理信息系统；QGIS Processing 算法应记录参数；MCP 需要 localhost 与会话边界；空间分析输出必须复核 CRS 和输入数据。