從 MCP 出發，一般開發者如何補足 Agent 工程能力

被高估的 MCP 與被低估的感知循環

Agent 工程師和一般開發者最大的差別，不是會寫多少程式碼，而是能否讓 AI 在真實環境中自主感知、決策和執行。 MCP（Model Context Protocol）作為連接 AI 模型與外部工具的標準協議，確實讓工具集成變得前所未有的簡單——你用一份協議就能讓 LLM 調用數據庫、文件系統或任何 API，省去了為每個工具接口寫適配的時間。但如果你以為學會 MCP 就能成為 Agent 工程師，那就掉進了最早的陷阱。

MCP 解決的只是「工具呼叫」這一層，而 Agent 工程的核心是感知-思考-行動的循環。工具呼叫是「行動」的一部分，但感知（如何獲取環境狀態並回饋給模型）和思考（如何規劃步驟、權衡優先順序、處理意外）是更棘手的能力。我在幫助團隊遷移到 MCP 時發現，多數開發者高估了協議本身的價值，卻低估了設計感知循環的難度。

一個真實場景：自動程式碼審查 Agent 翻車了

假設你正在用 MCP 建立一個自動程式碼來檢視 Agent。你的設計是：當有 PR 提交時，Agent 透過 GitHub API（透過 MCP 整合）讀取 diff，呼叫 LLM 分析變更，然後透過 MCP 的發布訊息工具在 PR 下評論。看起來合理，對吧？實際運行時你發現 Agent 經常卡在三件事上：

1. 沒有上下文感知：Agent 只看了當前 diff，卻不知道這個文件的歷史變更或相關的 issue 討論，導致評論內容重複甚至矛盾。
2. 循環失控：當 Agent 發現一個 lint 錯誤並建議修復後，它又去執行修復，但修復後的程式碼自動提交觸發了新的 PR 事件，Agent 再次被喚醒，形成無限循環。
3. 工具選擇錯誤：Agent 誤用了“刪除檔案”工具來“刪除一行註解”，因為它按字面理解“刪除”指令，而沒有先確認檔案的上下文。

這些失敗不是 MCP 的問題，但你一定會在用 MCP 搭建「行動層」時遇到。 MCP 只給了你一個標準化接口，但感知資訊來自哪裡、循環邏輯如何設計、邊界條件怎麼處理，這些都需要你自己實現。

第一步：從“單次呼叫”轉向“感知-行動循環”

我建議你最開始的練習不是寫一個全功能的 Agent，而是改造一個你現在日常用的腳本。例如你有一個自動清理臨時檔案的腳本，把它變成 Agent：

1. 以 MCP 暴露檔案系統工具：包含 list、read、delete、rename 等操作。
2. 增加感知輸入：不是直接寫死刪除規則，而是讓 LLM 透過 MCP 讀取磁碟使用情況，再決定哪些檔案需要刪除。
3. 設定循環限制：在 Agent 執行一次刪除後，讓它重新讀取磁碟狀態，比較前後變化，如果空間釋放不足則繼續，但最多循環 3 次。
4. 加入確認環節：在真正執行 delete 之前，讓 Agent 輸出一個“將要刪除的檔案清單”，然後由你手動批准或拒絕。

大部分開發者第一步就卡在「感知輸入」上。你可能會想：直接讀取磁碟使用率很簡單啊，Get-DiskUsage 或 df 指令就行。但問題是：LLM 怎麼知道它需要呼叫這個指令？你需要把「感知」也作為工具的一部分暴露給模型。本質上，你需要一個「環境感知工具」集合，而不是只有「操作工具」。 MCP 協定不區分這兩種，但你在設計工具清單時必須分開。

最容易踩的坑：把 MCP 當作萬用膠

最普遍的失敗方式是想利用 MCP 完成所有事情。例如讓工具本身做決策而不是讓 LLM 做決策，或把複雜邏輯寫在工具實作裡，讓 LLM 只做簡單的參數傳遞。這背離了 Agent 設計的初衷——決策應該由模型主導，工具只執行原子操作。

另一個常見錯誤是忽略錯誤處理。當 MCP 工具呼叫失敗時，你的 Agent 迴圈是直接終止，還是重試，還是降級？很多新手直接讓 Agent 重複調用，導致 API 耗盡或無限重試。正確的做法是為每個工具呼叫設定逾時和最大重試次數，並在降級時記錄日誌以供後續偵錯。

還有一個容易被低估的點是上下文視窗的管理。每次循環都會產生新的對話歷史，很快就會撐滿上下文。你需要設計摘要機制，將歷史循環的精華壓縮成簡短的狀態描述，而不是無腦追加。

失敗時的備選方案

如果你的 MCP-based Agent 在 3 次迭代後仍然無法穩定工作，不要死磕協定本身。考慮以下替代方案：

• 回退到硬編碼邏輯：對於高頻、確定性高的流程（如文件清理），寫一個傳統程式更可靠。用 Agent 做決策的成本可能遠遠超過收益。
• 混合架構：用 MCP 做工具層，但用規則引擎（如決策樹）取代 LLM 做部分決策。例如「如果磁碟使用率 > 90%，優先刪除超過 30 天的日誌檔案」可以用簡單 if-else 實作。
• 完全拋棄循環：如果你的場景是一次性的“查詢-回答”，不需要循環，那就用簡單的 Function Calling 而不是 MCP。 MCP 的優點在於多工具、多步驟場景，殺雞不用牛刀。

什麼時候該升級到系統化學習？

當你發現自己在以下任何一個方面反覆卡殼超過一周，就該考慮系統化學習了：

• 感知循環設計：不知道如何設計狀態回饋和上下文壓縮。
• 工具規劃策略：多個工具呼叫時，如何讓 LLM 正確編排順序。
• 安全性與沙箱：如何防止 Agent 執行危險操作。
• 除錯能力：Agent 行為異常時，你很難看出是模型問題、工具問題或循環邏輯問題。

系統化的課程能提供成熟的模式（如 ReAct、Plan-and-Execute）和工具鏈（如 LangChain、CrewAI）的最佳實踐，節省你大量試錯時間。但在此之前，務必先親手做一個簡單的循環，理解其中的核心矛盾。