https://yennj12.js.org/yennj12_blog_V4/tags/react/Recent content in ReAct on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 05:30:00 +0800https://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/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-part9-llm-core-zh/Sun, 31 May 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part9-llm-core-zh/這篇是 FDE 面試系列的最後一篇基礎知識篇。 LLM 的這三塊——Token、Prompt Engineering、Embedding—— 是你每天都在用的工具，但能說清楚的人比你想像中少。 說得清楚，就是專業的訊號。 面試情境 面試官：「你的 RAG 系統的 context budget 怎麼設計的？如果你要讓 LLM 做複雜推理，你用什麼 Prompting 技法？為什麼選 text-embedding-004 而不是 OpenAI 的 embedding？」 這三個問題把 Token、Prompt Engineering、Embedding 串在一起問，測的是你有沒有把這些工具整合進系統設計的意識。 一、Token：不是字，是 LLM 的計量單位 面試官問： 「Context Window 是什麼？對你的系統設計有什麼影響？」 Token 是什麼 LLM 不是以字元或單詞為單位處理文字，而是以 Token 為單位。 Token 是 Tokenizer 切出來的文字片段，大小不固定： "Hello world" → ["Hello", " world"] → 2 tokens "LLM" → ["L", "LM"] → 2 tokens（或 1 token，取決於 tokenizer） "不可思議" → ["不", "可", "思", "議"] → 4 tokens（中文通常 1 字 = 1 token） 粗略換算（GPT/Gemini 系列）：https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part1-loop-memory-zh/Sun, 21 Jun 2026 22:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part1-loop-memory-zh/大多數人把 AI Agent 當成「會呼叫工具的 ChatBot」， 以為加幾個 function call 就完成了； 真正的 Agent 工程需要持久記憶、確定性狀態機、可觀測的思考迴圈， 差距不在 LLM，在你能不能讓它在第 20 步還知道自己在做什麼。 面試情境： 你是某電商平台的 AI 基礎設施 Lead。PM 要求將現有的「單次 GPT 呼叫客服」升級為「可自主完成退款、查單、更換地址」的 Agent，日均對話量 80K，P99 回應時間需在 8 秒以內。請問你如何設計 Agent 迴圈、記憶系統與上下文管理策略，並說明在 MVP 和 Scale 兩個階段的架構差異？ 一、核心問題：什麼是真正的 AI Agent 單次 LLM 呼叫（stateless call）與真正的 Agent之間有一道本質的鴻溝。 前者每次呼叫都是白紙一張，不知道剛才做了什麼，也不知道任務完成到哪裡；後者具備三個關鍵能力： 自主決策迴圈：在沒有人類介入的情況下，重複「感知→思考→行動→觀察」直到任務完成或確認無法完成。 跨步驟記憶：第 15 個步驟還能記得第 1 個步驟收集的用戶資料，不會重複詢問相同問題。 工具組合能力：可以依情境選擇不同工具，並根據工具回傳結果調整下一步計畫。 為什麼這很難？ LLM 本身是無狀態的（stateless）。每次 API 呼叫都是獨立的 HTTP 請求，沒有跨請求的記憶。Agent 框架必須在應用層解決： 上下文視窗有限：GPT-4o 128K tokens，換算約 96K 中文字。長任務無法全塞。 幻覺累積問題：步驟越多，錯誤累積越嚴重，必須設計檢查點。 成本爆炸：每步驟都傳完整歷史，128K token × $5/1M input = 每步 $0.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part2-capstone-agent-product-zh/Mon, 22 Jun 2026 05:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part2-capstone-agent-product-zh/大多數人做法：把 ChatGPT API 包一層 wrapper，加幾個 if-else，叫它「AI 客服 Agent」。 正確答案：ReAct 迴圈 + 工具安全閘 + 對話記憶 + Guardrails + 完整可觀測性， 缺少任何一層，上線兩週後你就會收到第一封「Agent 幫客戶退了根本沒問題的訂單」的事後報告。 本文是一個真實 Sprint 4 週期的工程回顧，紀錄哪些設計決策讓我們撐過了 100K sessions/day。 面試情境 你的公司想把電商客服從人工轉為 AI Agent，日均客服量約 30K sessions，高峰期（雙 11）可能到 80K。客服範圍包含訂單查詢、退換貨申請、產品推薦以及升級至人工。請描述你會如何設計這個系統，從 MVP 到可以承受 80K sessions/day 的生產架構，並說明關鍵的工程決策與取捨。 一、專案目標：AI 客服 Agent 的真實產品需求 這個 Capstone 專案的原型來自一個真實的電商平台改造案。業務背景很清楚： 現狀：人工客服 45 人，平均回應時間 4.2 分鐘，CSAT 3.7/5，月薪資成本 $180K USD 目標：AI 處理率 ≥ 70%，平均回應時間 < 8 秒，CSAT ≥ 4.0/5，月 AI 成本 < $35K 風險底線：不能有金融損失（錯誤退款、錯誤折扣），不能有個資外洩 拆解需求後，Agent 需要具備五種能力：