一場被混淆的工程決策
當你開始建立 AI Agent 時，遲早會面對一個選擇：用 MCP（Model Context Protocol）還是 Loop Engineering（循環工程設計）？它們都涉及「讓模型多次呼叫外部工具」這件事，但一個是標準化協議，一個是架構模式。把兩者混為一談，輕則專案延期，重則無法落地。
我曾經看過一個團隊試圖用 MCP 取代循環控制，結果發現 MCP 的 retry 機制無法滿足自訂重試邏輯——這不是協定的問題，而是選錯了工具。
核心區分：協定 vs 模式
MCP 是一個標準化的模型-工具互動協定。它規定了模型如何發現工具、呼叫工具、接收結果。 MCP 不關心你的業務邏輯有幾層循環、重試策略是什麼，它只保證一次呼叫能可靠地完成。
Loop Engineering 是做一件事：讓模型在循環中多次呼叫工具，直到滿足終止條件。它不是協議，而是一種架構模式。你手動編碼循環邏輯，控制每次呼叫的上下文傳遞、結果校驗、條件分支。
一個具體的場景：
- MCP 負責：呼叫天氣 API 並傳回 JSON 結果。協定確保連線穩定、錯誤可讀。
- Loop Engineering 負責：連續呼叫多個 API（天氣、航班、飯店），每次根據上一次結果決定下一步要呼叫哪個 API，直到產生完整行程。
如果專案只需要單一工具調用，MCP 足夠。如果你需要多步驟推理、動態決策，必須引入 Loop Engineering。
適用邊界：什麼時候用哪一個？
| 維度 | MCP | Loop Engineering |
|---|---|---|
| 呼叫次數 | 單次或有限次 | 動態循環，次數不定 |
| 上下文共享 | 無狀態，每次調用獨立 | 需維護歷史上下文 |
| 終止條件 | 由外部邏輯決定 | 可自訂（如結果穩定、逾時） |
| 複雜度 | 低，只需配置工具 | 高，需要編碼循環邏輯 |
| 典型場景 | 查詢資料庫、呼叫 API | 程式碼產生、多步驟推理、自動化測試 |
一個容易失敗的地方：當你的迴圈中有條件分支時，不要用 MCP 的 retry 機制來取代。 MCP retry 只重複相同調用，而需要的是「換一個工具繼續」。這時應該用 Loop Engineering 明確編碼決策樹。
最容易踩的坑：混淆協定與循環
最典型的錯誤是：試圖讓 MCP 管理循環狀態。 MCP 的每次呼叫都是獨立的，它不會自動傳遞上下文。如果你需要記住之前的結果，必須自己實現狀態管理。
舉個例子：用 MCP 寫一個自動修復程式碼錯誤的工具。第一次 MCP 呼叫找出錯誤，第二次呼叫修復它。但你發現第二次呼叫並不知道第一次的上下文。正確的做法是用 Loop Engineering 把兩次呼叫包裝在一個循環裡，手動傳遞上一次的修復結果。
另一個坑是 忽略錯誤處理。 Loop Engineering 中，每次循環都可能失敗。如果不處理錯誤，整個循環會死鎖或無限重試。 MCP 提供了標準錯誤碼，但循環邏輯必須自己寫。
如何選擇：一條簡單的決策路徑
- 如果只有一次工具調用，沒有後續依賴 → 直接選 MCP。
- 如果調用次數固定且少量（<5次），則上下文可序列化 → 用 MCP + 簡單循環（用程式碼控制，而非協議）。
- 若呼叫次數不固定、需動態決策、情境複雜 → 必須使用 Loop Engineering。
- 如果團隊已有 MCP 基礎設施，但需要循環 → 在 MCP 之上建造 Loop Engineering 層，不要用 MCP 取代循環。
失敗時的備用方案
如果你發現目前方案行不通，最常見的備用方案是：
- 從 MCP 切換到自訂工具協定：當 MCP 的限制（如無狀態、呼叫次數）成為瓶頸時，可以放棄 MCP，改用直接 HTTP 呼叫或 gRPC。
- 從 Loop Engineering 退化為多次獨立調用：如果循環邏輯過於複雜難以調試，可以拆解成多個不依賴的 MCP 調用，儘管犧牲了動態決策能力，但提升了可維護性。
- 引入狀態管理框架：在 Loop Engineering 中，使用 Redis、LangGraph 等工具管理狀態，避免自己造輪子。
從理論到實踐：一個遷移案例
假設你正在建立一個程式碼審查 Agent。最初以 MCP 呼叫程式碼品質 API，每次只解決一個警告。後來需要連續修復所有告警，且每次修復後重新檢查。
錯誤做法：用 MCP retry 重複呼叫修復 API，忽略警告變更。 正確做法：用 Loop Engineering 寫一個迴圈：
- 呼叫程式碼檢查 MCP 工具取得警告清單。
- 依序修復每個警告（每次呼叫一個修復 MCP 工具）。
- 再次檢查，如果新告警出現則重複。
- 修復後無新警報或達到最大輪次時終止。
在這個循環中，MCP 只負責單次工具調用，循環控制和上下文傳遞由工程程式碼實現。
下一步：成為 Agent 工程師
在理解 MCP 和 Loop Engineering 的差異後，下一步是掌握更系統化的 Agent 建構方法。如果你希望從一般開發者轉型為 Agent 工程師，需要深入理解情境管理、動態工具編排、錯誤復原策略等進階話題。
暫無評論，快來發表你的看法吧