业务问题：自然语言能驱动 QGIS，不代表它应获得项目写权限
QGIS Agent 的官方插件页将它描述为运行在 QGIS Desktop 内的 LLM 驱动助手。页面列出的能力很广：查看项目信息、添加或移除图层、执行 Processing 算法、运行 PyQGIS、设置图层标注和渲染地图。对需要反复执行空间处理的团队，这能减少命令记忆和界面点击；对生产项目，它也意味着必须把“提出请求”“生成计划”“执行写操作”分开。
资料依据：工具、检索和工作流都在同一插件内
插件页当前列出 20 个内置 QGIS 工具、679 条 Processing 算法/工具参考条目和 RAG 增强 API 文档检索。它还列出 Cookbook 自演化、长期记忆、任务图、工作流录制与回放，以及在用户意图模糊时主动澄清。这里的价值不是让模型自由生成任意 PyQGIS，而是先将常见操作锚定到可检索的工具与参考项。
页面也列出三种安全机制：PyQGIS AST 静态扫描、危险操作确认和不可信数据清理。它们应被理解为执行前的安全门，而不是脚本一定正确的保证。比如“删除重复图层”仍需要先给出候选列表、匹配依据和影响范围；静态扫描无法替代对业务字段、数据源和输出位置的核验。
本地 MCP 是接口，不是默认授权
QGIS Agent 可选地将同一组工具暴露为 MCP server，供外部 AI agent 调用。官方页面明确说明它默认关闭，必须从设置页显式启动，只监听 127.0.0.1，并要求访问令牌。这意味着本机其他程序也不能仅凭知道端口就调用它。
更重要的是，execute_pyqgis、execute_processing、remove_layer、load_project、save_project 与 run_skill 等特权工具对外部 agent 默认隐藏；即使管理员主动启用，每次执行仍需屏幕确认。端口和令牌保存到 ~/.qgis_agent/mcp_session.json，文件模式为 0600，并在服务停止时删除。这个设计把运行会话、最小权限和人机确认绑定在一起。
业务场景：把批量制图请求变成可回放的变更单
以“对十个行政区批量生成坡度统计图”为例，agent 可以先读取项目和图层元数据，列出将使用的 DEM、目标 CRS、Processing 参数和输出目录；用户确认后再运行算法。工作流录制与回放可保存重复步骤，但每一轮仍要检查输入数据版本、输出是否已存在、统计单位和地图范围。
如果外部 agent 通过 MCP 参与，建议仅开放只读项目检查、图层枚举和渲染预览。将保存项目、删除图层、运行任意 PyQGIS 等写操作留在本地屏幕确认之后。这样，自动化能缩短准备时间，又不会把一个聊天请求直接转化为不可逆修改。
技术实施路径
- 默认关闭 MCP，仅在本机短时会话中启动。
- 将工具分为只读、可逆写入和高影响写入三组；特权工具保持隐藏。
- 每次 Processing 或 PyQGIS 执行前展示输入图层、参数、CRS、输出路径和覆盖风险。
- 保存工作流回放记录，同时记录 QGIS、插件、算法和数据版本。
- 在副本项目完成检查后，才将经确认的输出合并到正式项目。
风险边界
官方页面的工具数量、RAG、AST 扫描和确认机制说明了插件的设计方向，不能证明任一模型、脚本或外部 MCP 客户端的正确性。自然语言还会误解同名图层、隐含单位和业务术语；确认窗口也不能弥补错误输入。桌面 GIS agent 的可靠使用方式，是让它先解释将做什么、用什么数据、改动哪里，再由人决定是否执行。
结论
把本地 MCP、特权工具和屏幕确认拆开，才能让 QGIS 自动化既可用又可控。
关键词：GIS 是地理信息系统；QGIS 是桌面空间分析软件；MCP 需要最小权限和本机边界；AI Agent 自动化应保留 PyQGIS、Processing、CRS 和输出记录。