模型上下文協議：過度設計還是代理工作流程的未來？

Model Context Protocol（MCP）在開發者之間引發了關於其架構必要性的辯論。其核心目標是標準化 AI 代理與資料及工具的互動方式。然而，批評者認為，它所提供的功能——例如指令發現與權限範圍——早在數十年前就已由命令列介面（CLI）解決。

這種緊張關係凸顯了 AI 時代的一個根本問題：我們是透過引入新的一層流程，為本地環境增加了不必要的複雜性，還是 MCP 正在提供 CLI 無法提供的關鍵抽象？

CLI 觀點：為何還要再增加一個流程？

對於許多資深開發者而言，Model Context Protocol 看起來是多餘的。反對在本機上大量增設 MCP 流程的主要論點包括：

  • Permission Scoping（權限範圍）：CLI 指令已能以特定權限進行範圍限制，限制工具在系統上能執行的操作。
  • Discoverability（可發現性）：標準的 --help 旗標與 man page 為使用者（以及潛在的代理）提供了強大的方式來發現指令及其所需參數。
  • Resource Overhead（資源開銷）：在單一 PC 上執行數十甚至數百個獨立的 MCP 流程會產生不必要的開銷，並增加系統不穩定的潛在風險面積。

從這個角度看，MCP 被視為「額外的複雜度與移動部件，卻收效甚微」。

超越本機流程：伺服器端 MCP

針對「100 個流程」的顧慮，有一個反論點是 MCP 並不一定需要在本機執行。該協議被設計為彈性，可支援伺服器端託管。

正如社群成員所指出的，Atlassian 等公司已經在實踐此方式。透過在伺服器端託管 MCP 並使用動態客戶端註冊（Dynamic Client Registration）與 OAuth，組織能在不給使用者本機機器增加負擔的情況下，提供安全且已驗證的工具存取。這也允許使用 oauth2-proxy 與 Nginx 等工具，將開源 MCP 包裹於單一登入（SSO）層，讓其具備企業級就緒性。

狀態管理與可稽核性

CLI 雖然在執行指令並取得結果方面表現優秀，卻無法處理複雜、多步驟代理工作流程所需的狀態管理。

當 AI 代理執行一個跨越五十步的任務時，簡單的 CLI 呼叫無法輕易「回滾」上下文或在特定點恢復失敗。這正是向更結構化協議轉變的關鍵所在。對於代理記憶的 Git 式分支與快照需求，正逐漸成為使這些流程具備可稽核與可恢復性的關鍵要求，將「100 個流程」從負擔轉變為有條理、可管理的紀錄系統。

結論

無論未來是涉及數百個本機 MCP 流程，或是集中式的伺服器端架構，Model Context Protocol 都代表了我們在 AI 工具整合思考方式上的轉變。雖然 CLI 仍是人類開發者的強大工具，但 AI 代理的需求——特別是關於狀態、遠端驗證與標準化發現——暗示需要更正式的協議，才能超越簡單腳本執行，邁向真正自主的代理工作流程。

Sources