MCP

前言 最近在 Kong 3.12 上做一個 PoC，想把公司內部的 RESTful API 透過 ai-mcp-proxy plugin 包成 MCP server，讓 Microsoft Copilot Studio 可以呼叫。同時為了讓呼叫者帶身分過來，在同一個 route 上掛了 openid-connect plugin，搭配 Microsoft Entra ID（原 Azure AD）做驗證。 理論上很單純：Copilot Studio 帶 token，Kong 驗證，通過後轉成對後端 REST API 的呼叫。實際做下去踩了一些雷，趁還沒忘掉趕快記下來。 架構概觀 Copilot Studio │ (Bearer token from Entra ID) ▼ F5 (load balancer) │ ▼ Kong Data Plane (Route /My-MCP) │ ┌─ openid-connect plugin (驗證 Entra ID token) │ └─ ai-mcp-proxy plugin (mode: conversion-listener) ▼ Backend RESTful API (Azure App Service) 401 Invalid Token OpenID Connect plugin 一掛上去，設定大致是這樣： ...

看到一篇文章寫的不錯，紀錄留存一下，並且簡單的重點整理。 本文僅做紀錄與整理，觀點本身皆來自原文作者。 原文：https://www.facebook.com/100063744608911/posts/1526846902783449/?mibextid=wwXIfr&rdid=ABv4HxePsdb0LmOe Agent 開發的三個階段演變 第一階段：工具連接期 (Function Calling / MCP) 作法：利用 LLM 的 API 與 Function Calling 能力，將 AI 與後端系統串接。後來演變成標準化的 MCP (Model Context Protocol)。 痛點：技術門檻過高，能獨立完成的人很少。 第二階段：多代理協作期 (A2A / Multi-Agent) 作法：類似 Google 提出的 Agent to Agent，讓多個 AI 各司其職。 痛點：類似「微服務」亂象，過度設計 (Over-engineering)。管理多個 Agent 的 Context 很困難，且往往「一個 Agent + 多個 Tools」就能解決問題。 第三階段：Coding Agent 與 SDK 成熟期 (現在) 作法：使用 Claude Code 或 GitHub Copilot 這類高度可自訂的 Coding Agent。 突破：透過自訂 Instructions 和 SKILLs (流程知識)，不僅能寫程式，還能處理非開發任務。這是最直覺有效的路徑。 AI 時代的 MVP (最小可行性產品) 開發新路徑 過去的軟體開發往往是「從輪子造車」(從底層一行行寫)，風險在於最後一刻才知道客戶喜不喜歡。AI 讓「理想的 MVP 路徑」(滑板車 -> 腳踏車 -> 汽車) 變得成本極低且可行： ...