Chickenrice's Workshop

TL;DR Agentic RAG 是 RAG（檢索增強生成）的進階版，它結合「代理人（Agent）」的規劃與判斷能力，能夠將使用者的複雜查詢拆解成多步驟任務，結合資料庫檢索與外部工具呼叫，並具備記憶與學習能力。簡單來說，它讓 LLM 不只會找資料，還會動腦解題、學習改進，能處理更複雜、更實用的問題。 第五堂課的主題是最近非常熱門的一個進階技術概念：「 Agentic RAG 」。這是我學習剛後整理出來的筆記跟心得，希望能幫助大家更好地理解它是什麼、跟基本 RAG 有什麼不同，以及它的實際應用潛力！ RAG 是什麼？ 在介紹 Agentic RAG 之前，先簡單回顧一下 RAG 的基本概念： RAG （Retrieval-Augmented Generation）是一種讓大型語言模型（LLM） 從資料庫中檢索相關資訊，並加進模型的上下文 來回答使用者問題的技術。 這樣的設計能讓 LLM 給出的答案不再只是來自訓練資料，而是結合了最新、最即時的資訊。 影片中提到： 「RAG 能夠讓 LLM 根據使用者查詢，從資料庫中檢索資訊，並加到 context 中以提供更相關的回應。」 那什麼是 Agentic RAG？ Agentic RAG 是在 RAG 基礎上的進化版！它結合了「 代理人 (Agent) 的智慧」來強化整個資訊檢索與回應流程。 查詢分析與規劃 ：Agent 會先分析使用者的問題，並規劃成一連串的任務。 多步驟與多系統處理 ：能夠處理需要經過多個系統、多個步驟才能回答的複雜問題。 資訊驗證與迭代 ：如果第一次檢索結果不足，Agent 會重新發出工具呼叫直到找到答案。 長期記憶 ：Agent 能記住先前的嘗試，避免重複錯誤、越來越聰明！ 影片還開玩笑說：「我其實更想叫它 Adaptive RAG！」 實作技巧：Prompt Augmentation 為了讓 Agent 運作更聰明，可以使用 Prompt Augmentation 技術來加強提示內容。 例如透過設計 PromptPlugin ，在使用者提出查詢後，自動加入更多指示。 這能引導 Agent 先判斷 context 是否足夠，再決定是否呼叫工具函式。 Agentic RAG 的三個實際應用範例 ...

TL;DR 第四課主題開始探討 AI Agent 的「 工具使用設計模式 」（Tool Use Design Pattern）概念，個人覺得這對於理解 Agent 如何透過工具真的與所處的 context 進行互動，並觀察行動之後環境的變化，擬定下一個動作計劃直到完成目標 task 的模式很有幫助 為什麼需要工具？ 我們都知道大型語言模型（LLM）很強大，可以直接生成文字內容來回覆我們的問題。但有些任務，光靠 LLM 自己是做不到的，例如： 查看即時的航班狀態 進行精確的數學計算 查詢最新的客戶資料 這時候，就像人類需要工具一樣，AI Agent 也需要「工具」來完成這些超出它們本身能力的任務。 什麼是工具使用設計模式？ 簡單來說，「 工具使用設計模式 」就是一種方法，它讓大型語言模型 (LLM) 能夠與外部工具互動 。這些工具可以是： 計算機（calculators） API（例如查詢航班狀態的 API） 應用程式內部的特定功能（例如處理貨幣兌換的 function） 透過這個設計模式，AI Agent 就能夠 藉助外部工具來執行或驗證資訊 ，而不僅僅是依賴它自己學到的訓練資料。 學會使用工具的好處（實際應用範例） 學會這個模式，我們的 AI Agent 能做的事情就更多了： 處理資料查詢： Agent 可以使用 生成程式碼的工具 來建立資料庫查詢，從客戶資料庫中取得即時資訊。 與現有系統整合： Agent 可以連接到像 CRM（客戶關係管理系統）這樣的系統，直接回答客戶訂位相關問題， 減少人工介入 。 自動化複雜工作流程： Agent 可以 組合使用不同的工具 來自動化流程，例如處理電子郵件並將資訊轉發， 提高效率 。 工具呼叫的小細節（以 Semantic Kernel 為例） 課程中提到了使用 Semantic Kernel 這個框架來實作工具呼叫。我們學到了一些設定方式： 自動（Auto）： 讓 Agent 自行判斷是否需要呼叫工具函式。 必要（Required）： 根據情境， 強制要求 Agent 呼叫特定函式 。 這些設定讓我們可以依需求更靈活地控制 Agent 的行為。 實際操作：一個旅遊 Agent 的例子...

TL;DR 設計優良 AI Agent 的關鍵在於三個核心原則： 空間 （設計互動環境）、 時間 （考量長期互動關係）、 核心 （擁抱不確定性並提供透明控制）。透過明確說明 Agent 能力、提供使用者控制選項，以及運用具體範例（如旅遊助手），可以提升使用者信任與互動體驗。 第三章筆記：設計優良 AI Agent 的關鍵原則 三大設計原則 1. 空間（Space） Agent 所運作的環境應該設計得能夠連接事件、人物與知識，並且能根據使用者需求靈活切換於前台與後台。 重要應用： 在 UI/UX 設計中，清楚地向使用者說明 Agent 的用途與限制。 這是 Agent 工作所在的環境。在這個空間中，應該專注於連接事件、人物和知識。Agent 應該易於發現，同時能夠根據使用者需求在前台和後台之間切換。 2. 時間（Time） 設計良好的 Agent 應該能隨著時間持續學習與進步，累積與使用者互動的歷史，提供更一致且個人化的回應。 重要應用： 結合過去互動紀錄、實作「反思設計模式」，讓使用者能看到自己的提示歷史。 這是 Agent 隨著時間與使用者互動的方式。這很重要，因為如果我們設計得足夠好，Agent 可以隨著時間改進。 3. 核心（Core） 核心原則在於擁抱不確定性，並透過透明設計與控制選項來建立使用者的信任。 重要應用： 讓使用者像操作影片一樣，擁有開關、暫停、字幕等控制權限。 由於我們允許 LLMs 制定計畫並執行這些計畫，不確定性是 Agent 設計的關鍵部分，透過賦予人類使用者可見的控制和反饋工具來建立信任和透明度在這裡非常重要。 💡 實際應用範例：旅遊 Agent 課程中展示了一個旅遊規劃 Agent 的範例，使用 Semantic Kernel 與 GitHub models。這個範例體現了三大原則的應用： 開場白即自我介紹其功能：規劃度假、一日遊、隨機地點建議等 引導使用者提供進一步資訊（如是否指定地點） 明確聲明自身能力與限制，幫助建立信任 在這種情況下，我們要修改它…以應用我們剛剛談到的設計原則，我們要向使用者明確說明這個 Agent 的能力，並給予它一些建議，說明我們希望看到 Agent 完成哪些互動。 透明度與控制權 來源強調：「好的 Ag...

TL;DR 代理框架是開發 AI 代理的工具集合，協助管理代理的行為、環境脈絡與協作。在這堂課提供了初學者三種微軟的解決方案，可從 Azure AI 代理服務 起步，它提供簡單的單代理整合環境；進階應用可考慮 Semantic Kernel （企業級、支援多語言與模型服務）或 Autogen （研究導向、易於實驗）。實際操作程式碼是理解這些框架最有效的方法。 第二章筆記：探索 Agent Frameworks 什麼是 Agent Frameworks ？ Agent Frameworks 是協助開發人員建構 AI Agent 的工具，讓他們能夠更有效地管理 Agent 的工作、理解環境脈絡、促進 Agent 之間的協作，以及觀察與評估 Agent 的效能。 我們為什麼需要使用 Agent Frameworks ？ Agent Frameworks 能幫助我們更好地控制 AI Agent，特別是在多代理協作完成任務的情境中。它們能管理上下文資訊、決定 Agent 分工、促進溝通與合作，並提供觀察與效能評估工具。 如何選擇合適的 Agent Frameworks ？ 本課程關注的範疇都是微軟底下的解決方案，課程中提到了三種不同的 frameworks 以及其適合應用的情境 Azure AI Agent Service： 適合初學者與單一代理應用，可與 Azure 生態整合。 Semantic Kernel： 企業級框架，支援 C#、Java、Python 等語言，提供模型服務連接器。 Autogen： 研究導向，適合實驗與測試最新代理技術。 建議從簡單的單代理工具（如 Azure）開始，根據需求再轉向支援多代理的進階框架（如 Semantic Kernel 或 Autogen）。 Azure AI Agent Service 的主要特點 目前設計以單一代理為主，透過程式碼或 UI 使用，且能與 Azure 現有服務無縫整合，適合初學者快速上手。 Semantic Kernel 框架重點 專為企業級應用設計，支援多種語言與模型整合，注重開發者體驗，適合生產環境部署。 Autogen 框架特色 由 Microsoft Research 開發，專注於實驗與測試最新代理研究成果，是探索創新概念的好選...

這將會是 AI Agents for beginners 這一系列課程 學習心得的第一篇文章，主要是記錄以學習 AI Agent 新手的角度所習得的內容以及心得收獲 TL;DR AI Agents 是一種具備 理解能力、記憶能力與使用工具能力 的智慧系統，能根據使用者的自然語言指令， 自動規劃與執行任務 。其核心由 大型語言模型（LLM） 、 記憶（短期與長期） 、以及 可操作的外部工具 組成。課程透過一個模擬旅行規劃助手的程式碼示例，展示了 Agent 如何回應使用者需求、學習偏好並調整建議。這是進入 AI 自主應用開發的重要起點。 筆記內容 這份文件是基於 "What are AI agents?" 課程第一課的內容，旨在介紹 AI Agent的基本概念、構成要素以及如何開始建構它們。本課程將帶領學習者從概念到程式碼，涵蓋建構 AI Agent 的基礎知識。 什麼是 AI Agent？ AI Agent是一種能夠識別使用者請求的任務、建立完成該任務的計畫並執行該計畫行動的系統。它們結合了多個關鍵組件，使其能夠進行推理、記憶和利用工具來達成目標。 AI Agent 的核心組成部分： 大型語言模型 (LLM) : LLM 是 AI Agent 推理能力的核心。它負責解析使用者請求，理解任務，並制定執行計畫。課程中提到，LLM 的推理能力包括「識別使用者請求的任務，建立完成該任務的計畫並執行該計畫的行動」。 記憶 (Memory) : 記憶讓 AI Agent 能夠儲存和利用資訊來改進其表現。記憶分為兩種： 短期記憶 (Short-term memory) : 使用者與 Agent 之間的對話上下文，讓 Agent 能夠記住當前的互動狀況。 長期記憶 (Long-term memory) : 資料的集合，讓 Agent 隨時間在完成任務方面有所改進，例如記住使用者偏好。 工具 (Tools) : AI Agent 能夠存取和利用的外部資源或功能，以執行特定行動，例如： 透過 API 存取的服務 幫助確定採取何種行動的資料 用於向 Agent 傳送資訊的功能 AI Agent 如何運作...

AlphaEvolve 所面對的是極為廣闊的演算法搜尋空間。DeepMind 指出，現在的大型語言模型（LLM）已能解決複雜的數學與計算問題；AlphaEvolve 就是在這個空間中不斷嘗試、篩選，找出最優解。換句話說，AI 不再只是幫忙補寫簡單程式碼，而是已經進入能「跨領域探索並優化複雜演算法」的新時代。 什麼是 AlphaEvolve？ AlphaEvolve 可以想像成一位虛擬的「資深工程師」，專門用來產生、優化演算法。它是由 DeepMind 所開發，核心技術來自 Gemini 系列的大型語言模型，搭配自動化測試與評估流程，採用類似「自然演化」的概念來改善程式碼品質。 與早期只能幫忙寫簡單函式的 AI 不同，AlphaEvolve 能 主動探索並優化整段程式碼 ，甚至開發全新的演算法架構。它同時運用多個模型，包括 Gemini Flash 負責快速產生各種可能的解法，而更強大的 Gemini Pro 則提供深入見解與分析建議，兩者協同運作，就像創意團隊一樣。 AlphaEvolve 是怎麼運作的？ AlphaEvolve 的工作流程大致可以分為以下幾個步驟： 先輸入 原始程式碼 （可以是空白模板或部分初始版本）與 評估標準 （用來判斷解法好壞的測試機制）。 由 Gemini 模型 產生多個程式碼變體 ，類似一次生出很多「候選解」。 每個版本都會送進 自動評估系統 執行測試，根據正確性、效能等指標評分。 表現最好的版本會被留下，成為下一輪「繁衍」的基礎，繼續讓模型加以優化。 整個過程可以類比成「人工演化」：就像農夫選育植物或動物，每一代都挑選最優秀的個體。AlphaEvolve 透過「產生 → 測試 → 篩選 → 再產生」的循環，逐步找出最理想的演算法。 未來對軟體開發的影響 大幅提升效能： AlphaEvolve 曾為 Google 資料中心的排程系統設計新演算法，使全球運算資源使用率提升約 0.7%；也優化了 Gemini 訓練所用的矩陣運算程式碼，提升 23% 執行速度。 開發者角色升級： AlphaEvolve 產出的程式碼 具備可讀性 ，讓開發者可以像閱讀同事的程式一樣理解與修改它，AI 不再是黑盒，而是合作的夥伴。 激發前所未有的創新： AI 曾打破矩陣乘法長...

在 React 中，條件渲染（Conditional Rendering）是根據狀態或條件來決定是否顯示某些 UI 元素的核心技術。對於新手而言，這個概念看似簡單，但實作時常會遇到一些陷阱。本文將介紹常見的錯誤類型，並提供最佳實踐建議，幫助你寫出更穩定、可讀性更高的程式碼。 常見錯誤一：錯誤地比較字串與布林值 問題描述 當從 sessionStorage 或 localStorage 中取得布林值時，這些值實際上是字串類型（例如 'true' 或 'false' ）。若直接將其與布林值比較，會導致條件判斷錯誤。 錯誤範例 即使回傳的是 'false' ， Boolean('false') 還是會是 true ，因為非空字串在 JavaScript 中是 truthy。 正確寫法 常見錯誤二：在自訂元件中提前評估 children 問題描述 React 會在渲染父元件時先評估 children ，這會導致即使條件為 false ，仍有程式碼被執行，造成錯誤。 錯誤範例 正確寫法 常見錯誤三：條件渲染語法錯誤 錯誤範例 正確寫法 常見錯誤四：錯誤地使用數字當作布林值渲染 問題描述 React JSX 中 0 不會被當成布林值忽略，而是會直接渲染成字元 0 。 錯誤範例 正確寫法 最佳實踐建議 守衛條件（Guard Clause） ：避免巢狀邏輯 將條件放在 map 外層 ： 多重條件使用 switch ： 總結 條件渲染是 React 開發中不可或缺的一部分，掌握正確的使用方式能避免許多常見錯誤。以下是本文的重點整理： ✅ 明確比較值的類型 ：避免將字串與布林值直接比較。 ✅ 避免提前評估 children ：使用 Render Props 控制渲染時機。 ✅ 遵守 JSX 語法規則 ：條件渲染的表達式要包在合法結構中。 ✅ 數字不是布林值 ： 0 在 JSX 中會被渲染出來，要特別處理。 ✅ 使用守衛條件與清晰結構 ：讓程式碼更穩定、可維護。 希望這篇文章能幫助你在 React 的條...

在 React 的 JSX 中直接使用傳統的 for 迴圈會導致語法錯誤，因為 JSX 本質上是將標記轉換成函式呼叫。以下列出一般常用的三種方式：先在渲染前組裝陣列、使用陣列的 map() 、以及利用 ES6 陣列工具（如 Array.from 、展開運算符等）產生陣列後再 map() 。這些方式都能生成多個元件，適合不同的使用情境。 方法一：使用 for 迴圈 說明與使用情境： 可以先在 render 函式或組件外部使用傳統 for 迴圈建立一個元件陣列，然後將該陣列插入到 JSX 中。這種方式彈性高，適合根據計數或條件逐一產生元件的情境。請注意，每個元素都要設置唯一的 key 屬性以符合 React 列表的需求。 範例（TypeScript）： 優點： 清楚簡單，使用熟悉的 for 迴圈邏輯，直觀易懂。 允許在每次迴圈中使用複雜邏輯或條件，適合需要逐一累加元素的情況。 缺點： 程式碼較冗長，缺乏宣告式 (declarative) 的美感。 對於有資料陣列的情況較不直觀，需手動管理元素索引。 方法二：使用陣列的 map() 說明與使用情境： 如果已有一個包含資料的陣列，可以直接在 JSX 中對該陣列使用 map() 方法，將每個資料項目映射成一個元件。這是最常見做法，偏 functional programming 風格，程式碼簡潔。一般用於從伺服器或 state/props 傳來的資料陣列渲染列表時，非常方便。 範例（TypeScript）： 優點： 簡潔明瞭，一行 map() 就可處理整個陣列，程式更具宣告式。 避免手動建立額外陣列，直接回傳新陣列。 缺點： 對初學者來說，箭頭函式或回呼函式語法可能稍微陌生。 如果資料原本不是陣列 (例如只有數字 N)，就必須先生成一個陣列才能使用此法。 方法三：使用  from 、spread operator 或  fill  + map() 說明與使用情境： 當你只知道要重複產生元件的次數，但沒有現成資料陣列時，可以先用 ES6 的陣列工具來生成一個指定長度的暫時陣列，再用 map() 建立元件。常見做法包括： Array.from({ length: count }) 、ES6 展開運算符 ...[Ar...