https://yennj12.js.org/yennj12_blog_V4/tags/langgraph/Recent content in LangGraph on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSun, 21 Jun 2026 23:30:00 +0800https://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/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/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/fde-core-concept-3-state-machine-dag-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-3-state-machine-dag-zh/核心定義：DAG 是把 Agent 的「下一步由 LLM 在執行期決定」改成「下一步由工程師在編譯期定義」，讓系統的行為空間可靜態分析、可稽核、可成本管控。 大多數人把 Agent 做成 ReAct 迴圈——因為它最快能跑起來； 少數人在第一次工具呼叫爆炸後改成有守衛的迴圈； 更少人從一開始就把行為編碼成 DAG，把路由邏輯放在 Python 而非 prompt； 最少的人能說清楚為什麼這樣做可以把工具呼叫從 12 次壓到 4 次。 面試情境：「我們的 AI 文件審核系統上線後，有使用者反映處理速度極慢，有時要等 3–4 分鐘；後來發現有些 run 觸發了 25 次以上的 LLM 呼叫，導致每個 query 成本從預計的 $0.01 飆升至 $0.08。如果請你重新設計這個系統的 Agent 架構，你會怎麼做，以及如何確保這個問題不再發生？」 一、為什麼面試官問這個 面試官問這個問題，真正在測試的不是你會不會用 LangGraph API，而是你是否理解 Agent 系統的確定性邊界問題。當 LLM 自己決定下一步時，系統的行為空間在執行前是無界的——相同輸入在不同推論溫度下可能走不同路徑，工具呼叫次數無法預測，成本預算無從管控。在一個 LLM 呼叫每次耗費數十毫秒和若干 Token 費用的世界裡，這不是學術問題，是直接打中 P&L 的工程問題。 面試官測試三個層次： 概念層：你能否清楚說明 ReAct 和 DAG 的本質差異，而不只是說「DAG 有節點有邊」 工程層：你是否知道反思迴圈為何需要雙重收斂條件，以及 State Schema 如何防止跨節點狀態污染 量化層：你能否用具體數字說明影響——工具呼叫次數、Token 成本、收斂延遲 弱答案的特徵：「DAG 就是有向無環圖，LangGraph 可以幫你把 Agent 畫成圖。」只描述工具特性，沒說清楚「為什麼要這樣做」和「不這樣做的具體代價」。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/rag-series-part5-production-zh/Wed, 20 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part5-production-zh/前言 你的 RAG 系統「感覺」不錯，但你能量化它有多好嗎？ 這是生產環境中最常見的盲區：工程師花大量時間優化 Chunking、調整 Reranker，卻沒有客觀的指標來驗證改動是否真的有效。 這篇是系列的最後一篇，涵蓋三個主題： RAG 評估（RAGAS）：如何量化 RAG 品質 GraphRAG：當向量搜尋不夠用時的替代方案 Agentic RAG：RAG + Agent，讓 AI 自己決定如何搜尋 Part 1：RAG 評估——RAGAS 框架 為什麼評估很難？ RAG 的輸出是自然語言，沒有標準答案可以直接比對。 「這個答案好不好」，需要從多個維度判斷。 RAGAS 的四個核心指標 RAGAS（RAG Assessment） 是目前最流行的 RAG 評估框架，定義了四個指標： 1. Faithfulness（忠實度） 答案是否只根據 context，沒有幻覺？ 計算方式： Step 1: 把答案分解成一組陳述句（claims） Step 2: 對每個陳述，判斷 context 是否支持它 Step 3: Faithfulness = 有 context 支持的陳述數 / 總陳述數 理想值：接近 1.0 2. Answer Relevancy（答案相關性） 答案是否真的回答了問題？ 計算方式： Step 1: 讓 LLM 根據答案生成 N 個「可能的問題」 Step 2: 計算這些問題與原始問題的向量相似度 Step 3: Answer Relevancy = 平均相似度 理想值：接近 1.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-core-concept-13-idempotency-state-recovery-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-13-idempotency-state-recovery-zh/核心定義：Idempotency & State Recovery 是透過「執行前寫 Checkpoint、執行後 CAS 更新狀態、恢復時重播已完成步驟」的三段式協議，確保分佈式 Agent 在任意時間點中斷並重啟後，每個工具呼叫的副作用（扣款、通知、寫 DB）恰好執行一次，不多不少。 一、為什麼面試官問這個 面試官真正在測試的是你對 分佈式系統可靠性 與 副作用管理 的成熟度。這題的背後問題是：「你知不知道 Agent 不是函數——它的執行跨越多個 Pod、多個時間視窗，任何一步都可能在已產生副作用之後失敗？」 測試點一：副作用的不可逆性。 能否清楚區分「可重試的讀操作」與「不可重試的寫操作（發信、扣款、呼叫第三方 API）」，並說明為何後者必須有去重機制。面試官想知道你是否理解「at-least-once delivery」與「exactly-once semantics」的本質差異：前者是訊息系統的保證，後者是應用層必須自己實現的語意。 測試點二：一致性模型的選擇。 能否說明為何 Checkpoint 需要強一致性（Cloud Spanner external consistency）而非最終一致性（Firestore default mode），以及這個選擇的 latency 代價（~10ms vs ~1ms）。最終一致性在此場景下會造成新 Worker 讀到舊快照，誤判步驟未完成，重複執行已完成的工具。 測試點三：恢復路徑的完整性。 能否說明 StateGraph.update_state() 如何注入已完成步驟的輸出、跳過重新執行，並在 split-brain 情境下靠 Compare-And-Swap 避免雙 Worker 各自推進狀態。 弱答案長相： 「重試的時候我們就再跑一次，加個 try-catch 就好。」沒有提到去重 key、沒有提到 Checkpoint 持久化、沒有說明如何判斷哪些步驟已完成、也沒有提到下游服務如何識別重複呼叫。這個答案在面試官眼中等同於「不懂分佈式」。 強答案長相： 從「寫 pending → 執行 → 寫 completed（CAS）」三段式出發，說明 CAS 防止 split-brain，Recovery 時透過 StateGraph.update_state() 重播 StateGraph，最後給出具體數字：Spanner 寫入 ~10ms、恢復時間 < 100ms、重複通知率 0.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part14-memory-architecture-zh/Wed, 03 Jun 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part14-memory-architecture-zh/LLM 是無狀態的，但用戶是有狀態的。 Memory 系統要解決的問題只有一個： 讓無狀態的 LLM 表現得像是「記得你」。 怎麼設計這個橋樑，以及這個橋樑的代價——是這篇的核心。 一、核心問題：為什麼需要不同類型的 Memory 沒有 Memory 的 Agent 每次對話從零開始： Session 1： User: "我主要用 Python，偏好簡短的回答" Agent: "好的！" （記不住） Session 2（三天後）： User: "幫我寫一個排序函數" Agent: "您好！請問您用哪種程式語言？" ↑ 明明說過了，還在問 但「把所有對話都記住」也不可行： 問題 1：儲存量 10K 用戶 × 每天 10 輪 × 365 天 = 3,650 萬條對話記錄 問題 2：Context 限制 把所有歷史塞進 LLM context → 超過 context window 問題 3：相關性 3 年前討論的內容，現在可能完全不相關 結論：需要多種記憶類型，各自解決不同的問題。 二、四種記憶類型：各解決什麼問題 問題 解決方案 ───────────────────────────────────────────────────── 當前對話的臨時狀態？ → Working Memory（工作記憶） LLM context window 生命週期：當次對話 記得過去發生過什麼？ → Episodic Memory（情節記憶） 向量化的對話歷史 生命週期：跨 session，可衰減 記得這個人是什麼樣的人？→ Semantic Memory（語意記憶） 結構化的 user profile 生命週期：持久化，主動更新 知道怎麼做某件事？ → Procedural Memory（程序記憶） Few-shot examples / Fine-tuning 生命週期：模型層，最持久 三、完整 Memory 架構圖 用戶請求 │ ▼ ┌──────────────────────────────────────────────┐ │ Memory Retrieval Layer │ │ │ │ ┌──────────────────────┐ │ │ │ Semantic Memory │ ← 用戶偏好、profile │ │ │ (Structured DB) │ 每次對話都載入 │ │ └──────────────────────┘ │ │ + │ │ ┌──────────────────────┐ │ │ │ Episodic Memory │ ← 相關歷史片段 │ │ │ (Vector DB) │ 按語意相似度召回 │ │ └──────────────────────┘ │ └──────────────────┬───────────────────────────┘ │ 組合成 Working Memory ▼ ┌──────────────────────────────────────────────┐ │ Working Memory │ │ (LLM Context Window) │ │ │ │ [System Prompt] │ │ [User Profile from Semantic Memory] │ │ [Relevant History from Episodic Memory] │ │ [Current Conversation] │ │ [Current Query] │ └──────────────────┬───────────────────────────┘ │ ▼ LLM │ ▼ 回應 │ （對話結束後，非同步） ▼ ┌──────────────────────────────────────────────┐ │ Memory Update Layer │ │ │ │ ┌────────────────────────────┐ │ │ │ 提取重要資訊 │ │ │ │ → 更新 Semantic Memory │ ← 偏好、事實 │ │ └────────────────────────────┘ │ │ ┌────────────────────────────┐ │ │ │ 壓縮對話摘要 │ │ │ │ → 存入 Episodic Memory │ ← 做了什麼 │ │ └────────────────────────────┘ │ └──────────────────────────────────────────────┘ 關鍵設計決策：Memory Update 是非同步的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-part25-self-reflection-loop-zh/Thu, 04 Jun 2026 18:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part25-self-reflection-loop-zh/LLM 的幻覺問題不會被「更好的 Prompt」完全消除。 更實際的工程思路是：允許 LLM 犯第一次錯， 但設計一個系統讓它能自己發現錯誤、自己修正。 問題是：你怎麼確保「自我修正」不會無限進行下去？ 面試情境 面試官： 「在法務合約問答中，Agent 呼叫外部工具，但工具返回的 JSON 數據包含矛盾的條款。LLM 第一次生成時沒有注意到，產生了嚴重幻覺。你如何設計一個 Self-Reflection 架構，讓 Agent 在輸出最終答案前能自己檢查並校正？如何防止反思機制陷入死循環？」 一、核心問題：為什麼需要 Self-Reflection 沒有 Self-Reflection 的問題： Tool 回傳矛盾資料： 第 3 頁：「違約金為 500 萬台幣」 第 7 頁：「違約金為 50 萬台幣（與前款衝突）」 LLM 第一次生成： 「根據合約，違約金為 50 萬台幣。」（只看了第 7 頁，忽略矛盾） 結果： └── 法務顧問基於錯誤資訊給建議 └── 客戶簽了有利於對方的合約 └── FDE 被客戶投訴 如果有 Self-Reflection： 第一次生成後，由「審查者」指出： 「你的答案說 50 萬，但第 3 頁寫的是 500 萬，兩者矛盾。請重新分析。」 第二次生成： 「合約中關於違約金存在矛盾條款：第 3 頁寫 500 萬，第 7 頁寫 50 萬。 建議客戶在簽約前要求對方澄清哪一條款有效。」 ← 這才是正確的專業回答 二、Reflexion Pattern：設計原理 Reflexion 的三個核心洞察： 洞察 1：同一個 LLM 作為生成者和評估者 同樣的 Gemini Pro，給它不同的角色（System Prompt）， 它能同時做好「生成答案」和「找出答案的問題」 洞察 2：評估者的視角和生成者不同 生成者的 System Prompt：「你是一個法務助理，根據合約回答問題」 評估者的 System Prompt：「你是一個嚴格的法務審查員，專門找答案的問題」 不同的視角 → 更容易發現問題 洞察 3：錯誤原因要結構化，不能只說「有問題」 ❌ 「這個答案有問題，請重試」 ✅ 「第 3 條和第 7 條數字矛盾（500 萬 vs 50 萬），答案沒有提及這個矛盾」 結構化的錯誤原因 → 生成者能有針對性地修正 三、Generator-Evaluator 架構設計 ┌──────────────────────────────────────────────────────────────┐ │ 輸入 │ │ User Query + Tool Results（可能含矛盾資料） │ └──────────────────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ Generator Node（生成節點） │ │ │ │ System Prompt：「你是一個專業的法務助理。 │ │ 根據提供的合約條款回答問題。 │ │ 如果有矛盾的條款，必須明確指出並說明不確定性。」 │ │ │ │ Input： │ │ ├── User Query │ │ ├── Contract Context（Tool 回傳的原始資料） │ │ └── [如果是重試] Evaluator 的錯誤原因（feedback） │ │ │ │ Output：Draft Answer（初稿） │ └──────────────────────────┬───────────────────────────────────┘ │ Draft Answer ▼ ┌──────────────────────────────────────────────────────────────┐ │ Evaluator Node（評估節點） │ │ │ │ System Prompt：「你是一個嚴格的法務品質審查員。 │ │ 你的任務是找出答案的問題，而不是給出正確答案。 │ │ 必須以結構化 JSON 格式輸出評估結果。」 │ │ │ │ Input： │ │ ├── User Query │ │ ├── Original Context（原始合約資料） │ │ └── Draft Answer（等待審查的答案） │ │ │ │ Output： │ │ { │ │ "has_error": true/false, │ │ "error_type": "contradiction/hallucination/incomplete", │ │ "error_detail": "第 3 頁寫 500 萬，第 7 頁寫 50 萬.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/fde-interview-guide-part43-async-cart-agent-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part43-async-cart-agent-zh/大多數工程師看到「購物車 Agent」，第一反應是加一個 HTTP 呼叫。 資深工程師看到的是：200 萬個並發狀態機、隨時會蒸發的 Pod、以及絕不允許重複扣款的業務紅線。 前者寫了一個能示範的 Demo，後者設計了一個能活過黑五的系統。 差距不在代碼行數，在於你把「失敗」當作例外還是當作設計輸入。 面試情境 面試官提問（Staff FDE L6 考題）： 你的電商平台計劃在黑五期間為 200 萬名在線用戶 同時運行「自動購物車談判 Agent」。 Agent 必須在背景異步監控庫存、與供應鏈 Agent 協商折扣，並在完成後推送通知。 已知 GKE 節點在大促期間會因搶佔（Preemption）和 OOM 隨機重啟， 請問你如何設計這個系統的異步架構？ 當一個執行到第 5 輪反思循環（Reflection Loop）的 LangGraph Agent Pod 突然消失時， 你如何保證不遺失狀態、不重複通知、不重複扣款？ 一、核心問題：為什麼同步 HTTP 在這裡是個死路 1.1 規模帶來的物理上限 200 萬在線用戶同時觸發購物車事件，假設每個 Agent 執行一次完整談判流程需要 8–15 秒（含多輪 LLM 推理、供應鏈 API 呼叫），同步模型意味著： 同步 HTTP 模型的致命算術 ───────────────────────────────────────────────────── 並發請求量 ：2,000,000 個用戶 × 黑五流量因子 3× = 6M req 平均持續時間 ：~12s（5 輪反思 × 2.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part48-self-healing-agent-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part48-self-healing-agent-zh/大多數工程師的方法：在工具呼叫外面包一層 try-catch，失敗就 retry 三次。 資深工程師的方法：把「校驗」與「推理」分離，讓 Agent 的反思循環成為架構的一等公民。 普通做法：靠運氣假設外部 API 永遠回傳正確格式。 正確做法：用強型別 Schema 把「偽正確」的垃圾數據攔截在下游之前，Critic Agent 重寫參數，Circuit Breaker 隔離毒源。 面試情境 你在一家跨境電商公司擔任 FDE，負責設計一個基於 LangGraph 的供應鏈自動化 Agent。 系統每天處理約 50,000 筆訂單，依賴三家第三方物流商的 API 進行貨況追蹤。 某天凌晨兩點，主要物流商的 API 開始回傳 HTTP 200 但夾帶格式錯誤的日期欄位（DD/MM/YYYY 而非 YYYY-MM-DD）， 導致下游的 SQL Agent 批次寫入失敗，28% 的訂單狀態更新卡住。 面試官問：你如何在 Graph 設計層面實作自動容錯，讓系統不需要人工介入就能自我修復？ 以及當自我修復三次仍失敗時，你的降級策略是什麼？ 一、核心問題：為什麼 try-catch 是必要但不充分的 1.1 兩種不同性質的故障 外部 API 的失敗分為兩種截然不同的類型，絕大多數工程師只處理了第一種： 故障類型 A：硬故障（Hard Failure） ├─ HTTP 4xx / 5xx ├─ Connection Timeout ├─ DNS 解析失敗 └─ 對策：try-catch + exponential backoff ← 大家都做了 故障類型 B：軟故障（Soft / Silent Failure） ├─ HTTP 200，但 payload 格式錯誤（日期、時區、貨幣單位） ├─ HTTP 200，但欄位語意漂移（status: "in_transit" 變成 "IN_TRANSIT"） ├─ HTTP 200，但數值精度錯誤（公斤 vs 磅的混用） └─ 對策：需要 Schema 校驗 + 反思修正 ← 多數人沒有做 軟故障是最危險的，因為它看起來成功。下游的 SQL Agent 或 Pandas DataFrame 會靜默地接受垃圾數據，直到幾小時後報表出現異常才被發現，彼時已有幾萬筆記錄污染了資料庫。https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part52-tool-fanout-optimization-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part52-tool-fanout-optimization-zh/大多數工程師遇到「Agent 要並行呼叫 15 個 API」時，第一反應是 asyncio.gather()，然後假設「全部回來再合併」。 真正的 Staff FDE 知道：gather 是把所有雞蛋放進同一個計時炸彈。 正確答案不是「更快地等待」，而是動態熔斷、投機複製、強制截止、局部渲染——在 1.5 秒內交出 80% 的答案，比等 30 秒的「完美答案」更有價值。 系統設計的成熟度，體現在你如何優雅地處理你控制不了的那 20%。 面試情境 面試官：「你負責一個 AI 理財 Agent 的後端架構。用戶問：『幫我分析我持有的 15 檔美股今天的技術指標。』Agent 需要並行呼叫 15 次外部股票 Data API。請問：（1）如果單純用 asyncio.gather() 並行發起，你能預期哪些生產環境問題？（2）你會如何設計一個能應對 API 超時、Rate Limit、部分失敗的進階工具執行引擎？請從架構、程式碼模式、降級策略三個維度說明。」 一、核心問題：為什麼 gather() 在生產環境是炸彈 1.1 問題的表面現象 理財 Agent 接到用戶指令：「分析我持有的 AAPL、TSLA、NVDA… 等 15 檔美股的技術指標」。 Agent 的工具調用計畫很清楚：針對每一個股票代號，呼叫一次 get_stock_indicators(ticker) ——這是 15 次獨立的外部 HTTP 請求。 最直覺的實作是： 1results = await asyncio.gather( 2 *[get_stock_indicators(ticker) for ticker in tickers] 3) 順序執行的基準延遲：15 calls × 平均 2s per call = 30 秒。用戶體驗直接崩潰。https://yennj12.js.org/yennj12_blog_V4/posts/langgraph-ai-customer-ticket-system-zh/Sat, 11 Apr 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langgraph-ai-customer-ticket-system-zh/詳細講解如何使用 LangGraph 和 AI 構建生產級的智能客服工單處理系統，涵蓋架構設計、Agent 定義、狀態管理、錯誤處理和實際案例，幫助你快速上線 AI 驅動的客服系統。https://yennj12.js.org/yennj12_blog_V4/posts/langgraph-langchain-intro-zh/Sat, 11 Apr 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langgraph-langchain-intro-zh/全面介紹 LangChain 和 LangGraph 的核心概念、架構和實戰應用，涵蓋從簡單的 Chain 到複雜的多 Agent 工作流，幫助開發者快速掌握現代 AI 應用開發框架。https://yennj12.js.org/yennj12_blog_V4/posts/langgraph-ai-backend-ideas-zh/Sat, 11 Apr 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langgraph-ai-backend-ideas-zh/探索 LangGraph AI 後端在 10 個不同行業和場景的創意應用，從客服系統到內容創作、從數據分析到程式碼生成，展示 LangGraph 的真正潛力和未來發展方向。https://yennj12.js.org/yennj12_blog_V4/posts/langgraph-ai-backend-architecture-zh/Sat, 11 Apr 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langgraph-ai-backend-architecture-zh/深入講解如何設計可擴展、高性能的 LangGraph AI 後端架構，涵蓋從單體應用到微服務的演進，包括 Agent 拓撲、數據流、錯誤恢復、分佈式協調等生產級設計模式。https://yennj12.js.org/yennj12_blog_V4/posts/langgraph-ai-backend-core-code-zh/Sat, 11 Apr 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langgraph-ai-backend-core-code-zh/提供可直接用於生產環境的 LangGraph AI 後端核心代碼實現，包括完整的 FastAPI 集成、持久化層、錯誤處理、監控日誌等，幫助開發者快速構建產品級應用。https://yennj12.js.org/yennj12_blog_V4/posts/langgraph-ai-backend-logic-zh/Sat, 11 Apr 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langgraph-ai-backend-logic-zh/深入探討 LangGraph 工作流的邏輯設計，包括狀態定義、決策路由、條件轉移、複雜路徑選擇等，透過實戰案例展示如何設計清晰、高效、易維護的 AI 後端邏輯。