https://yennj12.js.org/yennj12_blog_V4/tags/asyncio/Recent content in AsyncIO on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 09:00:00 +0800https://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 秒。用戶體驗直接崩潰。