後AI時代的多代理 AI Agent 實作：使用 CrewAI 與 LiteLLM 打造自動化專案程式架構分析

在「後AI時代」，AI Agent 正逐步改變我們對人工智慧的想像。本文從 Generative AI 年會談起，介紹 MCP（Model Context Protocol）、CrewAI 與 LiteLLM 的整合實作，說明如何打造能協作、自主決策的多代理（Multi-Agent）AI 系統。從單一 LLM 到智能協作架構，這正是 AI 演化的新篇章。

前言

前陣子在觀賞2025 Generative AI 年會，聽到有位分享者提到「後AI時代」，為什麼說後AI時代呢，因為AI Agent的概念出現，加上MCP逐漸成熟，前兩年的超大LLM霸主時期不免出現一些小變化，在過去，我們人類先是提出了Auto Regressive，接著整理出大量的訓練語料，接著我們用Text-Generation解決了很多問答、總結的NLP難題，下一步則開始考慮多模態問題，接著需要更多更好的機制來解決Token轉換問題，還要有更多機器來支援算力消耗，屬實不容易，大部分LLM走在一條用單一模型解決所有問題的道路上，但這實在不容易，畢竟很多任務是這樣的，你讓他執行單一任務，他可以做到很精確，像是圖像辨識，CNN幾乎就有了碾壓性的效果，但是你要讓他兼顧幾個不同任務，這是個大課題。

於是就有人想了，那如果我把幾個Model結合起來，會是什麼感覺呢？我先破個梗，如果處理得不好，大概就是以下這種狀況。


這沒亂蓋吧？這張圖要多傳神就有多傳神，更何況他還說出了LLM的特色。


好啦，回歸主題，接著介紹說幾個在本次實作會應用到概念。

AI Agent 是能自主理解任務、規劃步驟、執行行動並根據結果調整策略的概念，結合了大語言模型（LLM）、記憶、工具與回饋機制，能完成多步驟任務。例如自動撰寫報告、分析資料或審查程式碼，不再只是被動回答，而能主動行動。

MCP 是一種標準化協定，用來讓 AI Agent 與工具、資料、記憶庫之間交換上下文與任務資訊。它幫助 Agent 保留任務狀態、共享工具清單、追蹤進度，實現多代理協作，MCP 讓 AI 系統有「記憶」與「任務持續性」。

CrewAI 是一個多代理（Multi-Agent）開發框架，讓開發者能定義多個 AI Agent 角色、任務與互動流程。它支援任務拆解、工具整合與自動協作，可讓不同專長的 Agent 協同完成目標。CrewAI 常用於自動化工作流與智能應用開發。

LiteLLM 是一個開源介面，讓開發者能以統一方式呼叫多個語言模型（如 OpenAI、Google等）。它提供 OpenAI 風格 API、成本管理與模型切換功能，使系統能輕鬆整合不同 LLM，並與框架如 CrewAI 搭配使用。

綜合以上，簡單解釋我們怎麼實現AI Agent：其實MCP本質上很像RPC，透過通訊協議我們可以在程式中任意呼叫不同的LLM，再搭配Crew AI，幫我們實現了簡單定義Agent，Agent應負責的任務，提供流程上的支援，最後完成一套AI Agen的工作流程。


程式內容

Crew AI with AI Angent By LiuChien (Gemini)

Crew AI是一套Python函式庫，讓你可以輕鬆實現AI Agent，如果想搭配更多樣化的LLM，也可以搭配LiteLM。

這個筆記本的程式雖然不多，但卻簡單實現了將一個 Ionic Project從Git下載之後進行解析，並且依照專案架構和相依套件進行解析，判斷目前專案出有什麼重大問題。

接下來我們採用了幾個步驟，為一個專案做健康檢查：

下載專案 分析專案架構 設定Crew AI、LiteLM (這裡設定用Gemini模型) 設定Agent (包含結構專家、依賴判斷專家、重構建議) 設定任務 (分別進行結構、依賴判斷，並給出建議) 開始解析並產出結果

參考資料


ㄧ、安裝Crew AI與其他工具

  1. Langchain
  2. CrewAI
  3. OpenAI
  4. LiteLM

二、設定金鑰

  1. HuggingFace金鑰 (給LiteLM使用)
  2. DeepSeek金鑰

因為我們會用到LiteLM串接HuggingFace上的LLM模型，如果使用的不是HuggingFace上的模型就不需要設定。

三、示範用的Github專案

  1. 一個年久失修，Ionic V1版本為基礎的Hybrid APP專案

四、掃描專案架構

  1. 專案架構和目錄組成
  2. 相依套件組成

五、定義Agent並指定LLM模型

依照以下目標，我們對每個Agent設定了角色、工作目標、背景知識，必要的話也可以切換不同LLM模型一起協作。

  1. 結構分析
  2. 依賴分析
  3. 重構建議

特別注意我們這裡用的是LiteLM，串接HuggingFace上的Text-Generation模型，所以這裡傳入的是指定型位置的字串。 想知道有哪些LLM可以用，可以參閱https://docs.litellm.ai/docs/providers。

六、定義各Agent需要執行的任務

前兩個任務分別是分析專案結構、套件相依問題，並且可以指定任務，第三個任務是重構建議，則可以直接請Agent用前兩個任務總結下去做建議，Crew AI會自動幫你處理上下文，想像一下你就是在一個聊天視窗，分別作以下三個任務的行為。

七、列印出分析結果和建議內容

以下是分析結果和建議內容。


根據您提供的依賴分析結果，專案目前處於一個極度不穩定、過時且充滿潛在風險的狀態。由於缺少實際的程式碼目錄結構文字輸出，我將專注於從技術棧層面提出重構建議與框架層次的模組優化方向。一旦底層技術棧穩定並現代化，上層的業務邏輯模組拆分與優化將能更順利地進行。

以下是具體的重構建議與模組優化方向：

前言：當前專案核心問題概括

目前專案最嚴重的問題是多重、衝突且嚴重過時的框架及套件依賴。這不僅導致專案無法正常運作，也帶來了巨大的安全漏洞、兼容性問題和維護負擔。任何上層的業務模組優化，都必須先建立在一個穩固且現代化的技術基礎之上。

一、核心技術棧重構與現代化 (基石重建)

這是專案最優先且必須執行的重構任務。目標是將整個應用程式升級到一個統一、最新且受到官方支援的技術棧。

  1. Ionic Framework 統一與升級：

    • 問題根源： 同時存在 Ionic 2 (ionic-native), Ionic 4 (@ionic/angular), Ionic 7 (@ionic/core) 的衝突依賴，導致無法正常編譯與運行。
    • 重構建議：
      • 策略： 進行一次徹底的 Ionic Framework 大版本升級。強烈建議直接升級到最新穩定版 Ionic (目前為 Ionic 7 或 Ionic 8 beta)。這將涉及重大變更，但長遠來看是避免未來技術債務的最佳途徑。
      • 具體步驟：
        • 完全移除所有舊的 Ionic 相關套件 (@ionic/angular: ^4.11.13, @ionic/core: ^7.8.6, ionic-native: ^2.9.0)。
        • 安裝最新的 @ionic/angular 和 @ionic/cli 版本。
        • 根據 Ionic 官方升級指南 (例如從 v4 升級到 v5, v5 到 v6, v6 到 v7) 逐步調整程式碼。這可能涉及 Angular 版本、Router 配置、生命週期鉤子、元件用法等變更。
        • 模組優化方向： 升級至現代 Ionic/Angular 版本後，將能充分利用 Angular 的模組化能力（如 NgModule、Standalone Components/APIs），更好地組織應用程式。

  2. 建置系統現代化 (Gulp 移除或升級)：

    • 問題根源： Gulp 3 及其配套插件嚴重過時，可能與新版 Node.js 不兼容，且缺乏維護，存在安全風險。
    • 重構建議：
      • 策略一 (推薦)： 徹底移除 Gulp，轉而使用 Angular CLI 內置的建置系統。對於 Ionic/Angular 專案，Angular CLI 提供了完整的開發、建置、測試工具鏈，性能更優且更易於維護。
      • 策略二 (次選)： 如果專案有極其複雜且難以遷移的 Gulp 任務，則將 Gulp 升級到 Gulp 4，並將所有相關 Gulp 插件 (gulp-concat, gulp-minify-css, gulp-rename 等) 升級到最新穩定版，或替換為現代替代方案 (例如 gulp-clean-css 替代 gulp-minify-css)。
      • 模組優化方向： 現代化的建置系統能更好地支持 Tree Shaking、Lazy Loading 等優化技術，減少打包大小，提高應用程式性能。

  3. Cordova 插件與 ionic-native 統一升級：

    • 問題根源： 大量 Cordova 插件版本過時，且 ionic-native: ^2.9.0 已廢棄，與現有或未來的 Ionic 版本不兼容，帶來安全隱患和運行時不穩定。
    • 重構建議：
      • 策略： 將所有 Cordova 插件和 ionic-native 依賴升級到最新且兼容 AndroidX 的版本。
      • 具體步驟：
        • 移除 ionic-native: ^2.9.0。
        • 對於每個舊的 Cordova 插件 (cordova-plugin-device: ^1.1.7, cordova-plugin-splashscreen: ^4.1.0, cordova-plugin-statusbar: 2.4.2 等)，查找其最新穩定版，並替換為官方維護的 @ionic-native/* 範疇套件 (例如 @ionic-native/device) 和相應的 Cordova 插件版本。
        • 仔細檢查每個插件的 Breaking Changes，並調整程式碼以適應新版本 API。
        • 模組優化方向： 統一使用 @ionic-native/* 套件，可以將裝置相關功能封裝在獨立的服務模組中，例如 DeviceService，提高可重用性和測試性。

  4. AndroidX 兼容性解決方案：

    • 問題根源： 雖然有 cordova-plugin-androidx 和 cordova-plugin-androidx-adapter，但由於其他插件過於老舊，可能仍無法完全兼容。
    • 重構建議： 在完成 Ionic Framework 和所有 Cordova 插件升級後，重新評估並調整 AndroidX 的兼容性。最新的 Cordova 和插件通常會內置 AndroidX 支援，使得這些輔助插件不再必要或需要更新到最新版本。

二、模組結構優化與最佳實踐 (基於 Angular/Ionic 現代化架構)

在完成技術棧的底層重構後，可以開始實施現代化 Angular/Ionic 專案的模組化策略。

  1. 清晰的職責分離 (Separation of Concerns)：

    • 優化方向： 將應用程式的各個層次明確劃分職責，例如：
      • core 模組： 放置應用程式級別的單例服務 (如認證、日誌、核心配置)、Guard、Interceptor 等。這些服務通常在應用程式啟動時載入一次。
      • shared 模組： 放置在多個功能模組中被重用的元件 (Components)、指令 (Directives)、管道 (Pipes) 和輔助服務 (Utility Services)。
      • features 模組： 根據業務功能劃分，每個功能模組包含其特有的頁面、元件、服務和路由。

  2. Angular 特性模組化 (Feature Modules)：

    • 優化方向： 根據主要業務功能，將應用程式拆分為多個獨立的 Angular Feature Modules。
    • 實踐：
      • 例如：AuthModule (處理登入、註冊、忘記密碼), DashboardModule, UserProfileModule, SettingsModule 等。
      • 每個 Feature Module 應具備自己的路由配置，並可實現延遲載入 (Lazy Loading)，以優化應用程式的初始載入時間。
      • 此策略極大地降低了模組間的耦合度，提升了開發效率和可維護性。

  3. 共用元件與服務模組 (SharedModule)：

    • 優化方向： 建立一個 SharedModule 來匯出 (export) 那些在整個應用程式中都會被使用到的元件、指令、管道和常用 Angular Modules (如 CommonModule, FormsModule, IonicModule)。
    • 實踐： 避免在 SharedModule 中提供 (provide) 服務，以防止單例服務被多個延遲載入模組重複實例化。服務應在 CoreModule 或特定的 Feature Module 中提供。

  4. 資料存取抽象模組 (DataModule 或 APIModule)：

    • 優化方向： 將所有與後端 API 互動、資料處理、資料庫存取 (如果應用程式有離線資料庫) 的邏輯集中在一個或幾個特定的模組中。
    • 實踐：
      • 定義統一的 API 服務，例如 UserService, ProductService，這些服務只負責與後端通信和資料轉換，而不包含業務邏輯。
      • 可以使用 HttpClientModule、ngrx/store (如果需要狀態管理) 或其他資料管理庫。
      • 這有助於將後端細節與前端業務邏輯解耦，提高資料層的可測試性和可替換性。

  5. 設定檔模組化 (ConfigModule)：

    • 優化方向： 集中管理應用程式的所有配置設定 (如 API 端點、環境變數、常數)。
    • 實踐： 建立一個 ConfigService 或使用 Angular 的 environment.ts 檔案，確保配置參數在不同環境 (開發、測試、生產) 下能被正確管理和載入。

三、技術債務清理與風險管理

  1. 廢棄套件移除： 清理 package.json，移除所有已明確廢棄或不再使用的套件依賴，減輕專案負擔。
  2. 安全性漏洞修復： 透過升級所有套件到最新版本，修復已知的老舊套件帶來的安全性漏洞。定期使用 npm audit 或類似工具檢查依賴安全問題。
  3. 性能與維護性提升：
    • 採用最新的 Angular/Ionic 功能 (如 Standalone Components, Signals 等)，簡化程式碼，提高執行效能。
    • 精簡打包體積，利用 Tree Shaking 和 Lazy Loading 優化應用程式啟動速度。
    • 確保所有程式碼都符合 Linting 規範 (如 TSLint 或 ESLint)，保持程式碼風格一致性。

四、實施策略建議

由於涉及大規模的技術棧升級，建議採用以下策略：

  1. 階段性重構： 不要試圖一次性升級所有東西。可以先專注於 Ionic Framework 和 Angular 的核心升級，確保應用程式能重新運行，然後再逐步處理 Cordova 插件和 Gulp 移除。
  2. 建立全面的測試： 在開始大規模重構之前，盡可能多的建立現有功能的自動化測試（單元測試、整合測試），以確保在重構過程中不會引入新的錯誤，並能驗證升級後的應用程式行為符合預期。
  3. 版本控制與分支策略： 使用強大的版本控制系統 (如 Git)，並為重構工作建立一個專門的長期分支。頻繁提交並在小階段完成後合併回主分支。
  4. 團隊培訓： 如果團隊成員不熟悉新的 Ionic/Angular 版本和最佳實踐，需要提供相應的培訓。

這個專案的重構是一個巨大的挑戰，但也是一次徹底清理技術債務、提升專案品質和未來可維護性的絕佳機會。

結論

我這次一共實作了 Gemini 和 DeepSeek 兩個版本。整體來說，實作成本並不高，只需要準備好呼叫模型所需的 API 金鑰。

使用不同的 LLM 作為 Agent 是一件很有趣的事。雖然這次的範例中我都採用了相同的 LLM，但實際應用時，依照不同 LLM 的特性進行分工與配置，往往能獲得更佳的效益。文末我也附上了原始碼，大家可以自己試著玩玩看 —— 不過記得要先申請金鑰喔。

以 MCP 的規劃 來看，它的目標並不只是讓 LLM 扮演 RPC 的角色而已。對 AI Agent 而言，最具突破性的能力是「互為 Agent、甚至能相互分享」。這樣的設計讓 AI Agent 的概念再次向前推進一大步。

在不久的將來，AI 的成長速度可能會比我們想像中更快、更強，而我們正親眼見證這段歷史的展開。

留言

張貼留言

這個網誌中的熱門文章

Prompt, Fine-tune 和 Training，誰才是大工程？

圖片
  在機器學習，尤其是自然語言處理（NLP）的世界中，「Prompt」、「Fine-tune」和「Training」是經常出現的三個概念。雖然它們都涉及到模型的學習和調整，但每一個的目的、方法和使用情境都有明顯的不同。我們來仔細了解一下它們之間的區別。 首先，Prompt 是指你給機器學習模型輸入的一個提示或問題。這個提示並不會改變模型本身，而是依賴模型已經學過的知識來生成回答或執行某個任務。你可以把它想像成一個引導詞，模型根據這個提示來給你回應。比如，對於一個語言模型來說，給它一句話「寫一篇關於太空探索的文章」，它就會根據這個提示生成相關的內容。這種方式不需要對模型進行任何訓練或微調，只是利用它已經學過的知識來做預測或生成。 接下來是 Fine-tune，它是指對一個已經預訓練的模型進行進一步的調整，使其更適應某個特定的任務或領域。這時，模型的基本架構和大部分知識已經存在，所謂微調，就是在這個基礎上，根據一個小範圍的資料集進行再訓練。比如，假設你有一個通用的語言模型，然後你希望它能在醫學領域表現得更好，那麼你可以用大量的醫學文獻來微調這個模型。這樣，它就會在理解和處理醫學相關問題時更加精準。 最後，Training 則是指從頭開始訓練一個模型，讓它從大量的資料中學習，並逐漸調整模型的內部參數，使其能夠處理特定任務。這是最基本、最根本的學習過程。對於一個語言模型來說，訓練的過程可能涉及大量的文本資料，從中學習語言結構、語法規則、常識知識等。這個過程通常需要大量的計算資源和時間，因為模型需要處理的是大規模的資料集，而且每次的參數調整都會影響到模型的整體性能。 總結來說，Prompt 是利用現有模型的知識來引導其輸出；Fine-tune 是在預訓練模型的基礎上，進行小範圍的調整來提升特定領域的表現；而 Training 則是從零開始訓練模型，讓它在大量的資料中學習並建立知識庫。三者之間的區別，主要在調整的範圍和深度上。 以下來總結它們的不同： 1. Prompt (提示)     定義：在預訓練的模型上使用一個“提示”或“問題”，來引導模型生成特定的輸出。     範疇：這通常與大規模語言模型（如 GPT 系列）相關，模型在預訓練階段學會了語言結構、知識等，然後用戶可以給它一個“提示”來引發它生成特定類...
閱讀完整內容

用Python實作 Perspective Transformation 透視變換

圖片
主要演算法 通常我們在自然背景拍攝一張照片時，或多或少都會有一些 透視變形 存在，而透視變形是由拍攝和觀看圖像的相對距離決定的，導致遠近特徵的相對比例有變化，產生了彎曲或變形，當然在本例子，我是刻意拍了一張比例歪斜的圖，想要驗證依照公式轉換會得到什麼效果。 依照解決方法，這樣的變形我們可以下列的聯立方程式來表示： ​x = ax’ + by’ + cx’y’ + d y = ex’ + fy’  + gx’y’ + h ​其中x、y為你原始影像的座標系，x’、y’為校正後的座標系， a、b、c、d、e、f、g、h為常數，表示變形關係。 程式片段 定義 高斯消去 2. 先定義4個點，找出矩陣 3. 照公式進行矩陣轉換，解出方程式，輸出結果就得到圖片了。 4. 另外我也參考網路範例，仿造OpenCV寫了一個轉置方法，後續比較一下兩種做法的差異。   測試資料與結果 原圖是張刻意拍歪斜的照片，我標出四個白點，可以看到原始轉換區塊變形到接近菱形了。 2. 轉換後得到的結果如下，或許是因為變形幅度高，沒達到完整的轉換。 3. 參考網路實作 Perspective Transformation 做出來的效果，因為先做3D後轉2D，校正效果很好，只是程式寫得不好，有失真。 4. 使用Open CV做的效果 討論 原本課堂講解的校正來源是一個平行四邊形，校正效果相當好，但在本次作用我使用一個不規則的多邊形來做轉換，雖然轉換結果不比原本的好，但還算可以得出資訊。 參考Perspective Transformation實做出來的程式做轉換，對於不規則多邊形轉換的效果很好，只是有失真，若用OpenCV轉出來的話就趨近完美了。 此類的校正可以應用在機器人自駕時的資訊辨認，或是在OCR應用上先把讀入的圖片做校正，在讀取資訊，可以減少判斷失誤。 在Deepfake影片偵測的研究中，許多論文的原理是把影像的Frame讀入後分析他是不是假造影像；如果在深度學習時，我先把人臉或是指定的擷取特徵做校正，可以把每個Frame的特徵變成一樣的構圖，就有機會分辨出他是不是造假的Frame：因為Frame造假是基於原本扭曲變形的畫面做變更，在校正後應該可以看出他和一般正常角度Frame的不同之處。
閱讀完整內容

這個身分證檢查器是用ChatGPT寫的吧？！

圖片
隨著大語言模型（英語：Large Language Model，LLM）的蓬勃發展，相關的應用越來越多，人們透過大量的資料訓練(Train）出一個一個模型（Model），再用這些模型去產生我們想要的結果，某種程度來講，這些語言模型對我們的工作和生活帶來不少程度的幫助；從最早我們用模型來寫文章，用模型來產生照片，用模型來產生影片，很多人都讚嘆電腦程式的進步，大大的改變了我們的生活，那有沒有有一種可能是，我們也可以用模型來寫程式呢？ 當然用模型來寫程式，未必是下一個指令像「給我一個預測股市走勢的程式」，他就能把你想要的東西都給你，更重要的是我們要告訴他，你想要他為做些什麼？做得對不對？ 你正在做什麼並不重要，重要的是你知道自己正在做什麼。 計畫 接著我們來試著做一個身份證字號的驗證程式，要達到想要的結果之前，其實我們還是要有一些系統性的思考邏輯，先提出構想，完整藍圖，分解功能，再重新組合，套用平時開發程式的步驟，不外乎： 需求收集 系統分析 需求收集 我們想要做一個台灣的身份證號碼驗證器，需要可以輸入任何一組號碼，可以知道號碼的主人是從哪裡來？可以知道號碼的主人是先生還是小姐？我們不想要安裝程式，太麻煩了，還有，希望畫面可以漂亮一點，好用一點。 系統分析 接著我們就來想想，做一下簡單的分析，看看要如何滿足需求； 需要簡單容易使用，我們可以寫成網頁版。 需要畫面好看，雖然好看是一件很主觀的事情，但我們可以用主流的網頁框架。 希望體驗好一點，那連提示訊息都一起改善，至少在不同裝置上用來都差不多。 程式要判斷號碼是否正確，那有沒有計算規則？有什麼標準格式？ 再來我們分別列出對應的解決方法； 美觀問題，我們可以用 Bootstrap ，因為是主流框架，至少能向市場趨勢靠攏；我們也可以用 SweetAlert 套件來改善體驗問題，讓不同裝置的操作感受更一致。 判斷號碼正確性的演算法，我們在 維基百科上找到的中華民國國民身分證相關規則 ，夠我們處理這一次的問題。 程式提供一個介面，可以填寫證件號碼、性別、發證的縣市，來完成基本需求。 寫程式的浪漫...分解再重組，就像玩積木一樣快樂。 開工  做完分析後，我們就可以來做功能開發了，這次我們不找訓練有素的猴子，而是用ChatGPT來完成工作，打開介面後，緩緩地貼上我們的Promt。 寫一個HTML網頁, 使用Bootstrap...
閱讀完整內容