發表文章

設定 MCP Server 發生 spawn npx ENOENT spawn npx ENOENT 的解決方法

在前端開發日常中, nvm(Node Version Manager) 是不可或缺的工具之一。它讓我們可以在多個 Node.js 專案之間快速切換版本,保持每個專案的相容性與穩定性。 不過,當我最近嘗試安裝 Figma Context Mcp 的 server 時,卻因為使用了 nvm 而遇到了一個讓人摸不著頭緒的錯誤: spawn npx ENOENT spawn npx ENOENT。 🔍 問題根本原因(Root Cause) MCP server 在啟動時會使用 Python 或桌面應用透過 child_process.spawn 的方式呼叫 Node.js 子進程。不過,這種呼叫方式不會載入使用者 shell 的 PATH 設定。 若你是透過 nvm 安裝 Node.js, node 與 npx 的路徑(如 ~/.nvm/versions/node/... )不會自動被納入 PATH,導致 MCP 在啟動時找不到正確的 Node 環境。 簡單來說: nvm 下的 node 不在應用程式能看到的 PATH 中,導致執行 npx 時出現 ENOENT 錯誤。 ✅ 可行解決方案 方案一:不用 npx,直接指定完整路徑 將需要啟動的 MCP server 套件安裝為全域模組,然後在設定檔中,改為直接指定 node 執行檔與腳本的完整路徑: 這樣一來就能完全繞過 npx,在無需依賴 PATH 的情況下正確執行 MCP server。 如果想知道 node 安裝路徑,可以善用 where 指令 方案二:讓 Node 被系統找到 如果你仍希望使用 npx ,那就必須讓桌面應用或 subprocess 找得到 Node 的執行檔。方法有兩種: 建立 symlink: 將 nvm 安裝的 Node 建立連結到系統路徑中,例如: 這樣可讓任何 subprocess 或應用程式在沒有 shell 的情況下,仍能找到正確的 Node 執行檔。 改用 Homebrew 安裝 Node: 有使用者移除 nvm 改用 Homebrew 安裝 Node.js,因其安裝在 /opt/homebrew/bin 這類系統預設路徑,MCP s...

[筆記] AI agents for beginners 第九課: Metacognition Design Pattern 課後心得

圖片
Metacognition Design Pattern:AI 自我反思的力量 TL;DR 本篇文章介紹 AI 中的「後設認知設計模式」,即讓 AI Agent 具備「思考關於思考」的能力,能記錄使用者偏好、分析自身決策並隨時間持續改進。透過機票預訂的範例與程式碼展示,說明如何實作出能記憶、反思並適應不同情境與需求的智能代理。 摘要 這份簡報文件基於「How can AI agents improve?」的影片與課程內容,深入探討後設認知(Metacognition)在 AI Agent 提升能力中的核心角色。後設認知使 Agent 能夠自我反思、自我調整,提升透明性、適應性與決策品質,特別適用於需要理解上下文與長期偏好的場景。 後設認知的定義與應用 定義: 「思考關於思考」,即讓 AI 不只反應輸入,還能反思自己的運作與回應邏輯。 應用: AI 可藉由數據與分析,識別錯誤、優化決策與規劃。 “AI agents can use data and analysis to identify errors and make improvements in its planning and responses.” 後設認知對 AI Agent 的優勢 持續進化: 從使用者互動中學習、修正並成長。 推理透明: 能表達其決策依據,更容易讓使用者信任。 適應環境: 可根據使用情境動態調整策略。 “It allows agentic systems to be more transparent on its reasoning and decision making… making it more adaptable.” ✈️ 實例:預訂機票的後設認知應用 課程中以「幫我預訂最佳航班」為例,說明後設認知如何協助 AI 理解並持續考量使用者偏好(如價格、時間、航空公司等)作為決策依據。 “Metacognition comes into play… enabling the agent to reflect on this decision of how it’s defining the best flight.” 程式碼範例:追蹤客戶偏好 Agent 內部維護 customerPreference...

[筆記] AI agents for beginners 第八課: How to use a multi-AI agent system 課後心得

圖片
TL;DR 這篇文章介紹 Multiple Agent AI System 的概念與應用方式,說明在單一 AI 難以處理複雜任務時,如何透過多個角色明確的 AI 協同完成目標。文中涵蓋三種設計模式(群組聊天、任務移交、協同過濾),並以「前台建議者 + 禮賓審核者」的範例,示範如何透過角色分工與對話控制,提高 AI 輸出的品質與真實感。 文件來源: 擷取自「如何使用多 AI 代理系統」影片與相關課程資源 核心主題 本來源詳細探討了在人工智慧應用中採用多個 AI 代理(agent)協同工作的設計模式,以及這種模式的優勢、不同類型和實作範例。 主要概念與事實 多代理設計模式的定義 多代理設計模式是指「多個 AI Agent 一起工作以完成一個共同目標或任務」。 "to put it simply the multi agent design pattern is where we have multiple AI agents working together to complete a common goal or task" 使用多代理的時機 當單一 AI 代理不足以有效率或全面地完成複雜任務時,可以考慮使用多代理系統。多代理系統能提供更精煉或多角度的結果,例如透過協作或審查機制。 多代理系統的控制與可見性 多代理系統中存在控制對話流程和選擇代理的機制,例如: Termination function(終止函數) :定義代理之間互動結束的條件,例如當特定代理批准了結果時。 Selection process(選擇過程) :定義對話如何進行,例如輪流發言或根據規則選擇發言者。 不同的多代理設計模式 Group Chat (群組聊天) 類似人類的群組聊天,每條訊息廣播給所有代理。通常由一個 group chat manager (通常是另一個 AI 代理)來選擇處理任務的代理。 應用範例: 航空客服應用,有專門處理訂位、客訴或航班狀態查詢的代理,將顧客訊息路由至正確代理。 "there is group chat where just like a group chat with your friends and colleague...

[筆記] AI agents for beginners 第七課: What Is the AI Agent Planning Design Pattern 課後心得

圖片
TL;DR 這堂課講解了讓 AI Agent 更聰明處理複雜任務的方法,叫做「 規劃設計模式(Planning Design Pattern) 」。 簡單來說,就是讓 AI 把一件大事(像是規劃整趟旅行)分解成很多小任務(訂機票、找住宿、排行程…),然後每一小段都可以自己處理,甚至交給不同的 Agent 幫忙。這樣不只更有邏輯,還能讓整體流程自動化又可控! 本章的要點如下: ✅ 讓 AI 學會「規劃」和「分工」,不再是一個指令只做一件事的單工思維 ✅ 使用工具像 Pydantic 來結構化輸出,讓每個步驟都清楚可交棒 ✅ 加入「驗證機制」,確保 AI 輸出的內容完整又符合格式 ✅ 最酷的是,LLM 還可以理解「家庭友善」這種模糊條件,把人類的語意變成具體任務! 概要 本章說明了一種讓 AI Agent 有能力處理複雜任務的方式: 規劃設計模式 (Planning Design Pattern)。它的核心概念是把大型任務分解為更小、可管理的子任務,進而交由不同 Agent 或流程來執行,提升效率與可靠性。 核心概念與重點 規劃設計模式的定義與功能 讓 AI 能夠理解任務的整體結構,拆解為可執行的步驟 來源指出:「規劃設計模式使這一點更加清晰,透過讓 AI Agent 列出構成更複雜任務的子任務。」 複雜任務 → 子任務範例 例如:規劃 3 天的度假行程可拆分為: 預訂機票 訂飯店 安排交通 設計每日活動 多 Agent 協作 當系統中有多個 Agent,可以分頭處理子任務,效率更高。 來源說:「這真的有影響力的是與多個 Agents 協作... 子任務由不同 Agent 或流程完成。」 結構化輸出 + 驗證 輸出格式可以使用 JSON 或透過工具如 Pydantic 處理 這使資料可以交由下游的 Agent、流程、工具等繼續處理 結構化輸出 + 驗證機制 → 提高準確性與可持續運作 使用 Pydantic 進行結構定義 可定義: 任務清單 每個子任務所屬的 Agent 每項任務需要的欄位格式與驗證條件 LLM 的加值能力 不像傳統 API 調用,LL...

[筆記] AI agents for beginners 第六課: How to build effective AI agents 課後心得

圖片
TL;DR 建立有效 AI 代理的 3 大關鍵: 1. 系統訊息框架(System Message Framework): 以清楚可擴展的方式定義 AI 代理的角色、語氣與行為,並透過 LLM 生成具體系統訊息,讓提示設計變得更可控、更易迭代。 2. 人機協作架構(Human-in-the-Loop): 在 AI 執行關鍵任務前加入人類批准或介入機制,讓代理更可靠,尤其適合多代理協作的應用情境。 3. 安全與隱私考量: 開發 AI Agent 時需評估潛在安全風險與用戶資料保護,雖影片中僅略提,但書面章節中有更完整內容。 簡而言之,透過 系統化設計提示 、 納入人類監督 與 關注資料安全 ,才能打造真正 可信賴又有效的 AI Agent 。 核心主題: 本課程探討了建立有效且值得信賴的 AI Agent的關鍵方法,特別著重於以下三個方面: 系統訊息框架 (System Message Framework) 人機協作架構 (Human in the Loop Architecture) 安全性與隱私 主要觀點和重要事實: 系統訊息的重要性: 「系統訊息是我們作為 AI Agent 創建者在處理 LLM 時可以產生最大影響和控制的地方之一。」它對於設定清晰的指令至關重要,以確保 AI Agent 執行我們期望的操作。 系統訊息框架的工作原理: 這個框架的核心是使用一個基本的系統訊息作為輸入,然後由一個經過特別設定的 LLM(擁有用於生成系統訊息的模板)來生成一個更詳細和具體的系統訊息。這個生成的系統訊息會涵蓋代理的「職責、語氣、風格、互動指令以及任何額外說明。」 迭代式提示設計: 「在開發 Agent 時,尤其是在處理更複雜的場景時,很少能在第一次、第二次甚至第三次就獲得完美的提示。」提示設計是一個迭代的過程,系統訊息框架允許通過修改生成模板來更有效地進行迭代,從而提高所有代理的效能。 系統訊息框架的優勢: 可擴展性 (Scalable) 和可重複性 (Repeatable): 使生成提示的過程更有效率。 提高提示品質: 生成的系統訊息更清晰、更具體。 簡化迭代過程: 輕鬆調整模板,進而改進所有代理的提示。 人機協作的需求: 「在處理任務的過程,您可能會建立需要人類批准或介入...

[筆記] AI agents for beginners 第五課: What Is agentic RAG 課後心得

圖片
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 的三個實際應用範例 ...

[筆記] AI agents for beginners 第四課: What Is the Agent Tool Use Design Pattern 課後心得

圖片
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 的例子...