CrewAI 是什麼？多 Agent 與 RAG 框架完整解析

by Rain Chu | 7 月 28, 2026 | Agent, AI

CrewAI 不是一個大語言模型，而是一套用來編排 AI Agent 的 Python 框架，它把一個複雜任務拆成不同角色，再透過 Task、Process 與 Crew 控制合作方式。模型負責思考，工具負責行動，知識庫負責補充事實，而 CrewAI 負責讓這些元件按照可理解的流程運作。

提示詞優化是一個很適合理解 CrewAI 的案例，只要把工作拆成分析、改寫、測試與最終審核，就能看見多 Agent 的價值，也能看見它的代價，Agent 數量增加後，模型呼叫、檢索次數、延遲與費用都會一起增加。真正重要的不是組一支看起來很熱鬧的 AI 團隊，而是讓每個角色都有不可取代的責任。

CrewAI 是什麼

CrewAI 是獨立開發的多 Agent 自動化框架，不依賴 LangChain，官方把主要能力分成 Crews 與 Flows，Crews 適合需要角色分工、探索與協作的任務，Flows 適合需要明確順序、狀態、條件分支與可稽核結果的工作流。

可以把它想成一間小型公司，Crew 是團隊，Agent 是成員，Task 是工作單，Process 是工作順序，Tool 是成員可以使用的工具。Knowledge 則是團隊共同或個別可查閱的資料庫。

提示詞優化 Crew 的完整架構

使用者輸入原始需求
        ↓
RAG 檢索提示詞規範與案例
        ↓
Prompt Analyzer 找出目標、限制與缺漏
        ↓
Prompt Optimizer 建立第一版完整提示詞
        ↓
Prompt Tester 以驗收標準比較品質
        ↓
Ultimate Optimizer 整合修正並輸出定稿

這種設計的關鍵是讓每個 Agent 產生下一個 Task 能直接使用的結果，分析師不應只給模糊評論，而要輸出結構化問題清單，改寫者要根據問題清單產生完整版本，測試者要使用固定量表，而不是憑感覺說新版比較好，最後的審核者只整合已確認的修正，不再任意改變需求。

若要進一步降低漂移，可以用 Pydantic 或 JSON 結構固定每一階段的輸出。這比單純增加角色背景故事更有效，因為下一個步驟能明確知道要讀取哪些欄位。

四個 Agent 不一定比兩個好

分析、優化、測試與最終優化看起來很完整，但每個角色都使用大型模型，還在每一階段重複查詢向量資料庫時，成本很容易放大。對簡單提示詞而言，分析與改寫可以由同一個 Agent 完成，再保留一個獨立測試 Agent，就已經有清楚的製作與驗收分工。

• 保留不同 Agent，當兩個角色需要不同工具、不同權限或不同模型時。
• 合併 Agent，當工作只是同一段文字的連續改寫時。
• 改用一般函式，當步驟不需要推理，只是格式轉換或資料驗證時。
• 改用 Flow，當流程需要條件分支、重試、人工確認與狀態保存時。

RAG 在 CrewAI 裡負責什麼

RAG 的用途不是替 Agent 增加想像力，而是讓它在執行任務前找到可靠的參考資料，提示詞優化系統可以把提示詞指南、優秀範例、品牌規範與輸出格式放進知識庫。使用者送出需求後，系統只取回最相關的片段，再讓 Agent 根據這些內容工作。

2024 年的實作組合是 Phidata、pgvector 與 OpenAI Embedding，Phidata 現在已改名為 Agno，如果要維護舊專案，應先確認套件名稱與匯入路徑，不宜直接照搬舊版命令。

目前 CrewAI 已有內建 Knowledge，可讀取文字、PDF、CSV、Excel、JSON 與網站內容，官方的 provider-neutral RAG client 預設使用 ChromaDB，也支援 Qdrant，若既有系統已使用 PostgreSQL，仍可把 pgvector 封裝成自訂 Tool，若只是做第一個原型，先用內建 Knowledge 通常更省事。

想理解本地檢索的完整取捨，可以搭配 GraphRAG 使用本地 Ollama，若知識來源主要是專案文件與程式碼，OpenWiki 建立 Agent 共用知識庫也很適合一起比較。

先用 RAG，不要急著訓練模型

手上有大量人工撰寫的中英文檢索式或高品質提示詞時，第一步不一定是微調。先把資料清理成「需求、上下文、限制、輸入範例、理想輸出」的成對資料，再用 RAG 找相似案例，通常能更快驗證需求。

• 先建立測試集，保留一批資料完全不進知識庫。
• 用 RAG 加單一 Agent 建立基準結果。
• 加入獨立評分 Agent，比較正確性、完整性與格式。
• 只有在格式高度穩定、資料量充足且 RAG 已到瓶頸時，再評估微調。

這樣做的好處是資料更新不必重新訓練，錯誤案例也能快速撤換。若資料彼此關聯複雜，還可以參考 Graphify 知識圖譜，評估是否需要從純向量檢索進一步加入實體與關係。

CrewAI 2026 最新安裝方式

截至 2026 年 7 月，官方文件要求 Python 3.10 以上且低於 3.14，並建議使用 uv 管理套件。CrewAI 現在預設建立 JSON-first 專案，Agent 放在 agents/*.jsonc，Task 與 Crew 設定放在 crew.jsonc。若需要早期常見的 Python 與 YAML 結構，才使用 --classic。

uv tool install crewai
uv tool update-shell

crewai create crew prompt_optimizer
cd prompt_optimizer
crewai install
crewai run

建立後會看到 crew.jsonc、agents/、knowledge/、skills/ 與 tools/。這個結構已經把多數需求放進設定檔，適合先從角色與任務定義開始，再加入自訂 Python Tool。

需要舊版 Python 與 YAML 專案時

crewai create crew prompt_optimizer --classic

舊版教學常出現 crew.py、agents.yaml 與 tasks.yaml，這些概念仍然有效，但預設腳手架已經不同。遇到匯入錯誤時，先確認 CrewAI 版本，再對照該版本官方文件。

CrewAI 如何連接 Ollama

CrewAI 不限定 OpenAI 或 Anthropic。官方文件提供 Ollama 設定，只要在 Agent 指定 LLM 與 base_url 即可。這能把多數推理留在本地端，避免每個 Agent 都產生雲端 API 費用。

from crewai import Agent, LLM

local_llm = LLM(
    model="ollama/qwen3:8b",
    base_url="http://localhost:11434"
)

analyzer = Agent(
    role="提示詞分析師",
    goal="找出需求缺漏並建立清楚的改寫規格",
    backstory="你擅長把模糊需求拆成可驗收的條件",
    llm=local_llm
)

如果 Ollama 在另一台主機，把網址換成實際內網位置即可。部署前要確認 Ollama 有對區域網路監聽、防火牆已開放，而且 CrewAI 使用的模型名稱與 ollama list 完全一致。選擇模型時可以參考 本地大模型推理框架比較。

Docker 與硬體需求怎麼看

Docker Desktop 不是 CrewAI 的必要條件。早期範例需要 Docker，是因為它用容器啟動 PostgreSQL 與 pgvector。Linux 伺服器可以直接使用 Docker Engine，也可以把 PostgreSQL 安裝成系統服務。若改用 CrewAI 內建 Knowledge 與本地 ChromaDB，第一版甚至不一定需要 Docker。

一般筆電可以執行 CrewAI，因為框架本身不重。真正決定硬體需求的是模型、Embedding、向量資料庫與同時執行的 Agent 數量。雲端模型加本地向量庫的門檻最低。本地模型則要依參數量、量化格式與上下文長度準備足夠的記憶體或顯示記憶體。

成本最高的地方不是框架

CrewAI 開源框架本身不是主要成本。費用通常來自每個 Agent 的模型呼叫、反覆 RAG 檢索、長上下文、Embedding 建庫與失敗重試。四個 Agent 各自檢索並呼叫一次大型模型，很可能比單一 Agent 加一次驗收多出數倍費用。

• 讓檢索結果在同一輪工作流中共用，不要每個 Agent 重複搜尋。
• 分類、格式檢查與簡單摘要改用小模型。
• 昂貴模型只負責最終改寫或高風險判斷。
• 為 Task 設定清楚的 expected output、guardrail 與最大重試次數。
• 保存每次輸入、檢索片段、輸出與評分，才能知道錢花在哪裡。

Crews 與 Flows 應該怎麼選

若任務需要研究、創作、分析與不同專業觀點，使用 Crew。若工作需要固定順序、條件分流、錯誤重試、人工核准與狀態恢復，使用 Flow。正式系統通常會把兩者結合，由 Flow 控制整體流程，只在需要推理的節點呼叫 Crew。

如果需要從桌面工作台管理 Agent 專案，也可以參考 OpenWork 與 OpenCode Agent 工作台，比較框架層與操作介面的差異。

我會怎麼重做這套提示詞優化系統

1. 先用單一 Agent 加 Knowledge 建立基準版本。
2. 定義固定評分表，檢查目標、背景、限制、格式與可驗收性。
3. 加入一個獨立測試 Agent，只負責找問題與打分。
4. 分數未達門檻時，由 Flow 送回改寫，並限制重試次數。
5. 先用 Ollama 小模型跑分析與分類，必要時才把最終改寫交給較強模型。
6. 用保留測試集比較原始提示詞與優化結果，不把自我評價當成唯一證據。

這個版本的 Agent 更少，但責任更清楚，也更容易測試。CrewAI 的價值不是替程式多包幾層，而是讓角色、任務、工具、知識與執行順序都能被明確描述。當每個步驟都能觀察、驗證與替換，多 Agent 才真正從展示走向可維護的系統。

官方資源與案例程式碼

• CrewAI 官方文件
• CrewAI GitHub
• CrewAI 安裝說明
• CrewAI 連接 Ollama 與其他模型
• 提示詞優化案例程式碼
• AI超元域開源專案

FAQ

CrewAI 是模型還是框架

CrewAI 是多 Agent 編排框架。它負責組織 Agent、Task、Process、Tool、Knowledge 與 Flow，實際推理由 OpenAI、Anthropic、Ollama 或其他模型提供。

CrewAI 可以完全使用本地模型嗎

可以。Agent 的 LLM 可指向 Ollama，也能連接其他 OpenAI 相容端點。若 Embedding 與知識庫也改用本地方案，就能大幅降低雲端 API 成本。

Crew 和 Flow 有什麼差別

Crew 強調角色分工與自主協作。Flow 強調精確的執行路徑、狀態、條件分支與可恢復性。正式系統常用 Flow 管理整體流程，再把需要創作或分析的工作交給 Crew。

建立提示詞優化工具需要微調模型嗎

通常不需要先微調。先用 RAG 提供規範與案例，再建立獨立測試集評估品質。只有資料格式穩定、數量足夠，而且 RAG 已無法改善時，才值得評估微調。

使用 CrewAI 一定要安裝 Docker Desktop 嗎

不一定。Docker Desktop 只是啟動 pgvector 的方便方式。CrewAI 本身不依賴 Docker，Linux 可以使用 Docker Engine，也能改用本機 ChromaDB 或遠端向量資料庫。