發表文章

目前顯示的是 9月, 2025的文章

在LINE Bot中使用MemoryCache保存Semantic Kernel的對談記憶

圖片
在開發 LINE Bot 的 AI Agent 或客服機器人時,最重要的功能之一就是 記憶 。 使用者永遠會預期機器人應該要能「記得上一句話」,並能依照上下文繼續對話。 在 Semantic Kernel 中,提供了 ChatHistory 物件來維護對話脈絡。這個物件會記錄 system / user / assistant 的訊息序列,當傳給大語言模型 (LLM) 時,就能讓模型在上下文中產生更自然的回覆。 但是,有一個問題: LINE Bot 的 Webhook API 是 Stateless 的 ,這意味著,每一次訊息事件進來,Controller 都是新的,不會自動幫你保存之前的 ChatHistory 。 因此,如果我們要讓 Semantic Kernel 記住對話,就需要額外設計一個「記憶儲存機制」。 短期記憶的解決方案:MemoryCache 方法有很多,但如果你的應用場景是: AI Agent / QA 客服 一次對話通常會在 半小時內結束 這時候就不需要複雜的資料庫,只要使用 .NET 內建的 MemoryCache 就能搞定。 MemoryCache 的特點 存放在伺服器記憶體中 可以設定 滑動到期時間 (SlidingExpiration) → 長時間沒互動就清掉 可以設定 絕對到期時間 (AbsoluteExpiration) → 即使一直互動,最多存活多久(避免高費用或token爆掉) 效能快。但也因為是存放在伺服器端記憶體中,應用程式重啟或多台伺服器作HA架構時,資料會消失,重新佈署應用程式時,也會消失。 還算是適合「短期記憶」的應用場景。 專案架構 底下示範如何在 LINE Bot WebAPI 專案中,整合該機制,我們建立了三隻程式: Controllers/LineBotChatGPTWebHookController.cs (處理 LINE Webhook) Controllers/ChatCompletion.cs (使用Semantic Kernel 生成 AI 對話) Controllers/ChatHistoryMemoryStore.cs (短期對談記憶保存) 完整程式碼我放在: https://github.com/isdaviddo...

C# 格式化(formatter)在 VS Code 中的選擇

圖片
程式碼的世界裡,有一個古老的爭論: 大括號 { 到底該放在同一行,還是獨立成一行? 這不只是排版問題,有時甚至會演變成團隊會議上的「宗教戰爭」。而我自己也有喜歡的 indent style ,如果看到團隊中其他人的寫法和我不同,雖不至於惱怒,但總覺得有些彆扭。有一種衝動很想把它全部改成自己習慣的方式。 你大概可以想像,當有一天,我發現 VS Code 升級到新版之後,排版和對齊方式竟然變成和我喜歡的不同,那時候我有多麼的震驚,一整天都想要把它給改回來。 怎麼做? 今天我們就來談談,如何在 VS Code 裡改設定,讓 { 的排版聽話。 兩種常見風格 先來看看範例: 1. K&R (大括號跟在同一行) public class HelloWorld { public void SayHello ( ) { if ( true ) { Console . WriteLine ( "Hello, world!" ) ; } } } 2. Allman Style(大括號獨立一行) public class HelloWorld { public void SayHello ( ) { if ( true ) { Console . WriteLine ( "Hello, world!" ) ; } } } 先問問,你喜歡哪一種? 各自的優缺點 同一行風格 (K&R) ✔ 節省垂直空間,檔案比較短。 ✔ 很多 C# 官方範例和文件都是這種格式。 ✘ 有人覺得程式「擠在一起」,閱讀時容易忽略最末端的 { 。 獨立一行風格 (Allman) ✔ 大括號醒目,結構一眼就能看出來。 ✔ 不容易漏掉對應的 { 與 } 。 ✘ 程式會「莫名變長」,多佔好幾行。 👉 簡單說:前者像極簡主義,後者像穿寬鬆衣服,空間感十足。 你是哪一派呢? 在 VS Code 裡如何調整? 方法一: .editorconfig (推薦) 在專案或解決方案根目錄新增 .editorconfig 檔案: root = true [*...

開發者的肌肉記憶

圖片
前陣子,網路上出現一支很轟動的受訪影片, 原因不只是它的長度驚人👉整整六小時: 更重要的是,受訪者是 DHH。 如果你不熟悉他是誰,DHH 全名是 David Heinemeier Hansson,他是 Basecamp 的創辦人,更是 Ruby on Rails 框架的建立者。在開發者的江湖裡,他是那種推一句話就可能引發社群爭論、寫一篇 blog 就可能改變許多開發者的那種人。 訪談中,他談到一個很多人都有那麼點感覺的主題: AI 與 Vibe Coding 對開發者帶來的影響。 他坦言,自從頻繁使用 Auto Complete 與 AI code generation 之後,開始感受到一種「技能退化」的跡象。(有鑑於他的開發能力與背景,我相信他說的,遠多過於其他那些早已不寫 Code 的業界大佬) 一些原本熟練的 API 名稱,突然要多想一下; 思考邏輯的節奏被打斷,肌肉記憶也逐漸消失。 你知道我個人對 AI 輔助開發一直以來的看法, 在絕大部分的情況下,我支持使用 AI 輔助開發遠高於其他人。 為何是「在絕大部分的情況下」呢? 因為,身為一位稍有年資的開發者,我依稀覺得有某個地方怪怪的,但又一直說不上來是哪裡。 直到這次聽到 DHH 的分享,他是第一個明確說出我一直講不出來的那種感受的人,深思後我不得不同意他的觀點。 大量使用 AI輔助開發,特別是最近很紅的 CLI 那種,確實有可能失去開發者特有的 「肌肉記憶」,不只是敲鍵盤的準確度而已,而是某種鍵盤跟大腦之間獨特的聯繫。 如今,大量使用 AI 輔助開發的人, 大多都認為未來開發者的角色將逐漸改變。 從一個「敲打鍵盤的人」,變成一個「溝通者」或「監工者」。 與 AI 溝通、審視 AI 產出、並且進行判斷與修正。 但這樣的轉變,是否也像極了過去許多技術人員,逐漸離開技術轉型成主管的過程? 看似升級,實則在過程中逐漸失去對技術本身的感知與掌握。 當我們不再自己動手,久而久之,是否也會失去「能動手」的能力? DHH 說,那些「自己一行行鑿刻程式碼」的過程,恰好是開發工作樂趣的來源。 當我們在鍵盤上敲下每一個詞彙時,大腦同時也在構建一種獨特的神經迴路 – 那正是開發者創造力與思考能力的來源。 他並不反對 Vibe Coding,只是用一個開發人員的角度給出了提醒...