Keep Walking - 王建民篇

作者： -
哇, 我喜歡的Keep Walking廣告增加了王建民篇...看來我需要考慮要不要更新桌面了...^_^

留言

張貼留言

這個網誌中的熱門文章

原來使用 .net 寫個 MCP Server 如此簡單

作者： -
圖片
MCP 的重要性與意義 MCP 的重要性在於它建立了一個標準化的架構，讓開發者能夠快速建構出給 AI Agent 呼叫的各種功能。 舉例來說，假設我們希望實現一個 可以透過自然語言對談的請假功能 ，傳統上我們必須建立一個前端 Chat Bot 作為 UI、還得撰寫後端 API、資料驗證邏輯、資料庫存取介面…等，另外還要設計 Chat Bot 的對話邏輯，才能把請假功能整合到Chat Bot的對談訊息中。 但在 MCP 的架構下，這樣的流程可以大幅簡化。 開發者只需要實作幾個「請假功能」的介面（Tool Interface），接著定義好運行這個功能需要輸入哪些參數（例如請假人、開始時間、代理人、事由…etc.），並透過 JSON 來描述這些參數的格式與驗證邏輯。接著，AI Agent 便可以在對話過程中，自動根據對談前後文理解使用者意圖，挑選出適合的Tool來運行，主動發出呼叫的請求。如此一來，大幅簡化了AI Agent開發的難度。(本質上就是 Function Calling 的概念) 而 .net 又把這個難度降低到人人可以開發的程度，底下是一個使用 .net 開發的 請假功能 MCP Server，並且使用 GitHub Copilot來呼叫的例子： 其實我之前用 Semantic Kernel做個類似的範例，只是如今 .net 讓它變得更簡單，而且輕易地可以透過MCP架構讓不同的 MCP Client端呼叫使用。 如何用 .NET 撰寫 MCP Server 要使用 .NET 撰寫 MCP Server 非常簡單，受益於 Microsoft.Extensions.Hosting 和 ModelContextProtocol 套件，我們可以在幾分鐘內輕鬆地實作 MCP Tool 和 MCP Server 。 以下是MCP Server的完整程式碼： using Microsoft . Extensions . DependencyInjection ; using Microsoft . Extensions . Hosting ; using Microsoft . Extensions . Logging ; using ModelContextProtocol . Server ; using System ...
Read more »

使用LM Studio輕鬆在本地端以API呼叫大語言模型(LLM)

作者： -
圖片
最近上課常被問到，如何在地端環境搭建出大語言模型(LLM)，並且呼叫其API。 一開始我不太理解為何會有這樣的需求(因為在地端自行搭建運行LLM的成本不一定比較低，即便可能比較安全)，但被問多了，也就開始遍尋相關的解決方案，看看有沒有什麼最簡單的方式，可以讓開發人員在地端測試大語言模型? 後來我選擇 LM Studio ，它就是一款設計來運行大型語言模型（LLM）的平台，有個算是挺優雅的整合環境，讓一般 end-user 或開發人員，都可以輕易地在 local 端進行模型的部署和測試。 LM Studio 本身支援多種模型架構和框架，當然，最重要的是，它是免費的。 下載安裝 都很容易，我就不多說。 安裝好之後，你可以看到首頁中已經呈現了許多 Hugging Face上的模型： 這顯然是因為Hugging Face是大部分免費開源模型的集散地。 你可以搜尋自己喜歡的模型，透過LM Studio下載到local之後，就可以直接載入(下圖一)： 隨手設定一下 system prompt(上圖二)，然後，就可以直接對談了。(上圖三) LM Studio會使用你的GPU進行運算(如果有的話)，你會發現，原來有好的設備(GPU)，運行的速度可以如此之快。 Local Server 對於開發人員來說，它還有個超級更友善的功能。 LM Studio本身還提供一個 local server，可以幫你把模型包裹起來讓你直接透過API呼叫該模型的功能，例如： 上圖是我們開啟 LM Studio中 Local Server功能後的結果，你可以透過 localhost 的 1234 port 來呼叫這個被 LM Studio 運行起來的大語言模型。(有沒有發現，我們用的也是 chat/completions API) 透過Postman簡單提供一下 JSON Body: { "model": "LM Studio Community/Meta-Llama-3-8B-Instruct-GGUF", "messages": [ { "role": "system", "content": "你是AI助理，請一律用繁體中...
Read more »

開啟 teams 中的『會議轉錄(謄寫)』與Copilot會議記錄、摘要功能

作者： -
圖片
在 Teams 中有一個非常好用的功能，可以透過 “謄寫” 把 Teams 的語音會議變成逐字稿，這部分當然是用到語音識別(語音轉文字)的AI技術。 開始謄寫與自動會議紀錄 當啟動一個會議之後，主席可以透過底下這個『開始謄寫』功能來開啟： 這個功能之所以重要，是因為他也是 Teams Copilot 要能夠順利使用的基礎。我們可以透過 Teams Copilot 進行會議的摘要、總結、整理、或是進行會議內容的詢問，而這後面用的則是LLM(大語言模型)的能力： 這功能對於需要參加很多會議的主管、或是在開會遲到的同仁，都是很方便的功能，可以透過詢問Copilot快速地進入會議狀況。 開啟 “謄寫” 功能 然而，這一切的基礎 “謄寫” 功能卻不是每一個機構都有預設開啟，如果你發現你的 “謄寫” 功能是灰色的(無法點選)，就意味著你的組織沒有開啟(或沒有為你開啟)這個功能。 那組織的管理員該如何開啟此功能呢? 很簡單，只需要到 Teams 系統管理中心，點選 『設定和原則』 --> 『會議』： 進入 『會議』 的設定之後，找到『會議錄製』–>『轉錄』 將其『開啟』即可: 如此一來，組織內的同仁就可以順利的使用 Tteams 會議中的語音轉文字(謄寫)功能，也可以使用 Copilot 來查詢會議的內容囉。 Enjoy it~
Read more »

在VS Code當中使用 Azure DevOps MCP Server

作者： -
圖片
來看看這張圖發生了什麼事情? 沒錯，我們正在VS Code當中，使用 GitHub Copilot Agent Mode，透過自然語言的方式，查詢Azure DevOps中的工作項(WorkItems)。 其實，不僅僅可以查詢，也可以檢視細節、甚至新增、修改。範圍也不只有 WorkItems ，還包含 Pipeline 的觸發、PR的建立或PR Comment的新增…等，全部都可以透過自然語言來進行。 而這些，全都拜MCP所賜。 關於MCP 你大概聽說過 MCP，它是 Anthropic 提出的一套開放式標準協議（Model Context Protocol） ，旨在讓大型語言模型（LLMs）可以安全、模組化、可擴充地存取外部工具和資料來源。 簡單來說，你可以把 MCP 想像成 AI 世界中自然語言對談機器人對外的接口，像是我們寫程式的時候，可以透過 API 來串接外部系統， MCP 就是大語言模型對外「運行指令與資料交換」的標準協議 。 不同的是，傳統 API 是設計給 開發者 來用的，強調結構化資料、明確定義與嚴謹的格式；但 MCP 是設計 給大語言模型用 的，它理解自然語言、懂語意、會參考上下文。MCP 的設計讓模型能夠和用戶在以「對話的方式」溝通時，依照用戶的命令與外部系統互動，但底層其實還是透過 function calling 的概念與結構化的 JSON 交換資料，只是這一切都被封裝得更自然、更貼近人類使用者的自然語言。 如同上面你看到的，大語言模型透過 MCP，可以自動呼叫 Azure DevOps 系統的API，查詢資料、比對欄位、下指令修改狀態，整個流程就像是你請了一位懂 DevOps、又能聽懂人話的數位助理。 底下是新增一個 bug 單的例子： 這正是 MCP 的魔力： 讓大語言模型從資訊生成者，進化為任務執行者 。這背後不只是一個協議，而 是未來開發體驗的轉變 。未來開發者不再只寫程式，而是設計如何與 AI 協作；工作流程不再只是「使用工具」，而是「 與工具對話 」。 如何實現? 作法比想像的簡單超級多，由於最新版的 VS Code 和 GitHub Copilot 已經支援 MCP，所以你只需要確認你是在 Agent Mode(下圖一)，然後在專案工作區的 .vscode 資料夾中，置入一個 mcp.json 檔案...
Read more »

原來使用 .net 寫個 MCP Client 也如此簡單

作者： -
圖片
之前我發了一篇文章，標題是「原來使用 .NET 寫一個 MCP Server 如此簡單」。結果有不少朋友留言敲碗，說：「只有 Server，沒有 Client，這怎麼行？」 呃…我只能說，這個要求顯然 很有道理 。🙄 所以今天趁上課的空檔，補一篇文，來介紹如何撰寫 MCP Client ，把整個架構補齊。 你會發現，其實，開發 MCP Client 也非常簡單耶。 MCP 架構的本質 不過，在開始之前，有一個觀念需要釐清：無論是 MCP Server 或 MCP Client，其實都與 LLM（大型語言模型）沒有 直接關聯 ，這和很多人理解的不同。 MCP 架構的本質，只是為了讓 AI Agent（或 Chat Bot）更容易知道怎麼呼叫外部的服務提供者(就叫做MCP Server)，並且能方便地列舉出這些服務所提供的功能(就叫做MCP Server Tool)，以及清楚了解每個功能呼叫時所需的參數。某種程度上，它的角色有點類似早期 Web Service 時代的 WSDL/SOAP ，或是現代 REST API 架構中的 Swagger/OpenAPI 👉👉 都是用來提供一種 標準化的服務描述與呼叫方式 ，使服務整合變得更一致、更具可預測性。 至於， 什麼時候該呼叫哪一個功能 、呼叫時所要填入的具體參數 值 是什麼，這些判斷與決策的工作，才是由 AI(LLM) 來處理的。而真正去執行這些呼叫動作的，則是 AI Agent(或者稱之為，MCP Host)。 簡單的說就是，對談機器人(或AI Agent)可以藉由 LLM 來呼叫遠端的服務，而 MCP 架構則讓對談機器人可以得知有哪些服務可供呼叫，並且在呼叫時應該要傳入哪些參數。 因此，要開發一個能夠呼叫 MCP Server 服務的 Client 端，自然也需要建立一個具備決策與執行能力的 AI Agent。 這部分，我們待會會採用 Semantic Kernel 作為實作的基礎框架。 之前我們 早已介紹過 Semantic Kernel ，它不僅可以介接各種 大語言模型（像是 OpenAI 或 Azure OpenAI），還能彈性地設計與掛上各種 skills 與 plugins ，非常適合用來打造具備「對談 → 意圖理解 → 功能選擇 → 發出呼叫」這一整套流程的AI Agen...
Read more »