.NET Walker

一開始寫這篇文章的時候，我有點困擾。 到底這一篇我到底該命名 『使用 Dify 串接 LINE Bot』 ，還是 『使用 LINE Bot 串接 Dify』?? 但我想，反正你應該知道我的意思，本文就是討論如何把兩者串在一起。 如果不熟悉 Dify ，本篇文章的前面還有兩邊文章你可以簡單的介紹了一下，所有連結位置在底下: https://studyhost.blogspot.com/search?q=dify 總的來說(我20年前就這麼說話了，最近有人說AI很喜歡說『總的來說』，但顯然是AI學我的)，我們可以在 Dify 裡面設計一個類似底下這樣的 workflow，他可以是一個簡單的對談聊天機器人，也可以是串接到後端HR請假系統，可以協助企業進行請假的 AI 助理： 顯而易見，使用 Dify 的好處很多。而在這邊它對我們來說，意義上是一個所視即所得的 Chat Bot(AI助理)設計平台，你可以在 Dify 中先把對談流程設定好，並且進行測試。 設計初步完善之後，我們可以透過Dify API來進行串接，例如串接到 Teams Bot或是LINE Bot。API的部分我們之前在 這一篇 介紹過。 由於Dify內建處理了對談前後文與記憶的部分，並且可以直接串接OpenAI的API(或是其它LLM亦可，同時也便於抽換)，這讓我們開發 AI 助理輕省不少。 這也是我覺得 Dify 作為一個 LLMOps 開發平台(Platform)應該算是當之無愧的原因了。 串接到 LINE Bot 那在Dify上開發測試完之後，我們當然希望能夠整合在 LINE Bot(或是隨便其它什麼 Bot)上面。前面說過，由於 Dify 有提供一組API，我們可以透過該API輕易地進行串接，API的部分，我們在先前 這一篇 介紹過。因此，我們底下要更進一步，談談如何實際跟 LINE Bot 整合在一起。 其實架構上不複雜，我們只需要建立一個 LINE Bot 的 WebHook ，並且在其中呼叫 Dify API即可： 也就是上圖中，紅色虛線框起來的這一段。 這部分該如何進行呢? 倒也容易，我們看底下 WebHook 的部分： var responseMsg = "" ; //準備回覆訊息 if ( LineEvent != n

我是覺得 Power Automate Desktop 本身已經很強，過去幾年，MS推過這類 no code/low code 產品N次，但就像我有位好朋友才剛剛說的：『你早人家一步是先知，早人家兩步往往是烈士!』一個產品要獲得最後的成功，總是得蒐集齊了天時、地利、與人和。 我覺得這次 Power Automate Desktop 算是做得很不錯，actions 的數量和生態系頗好。我最近也幫不少企業做了 Power Automate Desktop 的教育訓練。 然而今天，居然差點被學員的一個小問題給考倒了。 有位學員碰到一個我覺得頗簡單的情境，希望能夠在 Power Automate Desktop 的流程運行中計算一個字串變數的長度。我想說這個隨便哪一種語言都能做的功能，Power Automate Desktop應該可以吧，結果，找了半天，竟然沒有!!! Power Automate Desktop中，字串相關的 actions 清單在底下: 文字動作參考 - Power Automate | Microsoft Learn 還真的沒有。 怎麼辦? 身為程式設計師的想法當然是–>那我寫 code 總可以了吧。 找到了 Run Python Script 的 action： 用的時候發現，寫code是很容易，但怎麼把變數傳進去和把計算結果傳出來，倒是花了我一點時間。原來，run python script 居然可以透過 print 來把運行結果傳出來，所以，底下這段指令可以取得 UserInput 字串，並且透過運行 Python Code 取得長度，最後設定在 PythonScriptOutput 變數中: 如此一來，不只可以取得字串長度，基本上你想幹什麼都行。底下透過三個action做一個示範，讓用戶輸入文字，然後透過 python 計算該文字的長度，最後透過對話視窗顯示出來： 最後，整個流程完整的 script 設計如下： 結果，no code solution 還是透過 code 解決了問題 🤣 後記： 這篇其實主要是想介紹在RPA中透過 Run Python Script 來實現系統中可能無法直接提供的功能。但基於RPA的精神，還是應該少寫一點code比較好。 因此，網友提供了一個比較標準的作法，可

只要活著，就會改變。 我常說，只要你待在資訊領域夠久，那『 變化 』這件事情對你來說，就絕對是家常便飯。 LINE Bot 最近的變化是，從 2024/9/4 之後，開發人員無法透過 LINE Developer Console 建立 LINE Bot 帳號囉。 過去，開發人員一般都在 LINE Developer Console 建立 LINE Bot 對談機器人( LINE Messaging API channel)，其實也就是官方帳號，為了讓入口更加一致，現在改為統一在 LINE Official Account Manager 才能建立。 如果你從 LINE Developers Console 進去，試圖建立 LINE Bot 帳號，現在會看到底下畫面： 也就是請您改為到 LINE Official Account Manager 建立，點選按鈕之後，會出現: 依照步驟建立好之後，你可以選擇暫時不要申請認證帳號: 進入管理畫面後，可以先去開啟 LINE Messaging API 功能： 這個步驟一定要做，否則，你將無法在 LINE 開發人員後台(LINE Developer Console)看到該帳號 過程中你會成功的讓該官方帳號啟用 LINE Messaging API功能，並且選擇或建立 Service Provider: 同時也可以在這邊設定 WebHook： 我自己覺得這個改變很是關鍵。 這讓對談機器人的建立主導權，從開發團隊移轉到帳號擁有者身上。這是一件好事，怎麼說呢? 過去，很多甲方的客戶(業主)並不知道其實自己就可以建立一個新的對談機器人，或是可以自行把已經建立好的官方帳號升級(加入)對談機器人的功能，以為必須透過開發商(乙方)來建立。甚至可能也不知道其實不需要開發商的介入就可以自行設定 WebHook 來改變官方帳號的自動化行為。 這導致，開發商總是用自己的公司(或工作室)名稱來幫業主申請官方帳號，徒增後續的帳號認證和管理、移轉權限的困擾。如今這樣調整之後，整個帳號建立、設定的主導權從開發商回歸官方帳號的業主身上，省去彼此間權利義務歸屬的困擾。 建議未來，都由帳號擁有者(業主、客戶)自行建立官方帳號(或是LINE Messaging API Channel)，而開發商則是專注於在測試、

開源 一個軟體或產品，要讓人信任它最簡單的方法，就是『開源(open source)』。 有時，用戶心裡會想：『我在你們這個技術上投資，萬一哪天你們整個開發團隊解散了怎麼辦? 我的投資不就打水漂了嗎? 』的確，這顧慮不無道理，產品的開發團隊也知道。 怎麼辦呢? 答案很簡單，就是『👉開源』。 怎麼讓用戶相信產品開發團隊在雲端上host的平台很正直，不會拿客戶上傳的資訊幹些什麼壞事? 答案也很簡單，又是『👉開源』。 總之呢，開源是快速獲取用戶信任的好方法。除了原始程式碼開源，最好連運行的環境也一併容器化，也開源。放上docker hub上讓大家可以免費下載。很佛心，沒錯，但它要換來的就是，你的信任和使用。 Dify 好唷，Dify 這個 2023年才開始的專案就是這麼幹的，這讓你可以比較放心這個其實只有20多人的新創團隊(而且還不是歐美血統)所開發的大語言模型 AI Agent 運行平台/框架。 Dify.AI 有一個雲端版本的 portal (如下圖)，功能面我先不在這篇文章說，這篇只講容器化，但讀者可以自行上網申請一個帳號體驗一下： 總的來說，Dify 對自己的定位是 LLMOps 平台，負責幫你代勞一堆有的沒的LLM相關整合大小事。(前面說了，這個你自己上網查或申請個帳號去體驗一下) 我們來看它如何在地端環境執行，首先，它整個專案在 GitHub上，可以透過底下指令下載： git clone https://github.com/langgenius/dify.git clone 下來之後，進到 \dify\docker 資料夾： 接著透過 docker-compose指令： docker-compose up -d 來運行，接著稀哩哩嘩啦啦的執行一陣： 接著你可以開啟 http://localhost/install ，進入整個系統的設定畫面： 設置好帳密之後，以後就可以透過 http://localhost/apps 網址登入站台囉： 整個畫面跟前面說到的 Dify.ai 網站完全相同，等於是你可以把人家整個網站 host 一份在自己的地端伺服器上，確保你的投資(例如設計的 AI Agent) 不會變成孤兒。 而我們在雲端設計好的 AI Agent，也可以透過匯出 DSL，直接在地端匯入： 匯