.NET Walker

以前，要做一個 AI Agent，光是想怎麼讓它跟外部系統溝通，就足以讓人頭痛。 但現在不同了。 Dify 與 MCP：天作之合的組合技 先說說 Dify 。如果你還沒用過它，那真的該好好認識一下。Dify 是一個開源的 LLM 應用開發平台，整合了視覺化的工作流程編輯器、RAG（檢索增強生成）管道、AI Agent 開發能力、模型管理等功能。簡單說，就是把原本複雜的 AI 應用開發，變成拖拖拉拉就能搞定的事情。 然後，另外是 MCP （Model Context Protocol）。這是 Anthropic 推出的協議標準，目的是讓 AI 模型能夠標準地串接各種外部工具、與不同的資料來源溝通。 試想一下，以前當我們想讓 AI 接資料庫、串 API、整合各種企業內五花八門的資訊系統時，每套都要自己刻一個介面。有了 MCP，這些都變成像是標準化的「插頭」，插上去就能用。 當這兩個東西碰在一起，會發生什麼事？ 讓流程無所不能的魔法 有了 MCP 之後，Dify (開發的AI Agent) 能做的事情突然變多了。 更讚的是，我之前做了一個小工具，可以把 Dify 直接串到 LINE OA(官方帳號) 上。現在要設計一個 AI Agent？ 輕鬆到太過美好。 以前要花兩週處理的工作，現在可能半小時就搞定了。 實戰：用 MCP 串接請假系統 直接看個案例。 底下這張圖片就是 Dify 串接 MCP 請假系統進行請假的畫面。看到了什麼？對話介面相當乾淨(下圖右方)，使用者只需要自然地說「我要請假」，AI Agent 就會自動處理剩下的流程，蒐集請假所需要的資料，然後透過MCP呼叫串接好的HR請假系統的 API，完成請假功能。 當然，查詢剩餘請假時數，也是如此。 這背後發生了什麼？AI 透過我們做好的 MCP Tools，呼叫了請假系統的 API，確認你的假別、假期餘額、代理人…等資訊。所有這些複雜的商業邏輯，都被優雅地包裝在 MCP Server 裡面。使用者完全感覺不到複雜性，就像在跟一個很聰明的 AI 聊天助理對談而已。 這就是 MCP 的魅力。 它不只是一個協議，更是一個思維模式的轉變——把複雜的系統整合，變成簡單的行動，讓AI Agent可以在與用戶對話互動中隨時調用。 用 .NET Core 打造你的 MCP Server ...

為何有這種需求 最近在上 Azure DevOps 課程，下課後，一群學員突然跑來問了個問題。 「老師，我們公司有三十幾個 Azure DevOps 專案，每個專案都有自己的 repo，每個 repo 都有自己的 pipeline yaml 檔…」他頓了一下，臉上帶著某種「歷盡滄桑」的表情，「有沒有辦法讓這些 pipeline 共用同一份 template？改一次就全部生效的那種？」 我其實急著下課，並沒有聽得很仔細，腦袋裡還在糾結：「為何要讓所有的 repo 都共用同一份 yaml template，每個開發專案不是應該有自己的 pipeline design 嗎？為何要為了統一控管搞得這麼複雜？」 於是我追問：「為什麼會有這種需求呢？」 他苦笑著說「每當公司想要在 pipeline 裡加入一些共用的步驟，比如說安全掃描、程式碼品質檢查、部署前的驗證等等，我們就得一個一個 repo 去改 pipeline yaml 檔。三十幾個專案，每個專案又可能會有好幾個 repo，改起來超級累人。」 教室裡其他學員也紛紛露出「我懂我懂」的表情。這種痛，做 DevOps 的人應該都瞭。 更慘的是，當你好不容易改完三十幾份檔案，過兩個月主管又說：「欸，我們現在還要加入程式碼品質檢查。」然後你又要再改一輪。如果哪天發現其中一個步驟寫錯了，想改？好啊，三十幾個 repo 再巡一次。 這就像是複製貼上了三十幾份同樣的食譜，結果發現鹽放太多了，然後你得把三十幾本筆記本都翻出來，一本一本改。真的累。 「所以…」學員問，「有沒有辦法讓這些 pipeline 共用同一份 template？改一次就全部生效？」 我當下趕著回家，沒多想，也來不及具體回答。 但回家後仔細思量：「這個問題其實挺實際的，應該是有解決方案的吧?」稍微翻了一下，果然發現 Azure DevOps pipeline 原本就支援引用外部的 yaml template。 如何實現？ Azure DevOps 其實早就想到這個問題了。它提供了一個機制，讓你可以把 pipeline 的某些步驟抽出來，放到另一個 repo 裡當作「模板」，然後其他專案的 pipeline 就可以「引用」這個模板。 聽起來很簡單對吧？但實際上第一次設定的時候，總會有那種「欸這樣寫對嗎?」的不確定感。 我也是這樣，看著官方...