https://yennj12.js.org/yennj12_blog_V4/tags/fanout/Recent content in FanOut on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-14-speculative-tool-fanout-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-14-speculative-tool-fanout-zh/核心定義：Speculative Tool Execution（投機工具執行）是在 Agent 大扇出場景下，透過「投機雙發」消滅慢尾端呼叫、「硬截止時間 + 部分結果標注」防止最慢的單一 API 拖垮整體回應，讓 N 個並行工具呼叫的完成時間趨近第 50 百分位而非第 99 百分位延遲。 一、為什麼面試官問這個 面試官真正在測試的是你對尾部延遲（Tail Latency）的工程直覺，以及你能否在「並行 = 快」的表面認知背後，看見「任一慢者拖垮全局」這個隱藏陷阱。這題在 FDE 面試、平台工程師面試中高頻出現，因為 LLM Agent 架構幾乎都有大扇出需求——爬多個資料源、同時呼叫多個外部 API、並行執行多個查詢工具——而大多數候選人對這個問題的認識停留在「用 asyncio 並行就好」。 測試點一：尾部延遲量化能力。 你能否當場說清楚：15 個呼叫各有 P50=2s、P99=3s 的延遲分佈，asyncio.gather 的完成時間趨近所有呼叫延遲的最大值，而非平均值。數學上，15 個獨立隨機變數的最大值期望值遠大於單一變數期望值。面試官想看到工程師對資源等待的量化直覺，而不是模糊的「並行比序列快」。 測試點二：降級設計思維。 你能否清楚說明「不需要所有資料才能給出有用回應」，並設計出讓 LLM 在缺少部分資料時仍能產出帶標注的分析，而不是直接報錯或讓使用者白等到逾時。弱候選人把「部分成功」當例外狀況處理；強候選人把部分成功當主路徑設計，並知道如何在 System Prompt 中預先教會模型處理缺失欄位。 測試點三：熔斷與防護層設計。 能否描述 Circuit Breaker 的三個狀態（Closed / Open / Half-Open）、觸發條件（連續失敗 5 次 → 開路 30 秒）、以及如何與投機雙發機制協同而不互相衝突（例如：熔斷開路時不應再觸發 hedge，應直接走備援路徑）。 弱答案典型樣貌： 「我用 asyncio.gather 並行呼叫，然後設一個 timeout 參數。」無法量化改善幅度、未討論部分結果標注、不知道 gather 與 wait 的差異、沒有熔斷機制設計、沒說清楚 SSE 與輪詢的取捨。