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 則是團隊共同或個別可查閱的資料庫。
| 元件 | 負責內容 | 提示詞優化案例 |
|---|
| Agent | 角色、目標、模型、工具與行為 | 分析師、改寫者、測試者 |
| Task | 工作描述、輸入、預期輸出與驗收條件 | 找出缺漏、產生新版、比較品質 |
| Crew | 組合 Agent 與 Task 並啟動執行 | 完整的提示詞優化團隊 |
| Process | 決定工作如何安排 | 依序分析、改寫、測試與定稿 |
| Flow | 控制狀態、事件與條件路徑 | 品質不合格時退回重寫 |
| Knowledge | 提供文件、網站或結構化資料 | 提示詞規範與優秀案例 |
| Tool | 讓 Agent 存取外部能力 | 向量檢索、網頁搜尋與評分器 |
提示詞優化 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。
| 需求 | 建議方式 |
|---|
| 研究後寫成報告 | Crew |
| 分析、改寫與交叉審核 | Crew |
| 依分數決定重寫或通過 | Flow |
| 呼叫 API 並等待人工批准 | Flow |
| 完整內容生產管線 | Flow 控制流程，Crew 處理創作 |
如果需要從桌面工作台管理 Agent 專案，也可以參考 OpenWork 與 OpenCode Agent 工作台，比較框架層與操作介面的差異。
我會怎麼重做這套提示詞優化系統
- 先用單一 Agent 加 Knowledge 建立基準版本。
- 定義固定評分表，檢查目標、背景、限制、格式與可驗收性。
- 加入一個獨立測試 Agent，只負責找問題與打分。
- 分數未達門檻時，由 Flow 送回改寫，並限制重試次數。
- 先用 Ollama 小模型跑分析與分類，必要時才把最終改寫交給較強模型。
- 用保留測試集比較原始提示詞與優化結果，不把自我評價當成唯一證據。
這個版本的 Agent 更少，但責任更清楚，也更容易測試。CrewAI 的價值不是替程式多包幾層，而是讓角色、任務、工具、知識與執行順序都能被明確描述。當每個步驟都能觀察、驗證與替換，多 Agent 才真正從展示走向可維護的系統。
官方資源與案例程式碼
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 或遠端向量資料庫。
by Rain Chu | 7 月 8, 2026 | Agent, AI
OpenCode 和 OpenWork 這組工具，真正值得看的地方不是「又一個 Claude Code 替代品」而已，而是它把 AI Agent 從純命令列往桌面工作台推了一步, OpenCode 負責 agentic coding 的核心能力，OpenWork 則把工作目錄、Session、Skill、Plugin、MCP、權限確認和遠端 worker 包成比較容易操作的圖形介面。
這條路線剛好踩在很多人的痛點上：Claude Code 好用，但成本、封閉性和模型選擇會卡住；Codex 很適合開發工作，但一般辦公流程、跨工具流程、團隊共享設定，還需要另一層產品化介面, OpenWork 的企圖就是把 opencode 這套底層能力包成「可以給團隊重複使用的 Agent 工作流」。
如果你之前已經在看 OpenCode 如何使用本地端模型，這篇可以當成下一步：不只讓模型接進來，而是把 skills、plugins、MCP 和權限流程一起整理成可操作的工作台。
OpenWork 是 opencode 的桌面層，不是另一個單純聊天 App
OpenWork 官方把自己定位成 Claude Cowork 和 Codex 的開源替代方案，它是一個 local-first 的桌面 app，背後 powered by opencode 你可以在本機跑 host mode，也可以用 client mode 連到既有 OpenCode server, 之後透過 UI 管理 session、看 streaming event、處理 permission request、管理 templates、安裝 skills 和 plugins。
這個定位很重要。OpenWork 不是要取代 OpenCode，而是把 OpenCode 原本比較偏開發者的 CLI 體驗，變成更像工作台的產品。OpenCode 擅長讀檔、改檔、跑工具、處理任務；OpenWork 則負責讓這些能力變得可視化、可審核、可分享。
這也是我覺得它和 用 AI 組一家公司那篇可以放在一起看：真正有價值的不是單一模型多會回答，而是能不能把一套工作流程產品化，讓人、Agent、工具和權限一起運作。
OpenCode 和 OpenWork 的分工
這兩者的分工：
| 項目 | OpenCode | OpenWork |
|---|
| 核心角色 | AI coding agent 與 CLI/Server 核心 | 桌面工作台與協作介面 |
| 使用者體驗 | 偏工程師、命令列、設定檔 | 偏圖形介面、session、權限與模板 |
| 擴充方式 | plugins、agents、SDK、生態資源 | skills manager、plugins、MCP、templates |
| 適合場景 | 開發、專案自動化、終端機工作流 | 把 Agent 流程包成團隊可重複使用的工作台 |
OpenWork README 裡有一句很關鍵：它是 ejectable 意思是就算 UI 還沒包到某個能力，只要底層 OpenCode 能做，理論上還是可以回到底層去做。這是開源工具很重要的特性，因為你不會被單一 UI 的產品進度完全卡死。
安裝與模式：先分清楚桌面 App、Host mode、Client mode
OpenWork 有幾種使用方式。最直覺的是下載桌面 app；如果你想自己 build，就要準備 Node.js、pnpm、Bun、Rust/Tauri、OpenCode CLI 官方 source build 流程大致是：
git clone https://github.com/different-ai/openwork
cd openwork
git checkout dev
pnpm install --frozen-lockfile
pnpm dev
如果只想跑 CLI host，也可以用 OpenWork Orchestrator：
npm install -g openwork-orchestrator
openwork start --workspace /path/to/workspace --approval auto
這裡要注意一件事：OpenWork 的 Host mode 會在本機跑 host stack，預設綁在 127.0.0.1 Client mode 則是連到既有的 OpenCode server，如果你看到 ready 是灰色、New task 不能按，第一個方向不是懷疑模型，而是檢查工作目錄、host stack、OpenCode server、provider key 或本地模型連線是否真的準備好。
Skills、Plugins、MCP：OpenWork 真正有用的地方
OpenWork 的 Skills manager 可以列出 `.opencode/skills`，也能把本地 skill folder 匯入到 `.opencode/skills/<skill-name>` 這個方向很像 Claude Code / Codex 的 skills 概念：把常用工作流程寫成可重複使用的操作說明，讓 Agent 每次做事不用從零開始猜。
如果你站上看過 用 skill-creator 建立 Skill，OpenWork 這裡的邏輯也很接近：與其每次都寫一長串 prompt，不如把工作流程變成可安裝、可分享、可版本化的能力。
Plugin 則是 OpenCode 的原生擴充方式。OpenWork 會讀寫 `opencode.json`，Project scope 在工作目錄的 `opencode.json`，Global scope 通常在 `~/.config/opencode/opencode.json`。
awesome-opencode 這個 repo 則像是生態目錄，整理了 plugins、themes、agents、projects 和 resources 它不是核心工具，但很適合用來觀察 opencode 生態正在長出哪些周邊能力。
Build Mode 和 Plan Mode：不要一開始就讓 Agent 放手改
OpenCode 這類 agentic tool 最容易出問題的地方，是使用者還沒搞清楚任務邊界，就直接讓 Agent 進入執行狀態。比較穩的做法是先用 Plan Mode 讓它讀資料、拆任務、確認工具與風險，再進 Build Mode 讓它動手。
我會把它想成兩層：
- Plan Mode：先觀察、讀檔、列步驟、找不確定性、提出執行順序。
- Build Mode：開始改檔、跑命令、安裝依賴、呼叫工具、產出結果。
這和 Claude Code Workflow 裡的做法一致：先讓 Agent 把路線講清楚，再授權它動手。
AI Agent 的效率不是靠更衝，而是靠每一步都能回頭檢查。
本地模型與 Ollama：重點在 provider 設定，不是只裝好模型
很多人以為「Ollama 已經能跑模型」就等於 OpenWork 會自動看到它，但中間還差 provider 設定、base URL、模型名稱，以及 OpenCode / OpenWork 讀取設定檔的位置。
原則上，你要確認三件事：
- Ollama server 已經在跑，常見位置是 `http://localhost:11434`，遠端機器則要確定防火牆與 bind address。
- OpenCode 的 provider 設定有指到 Ollama 或 OpenAI-compatible endpoint。
- OpenWork 使用的 workspace / dev-mode / global config，和你實際編輯的設定檔是同一份。
這部分可以搭配 Ollama 遠端連線教學 和 LM Studio 與 Ollama 的零 API 成本環境一起看 OpenWork 不是魔法入口，它還是要靠底層 provider 設定把模型接起來。
Token 成本：免費模型不等於無限使用
免費通常代表某段時間、某個額度、某個服務條款下不用付費，不代表可以無限燒，也不代表 latency、rate limit、上下文長度和品質都沒有代價。
OpenCode / OpenWork 這種工具特別容易消耗 token，因為 Agent 會讀檔、反覆規劃、呼叫工具、看輸出、再修正你讓它處理一個大型 workspace，成本不是只有最後回答那幾百字，而是整個工作循環。
所以比較實際的策略是：
- 簡單查詢與短任務用便宜或本地模型。
- 高風險修改、跨檔案重構、複雜判斷再用強模型。
- 能寫成 skill / template 的流程就固化，減少每次重新解釋。
- 先 Plan 後 Build，避免 Agent 一路試錯燒成本。
Windows 使用者要先注意的幾個坑
Windows 問題不少，這也很符合這類 Tauri / Node / CLI 混合工具的現況。
OpenWork README 也有提到，Windows access 有一部分是透過 paid support plan；source build 則會牽涉 Node、pnpm、Bun、Rust、Tauri 和 OpenCode CLI。這不是一般雙擊安裝就結束的輕工具。
- Ready 灰色：先檢查 host stack 是否啟動、workspace 是否選對、provider 是否可用。
- New task 灰色：通常表示前置狀態未完成，例如沒有有效 session、工作目錄或 worker 尚未 ready。
- nul 檔案問題：Windows 下 `nul` 是特殊裝置名，如果工具誤產生同名檔，刪除會很麻煩。這種問題要優先回報 issue，並避免在重要目錄直接測不穩定版本。
- `.config` 目錄看起來不對：要確認你看的到底是 OpenCode global config、workspace config，還是 dev-mode 隔離狀態。
這裡我會建議用比較保守的方式測：先開一個乾淨測試資料夾，不要直接指到重要專案；先確認 session、provider、permission、簡單讀寫任務都正常，再把 OpenWork 放進真正的工作流程。
OpenWork 適合誰？
OpenWork 現階段比較適合三種人。
- 第一種是想把 OpenCode 圖形化的人。你已經接受 agentic coding，但希望有 session、permission、skills、plugins 的視覺工作台。
- 第二種是想把 Agent 工作流交給團隊的人。Templates、skills、remote sharing 這些能力，重點都是讓流程可以重複與分享。
- 第三種是正在比較 Claude Code、Codex、OpenCode 生態的人。OpenWork 讓 opencode 不只停留在 CLI，而是開始往產品化入口走。
但如果你現在只想要一個穩定、少設定、打開就能工作的辦公 AI，OpenWork 可能還會讓你覺得太工程化。它的價值在於可控與可擴充，不在於完全隱藏複雜度。
資源整理
截至我整理資料時，OpenWork GitHub repo 約 1.6 萬 stars，awesome-opencode 約 8 千多 stars 這代表生態正在被快速關注，但也代表文件、Windows 體驗、plugin 相容性和錯誤處理還會持續變動。用它之前要有「早期開源工具」的心理預期。
OpenWork 把 OpenCode 從工具變成工作台
OpenCode 已經回答了「AI Agent 能不能在 terminal 裡幫我做事」；OpenWork 想回答的是下一題：「這套能力能不能被包成一個可視化、可分享、可審核的工作台？」
現階段最好的用法，是先用 OpenCode 跑穩本地模型、provider、skills 和 plugins，再用 OpenWork 管理 session、權限、template 與團隊共享流程。
OpenWork 的重點不是多一個聊天視窗，而是讓 opencode 的 Agent 能力開始變成「可交付的工作流程」。這會是 2026 年 AI 工具很重要的一條線。
FAQ
OpenWork 是什麼？
OpenWork 是 powered by opencode 的開源桌面工作台，讓使用者在本機或遠端 server 上管理 AI Agent session、skills、plugins、MCP、templates 與權限確認。
OpenWork 和 OpenCode 有什麼差別？
OpenCode 是底層 AI coding agent 與 CLI/Server 核心；OpenWork 是圖形化桌面層，負責把 session、權限、skills、plugins、templates 與工作目錄變得更容易操作。
近期留言