Unity MCP：把 Unity Editor 變成 LLM 的遙控器，但先想清楚這幾件事
Unity MCP acts as a bridge between AI assistants and your Unity Editor. Give your LLM tools to manage assets, control scenes, edit scripts, and automate tasks within Unity.
秒懂
- 它是什麼？
- Unity MCP 以 Model Context Protocol 為橋梁，讓 Claude、Cursor 等 AI 助手直接操作 Unity Editor。本文拆解它的運作方式、安裝流程、實際限制，並對比同類方案，幫你判斷何時該用、何時不該用。
- 適合誰用？
- Unity MCP 適合已經在用 MCP 客戶端（如 Claude Desktop、Cursor）的 Unity 開發者，尤其是想快速原型化場景、自動化重複資產操作的團隊。不適合追求完全自動化、不願介入驗證的專案，也不適合只用 Unity 內建工具、不想引入 Python 與 uv 依賴的環境。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 10 天前。
- 用什麼語言寫的？
- 主要是 C#（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決什麼問題：讓 AI 不再只是聊天，而是動手改場景
多數 AI 程式設計助手停留在文字建議的層次。你問它怎麼加 Rigidbody，它給你一段程式碼，你複製貼上，再手動切回 Unity Editor 確認結果。Unity MCP 想打破這個迴圈。它把 Unity Editor 的操作包成 47 個工具，透過 Model Context Protocol 暴露給 AI 助手。AI 收到你的自然語言指令後，可以直接呼叫工具去建立 GameObject、修改場景、編輯 C# 腳本、執行測試，甚至觸發建置。目標對象很明確：正在用 Claude、Cursor、VS Code 或其他 MCP 客戶端開發 Unity 專案的工程師，以及想用自然語言驅動場景原型設計的設計師。它不是給所有 Unity 開發者的通用工具，而是給那些已經接受「AI 能操作編輯器」這個前提的人。
實際運作機制：MCP 伺服器、Unity 端套件與工具呼叫的三角關係
Unity MCP 的架構可以從 README 的描述與儲存庫佈局推測出來，但細節文件沒有展開。它包含兩個主要部分：一個是 Unity 端的套件，透過 Package Manager 安裝；另一個是 Python 3.10+ 環境下的 MCP 伺服器，依賴 uv 執行。MCP 伺服器扮演中介，它接收 AI 客戶端的工具呼叫請求，轉譯成 Unity Editor 能理解的指令，再回傳執行結果。Unity 端則負責實際操作編輯器，例如建立物件、修改屬性。這個設計的關鍵在於，AI 不需要知道 Unity 的內部 API，只要知道 MCP 工具的清單與參數。README 提到有 47 個「focused MCP tool entrypoints」，並提供工具目錄頁面，但具體每個工具的名稱與參數格式，需要去官方文件查閱。文件也提到 v10 有「asset generation」功能，以及 Roslyn 腳本驗證，後者可能是在 AI 修改 C# 腳本後，先用 Roslyn 做語法檢查，避免把壞程式碼直接寫入專案。這些都是推測，實際行為要以官方指南為準。
安裝與設定：從 Package Manager 到 Configure All Detected Clients
安裝流程在 README 的 Quickstart 有清楚步驟。第一步，在 Unity 中開啟 Package Manager，選擇 Add from git URL，貼上 https://github.com/CoplayDev/unity-mcp.git?path=/MCPForUnity#main。若要鎖定特定版本，可以改用 tag，例如 #v10.0.0，或者用 openupm add com.coplaydev.unity-mcp 指令。第二步，在 Unity 選單中開啟 Window → MCP for Unity → Configure All Detected Clients。這個動作會自動偵測你機器上已安裝的 MCP 客戶端，並寫入對應的設定檔。第三步，直接對 AI 下指令，例如「Create a cube at the origin and add a Rigidbody.」，AI 就會透過工具在場景中建立物件。前置需求是 Unity 2021.3 LTS 到 6.x，以及 Python 3.10+，且 Python 必須透過 uv 管理。這裡有個實際門檻：如果你的專案環境沒有 uv，或是 Unity 版本太舊，安裝就會卡住。另外，Configure All Detected Clients 只對「已偵測到」的客戶端有效，若你用的是冷門客戶端，可能得手動編輯設定檔，但 README 沒有提供這部分的細節。
進階功能與真實限制：多實例、工具分組、遠端伺服器
README 的 Advanced 區塊列出幾個進階功能，但描述都很簡短。Multi-Instance Routing 讓你能同時連接多個 Unity 實例，這對同時開著不同專案的人有用，但文件沒有說明它如何區分請求要送到哪個實例。Tool Groups 把工具分成 vfx、animation、ui、testing 等群組，這暗示你可以在客戶端設定中只暴露特定群組，減少 AI 誤用工具的機會，但實際設定方式需要看指南。Remote Server Auth 則是把 MCP 伺服器架在遠端主機並加上認證，這對團隊共用或 CI 環境有意義，但也增加了網路安全風險。真正的限制在於，Unity MCP 依賴 Unity Editor 正在執行且回應。如果 Editor 忙碌、卡住或當掉，AI 的工具呼叫就會失敗。此外，AI 對 3D 場景的理解有限，它可能正確地建立一個 cube，但擺放位置或旋轉角度不符合你的視覺直覺。這類工具適合「可驗證、可快速修正」的操作，不適合需要高度美術判斷的任務。文件也提到 v10 有遷移指南，代表從 v9 升到 v10 可能會有破壞性變更，這對已上線的專案是升級成本。
替代方案比較：Unity 官方 AI 工具、Aura for Unity 與純程式碼生成
Unity MCP 不是唯一讓 AI 進入 Unity 編輯器的方案。Unity Technologies 自己有提供 AI 相關工具，但 README 特別聲明本專案與 Unity Technologies 無關，這暗示兩者是不同路線。Unity 官方的方案通常整合在編輯器內，但可能不是開放原始碼，而且不一定支援 MCP 協定。另一個直接相關的是 Aura for Unity，它由同一家贊助商 Aura 提供，是付費的 Unity/Unreal AI 助手。README 說 MCP for Unity 是免費且 MIT 授權，Aura for Unity 是進階版，這表示如果你需要更深入編輯器整合、更好的場景理解或技術支援，可能要考慮付費方案。至於純程式碼生成工具，例如 GitHub Copilot 或 Cursor 的內建聊天，它們只產生程式碼片段，不會直接操作 Unity Editor。Unity MCP 的差異在於它的「執行」能力：AI 不只是建議，而是真的去改場景、跑測試。這個差異既是優點也是風險，因為 AI 的錯誤操作會直接影響你的專案狀態，不像程式碼建議可以輕鬆丟棄。
維護成本與授權考量：MIT 的彈性與社群依賴
授權是 MIT，這代表你可以自由使用、修改、甚至商用，不需要付費。但這不表示沒有維護成本。專案的主要分支是 beta，這暗示穩定版本可能不是預設分支，如果你直接從 main 安裝，可能拿到的是開發中版本。README 建議從 beta 分支貢獻，但一般使用者用 main 或 tag 安裝。v10.2.0 在 2026 年 9 月釋出，顯示開發還算活躍，但活躍度不能保證未來。專案由 Aura 贊助，而 Aura 同時有付費產品，這代表免費版的發展方向可能受贊助商商業利益影響。升級成本方面，v10 有專門的遷移文件，代表從 v9 到 v10 不是單純的套件更新，可能需要調整設定或重新安裝。此外，Python 與 uv 的依賴是長期維護負擔，如果 uv 停止維護或 Unity 更新後不相容，你就得自己想辦法。最後，安全層面，讓 AI 操作編輯器等於開放一個能執行任意工具的外部入口，README 有 SECURITY.md 提供私人回報管道，這表示專案本身意識到風險，但使用者仍應自行評估在團隊環境中暴露 MCP 伺服器的風險。
結論：誰該採用，誰該避開，以及第一步該做什麼
Unity MCP 適合那些已經熟悉 MCP 生態系、且願意在 AI 每次操作後檢查場景狀態的開發者。它特別適合快速原型設計，例如用自然語言生成一堆測試物件，或是批次修改資產屬性。不適合的場景包括：需要精確控制場景層級的正式專案、沒有 Python 環境的團隊、以及對 AI 操作編輯器有安全疑慮的企業。採用前，先確認你的 Unity 版本在支援範圍內，並在一個測試專案中安裝，不要直接進主專案。接著，花時間閱讀官方工具目錄，了解哪些工具會修改場景、哪些只讀取資訊。最後，測試 Multi-Instance Routing 是否真的能區分多個 Editor 實例，因為如果你的工作流程需要同時開多個專案，這會是關鍵功能。Unity MCP 提供了一個具體的橋梁，讓 LLM 從「建議者」變成「操作者」，但這個橋梁的穩固程度，取決於你對 AI 錯誤的容忍度，以及你對 Editor 狀態的掌控能力。
編輯結論
Unity MCP 適合已經在用 MCP 客戶端（如 Claude Desktop、Cursor）的 Unity 開發者，尤其是想快速原型化場景、自動化重複資產操作的團隊。不適合追求完全自動化、不願介入驗證的專案，也不適合只用 Unity 內建工具、不想引入 Python 與 uv 依賴的環境。採用前應先確認你的 Unity 版本落在 2021.3 LTS 到 6.x 之間，並實際測試多實例路由與工具分組是否符合你的工作流程。最後，記住它與 Unity Technologies 無關，是獨立專案，授權為 MIT，可自由修改，但後續維護仰賴社群與 Aura 贊助，升級到 v10 時務必閱讀官方遷移文件。
社群筆記