4-1 透過回顧 AI 代理談 MCP

在這個章節中，我們將與大家探討目前 AI 社群中最熱門的話題之一：MCP (Model Context Protocol)。我們會先介紹 MCP 是什麼、為什麼需要 MCP，以及在實際使用 Cursor 時，如何透過整合不同的 MCP 伺服器來大幅提升執行不同任務的效率與生產力。

在章節的第一單元，我們會先花一些時間回顧 AI 代理，因為要理解 MCP 的存在價值，必須先從 AI 代理談起。透過 AI 代理的視角，我們才能更清楚地理解 MCP 的優勢。

什麼是 AI 代理？

我們在前幾章節中已經提到，AI 代理是指在不需要人類介入的情況下，根據指定的目標自主完成相關任務。當你設定一個目標後，AI 代理會根據該目標進行規劃、推理，列出達成目標所需的各項任務，並逐一完成。完成後，AI 代理會檢查是否已達成目標，若尚未達成，則在過程中進行調整，直到目標實現為止。

我們在前幾章節中曾展示過一個例子：假設今天的目標是完成某個函式 (function)。AI 代理會根據這個目標，第一步掃描整個程式碼庫，理解程式碼庫的風格；接著根據該風格及函式的需求，實作函式的程式碼；然後根據函式需求，撰寫相關的單元測試 (unit test) 程式碼；再使用剛完成的函式執行測試。如果測試過程中出現錯誤或未通過的測試，AI 代理會回頭修正錯誤或修改函式，直到所有測試都通過為止。

在這個過程中，唯一需要人類介入的部分是最初輸入「完成該函式」的目標，其餘皆由 Cursor 的 AI 代理自動完成，包括執行任務、修正錯誤，直到目標達成。

當然，完成任務 (例如函式) 後，身為工程師仍需扮演檢查的角色。然而，與過去使用自動補全或 AI 聊天模式相比，AI 代理讓我們需要做的事情更少，效率更高，生產力也更強。

從技術角度理解 AI 代理

若從技術角度高層次地看待 AI 代理，我們推薦參考 Google 之前發表的 AI 代理白皮書。該白皮書中提供了一個簡易的架構圖，顯示 AI 代理的執行環境包含幾個重要元素：統籌層 (orchestration layer)、模型 (model) 及工具 (tools) 這三大核心要件。

在統籌層中，又包含記憶功能、推理功能等不同面向。將這個架構對應到 Cursor 的脈絡，我們可以這樣理解：

模型：指的是我們熟知的各種 AI 模型，例如大型語言模型 (LLM)，包括 GPT 模型、Claude 模型，或 Google 推出的 Gemini 模型。
統籌層：在使用 Cursor 時，Cursor 主要扮演統籌層的角色。雖然 Cursor 有自己的模型，但大多數使用者仍會透過 Cursor 對接其他模型 (如上述的 GPT、Claude 等)。因此，Cursor 在這裡主要負責處理記憶、推理與任務規劃等功能。

工具的重要性

在 AI 代理的執行環境中，還有另一個核心元件——工具。然而，在前幾章節中，我們沒有特別強調工具在 Cursor 中的角色。

相信你可能會問：這裡提到的「工具」究竟是什麼？當我們實際對接到不同工具時，又能帶來什麼樣的效果？以下透過幾個具體例子來說明。

對接專案管理工具 (如 Linear 或 Jira)

假設 AI 代理能對接到 Linear 或 Jira 這類專案管理工具，AI 代理就能直接從這些平台抓取某個任務(task) 的資訊，並根據該資訊確認需求。比起在 Cursor 的對話框中手動輸入需求，若能直接透過任務連結或任務編號提供資訊，Cursor 即可自動抓取相關需求內容，大幅節省時間。

對接瀏覽器操作工具 (如 Playwright)

假設完成一個全端 (full-stack) 功能後，我們希望 Cursor 幫忙執行 E2E 測試並撰寫相關測試程式碼。然而，Cursor 本身並沒有操作瀏覽器的功能，所以只靠 Cursor 是做不到的。不過，若能對接到像 Playwright 這樣的工具，Cursor 就能透過與瀏覽器的互動，實際完成 E2E 測試。

對接 GitHub 以自動化 PR 流程

我們在第三章提到，Cursor 可根據 Git 提交紀錄自動撰寫 PR (Pull Request) 描述，但最終仍需工程師手動將描述複製貼上到 GitHub 或 GitLab 等平台以提交 PR。若能將 GitHub 對接到 Cursor，則在撰寫完 PR 描述後，Cursor 可以直接在 GitHub 上發 PR，省去手動操作的步驟，從而進一步提升效率。

透過這三個例子，希望大家能感受到，雖然 Cursor 在撰寫設計文件、程式碼或 PR 描述方面已提供很多幫助，但若想進一步拓展 AI 代理的能力，必須對接到我們日常工作中常用的工具。然而，Cursor 本身並未內建這些工具，因此需要一個方法讓 Cursor 能與這些工具整合。

MCP 的角色

讓 Cursor 對接到不同工具，正是這個章節要介紹的主題——MCP（Model Context Protocol）。MCP 的設計目的在於讓 Cursor 或其他 AI 應用程式能以標準化方式對接到不同工具。MCP 全名為「Model Context Protocol」，目前已被視為業界統一的標準協定。

MCP 最早由 Antrhopic 於 2024 年底提出，至 2025 年初，連主要競爭對手 OpenAI、Google 也加入支援 MCP 協定。因此，現今談到讓 AI 應用程式對接工具時，MCP 是業界首要提及的標準。

在下一單元中，我們將詳細介紹 MCP 的具體內容，以及如何透過不同的 MCP 伺服器讓 Cursor 對接到各種工具，進而提升工作效率與生產力。

此系列文章為 《給工程師的 Cursor 工作流 — 透過 AI 代理全方位提升開發生產力》 搭配的教材。希望透過這系列文章，將過去協助導入 AI 工具及使用 Cursor 的經驗擴展並分享給想提升生產力的讀者。如果對課程感興趣的讀者，可以加入 E+ 成長計畫，觀看影片學習。