大模型剛開始進入軟體時，最常見的形態是在介面旁邊增加一個聊天視窗。

使用者可以詢問某個命令在哪裡、一個錯誤是什麼意思，或者讓模型根據幫助文件給出操作步驟。這確實降低了軟體的使用門檻，但模型與軟體之間仍然隔著一層介面：模型能夠回答問題，卻不一定知道當前專案裡真正存在什麼，更不能穩定地操作軟體內部的物件。

隨後出現了另一條路線：讓模型讀取螢幕截圖，模擬滑鼠和鍵盤，像人一樣尋找選單、填寫引數和點選按鈕。

Computer Use 擴大了模型能夠操作的軟體範圍，卻沒有從根本上解決專業軟體中的語義問題。對於 CAD、CAE、EDA 和科學計算軟體而言，模型不僅要知道按鈕在哪裡，還要知道：

  • 當前選中的是哪個零件、面、特徵或元器件；
  • 一條線路在電氣意義上連線到了哪個網路；
  • 引數使用毫米、英寸、歐姆還是兆帕；
  • 修改尺寸後哪些下游特徵會失效；
  • 模擬是否真正收斂；
  • 結果對應的是哪組材料、載荷和邊界條件。

當模型開始從“回答軟體問題”轉向“參與實際工作”，軟體也就需要一種新的介面：它既不能只面向程式設計師，也不能只面向圖形介面，而要讓模型能夠發現、理解和呼叫軟體能力。

Model Context Protocol，也就是 MCP，正是在這樣的需求下發展起來。

MCP最初要解決的不是點選軟體，而是連線碎片化

2024年11月25日，Anthropic 正式開源 MCP。

當時大模型已經可以生成程式碼、分析文件和呼叫函式，但一旦需要訪問企業檔案、資料庫、程式碼倉庫或業務系統，開發者仍然要為每一個數據源單獨編寫聯結器。一個模型應用接入 Google Drive、Slack、GitHub、PostgreSQL 和本地檔案系統，往往意味著五套互不相容的整合。

Anthropic 將這一問題概括為模型被隔離在資訊孤島之外：模型能力不斷提高，但真實資料和軟體能力仍散落在不同系統中。MCP 因此被設計成一套開放標準，讓資料來源和工具只需提供一次標準化服務，就能被多個相容的模型應用連線。最早公開的參考伺服器便覆蓋了 Google Drive、Slack、GitHub、Git、PostgreSQL 和 Puppeteer。MCP 的最初兩位主要建立者是 David Soria Parra 和 Justin Spahr-Summers。

MCP 的結構受到 Language Server Protocol，也就是 LSP 的啟發。

LSP 解決的是編輯器與程式語言工具之間的重複適配問題。過去，每種編輯器都要分別實現 Python、Java、C++ 等語言的補全、診斷和定義跳轉；有了 LSP，語言伺服器可以同時服務多種編輯器。

MCP 採用了類似思路：

不再讓每一種模型應用分別適配每一套軟體和資料來源，而是由軟體提供標準伺服器，再由相容的模型客戶端連線。

MCP 使用 Host、Client 和 Server 架構，通過 JSON-RPC 交換訊息。伺服器可以公開三類核心能力：

  • Resources：檔案、資料庫記錄、工程物件、日誌和其他上下文；
  • Tools：查詢、修改、執行、計算和匯出等操作；
  • Prompts：經過整理的任務模板和工作流程。

Host 是承載模型和使用者互動的應用，Client 負責與某個 MCP Server 建立連線，Server 則把具體系統的資料和操作能力提供出來。

MCP 因此並不是新的求解器、建模核心或自動化引擎。它更像是模型與既有軟體能力之間的一層通用介面。

從本地聯結器到生產協議

MCP 在2024年公開時，首先適合本地檔案、開發環境和桌面工具。它真正引起大型軟體廠商重視，則與2025年的快速演進有關。

2025年3月：遠端連線和許可權控制開始成形

2025年3月的規範加入了基於 OAuth 2.1 的授權框架，以 Streamable HTTP 取代早期的 HTTP+SSE 傳輸方案，並增加工具註釋，讓客戶端知道一個工具是否只讀、是否具有破壞性。

這一步非常關鍵。

如果 MCP 只能連線使用者電腦上的本地程序，它更像開發者實驗工具；當它擁有遠端傳輸、身份驗證和許可權描述後，企業軟體才有條件通過雲端服務提供 MCP。

2025年6月：工具返回結果變得更適合專業任務

2025年6月的版本增加了結構化工具輸出、Resource Link 和 Elicitation。

結構化輸出允許工具返回具有明確欄位的資料，而不是一段模糊文字。對於工程軟體，求解工具可以返回：

求解狀態
最大應力
最大位移
危險位置物件ID
單位
警告數量
結果檔案

Elicitation 則允許伺服器在執行過程中向用戶請求必要資訊，例如要求確認材料、單位、檔案位置或操作範圍。協議同時加強了 OAuth 資源伺服器定位和令牌使用安全。

2025年：大型模型與平臺廠商相繼採用

MCP 最初由 Anthropic 提出，但很快不再侷限於 Claude 生態。

Microsoft 在2025年3月為 Copilot Studio 推出 MCP 預覽，並於5月宣佈正式可用。連線 MCP Server 後，伺服器釋出的工具和資料可以自動加入智慧體；當伺服器更新工具時，Copilot Studio 也可以動態同步，而不必手工重新建立每一個 Action。Microsoft 還把 MCP 接入現有聯結器體系，以繼續使用虛擬網路、資料防洩漏和多種身份驗證機制。

OpenAI 隨後在 API、ChatGPT Apps 和智慧體工具體系中採用 MCP。開發者可以讓模型連線遠端 MCP Server，限制允許呼叫的工具，併為寫入操作設定審批要求；ChatGPT 的自定義應用同樣以 MCP 作為連線工具和內部資料的重要基礎。

GitHub 釋出並維護官方 GitHub MCP Server，讓不同 IDE 和智慧體讀取倉庫、Issue 和 Pull Request，建立任務，並呼叫程式碼安全等功能。組織還可以使用 MCP 策略和登錄檔限制允許執行的伺服器。

Google Cloud 在2025年為資料庫工具箱加入 MCP，並在同年12月宣佈為 Google 服務提供官方 MCP 支援。Google 對此給出的原因也很直接：依賴社群伺服器要求開發者分別安裝和維護多個本地實現，容易形成脆弱的整合，因此需要由服務提供方維護遠端、可治理的官方端點。

MCP 至此完成了一次重要轉變：

它從 Anthropic 提供的開放連線方案，逐漸變成不同模型、智慧體平臺和軟體廠商共同採用的介面層。

2025年末：進入中立治理

2025年11月的規範繼續增加 OpenID Connect 發現、增量授權、工具顯示資訊和實驗性的 Tasks。Tasks 用於跟蹤耗時較長、需要輪詢狀態或延遲獲取結果的任務，對編譯、批次處理和工程模擬尤其重要。該版本還正式建立了治理結構、工作組和 SDK 分級制度。

2025年12月，Anthropic 將 MCP 捐贈給 Linux Foundation 下成立的 Agentic AI Foundation。AAIF 的創始專案還包括 Block 的 goose 和 OpenAI 的 AGENTS.md，成員包括 Anthropic、OpenAI、Microsoft、Google、AWS、Cloudflare 和 Bloomberg 等機構。

這一變化減少了軟體廠商對“接入競爭對手私有協議”的顧慮。MCP 的治理不再只由某一家模型公司控制，而是逐漸成為中立的開源基礎設施。

截至2026年7月，穩定規範仍為2025-11-25。計劃於2026年7月28日釋出的下一版正在進一步弱化協議級會話，轉向更適合普通 HTTP 基礎設施的無狀態核心，並通過擴充套件機制承載 Tasks、互動式介面等能力。

為什麼軟體廠商開始把產品做得對模型友好

軟體廠商支援 MCP，並不只是為了追隨一個熱門協議。

真正的變化是：模型正在成為新的軟體入口。

過去，使用者先開啟 CAD、EDA 或辦公軟體，再從選單中選擇功能。未來，使用者可能先向 Codex、Claude、Copilot、ChatGPT 或企業內部智慧體提出目標：

檢查這套電路的供電問題。

修改模型後重新比較應力結果。

找出裝配體中的干涉並生成報告。

讀取專案狀態，建立修復任務並提交程式碼。

智慧體再決定需要呼叫哪些軟體。

當這種工作方式逐漸普及時，軟體能否被模型正確發現、理解和呼叫，就會像檔案格式、外掛生態和雲端 API 一樣，成為產品競爭力的一部分。

保住專業軟體在工作流中的位置

模型能夠生成程式碼，也可以呼叫開源庫重新實現部分功能。如果傳統軟體始終只能由人通過介面操作，智慧體便可能繞開它：

  • 直接生成通用幾何檔案；
  • 呼叫其他模擬服務；
  • 使用開源庫處理資料；
  • 依賴第三方指令碼完成轉換；
  • 轉向介面更開放的競爭產品。

廠商提供 MCP，可以讓自己的幾何核心、求解器、元件模型、設計規則和專案資料繼續成為智慧體工作流中的權威執行環境。

Autodesk 對 MCP 的定義便強調，伺服器負責驗證請求、執行許可權、訪問資料並返回結果，而不是讓模型直接繞過產品內部控制。

避免為每一種模型重複開發外掛

假設一家軟體廠商要同時支援 ChatGPT、Claude、GitHub Copilot、Gemini、Cursor 和 Codex。

沒有統一協議時，廠商可能需要分別適配六套工具格式、身份驗證、配置方法和生命週期。模型平臺每次更新，聯結器也可能需要跟著修改。

有了 MCP，軟體廠商可以維護一套伺服器，再由多個相容客戶端發現其中的工具。Autodesk Fusion 和 MathWorks 的官方實現已經同時列出 Claude、VS Code、GitHub Copilot、Codex、Gemini CLI 等不同客戶端。

這不是完全消除適配工作，而是把原來的多對多連線：

多個模型 × 多種軟體

轉化為：

模型客戶端 ↔ MCP標準 ↔ 軟體伺服器

把已有API開放給更多普通使用者

SOLIDWORKS、NX、MATLAB、AutoCAD 和 Ansys 很早就擁有宏、指令碼、外掛或程式設計介面。

但這些介面主要面向開發者。普通工程師即使知道軟體能夠自動化，也未必會編寫 C# COM 程式、NX Open 外掛、MATLAB 工具箱或 AutoLISP 指令碼。

MCP 可以把底層介面包裝成模型能夠理解的語義工具：

讀取裝配結構
查詢欠定義草圖
修改材料
檢查懸空輸入
生成網格
執行測試
讀取求解日誌
匯出STEP檔案

使用者只需要說明目標，模型負責選擇工具和組織步驟，軟體原有 API 則繼續負責確定地執行操作。

降低軟體學習和支援成本

專業工程軟體通常擁有大量命令、模組和引數。新使用者可能花很長時間尋找一個功能，熟練使用者在面對不常使用的模組時也需要重新查閱文件。

Siemens 在 Designcenter X NX 中加入 Copilot，讓它結合近期命令和當前任務提供操作指導，減少複雜流程的重新學習時間。

Proteus ProPilot 則能夠讀取當前原理圖、程式程式碼和模擬資料，結合實際 MCU 接線提供外圍裝置程式碼、元件建議、故障分析和軟體操作指導。

即使這些能力並不全部通過公開 MCP 伺服器呈現，它們體現了同一個方向：軟體幫助系統正在從通用文件搜尋，轉向理解使用者當前專案。

允許個人和企業選擇模型

軟體廠商不可能保證某一種模型永遠在能力、成本、延遲、隱私和地區可用性上適合全部使用者。

MCP 將軟體能力與模型選擇適當分開。個人可以使用自己已經訂閱的模型，企業可以接入獲准的雲模型、私有模型或本地模型，軟體廠商則繼續控制工程物件和操作許可權。

Proteus 允許使用者選擇 GPT、Claude、DeepSeek 和自託管模型；MathWorks 的 MCP 與 Agentic Toolkit 也支援多種編碼智慧體。

防止第三方替廠商定義介面

當廠商沒有提供 MCP 時，社群通常會利用已有 API 先做出一個版本。

第三方實現可以快速驗證市場需求，卻也可能出現：

  • 工具命名和引數不統一；
  • 不同軟體版本相容性不足；
  • 依賴任意指令碼執行；
  • 無法使用軟體內部身份和許可權；
  • 操作失敗後缺少事務與回滾；
  • 專案停止維護。

如果第三方專案首先獲得大量使用者，它就可能成為模型理解該軟體能力的事實標準。廠商後來即使推出官方方案，也要面對既有相容習慣。

因此，廠商提供官方 MCP 不只是增加功能，也是重新掌握物件語義、許可權邊界和版本相容的定義權。

“支援MCP”其實有四種不同狀態

討論軟體是否支援 MCP 時，不能簡單地只寫“有”或“沒有”。

第一類：廠商提供正式MCP Server

伺服器由軟體廠商維護，直接訪問產品內部物件或雲服務。

這類方案通常最容易獲得：

  • 準確的物件語義；
  • 軟體版本適配；
  • 官方身份驗證；
  • 企業許可權；
  • 錯誤狀態；
  • 正式支援。

第二類：產品內建AI，並通過內部MCP或類似介面工作

使用者能夠在軟體內使用上下文感知的 AI，模型也可能通過本地介面訪問軟體，但廠商未必把完整伺服器作為獨立開發產品公開。

Proteus 9.1 的實際使用便屬於這一方向。在本文作者使用的環境中，Codex 可以通過本地8001埠連線 Proteus，讀取工程上下文並呼叫相應能力。對普通使用者而言，它和 ProPilot 的產品內體驗共同構成了模型與原理圖、程式碼和模擬的連線。

第三類：廠商尚未提供專用MCP，但已有成熟API

第三方、合作伙伴或企業內部團隊可以基於官方 API 開發 MCP。

SOLIDWORKS 的 COM API 和 Siemens NX Open 都屬於這一基礎。MCP 並不會取代這些介面，而是將它們組織成更適合模型呼叫的工具。

第四類：主要依靠介面自動化

軟體缺少穩定 API，只能使用截圖、滑鼠、鍵盤、視窗控制元件或檔案匯入匯出。

這種方式仍然可以接在 MCP 工具後面，但它本質上仍是 RPA 或 Computer Use，穩定性和語義精度都低於直接訪問軟體物件。

常見軟體的MCP現狀與能力

以下狀態以截至2026年7月的公開資料和實際使用情況為基礎。

軟體或平臺 當前狀態 實現方 已經實現的主要能力
GitHub 正式MCP Server 官方 讀取倉庫、Issue、PR和程式碼資訊，建立Issue或PR，呼叫程式碼安全與Copilot雲端智慧體等能力
Microsoft Copilot Studio MCP客戶端與企業接入平臺 官方 接入外部MCP Server，自動同步工具和資源，結合OAuth、虛擬網路、DLP和企業治理
Google Cloud 託管MCP服務與資料庫工具箱 官方 連線Google服務和企業資料庫，為智慧體提供受控的資料查詢與操作入口
Autodesk Fusion 本地與雲端兩套正式MCP 官方 檢查活動文件、執行即時建模命令；管理專案、資料夾、條目、協作者和許可權
Ansys系列 PyAnsys MCP體系 官方 連線Mechanical、MAPDL、Fluent、AEDT和Lumerical，呼叫相應PyAnsys自動化與模擬能力
MATLAB MATLAB MCP Core Server 官方 啟動或連線MATLAB、檢查程式碼、執行程式碼、執行指令碼和單元測試、查詢工具箱
Simulink Agentic Toolkit與MCP工具 官方 讀取模型結構與訊號、修改模組和引數、解析變數、檢查模型並執行測試
Proteus 9.1 產品內建AI與本地MCP接入 官方產品能力 讀取原理圖、程式碼和模擬上下文，修改元件數值、導航物件、生成外設程式碼並協助故障分析
Siemens生態 通用開發者MCP已上線；NX目前以Copilot和NX Open為主 官方與企業自建 官方MCP搜尋西門子產品、開發文件和技術資源；NX Copilot提供工作流指導，直接建模控制可基於NX Open封裝
SOLIDWORKS 未見公開通用官方MCP，社群實現活躍 第三方 基於COM/VBA讀取和修改草圖、零件、裝配、工程圖和屬性，執行分析、匯出或查詢API文件
AutoCAD 社群MCP為主 第三方 通過AutoLISP、檔案通訊或DXF庫建立圖元、圖層、塊、文字、標註和P&ID物件
Blender 社群MCP為主 第三方 讀取場景，建立和修改物件、材質與燈光，渲染、匯出並執行Blender Python

GitHub：從程式碼上下文到軟體開發動作

GitHub 官方 MCP Server 可以在 VS Code、Visual Studio、JetBrains、Xcode 和其他相容客戶端中使用。它不僅能讀取倉庫資訊，還可以建立 Issue、列出 Pull Request、啟動部分 Copilot 雲任務，並呼叫程式碼掃描或金鑰檢測功能。具體工具繼續繼承 GitHub 原有許可權和訂閱要求。

它展示的是現代平臺軟體的典型路線：把原來分佈在網頁、API 和 Copilot 中的能力，整理成一個可以被多種智慧體呼叫的正式入口。

Autodesk Fusion：傳統CAD廠商的完整參考方案

Autodesk Fusion 提供兩個定位不同的 MCP Server。

本地 Fusion MCP 連線正在執行的桌面軟體，可以檢查活動文件、執行命令並即時建模。Fusion Data MCP 執行在 Autodesk 雲端，用於查詢和管理 Hub、專案、資料夾、條目和許可權。

這種拆分很有代表性：

本地MCP：操作當前設計
雲端MCP：管理專案和協作資料

它說明傳統桌面軟體不必全部遷移到瀏覽器，仍然可以通過本地 MCP 把正在執行的專業應用連線給外部模型。

Ansys：在成熟Python生態上增加模型介面

Ansys 並沒有重新為大模型開發一套模擬系統，而是在 PyAnsys 基礎上增加 MCP。

當前 PyAnsys 文件已經列出面向 Mechanical、Fluent、MAPDL、AEDT 和 Lumerical 的 MCP 專案，同時提供 PyAnsys Common MCP，幫助不同產品建立統一伺服器。

模型因此可以圍繞現有 PyAnsys 能力組織工作：

讀取分析設定
檢查材料和邊界條件
修改模型物件
生成網格
啟動求解
讀取日誌
提取結果

MCP 負責工具發現和呼叫，實際模擬仍由 Ansys 產品與 PyAnsys 完成。

MathWorks 的 MATLAB MCP Core Server 可以啟動或連線現有 MATLAB 會話，檢測工具箱、靜態檢查程式碼、執行程式碼、執行指令碼和測試。伺服器還支援通過擴充套件檔案增加企業或使用者自己的工具。

Simulink Agentic Toolkit 則進一步結合了 MCP Tools 與 Agent Skills。

工具負責讀取、編輯、查詢和測試 Simulink 模型；Skills 則提供模型化設計、測試和工程實踐知識。現有工具可以讀取系統層級、訊號流和引數，增加模組與線路，並通過 Gherkin 測試驗證需求。

這體現了一種新的軟體設計思路：

只給模型操作許可權還不夠，還要告訴模型在這個專業領域中應當怎樣正確使用這些許可權。

Proteus：讓模型同時看到電路、程式碼和模擬

Proteus 的價值不只在於能夠繪製原理圖，而在於它把微控制器程式與電路模擬放在同一個環境中。

在本文作者實際使用的 Proteus 9.1 中，Codex 可以通過本地8001埠接入 MCP，與當前工程進行互動。

Proteus ProPilot 的公開能力則包括即時分析原理圖、讀取程式碼和模擬資料、根據 MCU 引腳連線生成 SPI、I²C、PWM 等程式碼、修改元件數值、導航物件並協助定位電路或韌體問題。它還允許使用者選擇多種雲端或自託管模型。

這使模型不必只根據截圖猜測某根線接在哪裡，而可以同時結合：

原理圖連線
元件引數
MCU引腳
嵌入式程式碼
編譯資訊
模擬資料

Proteus 是 MCP 和上下文感知 AI 進入傳統 EDA 軟體的一個實際案例，但它並不是唯一方向。相同思路也正在 CAD、CAE 和科學計算軟體中出現。

Siemens NX：已經重視AI入口，直接建模MCP仍有發展空間

Siemens 已經上線官方 MCP Server，為智慧體提供西門子產品、開發文件、API 和技術資源搜尋。這個伺服器目前主要服務資訊和開發者內容，而不是直接操作 NX 幾何模型。

Designcenter X NX 則已經加入內建 Copilot。它結合當前任務和近期命令，為使用者提供工程工作流指導、命令建議和錯誤處理資訊。

對於更深層的建模控制，NX Open 仍然是重要基礎。企業可以將經過批准的 NX Open 能力封裝成內部 MCP，例如：

讀取零件和特徵樹
查詢表示式
修改引數
檢查失效引用
執行干涉分析
匯出指定格式

因此，Siemens 的現狀不是“不重視 MCP”，而是已經在開發者和知識入口採用 MCP，同時讓 NX 的模型操作繼續依賴其成熟的產品 API 和內建 Copilot。

SOLIDWORKS：第三方利用成熟COM介面先行

SOLIDWORKS 官方 API 是擁有數百項函式的 COM 程式設計介面，可以通過 VBA、VB.NET、C# 和 C++ 直接訪問設計功能。

目前公開的 SOLIDWORKS MCP 主要由社群開發。

一類伺服器只提供 SOLIDWORKS API 文件檢索，幫助模型尋找介面、列舉和示例；另一類伺服器通過 COM 和 VBA 直接操作軟體，覆蓋草圖、建模、裝配、工程圖、分析和匯出。部分專案已經提供大量工具，但開發者仍將其標記為研究、業餘或 Alpha 狀態。

這說明“第三方已經實現”與“已經適合生產”不是同一個結論。個人可以用它探索，企業則需要重新檢查工具範圍、異常處理、版本鎖定和許可權。

AutoCAD和Blender：社群證明了介面需求

AutoCAD 的第三方 MCP 可以通過 AutoLISP、檔案通訊和 ezdxf 操作圖層、圖元、塊、文字、標註、檢視和P&ID符號，也可以在沒有 AutoCAD 的環境中直接生成 DXF。

Blender 社群 MCP 能夠讀取場景、建立物件、設定材質、渲染、匯出並執行 Python。其常見架構是在 Blender 內安裝外掛，再通過本地 Socket 與 MCP Server 通訊。

這些專案證明，擁有成熟外掛和指令碼介面的軟體很容易被社群 MCP 化。

但任意 Python、AutoLISP 或宏執行也會擴大風險。模型一旦能夠執行未經限制的程式碼，許可權範圍可能從“修改當前模型”擴大到讀取檔案、啟動程序甚至訪問網路。因此，正式產品更適合提供範圍明確的語義工具，而不是隻開放一個萬能的 execute_code。

官方MCP與第三方MCP各自實現了什麼

官方和第三方不是簡單的好壞關係。

維度 官方MCP 第三方MCP
物件語義 可直接使用軟體內部物件和狀態 依賴公開API、宏、指令碼或檔案解析
版本相容 可以隨產品版本共同維護 軟體升級後可能出現失效
身份許可權 可以接入廠商賬戶與企業策略 常繼承本地程序或API金鑰許可權
功能範圍 通常較剋制，只開放受支援能力 往往更積極覆蓋實驗性功能
迭代速度 受正式釋出週期影響 社群開發通常更快
技術支援 有廠商文件和支援渠道 依賴維護者與社群
風險 可能受許可、訂閱和平臺策略限制 可能包含任意程式碼執行或供應鏈風險

官方 MCP 更適合處理身份、專案許可權、雲端資料和穩定物件。

第三方 MCP 則更容易填補廠商尚未覆蓋的場景，或者針對某一家企業的具體流程進行定製。

兩者未來很可能長期並存：官方提供穩定核心，社群和企業在其上增加專業工作流。

MCP與類似技術分別解決什麼問題

MCP 並不是軟體智慧化所需的唯一技術。

軟體API和SDK

API 是執行層。

SOLIDWORKS COM、NX Open、PyAnsys、MATLAB Engine 和 Blender Python API 真正負責讀取物件、修改專案和執行計算。MCP 通常建立在它們之上，而不是替代它們。

Function Calling

Function Calling 讓模型在一次應用請求中選擇開發者預先宣告的函式。

它適合一個應用內部的工具呼叫；MCP 則進一步規定了獨立客戶端和伺服器怎樣連線、發現工具、取得資源和協商能力。同一個 MCP Server 可以被多個相容應用使用。

OpenAPI

OpenAPI 描述 HTTP 服務的路徑、引數、請求體、返回結構和認證方法。

它面向一般程式呼叫；MCP 則面向模型和智慧體，增加了工具發現、Resources、Prompts、生命週期和模型互動語義。已有 OpenAPI 服務可以被封裝或轉換成 MCP，但本地桌面軟體的物件模型仍需要專門適配。

A2A

A2A 主要解決智慧體之間的發現、委派和任務交接。

MCP 解決智慧體如何連線工具，A2A 解決多個智慧體如何協作。例如設計智慧體可以把驗證任務交給模擬智慧體，模擬智慧體再通過 MCP 呼叫 Ansys。

RPA和Computer Use

RPA 與 Computer Use 操作圖形介面。

它們適合沒有 API 的遺留軟體、視覺檢查和少量邊緣步驟，但容易受到窗口布局、語言、解析度、彈窗和軟體版本變化影響。

更合理的優先順序是：

軟體API或SDK
      ↓
官方或第三方MCP
      ↓
受控指令碼與命令介面
      ↓
RPA或Computer Use

對個人使用者意味著什麼

對個人使用者而言，MCP 最直接的價值不是“一句話自動完成所有設計”，而是減少重複說明。

過去遇到電路或模型問題，使用者需要：

  • 擷取介面；
  • 標出元件；
  • 描述連線；
  • 複製程式碼；
  • 解釋引數；
  • 上傳日誌。

模型仍可能因為看錯一個引腳或單位而從一開始就判斷錯誤。

通過 MCP，模型可以先讀取當前工程，再回答：

哪些器件沒有接入電源網路？

哪個草圖沒有完全定義？

這組邊界條件是否缺少約束？

當前程式碼與實際 MCU 引腳是否一致？

修改前後的應力和網格質量有什麼變化？

它也可以幫助新使用者快速瞭解陌生專案，解釋物件關係，並給出下一步建議。

但軟體能夠被模型操作，並不代表設計結果自動可信。程式碼編譯成功不等於硬體安全，模擬完成不等於工況合理，模型重建成功也不等於零件能夠製造。

更穩妥的個人工作流是：

讀取專案
→ 解釋當前狀態
→ 提出修改方案
→ 使用者確認
→ 執行有限修改
→ 重新編譯、重建或求解
→ 檢查結果與日誌

對企業意味著什麼

企業使用 MCP，真正需要關注的不是模型節省了多少次滑鼠點選，而是設計能力能否被標準化、授權和審計。

企業可以把自己的規範整理成工具：

檢查電源與接地
檢查懸空輸入
檢查未定義草圖
檢查裝配干涉
檢查材料和單位
執行標準模擬
生成設計審查報告

不同專案可以複用同一套檢查流程，新成員也能更快理解歷史工程。

與此同時，企業必須對 MCP Server 進行治理：

  • 只允許批准的伺服器；
  • 區分只讀、建議、修改和高風險操作；
  • 為工具設定白名單；
  • 保留修改前後的物件差異；
  • 記錄使用的模型、工具和引數；
  • 對外發資料、刪除和覆蓋操作要求確認；
  • 為重要工程建立檢查點和回滾；
  • 把編譯器、規則檢查器和求解器結果作為證據。

GitHub、Microsoft 和 OpenAI 都已經把伺服器審批、組織策略、工具許可權和寫入確認納入企業 MCP 使用方式，這說明 MCP 進入生產環境後的核心問題已經從“能不能連線”轉向“誰可以連線、允許做什麼、怎樣留下記錄”。

對軟體設計方意味著什麼

軟體過去主要服務兩類介面：

面向人的圖形介面
面向程式設計師的API

模型進入工作流後，軟體還需要第三類介面：

面向智慧體的語義工具

面向模型的工具不應該只是：

點選第17個按鈕
開啟第5個視窗
選擇下拉框第3項

而應直接表達任務意圖：

讀取器件連線
檢查欠定義草圖
修改指定材料
執行干涉分析
生成網格
讀取求解日誌
匯出模型

一個成熟的工程 MCP 還應具備：

  • 穩定的物件標識；
  • 明確的單位和座標系；
  • 輸入範圍和型別檢查；
  • 修改前差異預覽；
  • 事務與撤銷；
  • 執行進度和取消；
  • 結構化錯誤資訊；
  • 軟體與工具版本；
  • 可核驗的執行結果。

軟體設計方也不應只把現有數百個底層 API 原樣暴露給模型。工具過多、名稱相近或引數複雜，都會增加模型選錯工具的機率。

更合理的方式是把底層介面重新組合成少量語義清晰的任務工具，並提供專業 Skills、規則和示例，讓模型不僅“有能力呼叫”，還知道“應當怎樣呼叫”。

軟體多了一種使用方式

模型進入工程軟體後，整合需要準確識別物件和單位、限制修改範圍，並返回可以核驗的結果。人員也需要能夠查看、拒絕和追溯這些操作。

MCP 為圖形介面和現有 API 之外增加了一條互動路徑。它是否有用，取決於軟體能否清楚地開放操作，以及工程師能否可靠地核驗結果。