https://yennj12.js.org/yennj12_blog_V4/tags/multi-agent/Recent content in Multi-Agent on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSat, 04 Jul 2026 09: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/ai-agent-team-for-consultant-part1-strategy-zh/Thu, 30 Apr 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part1-strategy-zh/前言 想像你是一家小型 AI 顧問公司的創辦人。客戶問你：「我們公司要怎麼導入 AI？」 你不可能 24 小時隨時接電話，但 AI Bot 可以。 這個系列文章將帶你從零開始，用純 Bot 建立一支能夠： 接受客戶需求、提問、釐清問題 產出顧問報告草稿 自動分派任務給不同專業角色 追蹤執行狀況並彙整成果 的 AI 顧問團隊。 本篇（第一篇）專注在策略層面：應該選哪條技術路線？各自的優缺點和適用場景是什麼？ 商業背景：我們要解決什麼問題？ 根據 ai_consultant 這個商業計劃的核心理念，AI 顧問的工作可以拆成幾個主要環節： 客戶需求輸入 → 問題釐清與診斷 → 方案設計 → 報告產出 → 執行追蹤 傳統顧問公司靠人來完成每個環節。我們的目標是： 用一組協作的 AI Agent 取代或增強每個環節，讓少數人力就能服務更多客戶。 這不是「一個超級 AI 什麼都做」，而是多個專責 Agent 分工合作的概念。 三條技術路線 路線 A：Claude Code + Skills / AGENTS.md 核心概念： 利用 Claude Code CLI 的原生 multi-agent 機制，透過 AGENTS.md（或 CLAUDE.md）定義每個 Agent 的角色、工具權限與行為邊界，搭配 Skills（可重複呼叫的 slash command 腳本）讓 Agent 之間能互相協作。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/ai-agent-team-for-consultant-part2-implementation-zh/Thu, 30 Apr 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part2-implementation-zh/前言 上一篇 我們比較了三條技術路線的優缺點。本篇進入動手實作，每條路線都包含： 環境設定 角色（Agent）定義 實際執行範例 關鍵注意事項 路線 A：Claude Code + AGENTS.md + Skills 1. 環境設定 1# 安裝 Claude Code CLI 2npm install -g @anthropic-ai/claude-code 3 4# 確認版本 5claude --version 6 7# 登入（需要 Anthropic 帳號） 8claude auth login 建立專案目錄： 1mkdir ai-consultant-team && cd ai-consultant-team 2. 建立 AGENTS.md（團隊憲章） AGENTS.md 是整個 Agent 團隊的「組織架構圖」，定義各角色的職責與協作方式。 1# AI 顧問團隊 - 組織架構 2 3## 團隊宗旨 4協助中小企業做出明智的 AI 導入決策，提供從需求診斷到執行規劃的完整顧問服務。 5 6## 角色定義 7 8### Coordinator（協調員） 9- **職責**：接收初始需求，判斷複雜度，分派給對應 Agent 10- **不做**：不直接撰寫報告，不做技術分析 11- **輸出格式**：JSON，包含 task_id、assigned_agent、priority 12 13### Intake Agent（需求收集師） 14- **職責**：與客戶對話，收集結構化需求資訊 15- **問題清單**：產業、公司規模、現有系統、痛點、預算範圍、時程 16- **輸出格式**：Markdown 的需求摘要文件 17 18### Analyst Agent（問題分析師） 19- **職責**：根據需求摘要，診斷問題根源，評估 AI 導入可行性 20- **輸出格式**：包含 feasibility_score (1-10)、risks[]、opportunities[] 的分析報告 21 22### Strategist Agent（策略顧問） 23- **職責**：設計 AI 解決方案，評估 ROI，排列優先順序 24- **輸出格式**：方案比較表 + 建議路徑 25 26### Writer Agent（報告撰寫師） 27- **職責**：整合所有 Agent 的輸出，產出最終顧問報告 28- **格式**：Executive Summary + 詳細分析 + 行動計畫 3.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-agent-team-for-consultant-part4-outsourcing-zh/Thu, 30 Apr 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part4-outsourcing-zh/情境設定 公司背景： TechBridge Studio，台灣台北，10 人軟體外包公司 主要業務： 承接中小企業的網站、APP、後台系統開發 每月詢問量： 約 40-60 個潛在客戶詢問 核心痛點： PM 每天要花 3-4 小時回覆詢問、估時、報價 需求不清楚的客戶佔 70%，常常來回溝通一週才能確定範圍 報價單格式不統一，常常漏掉風險評估 客戶問進度時 PM 要手動查詢 Jira，很耗時 目標： 用 AI Agent 團隊處理 80% 的初步詢問與報價流程，讓 PM 只需審核最終結果。 整體架構設計 客戶詢問（LINE / Email / 網頁表單） ↓ ① Intake Agent（需求釐清師） → 提問 10 個標準問題，整理結構化需求 ↓ ② Scope Agent（範圍評估師） → 拆解功能清單，標記模糊需求，評估風險 ↓ ③ Estimator Agent（報價估算師） → 根據功能清單估時、報價，套用公司價目表 ↓ ④ Proposal Agent（提案撰寫師） → 產出正式提案文件（含時程、里程碑、付款條件） ↓ ⑤ PM Review（人工審核） → PM 在 5 分鐘內審核並核可 ↓ ⑥ Follow-up Agent（追蹤師） → 3 天後自動詢問客戶是否有問題，追蹤成交 技術選型 本案例使用 Claude Code + AGENTS.https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part5-digital-marketing-zh/Thu, 30 Apr 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part5-digital-marketing-zh/情境設定 公司背景： PixelFlow Agency，台灣台中，8 人數位行銷公司 主要服務： 社群媒體管理、廣告投放（Meta / Google Ads）、SEO、內容行銷 服務客戶數： 同時服務 15-20 個品牌 核心痛點： 每個客戶每月需要 30-50 篇社群貼文，文案師產能跟不上 廣告成效報告每月要花 2 天手動彙整，格式各異 新客戶的「內容策略規劃」每次都要從頭寫，耗時 3-5 天 客戶問「我們這個月的廣告怎麼樣」時，帳號管理師要翻資料才能回答 目標： AI Agent 承擔 60% 的文案產出、100% 的報告彙整、80% 的策略草稿。 整體架構設計 定期觸發（每日/每週/每月）+ 客戶即時請求 ↓ ① Brand Agent（品牌守門員） → 載入品牌 DNA，確保所有輸出符合品牌調性 ↓ ┌────────────────────────────────┐ │ 並行執行（Parallel Execution） │ ├──────────────┬─────────────────┤ ② Content Agent ③ Ad Copy Agent （內容策略師） （廣告文案師） └──────────────┴─────────────────┘ ↓ ④ Analyst Agent（數據分析師） → 讀取廣告成效數據，產出洞察 ↓ ⑤ Report Agent（報告撰寫師） → 整合所有產出，製作月報/週報 ↓ ⑥ Presenter Agent（簡報師） → 把報告轉成客戶易讀的簡報格式 技術選型： 本案例使用 LangGraph + Claude API（路線 C）https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part7-agent-design-zh/Sun, 31 May 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part7-agent-design-zh/Agent 面試的陷阱不是問你能不能架起來。 是問你在什麼情況下選哪種架構，以及出問題時你怎麼 debug。 架構選擇題沒有標準答案，有的是 trade-off 意識。 面試情境 面試官：「你設計的 Agent 系統用的是 ReAct 還是 Planner-Executor？為什麼？如果這個 Agent 有 20 個工具，你怎麼讓它找到正確的工具？多輪對話中它怎麼記住之前說過的事？」 這三個問題連在一起問，是 FDE RKK 的標準深度追問模式。 一、ReAct vs Planner-Executor：核心架構選擇 ReAct（Reasoning + Acting） ReAct 的執行模型： 任務輸入 │ ▼ Thought（LLM 推理：我現在應該做什麼？） │ ▼ Action（呼叫 Tool 或輸出最終答案） │ ▼ Observation（Tool 的執行結果） │ └──────────────────────────────→ 再回到 Thought 直到輸出 final_answer 特性： ├── 每一步都由 LLM 動態決策 ├── 可以根據 Observation 隨時調整策略 └── Context 隨步驟累積（第 20 步的 context 包含前 19 步的 trace） ReAct 的適用場景：https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part16-multiagent-state-deadlock-zh/Thu, 04 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part16-multiagent-state-deadlock-zh/面試官不只想聽你說「加 max_loops 限制」。 他想聽的是：你知道為什麼會死鎖、死鎖發生在哪個環節、 以及你的架構設計如何讓問題根本不會發生。 面試情境 面試官： 「客戶使用 LangGraph 部署了一個階層式的 Multi-Agent 系統。Router Agent 分發任務給法務審查 Agent 和財務計算 Agent。上線後，特定的複雜查詢會導致系統 Timeout，或是多個 Agent 互相死循環呼叫。你在 Google Doc 看到對話日誌，如何定位問題？架構上如何設計 State Management 與護欄？」 一、核心問題：Multi-Agent 為什麼比 Single-Agent 更容易死鎖 Single-Agent（線性執行）： User → Agent → Tool → Tool → Answer ↑ 狀態簡單，只有一個執行者， 不存在競爭條件 Multi-Agent（網狀執行）： ┌─────────────────┐ │ Router Agent │ └────────┬────────┘ ↙ ↘ ┌──────────────┐ ┌──────────────┐ │ 法務 Agent │ │ 財務 Agent │ └──────┬───────┘ └──────┬───────┘ │ │ └──────┬────────────┘ ▼ ┌──────────────┐ │ Review Agent │ ← 可能再呼叫回 Router └──────────────┘ │ ▼ ?https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part31-adk-deep-dive-zh/Fri, 05 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part31-adk-deep-dive-zh/ADK 不只是「Google 版的 LangGraph」。 它是一個針對 Gemini + Google Cloud 生態系優化的 Agent 框架， 在抽象層次、狀態管理、部署模式上都有自己的設計哲學。 面試官考這題，是在測試你能不能幫客戶在 ADK 和 LangGraph 之間做出有依據的選擇。 面試情境 面試官：「客戶是一家保險公司，已經在用 Google Workspace 和 GCP。他們想部署一個多步驟的理賠審核 Agent，需要並行查詢三個系統（核保資料庫、醫療記錄、詐欺偵測），然後由一個審核 Agent 整合結果做決策。你會用 ADK 還是 LangGraph？如果用 ADK，架構怎麼設計？」 一、ADK 在 Google AI 棧中的定位 Google AI Agent 工具棧（由低到高抽象）： ┌─────────────────────────────────────────────────────────────┐ │ Level 1：Gemini API + Function Calling（最底層） │ │ 你自己管理所有狀態、Tool 呼叫、循環邏輯 │ │ 適合：完全客製化，或需要接非 Gemini 模型 │ └─────────────────────────────────────────────────────────────┘ ↓ 抽象提升 ┌─────────────────────────────────────────────────────────────┐ │ Level 2：Google ADK（本篇主題） │ │ 提供 Agent 類型、Tool 宣告、Multi-Agent 協調的標準框架 │ │ 原生整合 Gemini、Vertex AI、Google Search │ │ 適合：需要客製化邏輯，但不想從零搭框架 │ └─────────────────────────────────────────────────────────────┘ ↓ 抽象提升 ┌─────────────────────────────────────────────────────────────┐ │ Level 3：Vertex AI Agent Builder（最高層） │ │ 低代碼/無代碼界面，拖拉設定 Agent 工作流 │ │ 適合：快速原型、業務人員自助、標準企業聊天機器人 │ └─────────────────────────────────────────────────────────────┘ FDE 的判斷原則： 「如果 Agent Builder 能做到，就不用 ADK。 如果 ADK 能做到，就不用從頭用 Gemini API 寫。」 二、ADK vs LangGraph：根本差異 比較維度 ADK LangGraph ────────────────────────────────────────────────────────────────── 模型綁定 Gemini 原生（可接其他） 任何 LLM 抽象層次 高（有 Agent 類型概念） 低（Node + Edge 圖） 狀態管理 Session State（框架管理） StateGraph（你定義 schema） Multi-Agent AgentTeam + sub_agents 自己設計節點間通信 部署 Vertex AI Agent Engine 原生 需要自己包 Container Google Cloud 整合 原生（GCS、BigQuery、Search） 需要額外配置 學習曲線 低（比 LangGraph 少 boilerplate）高（但控制粒度更細） 適合場景 GCP 生態、快速落地 複雜自定義工作流、多模型混用 關鍵判斷點： 客戶在 GCP + 用 Google Workspace + 需要快速 POC → ADK 客戶需要複雜的條件分支 + 不同步驟用不同 LLM → LangGraph 客戶想混用 GPT-4o 和 Gemini → LangGraph（ADK 對非 Gemini 模型支援有限） 三、ADK 的四種 Agent 類型 ADK 的核心設計是「Agent 類型決定執行模式」，而不是讓你手動畫控制流程圖。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase16-part1-coordination-zh/Mon, 22 Jun 2026 01:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase16-part1-coordination-zh/大多數人看到多 Agent 系統，第一反應是「多幾個 Agent 就能平行加速」。 工程現實卻是：沒有協調機制的多 Agent，比單 Agent 更慢、更貴、更難除錯。 正確答案是：先確定協調模式，再決定幾個 Agent——而不是反過來。 協調成本才是多 Agent 系統的真正瓶頸，比 LLM token 更貴。 面試情境 你負責設計一個研究助理平台：使用者輸入一個複雜問題，系統要自動拆解子任務、分派給不同專業 Agent（搜尋、摘要、數據分析、引用驗證），最後整合回一份報告。規模目標是 2,000 個並發研究任務，每個任務平均涉及 8 個子 Agent。請說明協調架構如何設計，以及當兩個 Agent 搶同一份外部資源時你怎麼處理衝突？ 一、核心問題：多 Agent 協調比單 Agent 難在哪裡 1.1 單 Agent 的極限在哪裡 單一 LLM Agent 在以下情境開始出現瓶頸： 情境 問題 數字 超長 context 精度隨 token 數下降 > 32K tokens 後 recall 掉 15–30% 串行任務鏈 無法利用並行，延遲線性增長 10 步 × 3s = 30s 異構技能需求 同一 Agent 無法同時是程式碼專家與法律專家 prompt 膨脹、精度下降 長時間運行 上下文視窗耗盡，需要切割狀態 超過 4 小時任務必須外化記憶 多 Agent 解決了以上問題——但引入了一整類新問題：https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase16-part2-emergence-collective-zh/Mon, 22 Jun 2026 02:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase16-part2-emergence-collective-zh/大多數工程師遇到複雜問題，第一直覺是「換一個更大的模型」。 真正懂系統設計的人知道：讓十個中等模型彼此辯論，往往比一個頂尖模型獨自思考更準確。 湧現不是魔法，是可以設計的協作協議。 問題不是「能不能湧現」，而是「湧現後你有沒有辦法控制它」。 面試情境： 你的團隊正在構建一個醫療診斷輔助系統，需要在 99.5% 準確率與 < 3 秒延遲之間取得平衡。單一 GPT-4 只能達到 94% 準確率，且有時會「幻覺」出不存在的藥物交互作用。請設計一個多 Agent 集體推理架構，說明如何透過湧現行為提升準確率，同時保持可控性與可解釋性。 一、核心問題：湧現智慧的工程機會與不可控性 湧現（Emergence） 是系統層級的性質，無法從單一元件預測。一個 Agent 讀文件，十個 Agent 互相辯論，系統的行為質量不是線性疊加，而是非線性躍升。 為什麼湧現在 LLM 多 Agent 系統中特別有價值？ LLM 的認知偏差問題： 問題類型 單一 LLM 表現 多 Agent 集體推理 確認偏誤 容易強化初始假設 反對 Agent 強制挑戰 幻覺 4–8% 幻覺率（GPT-4） 辯論後降至 1–2% 知識盲點 受限於訓練資料 不同模型互補不同知識 複雜推理 單次 context 限制 分工後各擅勝場 湧現的工程挑戰： 不可預測性：5 個 Agent 的交互可能產生 120 種路徑排列 放大效應：一個 Agent 的錯誤可能被其他 Agent 強化而非糾正（Echo Chamber） 成本爆炸：N 個 Agent 互相溝通 = O(N²) token 消耗 延遲累積：串行辯論每輪加 2–5 秒，3 輪 = 6–15 秒額外延遲 工程師的任務不是「讓系統湧現」，而是設計湧現發生的條件，並在湧現失控前有干預能力。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/cloudflare-security-audit-skill-part2-agent-design-zh/Mon, 29 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/cloudflare-security-audit-skill-part2-agent-design-zh/單一 agent 做安全稽核，最大的問題不是「能力不夠」， 而是「confirmation bias」——它既找漏洞，又驗證自己找到的漏洞。 Cloudflare 的解法是：讓找漏洞的 agent 和否定漏洞的 agent 永遠是不同的人。 一、為什麼 Multi-Agent 在安全稽核場景特別有價值 安全稽核和一般的「讓 AI 寫程式」任務有一個關鍵差異： 一般 AI 任務的正確性標準： 輸出可以被執行 → 執行結果符合預期 安全稽核的正確性標準： 找到的漏洞可以被 exploit → exploit 確實成功 沒找到的地方確實沒有漏洞 第二個標準極難用單一 agent 達到，原因有三： 原因 1：Context window 污染 一個 agent 如果既做 Recon 又做 Hunt，它已經建立了對這個系統的「地圖」。這個地圖讓它不容易發現地圖之外的東西——因為它不會主動去懷疑自己的地圖。 原因 2：Confirmation bias 找到「可能的漏洞」之後，同一個 agent 驗證時會下意識地尋找支持的證據，而不是反駁的證據。 原因 3：Context 深度 vs 廣度的矛盾 深入追蹤一條可疑的程式碼路徑，和廣泛掃描整個 codebase，是兩種相互競爭的任務——在同一個 context window 裡很難同時做好。 Multi-agent 架構解決了這三個問題。 二、Hunt Phase 的 Agent 分配策略 按什麼維度分 Agent？ 維度 1：攻擊類別（Attack Class） ┌──────────────────────────────────────────────────────────────┐ │ Agent-Injection → 追蹤所有 untrusted input 到 sink │ │ Agent-AccessCtrl → 越權、IDOR、privilege escalation │ │ Agent-Crypto → 弱隨機數、hardcoded secrets、timing │ │ Agent-BusinessLogic → 狀態機、競爭條件、數值邊界 │ │ Agent-FeatureAbuse → 合法功能被惡用的路徑 │ │ Agent-Chained → 多步驟組合攻擊 │ │ Agent-Wildcard → 探索意外的地方 │ └──────────────────────────────────────────────────────────────┘ 維度 2：子系統（Subsystem） ┌──────────────────────────────────────────────────────────────┐ │ Agent-Auth-Injection → auth 子系統 × injection │ │ Agent-Auth-AccessCtrl → auth 子系統 × 越權 │ │ Agent-Plugin-Injection → plugin 系統 × injection │ │ Agent-Media-Resource → media pipeline × file handling│ └──────────────────────────────────────────────────────────────┘ 兩個維度可以組合。系統的設計原則是：當子系統有明顯的安全邊界時，按子系統切分比只按攻擊類別更有效。https://yennj12.js.org/yennj12_blog_V4/posts/cloudflare-security-audit-skill-part1-pipeline-zh/Mon, 29 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/cloudflare-security-audit-skill-part1-pipeline-zh/多數 AI 安全工具的做法：把程式碼丟給一個 LLM，問它「有沒有漏洞？」 Cloudflare 的做法：六個獨立 phase、多個平行 agent、adversarial validation、獨立事實查核。 差別不在「用了 AI」，而在「怎麼讓 AI 不說廢話」。 一、為什麼這個 repo 值得深讀 Cloudflare 在 2024 年開源了 security-audit-skill，把他們內部用 AI agent 做安全稽核的系統公開出來。 這不是一個「讓 ChatGPT 讀你的程式碼」的玩具。這是一個： 六階段 orchestrated pipeline，每個 phase 有明確的輸入/輸出 Multi-agent 架構，同一 phase 內多個 agent 平行執行 Adversarial validation：找漏洞的 agent 和驗證漏洞的 agent 是不同的 Structured output + schema validation：輸出有嚴格的 JSON schema Independent verification：最後一道全新 agent 逐一查核每一個事實宣稱 整個 Pipeline 的資料流： codebase │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ Phase 1: Recon │ │ Agent 1a (Overview) Agent 1b (Trust) Agent 1c (Input) │ │ └─────────────────────────────┘ │ │ ▼ │ │ architecture.https://yennj12.js.org/yennj12_blog_V4/posts/specialized-agent-orchestration-patterns-zh/Thu, 19 Mar 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/specialized-agent-orchestration-patterns-zh/多 Agent Token 優化系列 pt.7：深入探討專責化 Agent 的協作模式，涵蓋團隊組織架構、動態路由、任務分解策略、狀態管理、錯誤處理等生產級實作，幫助你打造高效協調的 Agent 團隊。https://yennj12.js.org/yennj12_blog_V4/posts/agent-specialization-multi-agent-guide-zh/Thu, 12 Mar 2026 22:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/agent-specialization-multi-agent-guide-zh/深入探索 Agent 專責化策略：從單一通用 Agent 到專業分工的專家團隊，涵蓋職責劃分、System Prompt 精簡、工具最小化配置、模型差異化選擇等完整實作，幫助你大幅降低 System Prompt 的 Token 消耗並提升輸出品質。https://yennj12.js.org/yennj12_blog_V4/posts/selective-context-passing-multi-agent-guide-zh/Thu, 12 Mar 2026 20:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/selective-context-passing-multi-agent-guide-zh/多 Agent Token 優化系列 pt.5：深入探索選擇性 Context 傳遞策略，從依賴關係映射、結構化輸出到相關性過濾，提供完整實作範例，幫助你大幅降低 Agent 間通訊的 Token 消耗。https://yennj12.js.org/yennj12_blog_V4/posts/multi-agent-token-optimization-claude-code-zh/Thu, 12 Mar 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/multi-agent-token-optimization-claude-code-zh/多 Agent Token 優化系列總覽：深入解析 Token 用量優化策略，涵蓋 Prompt Caching、Context 壓縮、Agent 專責化、模型分層、選擇性 Context 傳遞等方法，幫助你建構高效且低成本的多 Agent 系統。