.NET Walker

我覺得今年真的是 AI Agent 崛起的一年。 AI 輔助開發在今年幾乎可以說是全面 Agent 化，而一般的消費者應用領域，也開始有許多 AI Agent 出現。最近身邊的幾個專案，都不約而同地從傳統的 Web應用程式升級成採用單一對談式介面為主要入口的 AI Agnet。 上課時，和學員聊到這些改變。 其中有位學員問到，這是因為MCP出現的關係嗎? 我說不是，真要說的話，其實應該從 Function Calling 開始說起。 一切從 Function Calling 開始 還記得 Function Calling 嗎? 最初的 LLM 只能聊天。你問，它答。但它就是個黑箱，不會上網，不能查資料庫，不知道今天幾月幾號，現在是幾點，當然也不可能去執行你的 API。 後來模型的推理能力變強了(約莫是在 gpt 4o 前後的那個階段)，OpenAI 才提供了一個新的能力： 讓模型可以「要求系統替它做事」 。 這因為當時的LLM開始能夠理解、進行結構化輸出、並且能做到多步驟推理的這個基礎上。 那時候你跟模型聊天，模型可以依照你的對話，來判斷是否需要呼叫外部函式(API)，如果需要，模型就回你一段結構化的JSON，像是底下這樣(例如你在聊天的過程中提到要進行請假)： "function_call" : { "name" : "leave_request" , "arguments" : "{ start_date:2026-5-12,end_date:2026-5-13,leave_type:病假,substitute:張大寶 }" } 這就是 Function Calling。 很多人看到 Function Calling 這個字眼，誤以為「LLM 模型能夠直接呼叫API」?? 不，其實並沒有，也不能。 真正執行 API 的，是你的 Runtime、你的 Framework、或是你的AI Agent程式。 LLM 模型做的只有三件事： 依照對談或語意，判斷需不需要呼叫 API 以及，呼叫哪個 API (像是上面的 name) 還有，組出呼叫API時所需要的參數 (像是上面的 arguments) 然後...

你一定已經發現，最近一年在 AI 領域裡，「Skill」這個詞忽然之間就火了起來。本來 Skill 就是個一般般的英文單字，沒什麼了不起的，但現在一講到 AI Agent，不能沒有 Skill；講到 Agent 開發框架，當然也一定得談談 Skill。 最近看了一堆關於 AI Agent 的討論，幾乎每個新框架、新平台上線時，都會強調他們的 Skill 整合有多強、支援有多完整。就像當年「微服務」爆紅的時候，所有架構都要講微服務、所有工程師都在討論如何切分服務。 時代不同，但焦點轉移的方式卻是一樣的。 Skill 到底在夯什麼？簡單說就是： 你的 Agent 大腦(Model)再聰明，如果沒有 Skill，那它就只能聊天對談回答問題，頂多就是幫你做些決策或判斷，但卻沒辦法真正去「做」事情。 Skill 讓 Agent 有了「手」和「腳」 差不多就是一個人聰明絕頂，但四肢癱瘓，只能用嘴巴說話這樣。 AI Agent 沒有 Skill，就是這種情況。它知道怎麼回答你的問題，但沒辦法去呼叫你的系統、修改你的資料、執行你的商業邏輯。 Skill 就是那雙「手」和「腳」。透過 Skill，Agent 可以呼叫你的函式、連接你的資料庫、整合你的第三方服務、執行實際的業務操作。換句話說，Skill 是讓 AI Agent 從「一個聰明的客服」轉變成「一個能幹的員工」的關鍵。 MAF(Microsoft Agent Framework) 老實說，身為 .NET 開發者算是幸運的，相較之下微軟在 AI Agent 開發技術這塊，毫無疑問算是跑得非常快。 Microsoft 推出的 Agent Framework（MAF） 對整合 Skill 的支援，說實話，就是一個 優雅 。不只是功能全，在設計上也考慮到開發者的痛點。 舉個例子，如果你要給 Agent 加一個「查詢訂單」的 Skill，你不用寫複雜的 JSON Schema、不用手寫一堆的 serialization 邏輯。在 MAF 裡，你可以寫像這樣的程式碼： // 建立一個技能提供者，指向技能目錄 var skillsDir = Path . Combine ( Directory . GetCurrentDirectory ( ) , "skills" ) ; var...