https://yennj12.js.org/yennj12_blog_V4/tags/checkpoint/Recent content in Checkpoint on YennJ12 Engineering BlogHugo -- gohugo.ioen-usThu, 04 Jun 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part21-async-longrunning-agent-zh/Thu, 04 Jun 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part21-async-longrunning-agent-zh/HTTP 請求的超時通常是 30~60 秒。 你的 Agent 需要 30~60 分鐘。 這不只是「把 timeout 調大」的問題—— 這是一個需要重新設計請求/回應模型的架構問題。 面試情境 面試官： 「客戶想打造一個自動化市場競品分析 Agent。當用戶輸入指令，Agent 需要搜尋 50 個網頁、調用大數據分析工具、撰寫 20 頁報告。整個工作流需要 30 分鐘到 1 小時。你如何設計後端分散式架構？如果執行到第 25 分鐘時某個節點崩潰，如何確保不從頭來過？」 一、核心問題：同步 HTTP 模型的三個致命限制 同步模型（不可行）： 用戶發出請求 │ ▼ HTTP Request ───────────────────────────────── 等待 60 分鐘？ │ HTTP Response ← 60 分鐘後 ← 如果連線斷了呢？ 如果手機鎖屏了呢？ 如果用戶換了瀏覽器分頁呢？ 三個根本限制： 限制 1：HTTP 超時 └─ 大多數 Load Balancer、API Gateway 的 timeout 是 30~300 秒 Agent 跑 60 分鐘，連線早就被中斷 限制 2：無法容錯 └─ 如果 Worker 在第 25 分鐘崩潰 用戶必須從頭開始，浪費 25 分鐘的 Token 成本 限制 3：無法水平擴展 └─ 一個請求佔用一個 Thread 60 分鐘 100 個並發用戶 → 需要 100 個長期佔用的 Thread → 資源利用率極低 二、解決方案：解耦架構（Decoupled Architecture） 核心設計原則： 請求接收 和 任務執行 完全解耦 用戶 和 任務結果 透過 異步機制溝通 ┌──────────────────────────────────────────────────────────────┐ │ 完整系統架構 │ │ │ │ ┌────────────────────────────────────────────────────────┐ │ │ │ 用戶端（Frontend） │ │ │ │ ┌──────────────────────────────────────────────────┐ │ │ │ │ │ 1.