https://yennj12.js.org/yennj12_blog_V4/tags/crewai/Recent content in Crewai on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSat, 04 Jul 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/crewai-series-part1-introduction-zh/Thu, 21 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/crewai-series-part1-introduction-zh/前言 你有沒有遇過這樣的情境？ 你想讓 AI 幫你完成一個任務，但任務太複雜，單一的 ChatGPT 對話沒辦法做好： 需要同時搜尋網路、分析資料、寫報告 不同步驟需要不同的「專業角色」 任務很長，單一 context window 放不下 CrewAI 就是為了解決這個問題而生的。它讓你可以建立一個由多個 AI Agent 組成的團隊，每個 Agent 有自己的角色、工具和目標，協作完成複雜任務。 什麼是 CrewAI？ CrewAI 是一個開源的 Python 框架，專門用來建立多 Agent 協作系統。 用一個類比來說： 傳統 LLM 呼叫：你問一個全才顧問所有問題 CrewAI：你僱用一個團隊——研究員、分析師、文案、專案經理——各司其職 CrewAI 的核心理念是角色扮演 + 任務分工： 每個 Agent 有明確的職責（role）、目標（goal）、背景故事（backstory） 任務按照依賴關係自動排序和傳遞 Crew 負責協調整個流程 CrewAI vs 其他 Multi-Agent 框架 框架 特點 學習曲線 CrewAI 角色扮演導向，強調協作，設定直覺 低 LangGraph 圖形化流程，狀態機，彈性高 中高 AutoGen Microsoft 出品，對話式協作 中 LangChain Agents 工具豐富，但單 Agent 中 CrewAI 的設計哲學：讓非工程師也能理解 Agent 的邏輯（因為你在描述一個「團隊」，而不是寫演算法）。https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part2-agent-zh/Sat, 30 May 2026 10:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part2-agent-zh/RAG 是知識，Agent 是行動。 FDE 的工作常常是兩者都要。 Agent 面試的考點不是「你能不能架起來」， 而是「你知不知道它什麼時候會出問題，以及出了問題你怎麼設計讓它不失控」。 面試情境 面試官：「請設計一個 AI 客服系統，能夠查詢訂單狀態、回答 FAQ、在必要時轉接人工客服。然後告訴我：你的 Agent 如果陷入無限循環，你的架構怎麼防止它失控？」 一、Agent 的本質：LLM + Tools + Loop 用一句話說： Agent = LLM + Tools + Loop LLM 負責決策，Tools 負責執行，Loop 讓它反覆思考直到完成任務。 最主流的 Loop 模式叫 ReAct（Reasoning + Acting）： 用戶：「我的訂單 #456 到了嗎？」 │ ▼ Thought：「我需要查 CRM 確認訂單狀態」 │ ▼ Action：call_tool("get_order", order_id="456") │ ▼ Observation：「訂單 #456 狀態：出貨中，預計明天到達」 │ ▼ Thought：「我已經有答案了，可以回覆用戶」 │ ▼ Action：final_answer("您的訂單 #456 目前正在出貨，預計明天到達") Reason → Act → Observe → 再 Reason，這個循環一直跑到任務完成或觸發終止條件。https://yennj12.js.org/yennj12_blog_V4/posts/ai-fde-essential-guide-part2-zh/Tue, 26 May 2026 16:55:10 +0900https://yennj12.js.org/yennj12_blog_V4/posts/ai-fde-essential-guide-part2-zh/前言 多智慧體系統是現代 AI 應用的重要發展方向，能夠處理複雜的企業級任務。作為 AI FDE，掌握多智慧體框架的設計與實作是核心技能之一。本文將深入探討 LangGraph、CrewAI 等主流框架，以及 Model Context Protocol (MCP) 的實際應用。 1. 多智慧體系統核心概念 基礎架構原理 Agent 核心組件： 感知器 (Perception)：接收與理解環境信息 決策器 (Decision Making)：基於目標與狀態規劃行動 執行器 (Action)：與環境互動執行任務 記憶體 (Memory)：儲存狀態、經驗與知識 協作模式： 1from enum import Enum 2from dataclasses import dataclass 3from typing import List, Dict, Any 4 5class CoordinationPattern(Enum): 6 SEQUENTIAL = "sequential" # 順序執行 7 PARALLEL = "parallel" # 並行執行 8 HIERARCHICAL = "hierarchical" # 階層式管理 9 COLLABORATIVE = "collaborative" # 協作式決策 10 11@dataclass 12class AgentTask: 13 task_id: str 14 description: str 15 agent_id: str 16 dependencies: List[str] 17 priority: int 18 metadata: Dict[str, Any] 19 20class MultiAgentOrchestrator: 21 def __init__(self, coordination_pattern: CoordinationPattern): 22 self.https://yennj12.js.org/yennj12_blog_V4/posts/crewai-series-part2-real-world-tasks-zh/Fri, 22 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/crewai-series-part2-real-world-tasks-zh/前言 上一篇我們建立了第一個 CrewAI 應用。 這篇直接進入真實工作場景，用三個完整範例展示 CrewAI 能為企業解決什麼問題。每個範例都有完整可執行的程式碼，以及設計上的關鍵決策說明。 場景一：競爭對手情報分析系統 業務背景 產品經理每週需要花 2-3 小時手動追蹤競爭對手動態：新功能、定價變化、媒體報導。這是一個重複性高、但需要一定判斷力的工作，非常適合 CrewAI 自動化。 系統設計 使用者輸入：公司名稱清單 + 分析重點 ↓ [情報收集員] 搜尋每家公司的最新動態 ↓ [分析師] 分析收集到的情報，找出威脅與機會 ↓ [報告撰寫員] 產出格式化的週報，附行動建議 完整程式碼 1import os 2from crewai import Agent, Task, Crew, Process 3from crewai_tools import SerperDevTool, ScrapeWebsiteTool 4from pydantic import BaseModel 5from typing import List 6 7os.environ["OPENAI_API_KEY"] = "your-api-key" 8os.environ["SERPER_API_KEY"] = "your-serper-key" 9 10search_tool = SerperDevTool() 11scrape_tool = ScrapeWebsiteTool() 12 13# ---- Pydantic 模型定義輸出結構 ---- 14 15class CompetitorInsight(BaseModel): 16 company: str 17 recent_news: List[str] 18 new_features: List[str] 19 pricing_changes: str 20 threat_level: str # low / medium / high 21 opportunities: List[str] 22 23class IntelligenceReport(BaseModel): 24 summary: str 25 competitors: List[CompetitorInsight] 26 key_threats: List[str] 27 recommended_actions: List[str] 28 29# ---- 定義 Agents ---- 30 31intelligence_collector = Agent( 32 role="市場情報收集員", 33 goal="系統性地收集競爭對手的最新公開資訊，確保資訊的時效性和完整性", 34 backstory="""你是一位專業的市場情報分析師，擅長從公開資源中找到有價值的競爭情報。 35 你熟悉如何在新聞、官方部落格、社群媒體、產品更新公告中尋找關鍵訊號。 36 你注重資料的來源和時效性，只引用近期（3 個月內）的資訊。""", 37 tools=[search_tool, scrape_tool], 38 llm="gpt-4o-mini", 39 verbose=True, 40 max_iter=15, 41) 42 43market_analyst = Agent( 44 role="市場策略分析師", 45 goal="分析競爭情報，識別對公司的威脅和市場機會，提供有深度的策略洞察", 46 backstory="""你是一位有豐富經驗的市場策略分析師，曾在頂尖顧問公司工作多年。 47 你擅長從零散的資訊中找出規律和趨勢，並評估其業務影響。 48 你的分析既有宏觀視野，也有具體的行動建議。""", 49 verbose=True, 50 llm="gpt-4o", 51) 52 53report_writer = Agent( 54 role="商業報告撰寫員", 55 goal="將分析結果轉化為清晰、可行動的週報，讓高層能快速掌握重點", 56 backstory="""你是一位資深的商業報告撰寫專家，了解高層主管的閱讀習慣： 57 重點先說、數據說話、建議要具體。你的報告簡潔有力，能讓繁忙的決策者 58 在 5 分鐘內掌握所有關鍵資訊。""", 59 verbose=True, 60 llm="gpt-4o", 61) 62 63# ---- 定義 Tasks ---- 64 65collection_task = Task( 66 description="""收集以下競爭對手的最近 4 週內公開資訊： 67 競爭對手清單：{competitors} 68 分析重點：{focus_areas} 69 70 對每家公司，請搜尋並整理： 71 1.https://yennj12.js.org/yennj12_blog_V4/posts/crewai-series-part3-advanced-flows-zh/Sat, 23 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/crewai-series-part3-advanced-flows-zh/前言 前兩篇建立了 CrewAI 的基礎和實戰應用。 這篇是進階篇，涵蓋讓 CrewAI 真正走到生產環境的關鍵技術： Flows：當 Crew 的線性流程不夠用時 Memory 記憶體：讓 Agent 記得過去的對話和經驗 錯誤處理與成本控制：生產環境的必要設計 部署：把 CrewAI 包成 API 服務 Part 1：CrewAI Flows——事件驅動的複雜工作流程 Crew 的限制 Process.sequential 是線性的：任務一個接一個執行。但真實世界的工作流程往往需要： 條件分支：根據分析結果走不同的路徑 迴圈：重複執行直到滿足條件 平行執行：多個 Crew 同時跑，最後彙整 狀態管理：跨步驟保存和傳遞複雜的狀態 CrewAI Flows 就是為了處理這些複雜場景設計的。 Flow 的三個核心 Decorator 1from crewai.flow.flow import Flow, listen, start, router 2from pydantic import BaseModel 3 4class MyFlow(Flow): 5 6 @start() 7 def step_one(self): 8 """Flow 的入口點，Flow 啟動時執行""" 9 return "step one result" 10 11 @listen(step_one) 12 def step_two(self, step_one_output): 13 """當 step_one 完成後自動觸發，可以接收上一步的輸出""" 14 return f"processed: {step_one_output}" 15 16 @router(step_two) 17 def decide_next(self, step_two_output): 18 """根據 step_two 的輸出決定下一步走哪條路""" 19 if "error" in step_two_output: 20 return "error_path" 21 return "success_path" 22 23 @listen("success_path") 24 def handle_success(self): 25 return "成功！" 26 27 @listen("error_path") 28 def handle_error(self): 29 return "處理錯誤.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part3-frameworks-zh/Sun, 21 Jun 2026 23:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part3-frameworks-zh/大多數工程師的選擇：「先裝一個框架，之後再說。」 有經驗的工程師的選擇：「先定義 Agent 的交互模式，再選能支撐它的框架。」 框架給你速度，但也給你它的限制；抽象層降低入門門檻，但隱藏了你最需要控制的細節。 正確的問題不是「哪個框架最好」，而是「這個框架的抽象層，跟我的問題邊界對不對齊」。 面試情境 你的團隊正在構建一個客服自動化系統，需要協調「意圖分類 Agent」、「知識庫查詢 Agent」、「回應生成 Agent」與「品質審核 Agent」四個角色。面試官問：「你會選 AutoGen、CrewAI 還是 LangGraph？為什麼？如果規模到每日 50 萬次對話，架構需要如何演進？」 一、核心問題：框架選型的本質是什麼 Agent 框架的選型問題，表面上是技術選擇，本質上是控制權與抽象層的交換。 每個框架都做了一組隱性決策： 執行模型：對話驅動 vs. 圖驅動 vs. 任務佇列驅動 狀態管理：記憶體內 vs. 持久化 vs. 外部化 Agent 通訊：廣播 vs. 點對點 vs. 中介者模式 錯誤恢復：重試策略、fallback 路徑、人工介入點 選錯框架的代價不是「換框架」這麼簡單。當你的 Agent 邏輯與框架的執行模型深度耦合後，重構成本等同於重寫。 框架的三個本質問題 問題 1：誰決定下一步由誰執行？ ├── 框架決定 → 高度結構化，靈活性低 ├── LLM 決定 → 靈活但不可預測 └── 工程師的程式碼決定 → 可控但需要更多開發工作 問題 2：狀態存在哪裡？ ├── 對話歷史 (messages list) → 簡單，但 token 成本高 ├── 結構化狀態物件 → 可查詢，但需要 schema 設計 └── 外部資料庫 → 持久化，但增加延遲 問題 3：出錯時怎麼辦？ ├── 讓 LLM 自己決定 → 彈性，但不可靠 ├── 框架的重試機制 → 簡單，但缺乏語意 └── 工程師的顯式錯誤處理 → 精確，但需要更多程式碼 理解這三個問題的答案，才能判斷一個框架是否適合你的用例。https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part5-frontend-pipeline-zh/Sat, 04 Jul 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part5-frontend-pipeline-zh/後端做得再精巧,使用者感受到的只有兩件事: 「我按下去之後,看得到它在動嗎?」以及「這些任務能不能串起來自動接力?」 前者是即時進度串流,後者是 pipeline 編排。 這一篇——系列最終回——談的就是這條「從按鈕到體驗」的最後一哩路。 四篇走下來:架構(Part 1)、可靠性引擎(Part 2)、實戰任務(Part 3)、生產化(Part 4)。這些都是使用者看不見的底層。最後這一篇,我們談使用者唯一真正碰得到的東西:前端體驗,以及把任務串起來的 Pipeline。 一、即時進度串流:AI 任務為什麼非有它不可 先講「為什麼」。一個 AI 任務可能跑 30 秒到好幾分鐘。如果使用者按下「執行」後盯著一個沒有任何反應的畫面…… 沒有即時進度 ───────────────────────────── [執行] → (轉圈圈…30 秒…) → 使用者以為當機 → 重新整理 → 更慘 有即時進度 ───────────────────────────── [執行] → 「登入中…」→「掃描案件…」→「撰寫第 3 篇提案…」 → 「送出中…」→「完成 ✅」 使用者全程知道它活著、在做什麼、還要多久 對 AI 任務來說,即時進度不是體驗加分,是信任的基礎。因為任務久、又是黑箱,不給回饋,使用者就會焦慮、就會亂按。 這個系統用 SSE(Server-Sent Events) 解決,Part 1 提過機制,這裡完整拆開。 二、SSE 串流的完整運作:四個零件 ┌───────────────────────────────────────────────────────────┐ │ ① 背景任務寫 log │ │ Flow 執行中,每完成一小步就 append 一條 log 到 DB │ │ progress.https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part3-automations-zh/Sat, 04 Jul 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part3-automations-zh/有人問:AI Agent 到底能做什麼有用的事? 答案不是「聊天」,而是「把你每天重複做、又懶得做的知識勞動,一鍵跑完」。 爬賣家、收名單、寫投標文案、分析報表——這些都是人做很煩、AI 做剛好的事。 這一篇拆解 agent_auto_system 的四個實戰任務,每一個都是一種 agent 設計模式的縮影。 Part 2 我們把 Harness 這層地基打穩了——重試、驗證、評分、記帳都由它包辦。這一篇回到真正產生價值的地方:任務本身。我們挑四個最有代表性的,順著它們的 PR 歷史看設計是怎麼演化的。 本篇四個任務,四種模式 ───────────────────────────────────────────── ① Shopee 賣家爬蟲 → HTTP + DOM fallback + 分頁(容錯爬蟲模式) ② Google Maps 名單漏斗 → 確定性 funnel + LLM 只做最後分級(混合模式) ③ Tasker 自動投標 → Playwright 真登入 + 每案客製文案(瀏覽器代理模式) ④ 利潤健檢報告 → 四 agent 協作 + PDF 產出(多代理協作模式) 一、Shopee 賣家爬蟲:一個爬蟲的「三次進化」 對應 PR #2(新增)、PR #4、PR #5(兩次修正) shopee_seller_scraper 的目標很單純:給定一個關鍵字或分類,從熱門商品裡收集賣家清單。但它的 PR 歷史,完美示範了「爬蟲上線後才會遇到的現實問題」。 進化 1:先能跑(PR #2) 第一版把基本能力做出來:抓熱門商品 → 解析出賣家。這是 MVP。https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part2-harness-engine-zh/Sat, 04 Jul 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part2-harness-engine-zh/Demo 版的 AI:json.loads(resp.content)——今天能跑。 上線版的 AI:模型回了 ```json {...} ```、或回 429、或一本正經編造欄位——明天就炸。 差別不在模型多強,而在你有沒有一層「挽具」接住這些意外。 這一篇就是拆解 agent_auto_system 的 Harness 引擎——它如何把不可靠的 LLM,變成可預測的服務。 Part 1 我們鳥瞰了整個系統,並指出 executor.py 和 harness/ 是心臟。這一篇我們把它剖開,順著這個專案的 merged PR 歷史,看它是如何一步步長出「可靠性」的。 Harness 層有五個元件: src/automation/harness/ ├── provider.py 選模型、算 fallback 順序 ├── validator.py 每個任務的結果驗證規則 ├── evaluator.py 獨立的 LLM 評審,0–100 打分 ├── costs.py token 用量與美元成本估算 └── langfuse_tracer.py 可觀測性(Part 4 深入) 我們一個一個看,並穿插它們背後的 PR。 一、最不起眼卻最致命的第一個坑:被 markdown 包住的 JSON 對應 PR #1:fix: parse markdown-fenced JSON from LLM flow output 任何做過 LLM 結構化輸出的人都遇過這件事。你在 prompt 裡明明白白寫「只回 JSON」,結果模型很貼心地回你:https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part1-overview-zh/Sat, 04 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part1-overview-zh/大部分人寫 AI Agent:把 prompt 丟給 OpenAI SDK,拿到字串,json.loads(),能跑就好。 出事了才發現:模型偶爾回 markdown 包住的 JSON、偶爾 429、偶爾一本正經地亂編——每個任務都要各自處理一次。 這個專案的答案是:把「跟 LLM 打交道的所有髒活」抽成一層 Harness,讓業務邏輯乾乾淨淨。 這一系列會帶你從架構總覽,一路讀到它每一個 merged PR 背後的工程決策。 本系列以 yennanliu/agent_auto_system 這個開源專案為主角,一共五篇: Part 1(本篇):系統總覽、架構、資料流 Part 2:Harness 引擎——多模型容錯、自我修正、LLM 評審、成本追蹤 Part 3:自動化任務實戰——Shopee 爬蟲、Google Maps 名單、Tasker 自動提案 Part 4:生產化之路——Langfuse 可觀測性、Docker 瘦身、AWS 部署、權限系統 Part 5:前端體驗與 Pipeline 編排——SSE 即時串流、多步驟任務鏈 一、這個系統到底在做什麼 一句話:它是一個「AI 自動化任務的執行平台」。你在網頁上選一個任務(例如「爬 Shopee 賣家」「從 Google Maps 收集潛在客戶名單」「自動幫我在 tasker.com.tw 投標」),填幾個欄位,選一個 LLM 供應商與模型,按下執行——系統就會在背景跑一整個 AI 代理流程,並把進度即時串流回你的畫面。 它不是一個聊天機器人,而是一個把「重複性的知識工作」變成一鍵可執行任務的平台。目前內建 11 種任務類型: 任務類型 做什麼 ────────────────────────────────────────────────────────────── google_form_fill AI 檢視並自動填寫/提交 Google 表單 web_scraper 抓取網址,回傳結構化摘要 google_sheet_reader 讀取公開 Google Sheet,做欄位/統計分析 shopee_seller_scraper 從熱門商品收集賣家清單(最多 100 筆) profit_health_check 四個 agent 協作,分析 Shopee CSV,輸出 PDF 報告 x_scraper 抓取公開 X(Twitter)帳號的近期貼文 hacker_news_digest 把 HN 熱門文章整理成摘要 email_collect Google Maps 漏斗:找商家 → 抓 email → 驗證 → 分級 tasker_apply 自動在 tasker.https://yennj12.js.org/yennj12_blog_V4/posts/orchestration-agents-claude-code-comprehensive-guide/Sun, 21 Dec 2025 10:00:00 +0000https://yennj12.js.org/yennj12_blog_V4/posts/orchestration-agents-claude-code-comprehensive-guide/Comprehensive guide to building multi-agent orchestration systems with Claude Code - learn to coordinate specialized AI agents for complex software development workflows, from architecture design to implementation.