QGIS Agent MCP：讓 AI Agent 直接操作 QGIS，GIS 工作流程正走向 Agent 化
如果有一天，你不需要自己一步一步操作 QGIS，而是直接告訴 AI：「幫我完成這張地圖」呢？
我們過去談 AI 與 GIS，常見的做法是讓 ChatGPT、Claude 或其他大型語言模型產生 PyQGIS 程式，再由使用者自行貼到 QGIS Python Console 執行。這種方式已經能節省不少時間，但人類仍然要負責複製程式、執行工具、檢查錯誤，以及判斷最後的地圖是否合理。
隨著 AI Agent 與 Model Context Protocol，也就是 MCP，逐漸成熟，GIS 的操作模式正在出現新的變化。QGIS Agent MCP 嘗試解決的問題，就是讓 AI Agent 不只是「教你怎麼操作 QGIS」，而是透過結構化工具直接連接正在執行的 QGIS Desktop。
如果想先了解較早期的 QGIS MCP 應用，也可以參考站內的「出一張嘴 AI 畫地圖－QGIS MCP」；本篇則聚焦在 QGIS Agent MCP 這個以 Agent Workflow、工具探索與安全執行為核心的新專案。
先說結論：QGIS Agent MCP 是什麼？
QGIS Agent MCP 是一個開源 QGIS Plugin 與本機 MCP bridge，讓支援 MCP 的 AI Client 可以連接正在執行的 QGIS Desktop。連線後，Agent 不只取得文字說明，而是可以依照任務需要發現並呼叫 QGIS 工具。
目前專案的工具範圍涵蓋 Project、Vector、Raster、Processing、Database、Cartography、Layout、3D 與 Point Cloud 等 GIS 工作。它真正有意思的地方，不是單純把 Chatbot 放進 QGIS，而是把 QGIS 轉換成 Agent 可以理解與操作的 Tool Environment。
換句話說，使用者不一定需要先指定「下一步按 Buffer，再按 Spatial Join」，而是可以先描述想完成的空間分析目標，再由 Agent 規劃可能的 GIS Workflow。
先理解 MCP：AI 與軟體之間的通用工具介面
MCP 全名為 Model Context Protocol，可以把它理解成 AI Application 與外部工具、資料來源及服務之間的標準化介面。
如果沒有 MCP，每個 AI Agent 想操作不同軟體時，可能都要另外設計 API、Function Calling Schema 與連線機制。MCP 則讓 Client 可以用比較一致的方式發現 Server 提供的 Tool、理解 Tool Schema，再依照任務需要呼叫工具。
對 GIS 而言，這代表 Buffer、Clip、Layer Management、Processing、Map Rendering 等功能，都有機會變成 Agent 可以理解與呼叫的 Tool。
可以用下面三種模式理解這個變化：
| 操作模式 | 主要流程 | Agent 自主程度 |
|---|---|---|
| 傳統 QGIS | 人類操作 GUI，再執行 GIS 工具 | 低 |
| LLM + PyQGIS | AI 產生程式，人類檢查並執行 | 中 |
| QGIS Agent MCP | Agent 發現 Tool、執行 Workflow，再檢查結果 | 高 |
MCP 本身不會自動讓模型變成 GIS 專家。它解決的是「AI 如何以一致方式使用外部工具」這個介面問題；空間方法是否正確、資料品質是否可靠，仍然需要 GIS 專業判斷。
QGIS Agent MCP 的基本架構
QGIS Agent MCP 位於 AI Agent 與 QGIS Desktop 之間，基本流程可以整理成以下六層：
- 使用者：提出目標，例如「幫我分析目前專案中的道路資料」。
- AI Agent / LLM：理解需求、拆解工作與安排先後順序。
- MCP Client：發現並呼叫 QGIS 提供的工具。
- QGIS Agent MCP：負責工具探索、Project Context、Workflow 與安全控制。
- Authenticated Local Bridge：透過經過驗證的本機連線傳遞請求。
- QGIS Desktop：實際管理 Project、Layers、Processing、Layout、3D 與 Point Cloud。
最重要的差異在於，Agent 不只是把一段任意程式碼丟進 QGIS，而是透過一組有明確輸入與輸出定義的 Tool 執行工作。這讓每個步驟比較容易檢查，也比較適合加入確認、恢復與錯誤處理。
100 多個 GIS Tools，但不一次全部丟給 LLM
QGIS Agent MCP 的官方 README 將專案定位為提供 100 多個 specialist QGIS tools，涵蓋不同 GIS 工作領域。若把 100 多個 Tool Schema 一次全部放進模型 Context，會增加 Token 消耗，也可能讓 Agent 更難選擇正確工具。
因此專案採用低 Context 成本的工具探索方式：預設只載入 7 個核心或 Discovery Tools，等 Agent 理解任務後，再尋找最相關的工具 Schema。
| 傳統作法 | QGIS Agent MCP 的作法 |
|---|---|
| 100 多個 Tool Schema 全部載入 | 先提供 7 個核心 / Discovery Tools |
| 每次都傳送完整工具清單 | 依任務動態發現相關工具 |
| Context Window 容易被工具描述填滿 | 讓 Context 保留給 Project State 與任務推理 |
| 工具數量越多，選擇難度越高 | 逐步揭露最可能需要的 Schema |
這種設計的價值不只在節省 Token，也讓大型 Tool Ecosystem 更容易擴充。對 Agent 來說，工具多不一定是優點；能不能在正確的時間看見正確的工具，反而更重要。
qgis_context：先讓 Agent 理解目前的 GIS 專案
GIS 任務高度依賴目前 Project 的狀態。例如：
- 目前有哪些 Layer？
- 各 Layer 使用什麼 CRS？
- 欄位名稱與資料型別是否符合預期？
- 資料來源是否仍然有效？
- 專案中有哪些 Processing Algorithm 可以使用？
QGIS Agent MCP 使用 qgis_context 將 Project State、Schema 與即時能力整理成適合 Agent 使用的 Context Pack。官方 README 也說明它會在嚴格的 byte budget 下組合相關資訊；專案的執行說明則將這類 Context Pack 控制在約 2–32 KiB 的範圍，並透過 Project Revision 與增量更新減少重複傳輸。
這和單純把所有圖層摘要一次貼給模型不同。當專案發生小幅變化時，Agent 可以優先取得變更部分，而不必重新傳送完整的 Project Context。
Agent 可以操作哪些 GIS 工作？
QGIS Agent MCP 的工具不只處理簡單的圖層新增與移除，而是分布在一整段 GIS 工作流程：
| 工具領域 | 可以處理的工作例子 |
|---|---|
| Project | 建立與管理專案、讀取狀態、設定 CRS、儲存專案 |
| Vector | 圖層操作、Feature Query、屬性分析、幾何工作流程 |
| Raster | Raster Layer 管理、Raster Processing、Raster Analysis |
| Processing | 搜尋 Algorithm、執行 Workflow、驗證輸出 Layer |
| Database | GIS Database Workflow、Spatial Query |
| Cartography | Symbology、Label、Map Styling |
| Layout | Print Layout、Map Layout、輸出前檢查 |
| 3D GIS | 3D View、3D Scene Workflow |
| Point Cloud | LAS、LAZ、QgsPointCloudLayer、PDAL Processing |
這也是它和單一功能型 Chatbot 的差異。Agent 可以在同一個任務中先檢查 Project，再執行 Processing，接著調整圖層樣式與 Layout，最後檢查畫面結果。
Visual Review：Agent 不只執行分析，也可以看結果
GIS 與一般後端工具很不一樣。Processing 成功執行，不代表最後的地圖一定正確或適合閱讀。圖層可能疊放順序不合理、標籤互相遮擋、範圍沒有縮放到重點區域，或是色帶讓讀者很難理解數值差異。
因此 QGIS Agent MCP 將 Visual Review 放進 Workflow：
- Agent 執行 GIS Tool 或製圖操作。
- QGIS Render Map 或提供 Screenshot。
- 具備 Vision 能力的模型檢查地圖結果。
- 如果發現標籤、範圍或樣式問題，進行有界線的修正。
- 再次 Render 並檢查結果。
官方 README 也提醒，Screenshot 的結構檢查可以協助辨識空白畫面，但美學與語意判斷仍需要具備視覺能力的 Client。也就是說，Visual Review 是一個回饋迴圈，不是「看過畫面就保證地圖正確」。
Safe Autonomy：為什麼它刻意不提供任意 Python Execution？
早期某些 AI × QGIS 實驗工具會讓 LLM 產生 PyQGIS，再交由 QGIS 執行任意 Python。這種方式彈性非常高，但也代表 Agent 可能執行檔案操作、系統指令或其他未預期的程式碼。
QGIS Agent MCP 選擇比較受控的方向：
- 使用 Typed Tools 描述可執行的操作。
- 優先使用 QGIS Processing Algorithm。
- 透過 Guarded Workflow 管理具有副作用的操作。
- 使用 Revision Guards、Idempotency、Checkpoint 與 Atomic Workflow 降低重複執行的風險。
- 以 Restart Recovery 協助長時間工作在 QGIS 重啟後恢復。
這會犧牲一部分任意程式碼的自由度，但對長時間執行、需要確認與需要追蹤結果的 Agent Workflow 來說，反而比較容易建立信任邊界。
連 QGIS Plugin 都能由 Agent 協助尋找
QGIS 的一大特色是 Plugin 生態，但 Agent 不一定知道某個任務應該使用原生 Processing、目前已安裝的 Plugin，還是需要另外尋找相容套件。
QGIS Agent MCP 的 Plugin Advisor 會先檢查 QGIS Native Capability 與已安裝 Plugin，再從官方 QGIS Plugin Repository 尋找相容候選，並依相容性、維護狀態、使用狀況與風險等條件排序。
這裡的重點是「建議」而不是「無條件安裝」。如果真的需要安裝 Plugin，仍然需要使用者進行明確確認。對具有系統修改效果的操作來說，讓 Agent 先提出短暫且清楚的確認請求，比默默修改環境更合理。
MCP Tasks：把長時間 GIS 工作交給 Agent 管理
GIS 工作不像簡單的 Calculator Tool。大型 Raster、Batch Processing、Point Cloud 或 Visual Review 可能需要較長時間，如果所有工作都只能依賴一次性的 Tool Call，Agent 很難管理狀態與取消操作。
MCP 在 2026-07-28 規格中將 Tasks 放到正式的 Extensions Framework。Tasks 的概念是讓工具回傳一個可輪詢的工作，而不是要求 Client 一直等待單次呼叫完成。Agent 可以：
- 查詢長時間工作的狀態。
- 等待 Processing、Batch 或 Visual Review 完成。
- 在需要時取消工作。
- 在多步驟 Workflow 中保留中間結果或 Handle。
這讓 MCP 更接近長時間 Agent Infrastructure，而不只是「呼叫一個函式並立刻取得結果」的 Function Calling 介面。
如何安裝 QGIS Agent MCP？
目前可從官方 QGIS Plugin Repository 的 QGIS Agent MCP 頁面或專案的 GitHub Releases 取得 Plugin。
安裝前需求
- QGIS 3.44 LTR 或更新版本。
- 支援 MCP 的 AI Client。
- QGIS Agent MCP Plugin。
官方列出的相容 Client 包含 OpenCode、Codex、Claude Code、Claude Desktop、Cursor、Google Antigravity，以及其他支援標準 stdio MCP 的 Client。
安裝步驟
- 下載
qgis_agent_mcp-*.zipPlugin。 - 在 QGIS 開啟 Plugins → Manage and Install Plugins → Install from ZIP。
- 安裝並啟用 QGIS Agent MCP。
- 在 Plugin 中點選 Connect an AI client。
- 選擇要連接的 Client，執行 Connect / Repair。
- 依畫面指示重新啟動 AI Client。
- 重新連線後，就可以用自然語言要求 Agent 檢查或操作目前的 QGIS Project。
專案 README 強調，一般流程不需要手動複製 Port、Token 或 MCP Configuration File。實際可用的 Client、版本與連線方式仍可能隨 Plugin 更新而調整，安裝時應優先以 Plugin 畫面與官方文件為準。
版本狀態提醒
以 2026-08-20 查詢到的資料來看，QGIS Plugin Repository 將 QGIS Agent MCP 的最新穩定版本列為 0.4.9，發布時間為 2026-08-13，支援 QGIS 3.44.0 至 4.99.0。不過 GitHub
CHANGELOG.md可見的最新使用者版本條目仍是 0.4.8，日期為 2026-08-12；GitHub Releases 頁面也應與 Plugin Repository 分開判讀。這三者不應被當成同一個 Release Date。
四個適合實際測試的 Agent Prompt
下面的提示詞不是固定指令，而是用來觀察 Agent 是否會先理解 Project，再規劃合適的 Tool Workflow。
範例一：先檢查目前的 QGIS Project
請檢查目前 QGIS Project。先列出所有圖層、CRS、資料來源與有效狀態，找出失效 Layer，確認各圖層 CRS 是否合理。不要直接修改，先回報你發現的問題。
理想的流程應該是：
- 取得 QGIS Project Context。
- 列出目前 Layers。
- 讀取 Layer CRS、資料來源與有效狀態。
- 整理可能的問題。
- 等待使用者確認後，再進行修改。
這個例子適合測試 Agent 能否先執行 Read-only Inspection，而不是收到要求後立刻修改專案。
範例二：自然語言完成 Spatial Analysis
使用目前專案中的捷運站點圖層建立 500 公尺 Buffer，再統計 Buffer 內的餐廳 POI 數量，依餐廳數量製作分級設色，最後將結果加入目前 Project。
一個合理的 Workflow 可能包含：
- 找到捷運站與餐廳 POI Layer。
- 檢查兩個 Layer 的 CRS。
- 如果需要距離計算，先判斷是否應該投影到適合的 CRS。
- 執行 Buffer。
- 執行 Spatial Join 或相關統計。
- 建立統計欄位與分級設色。
- 將結果加入 Project。
- Render Map 並進行 Visual Review。
這個例子能測試 Agent 是否理解，真正的 Agentic GIS 不只是執行單一 Buffer，而是要自己組合多個 GIS Tool 完成一個目標。
範例三：改善地圖與 Layout
檢查目前地圖的製圖品質，改善主要道路與行政區界線的視覺層級，避免標籤重疊，建立適合 16:9 簡報使用的地圖版面，完成後進行一次 Visual Review。
這個任務會涉及 Layer Hierarchy、Symbology、Labels、Layout、Render 與 Bounded Correction，適合測試 Agent 能否形成「檢查 → 修改 → 再檢查」的回饋迴圈。
範例四：Point Cloud 與 PDAL
載入這個 LAZ 點雲，檢查 Classification，篩選 Ground Classification，將結果加入 QGIS Project，並回報處理後的 Point Cloud Layer。
官方 README 提到，LAS / LAZ 可以搭配 QgsPointCloudLayer 與 PDAL Provider；分類篩選時，建議優先使用 QGIS Processing 的 pdal:filter，而不是直接呼叫 PDAL CLI。這類任務可以測試 Agent 的 Tool Discovery、Processing Output Resolution 與 Layer Verification。
官方展示的完整 Agent Workflow
QGIS Agent MCP 官方展示了兩個從空白 Project 開始的案例：
- Wildfire Monitoring：從全新的空白 QGIS Project 建立法國尺度的 wildfire monitoring map，再深入到 Bordeaux 區域，顯示 prioritized detections、時間分類與 labels。
- Agricultural Data Exploration：結合年度 agricultural parcel data 與 satellite imagery，從 national view 逐步建立到具有 crop legend 的 parcel-level map。
這些 Demo 的重點不是某一個 Buffer 或 Raster Function，而是 Agent 能從空白狀態開始組合資料、分析、製圖與 Visual Review，完成一整段 Workflow。
從 GIS Automation 走向 Agentic GIS
GIS 自動化並不是新概念。過去我們已經可以使用 Model Builder、Processing Model、PyQGIS、GDAL 與 GeoPandas 完成大量自動化工作。AI Agent 帶來的不同，不在於「能不能自動執行 Buffer」，而在於使用者可以描述最終目標，再由 Agent 動態決定應該執行哪些步驟。
可以把這個演進整理成五個階段：
| 階段 | 工作方式 |
|---|---|
| GUI GIS | 人類 → GUI → GIS Tool |
| Script GIS | 人類 → PyQGIS / GDAL → GIS |
| AI Coding | 人類 → LLM → GIS Code → 人類執行 |
| Tool Calling GIS | 人類 → LLM → GIS Function Tool |
| Agentic GIS | 人類提出目標 → Agent 規劃 → Tool Discovery → Execute → Review → Correct |
因此，Agentic GIS 的核心不只是「AI 幫忙按按鈕」，而是讓 Project Context、Tool Discovery、Workflow Recovery 與 Visual Feedback 逐漸成為同一個可管理的工作流程。
為什麼 QGIS Agent MCP 值得關注？
它不是單純的 Chatbot
Agent 直接取得 QGIS Tool 能力，而不是只能回答 GIS 問題。使用者可以要求它讀取現有 Project、搜尋 Layer、執行 Processing 或準備 Layout。
它不是單純的 PyQGIS Code Generation
透過 Typed Tools 與 Guarded Workflow 執行，降低把任意程式碼直接交給 QGIS 的風險。這也讓每一步比較容易被記錄與檢查。
它開始處理大型 Tool Catalog 問題
Adaptive Discovery 與 qgis_context 讓專案不需要把所有工具一次塞進模型 Context。當工具數量持續增加時，這會是 Agent Tool Ecosystem 能否維護的重要架構問題。
它開始處理 Workflow Recovery
Checkpoint、Revision 與 Restart Recovery，讓 Agent Workflow 更接近長時間工作的實際需求，而不只是幾秒內完成的單次呼叫。
它加入 Visual Feedback Loop
GIS 結果本來就需要看地圖。Visual Review 讓 Agent 有機會形成 Execute → Observe → Correct 的閉環。
它是開源專案
專案採用 MIT License，開發者可以研究、Fork、修改與整合這套架構。不過開源不代表每個版本與每個 Client 的行為都已經穩定，仍應以實際測試為準。
目前仍有哪些限制？
- 仍是快速發展中的 Pre-1.0 專案：Tool Schema、Client Compatibility 與 Workflow 行為可能快速調整。
- Agent 不等於 GIS 專家：即使 Tool 執行成功，CRS、Spatial Method、資料品質與統計方法仍需要專業判斷。
- Visual Review 不保證語意正確：畫面看起來正常，不代表空間分析方法一定正確。
- 不提供任意 Python Execution：安全性較高，但非常客製化的 PyQGIS 工作可能仍需要額外 Tool 或 Processing Algorithm。
- QGIS 版本需求較新：官方 Plugin Repository 目前宣告最低版本為 QGIS 3.44。
- Client 與模型會影響體驗：Tool Planning、Spatial Reasoning 與 Vision 能力，仍取決於所使用的 AI Client 與模型。
因此，適合把 QGIS Agent MCP 當成能協助規劃與執行工作的工具層，而不是完全取代 GIS 專業人員的黑盒子。
資料真的完全不會離開電腦嗎？
QGIS Agent MCP 本身採用 authenticated local loopback bridge，官方設計強調 Project Data 保留在 QGIS。這表示 Plugin 與 Bridge 的連線設計以本機為主，但不應直接解讀成「使用任何 Cloud LLM 時，所有資訊都絕對不會離開本機」。
Agent 為了理解 Project，仍可能透過 Tool Result 或 qgis_context 取得部分 Layer Metadata、Schema 或分析結果。如果使用的是 Cloud AI Model，這些實際送入模型 Context 的內容，仍需要依 AI Client 與模型供應商的資料政策判斷。
如果處理敏感 GIS 資料，建議在使用前確認：
- 哪些 Project Metadata 會傳給模型。
- AI Client 是否會保留對話與 Tool Result。
- 模型服務商的資料使用政策。
- Plugin 的本機連線與確認設定。
常見問題
QGIS Agent MCP 是免費的嗎？
專案本身為開源軟體，採 MIT License。但連接的 AI Client 或模型可能有各自的訂閱或 API 費用。
一定要使用 Claude 嗎？
不需要。官方列出的相容 Client 包含 OpenCode、Codex、Claude Code、Claude Desktop、Cursor、Google Antigravity，以及其他支援標準 stdio MCP 的 Client。
需要另外安裝 Python 嗎？
官方說明 packaged plugin 不需要額外的 External Python Runtime Dependency。不過實際使用的 Processing Provider 或其他 QGIS Plugin，仍可能有自己的環境需求。
Agent 可以直接執行任意 Python 嗎？
不行。QGIS Agent MCP 刻意不提供 Arbitrary Python Execution，而是透過 Typed Tools、QGIS Processing 與 Guarded Workflow 執行。
可以操作 Point Cloud 嗎？
可以。官方 README 說明 LAS / LAZ、QgsPointCloudLayer 與 PDAL Processing 的相關 Workflow；分類篩選可優先考慮 QGIS Processing 的 pdal:filter。
支援 QGIS 4 嗎？
支援。官方 Plugin Repository 宣告 QGIS 3.44–4.x；GitHub README 也列出 QGIS 3.44 LTR 與 QGIS 4.2 / Qt 6 的驗證資訊。
它會取代 PyQGIS 嗎？
不會。PyQGIS 仍然是 QGIS 自動化與 Plugin 開發的重要底層能力。QGIS Agent MCP 更接近在既有 GIS 能力上建立一層可以被 Agent 使用的 Tool Layer。
結語
QGIS Agent MCP 現階段仍是一個相當新的開源專案，但它展示了一個值得注意的 GIS 發展方向。
過去 AI 與 GIS 的結合，大多停留在問答、Code Generation 或單一 Function Calling。現在開始出現的 Agentic GIS，則試圖讓 AI 理解 Project Context、尋找 Tool、執行 Workflow、觀察地圖，再根據結果修正。
短期內 GIS 不會全部變成 AI Agent，專業工作仍然需要理解 CRS、Topology、Spatial Statistics、Remote Sensing、Cartography 與資料品質。但 Agent 很可能逐漸接手資料下載、格式轉換、投影、Buffer、Overlay、欄位計算、統計、Layout 初稿與例行報表等具有明確 Tool Chain 的工作。
GIS Agent 最重要的價值，不是取代 GIS 專業，而是把 GIS 專家的操作知識轉換成可被 Agent 重複執行與組合的 Tool Workflow。對 GIS 開發者來說，真正值得研究的也不只是如何使用 QGIS Agent MCP，而是如何把自己的 GIS Function、資料服務與分析流程設計成 Agent 可以安全呼叫的 Tool。