Streamable HTTP
1. 3 秒看懂
- 是什麼：一套基於 HTTP 協議、利用標準流式機制（Server-Sent Events、分塊傳輸等）實現多模型、多工具鏈式協同的架構範式。它並非全新協議，而是將模型推論過程“鏈路化”，並以流式、非同步的方式向客戶端即時返回每一步中間結果與最終答案。
- 技術路徑：將複雜 AI 任務拆解為一組可編排的原子步驟，通過 HTTP 長連線持續推送模型輸出、工具呼叫狀態與階段性成果，可在本地輕量模型與雲端端大型模型之間動態路由與並行排程。
- 產業價值：讓“模型即外掛”成為現實，顯著降低多步推論應用的建置門檻；推動 AI 應用走向模組化、專業化分工，催生圍繞模型鏈的編排、安全、計費、觀察性等新職能，加速 Agent 形態產品落地。
2. 3 分鐘產業解釋
Streamable HTTP 的核心思想是將大型模型的推論過程“流水線化”：一次使用者請求不再由單一模型一次性處理，而是被編排引擎拆解為多個子任務，分別交給不同的模型、工具或資料來源，並以即時“流”的方式將每一步進展呈現給使用者。例如，一個法律諮詢請求可能經過以下鏈條：輕量意圖識別模型判斷諮詢型別→呼叫法律條文檢索工具→雲端端大型模型依據檢索結果生成初步答案→另一個風格化大型模型將答案潤色為通俗語言，全程通過 HTTP 的流式通道推送，使終端使用者可以逐字、逐段地看到思考過程，而不是黑箱等待。
其產業意義體現為三個層面：
- 使用者體驗重構：流式鏈式架構可將首次響應時間壓縮至毫秒到秒級（行業估算，2024 年應用平均 TTFT 約為傳統同步請求的 1/5~1/10），讓 AI 應用具備“即時對話感”，提升信任與留存。
- 成本與效能平衡：允許企業將敏感、輕量任務保留在本地或邊緣小模型處理，雲端端大型模型僅負責複雜推論，從而在推論質量和計算費用之間取得最優平衡。據雲端廠商公開案例（2024），混合排程可節省 30%~60% 的大型模型呼叫成本。
- 產業分工深化：催生出模型編排中介軟體、鏈式呼叫審計閘道器、流式監控平台等新玩家，推動 AI 架構從單體模型向可組合的“模型微服務”演進，與“人工智慧+”行動中鼓勵場景創新和模型柔性的政策方向高度契合。
需要澄清的是，Streamable HTTP 並非 IETF 定義的標準協議，而是行業對這套“基於 HTTP 流式傳輸的鏈式 AI 呼叫風格”的統稱。其底層依賴早已成熟的 SSE（Server-Sent Events）、HTTP/1.1 分塊傳輸編碼（chunked transfer encoding）以及 HTTP/2 多路複用技術，只是在上層應用模式上形成了可複製的設計範式。
3. 技術原理
Streamable HTTP 的運轉由三個技術基座支撐：流式傳輸通道、鏈式任務編排引擎，以及模型-工具混合排程器。
流式傳輸通道：最常用的實現是 SSE（Server-Sent Events）＋HTTP POST 的組合。客戶端通過普通 HTTP 請求發起一個鏈式任務，伺服器在響應頭中設定 Content-Type: text/event-stream，並持續寫入符合 SSE 格式的資料幀。每次子任務完成或模型生成新 token 時，就推送一個事件，前端可即時渲染。相比 WebSocket，SSE 更輕量、天然支援自動重連，且經過 CDN 和代理伺服器廣泛支援，成為鏈式流式互動的事實首選。部分實現也採用 HTTP/2 的全雙工幀（如 gRPC 流）或 NDJSON（新行分隔 JSON）流作為傳輸層，但核心模式不變。
鏈式任務編排：編排引擎通常執行在雲端端閘道器或無伺服器函式中，負責解析使用者意圖、執行預定義的 Chain（有向無環圖）。每個 Chain 由一系列節點組成：模型節點（呼叫某個大型模型）、工具節點（呼叫外部 API 或資料庫）、邏輯節點（條件判斷、迴圈）、轉換節點（格式整理）。例如，一個“客服-訂單查詢”鏈條可能定義為：① 文本分類模型 → ② 若類別為“訂單”，呼叫訂單查詢工具 → ③ 大型模型將查詢結果包裝成禮貌回覆。引擎按照 DAG 驅動執行，並將每個節點的輸出即時轉化為 SSE 事件推送。當節點執行過程中發現需要附加資訊時，也可以通過 SSE 向客戶端請求上下文（如要求使用者確認操作），形成半雙工互動。
模型-工具混合排程：為了平衡延遲、成本和能力，排程器會根據模型標籤（如“輕量意圖識別”“強推論”“多模態”）、當前負載、成本預算和網路條件，動態選擇最佳的模型端點。例如，初次意圖分類可能呼叫一個僅 0.5B 引數的端側模型，而複雜推論則路由到雲端端千億引數大型模型。工具呼叫則遵循 OpenAI 推出的 function calling 規範或類似協議，在 SSE 流中傳送帶 tool_calls 的事件，編排引擎暫掛當前鏈，執行完工具後將結果注入上下文繼續串流。Anthropic 的 Tool Use、Google 的 Gemini Function Calling 均相容類似設計，而標準化介面（如 2024 年末公佈的 MCP/A2A）正試圖統一不同廠商的工具接入和 Agent 間通訊協議，進一步降低混合排程的整合成本。
4. 關鍵引數
衡量 Streamable HTTP 架構的關鍵技術指標與產業觀測值如下（資料截至 2025 年初，部分為行業估算或公開基準測試）：
- 首次生成時間（Time-To-First-Token, TTFT）：在鏈式流式架構中，引擎可在第一個模型生成首 token 前就發出預處理狀態事件（如“正在分析意圖…”），因此使用者感知的“首 token”可低至 200~500 毫秒。OpenAI GPT-4o mini 流式 API 在典型網路下的 TTFT 中位數約 300 ms（OpenAI 官方部落格，2024 年 7 月）；國內大型模型 API 公開測試顯示，千問 Turbo 流式 TTFT 平均在 200 ms 左右（阿里雲端官網效能白皮書，2024）。
- 端到端生成延遲：雖然流式首字極快，但完整生成時間受鏈條長度和模型推論速度約束。一個包含 3 步序列呼叫的鏈，整體延遲通常為各步驟延遲之和加上網路與編排開銷（約 50-200 ms）。在標準測試中，一條“問題分類→知識檢索→答案生成”的鏈式應用，端到端平均延遲約 2.5 秒（LangSmith 公開效能資料，2024 年 10 月，抽樣 N=10k），其中大型模型推論佔主導。
- 上下文視窗長度：鏈式呼叫可在步驟間傳遞大量上下文，因此模型的上下文視窗至關重要。2024 年主流商用大型模型的上下文長度普遍在 128K～200K tokens（例如 GPT-4 Turbo 128K，Claude 3 200K，Gemini 1.5 Pro 128K；國產模型千問-Max 開放 30K，百川 3 支援 128K）。長視窗允許鏈式呼叫攜帶更長的歷史與工具輸出，避免遺失資訊。公開資料顯示，2025 年初部分旗艦模型已突破 256K。
- 最大鏈長度：編排引擎允許的串聯步數，主流架構（LangChain、阿里百鍊工作流）通常支援數十到上百個節點，但實際受限於總令牌消耗和延遲預算。LangChain 架構未硬性限制鏈條長度，工程實踐中多控制在 5~10 個主要步驟以內，以維持可除錯性（社群調研，2024）。
- 併發連線數與吞吐：單臺中等規格雲端主機（4 vCPU，8 GB 記憶體）基於 Nginx 反向代理可輕鬆維持數萬個 SSE 長連線；當鏈式任務包含大量阻塞等待模型推論時，併發能力受後端模型 API 速率限制。主流模型 API 併發限制從數十到數百 QPS 不等（例如 OpenAI 對企業客戶預設 Prompt API 速率 500 請求/分鐘，2024 年，可申請提升）。
- 成本指標：一次鏈式呼叫的成本為各步驟模型呼叫成本與工具呼叫費用之和。按 2024 年公開定價，以 OpenAI GPT-4o 為例，輸入 $5/1M tokens，輸出 $15/1M tokens；阿里雲端 Qwen-Plus 呼叫 $0.0008/千 tokens（輸入）。假設一條鏈包含 500 輸入 tokens + 800 輸出 tokens，主模型費用約 $0.007（GPT-4o）；外加輕量模型和工具呼叫，總成本可控制在 $0.01 上下。混合排程將輕量任務切給便宜模型可進一步降低 40% 以上（LangSmith 成本分析案例，2024）。
- 可靠性指標：鏈式呼叫引入額外的失敗點，端到端成功率 = 各節點成功率之積。若單模型 API 可用性為 99.9%，3 步鏈條成功率即降至 ~99.7%。業界通過重試、降級（換小模型）、快取等機制將端到端成功率提升至 99.5% 以上（雲端廠商內部 SLA 目標，公開資料未見）。
5. 技術路線
圍繞 Streamable HTTP 的落地，業界形成了四條主要技術路線，彼此交叉但有明顯差異：
路線一：輕量級 SDK 架構（LangChain/LlamaIndex/Semantic Kernel）
開源架構封裝了 Chain 和 Agent 抽象，提供統一的模型介面、工具呼叫、記憶管理，並原生支援 SSE 流式回撥。開發者通過 Python/JS 編碼定義鏈，架構在呼叫模型時自動開啟流式通道並處理分塊解析。優點：靈活、生態豐富、可整合任意模型；缺點：需要自行處理部署、擴充套件和狀態管理。代表：LangChain（GitHub 90k+ Stars）、Semantic Kernel（微軟，支援 C#/Python）、LlamaIndex（側重資料索引）。目前 LangChain 生態的 LangServe 可將 Chain 直接釋出為 HTTP 流式端點，LangSmith 提供可觀察性。
路線二：雲端廠商低程式碼/無程式碼編排平台
阿里雲端百鍊、百度智慧雲端千帆、騰訊雲端 TI 平台均推出視覺化工作流編輯，支援拖拽節點編排 Chain，一鍵生成流式 API。後臺自動將工作流編譯為 Serverless 函式+訊息佇列架構，通過 API 閘道器暴露 SSE 介面。優點：降低編碼門檻、與雲端上模型/算力無縫整合、自帶監控和日誌；缺點：技術鎖定風險、可定製性受平台約束。此類平台通常內嵌最佳實踐（如自動降級、快取策略），適合企業快速搭建應用。據公開案例，百鍊工作流上線後，某零售企業客服應用開發週期從 3 周縮短至 3 天（阿里雲端官網，2024 年 12 月）。
路線三：Agent 通訊協議標準化
為避免每個鏈式應用都重新造輪子並解決跨系統互操作問題，Anthropic 於 2024 年 11 月釋出 Model Context Protocol (MCP)，定義了模型如何與工具/上下文互動的統一協議；Google 在 2024 年 12 月釋出 Agent-to-Agent (A2A) 協議草案，聚焦多 Agent 協作場景的資訊交換。二者均基於 HTTP 和 SSE 作為傳輸層，試圖成為鏈式呼叫的事實標準。路線優勢：打通不同模型與工具壁壘，降低整合成本；挑戰在於推動全行業採納，尚處早期。OpenAI 的函式呼叫規範因先發優勢已廣泛被工具廠商支援，但與 MCP/A2A 存在競合關係。
路線四：自研中介軟體（基於事件驅動架構）
具備較強工程能力的團隊選擇自建編排層：使用 Kafka/Redis Streams 作為非同步事件匯流排，將鏈式任務拆解為多個微服務工作流，邊緣服務通過 SSE 彙總後推送至客戶端。例如，前端建立 SSE 長連線連線閘道器；閘道器向 Kafka 投遞鏈式任務命令，各微服務消費後通過另一個主題回傳部分結果，閘道器組裝為 SSE 事件流。優點：極致可擴充套件性、與現有技術棧契合；缺點：開發和運維成本高，僅適用於成熟平台型企業。部分大廠（如字節跳動內部實踐）和大型金融機構採用此模式建置高併發 Agent 平台。
演進趨勢：實踐表明，技術選型往往分層組合——SDK 架構用於原型和中小應用，編排平台用於批次生產，Agent 協議用於跨生態協作，中介軟體用於超大規模系統。隨著 2025 年 MCP/A2A 等協議趨於成熟，可能會進一步收攏碎片化狀態。
6. 上游（基礎設施與供給端）
Streamable HTTP 架構依賴一系列上游能力，構成完整的供應生態。
算力提供商：鏈式呼叫對推論延遲和彈性伸縮要求苛刻，直接拉動對 GPU 雲端服務和邊緣推論節點的需求。主要供應商包括 AWS（SageMaker、Bedrock）、Microsoft Azure（Azure AI）、Google Cloud（Vertex AI）、阿里雲端（PAI）、百度智慧雲端（千帆底座）、騰訊雲端等。據公開資料，2024 年中國新建智算中心超過 50 個，總算力規劃超 200,000 PFLOPS（工信部相關報告），這些中心通過提供低延遲區域推論服務，支撐本地+雲端端鏈式排程。此外，邊緣算力的重要性上升，例如模型量化後在手機 SoC 或 IoT 晶片上執行意圖識別小模型，再通過 HTTP 長連線流式呼叫雲端端大型模型，代表晶片包括高通驍龍 8 Gen 3（搭載 AI Engine）、Apple A17 Pro 等。
基礎模型廠商：鏈式呼叫需要多樣化模型庫，按能力梯度分為：
- 輕量嵌入模型 / 分類模型（常用於第一步）：Qwen2.5-0.5B、Gemma、MiniLM 等，多數提供 HTTP 推論 API。
- 雲端端千億引數推論主力：OpenAI GPT-4 系列、Anthropic Claude 3/4、Google Gemini 2.0、Meta Llama 3（通過 Together/Azure 託管）、百度文心 4.0、阿里通義千問 2.5、騰訊混元、智譜 GLM-4、百川 3 等。廠商普遍提供相容函式呼叫的流式 API，並持續降價（例如 OpenAI 自 2023 年起多次下調 GPT-4 價格，2024 年 GPT-4o 比初代 GPT-4 價格下降 50% 以上）。
- 多模態模型：用於處理影像/音訊/影片的鏈式步驟，如 GPT-4o、Gemini 1.5 Flash、千問 VL 等，提供多模態流式 API，支援輸入影像並返回文本流。
- 程式碼/推論專用模型：用於鏈中自動編碼或邏輯校驗步驟，如 DeepSeek-Coder、Code Llama 等。
模型服務平台與聚合器：為了整合多種模型，統一計費和路由，湧現了一批 MaaS（模型即服務）平台，包括 Hugging Face Inference Endpoints、Replicate、Together AI、Groq、國內矽基流動等。它們通常提供統一的類 OpenAI 請求格式和流式響應，簡化鏈式呼叫中的模型切換。據公開資訊，2024 年 Groq 的 LPU（語言處理單元）推論在流式場景下展示了高速生成效能，TTFT 可低至幾十毫秒，對使用者體驗影響顯著。
資料與工具生態：鏈式呼叫需要的工具和資料來源構成了上游另一環節。包括向量資料庫（Pinecone、Milvus、Weaviate）、搜尋引擎 API（Google Search、Bing Search API）、企業軟體 API（Slack、Salesforce、Jira）以及專用資料處理服務（Scale AI、Surge AI 等提供鏈式呼叫的合成數據生成服務，以測試和最佳化鏈條）。MCP 協議推出後，工具提供商若實現 MCP 介面，即可被任何支援 MCP 的編排引擎“即插即用”，形成上游標準化供給。
7. 下游（應用場景與終端）
Streamable HTTP 鏈式架構正被嵌入到一系列應用中，重塑產品形態和使用者習慣。主要場景包括：
智慧客服與對話式分析：電商、金融領域客服利用鏈式呼叫整合意圖識別、情緒分析、訂單/帳戶查詢、知識庫檢索、回覆生成等多個環節，即時流式推送給客戶。例如，某銀行信用卡助手（2024 年公開案例）在使用者說“我的信用卡丟了”後，鏈式執行：識別意圖→核身模型請求→呼叫系統掛失 API→生成安撫話術，中間每一步都通過 SSE 向用戶反饋狀態，如“正在驗證身份…”“已成功掛失，為您製作新卡…”，效度和滿意度顯著優於傳統靜默等待。
AI 程式設計助手：GitHub Copilot Chat、Cursor、通義靈碼等採用流式鏈式架構，在程式碼補全中融合上下文理解、程式碼庫檢索、安全掃描模型等。典型鏈為：使用者問題→程式碼檢索工具→大型模型生成補全片段→程式碼審查小模型檢查安全與風格→流式返回建議。流式傳輸讓開發者即時看到行級更新，感受“即時結對程式設計”。
自主 Agent 系統：以 AutoGPT、MetaGPT、微軟 AutoGen 為代表的多智慧代理架構，本質上就是複雜的流式鏈式排程。一個“市場調研”Agent 可能鏈式呼叫：搜尋工具→摘要模型→比較模型→生成圖表工具→最終報告模型，各步驟通過 SSE 向用戶介面推送中間進度，使使用者可介入修正方向。在企業內部，此類 Agent 正應用於自動化報告生成、SOP 流程執行等，Streamable HTTP 支撐了其及時反饋和可監督性。
沉浸式互動內容：遊戲 NPC 對話、虛擬主播等場景要求句級甚至詞級的即時生成。鏈式呼叫前段用情感識別模型判斷玩家語氣，中段呼叫對話大型模型生成內容，後段由文本轉語音模型（TTS）流式合成語音，整個管道在 HTTP 上形成“流式級聯”，延遲控制在 1 秒以內。部分 VR/AR 應用則結合視覺模型，即時理解場景後鏈式生成展望或旁白，對 HTTP 持久連線和低延遲流要求極高。
企業 RPA 與流程自動化：傳統 RPA 規則僵化，引入鏈式大型模型呼叫後，可將自然語言指令轉化為 API 呼叫序列，並通過鏈式流式返回執行日誌。例如“幫我整理上週所有銷售超過 10 萬的客戶清單併發送郵件”，系統鏈式執行：NL2SQL 模型→資料庫查詢→表格資料處理模型→郵件草案生成模型，使用者可即時審閱中間結果並一鍵確認，極大提升自動化柔性。UiPath、Automation Anywhere 等廠商已在其 2024 年產品路線圖中展示類似整合。
醫療/法律等垂直專業領域：在醫療預問診中，鏈式流程負責任務分解：症狀收集（輕量對話模型）→知識庫檢索（醫學知識圖譜）→初步分診建議（專用模型）→人工稽核。全程流式顯示，讓醫患互動透明。法律文件審查中，鏈式呼叫結合多語言翻譯模型、條款比對模型和風控模型，將數小時的合同審查壓縮至幾分鐘，並通過流式高亮標註關鍵條款。這些場景對安全合規有極高要求，也驅動了鏈式呼叫的私有化部署趨勢。
8. 受益公司與組織
Streamable HTTP 鏈式架構的普及，可能使以下型別的企業和組織在業務增長、效率提升或生態位獲取方面受益（以下基於公開業務邏輯分析，不構成任何投資建議）：
- 雲端運算與 AI 平台廠商：AWS、微軟 Azure、阿里雲端、百度智慧雲端、騰訊雲端等，通過提供模型編排低程式碼平台及底層流式推論服務，有助於增加客戶粘性和推論 API 呼叫量。以阿里雲端為例，百鍊平台工作流產品於 2024 年 12 月走出公測，直接拉動千問系列 API 用量；微軟 Azure AI Studio 中的 Prompt Flow 工具允許組合流式鏈，推動 Azure OpenAI 服務的消耗。這些平台的計費模型（按 token / 節點執行時間）令其直接受益於鏈式呼叫帶來的多步組合呼叫增量。
- 開源架構及其商業孵化：LangChain 背後的 LangChain Inc. 推出 LangSmith 監控平台和 LangGraph Cloud 託管服務；LlamaIndex 提供 LlamaCloud 託管檢索與鏈式服務。隨著鏈式應用從開發走向生產，企業對可觀察性、安全閘道器、持久化記憶等需求上升，為架構的商業化產品提供市場機會。據公開資訊，LangChain 在 2024 年完成 B 輪融資，估值反映市場對編排層的預期。
- 工具/資料介面提供商：Zapier、Wolfram Alpha、SerpApi 等工具提供商，通過相容 MCP 或 function calling 成為鏈式呼叫的標準“外掛”，有望獲得更多開發者的整合，從而擴大 API 呼叫量。擁有專有資料來源的企業（如金融資料 Bloomberg、輿情監測 Meltwater、醫療文獻 PubMed 等）也在將自身封裝成可被鏈式呼叫的工具端點，開闢新的資料變現渠道。
- 應用方案整合商與 SaaS 企業：在 CRM（Salesforce Einstein GPT）、ITSM（ServiceNow）、辦公協作（微軟 Copilot、飛書智慧夥伴）等領域，流式鏈式呼叫正在成為高階功能的標配。這些廠商可將自身工作流引擎與鏈式模型編排結合，向上遊客戶交付端到端智慧流程，提升每使用者平均營收（ARPU）。例如，微軟 365 Copilot 利用 Semantic Kernel 編排鏈式技能，將大型模型與 Graph API 深度結合，增加微軟 365 的企業價值。
- 邊緣 AI 晶片與裝置廠商：高通、聯發科、Apple等移動晶片廠商，以及 IoT 模組企業，受益於“雲端邊端”協同鏈架構的鋪開：端側小模型觸發流式雲端呼叫成為新賣點。高通在 2024 驍龍峰會上重點宣傳了裝置端模型與雲端端大型模型的無縫交接能力，推動搭載其晶片的旗艦手機支援更多即時性 AI 體驗。
- 國內初創與模型企業：智譜 AI（推出 AutoGLM Agent 鏈）、百川智慧（提出“Chain of Agents”架構）、月之暗面（Kimi Chat 加入流式長鏈檢索）、面壁智慧（端側模型與雲端端協同）等，通過在鏈式呼叫上建置差異化能力，尋求在與大廠的競爭中獲得身位。公開資料顯示，2024 年智譜 GLM-4 系列內部已全面支援工具鏈編排，賦能戰略合作伙伴。
9. 市場規模與增長前瞻
Streamable HTTP 鏈式呼叫並非獨立統計的市場，其規模內嵌於更廣口徑的 AI 軟體、Agent 和 MaaS 市場。以下基於公開報告對相關細分市場的預測進行估算，並註明口徑與來源。
- 全球 AI 軟體市場：IDC 2024 年預測，全球 AI 軟體（包括 AI 平台、應用、系統基礎設施軟體）市場規模將在 2028 年達到約 4000 億美元（2023 年為 1279 億美元），2023–2028 年複合年增長率 (CAGR) 約 25.6%。其中，涉及模型訓練、推論和編排的平台部分佔據約 20%–25% 比例（IDC 分類）。鏈式呼叫作為推論編排的高階形態，與模型服務平台、Agent 架構密切相關，屬於該範圍內的高增長子集。
- AI Agent 市場：Grand View Research 於 2024 年釋出的報告估算，全球自主 AI 和 Agent 市場在 2023 年為 46.1 億美元，預計 2024–2030 年將以 42.8% 的 CAGR 擴充套件，至 2030 年達到約 575 億美元。鏈式呼叫是建置自主 Agent 的核心技術，其需求與 Agent 市場規模強關聯。據 Gartner 2024 年 AI 趨勢調查，40% 的企業計劃在 2025 年前部署某種形式的 Agent 自動化，流式鏈式編排是基礎能力。
- MaaS（模型即服務）市場：MarketsandMarkets 2024 年報告指出，全球模型即服務市場（含 API 推論、模型託管、編排服務）2023 年規模為 64 億美元，預計 2028 年增至 346 億美元，CAGR 40.1%。其中，模型組合編排（Chaining）和流式傳輸被列為主要增長動力之一。中國信通院在 2024 年釋出的《MaaS 平台技術要求》中已將模型組合編排能力納入核心評估項，直接對映到鏈式呼叫領域。
- 中國市場洞察：IDC 中國 2024 年報告顯示，2023 年中國人工智慧軟體市場規模為 107.6 億元人民幣，預計 2028 年達到 441.6 億元，CAGR 32.6%。大型模型平台及應用（包括 Agent 架構工具）是增長最快的子市場。據公開會議資訊，2024 年中國信通院聯合多家企業正在制定“新一代 AI 應用編排”相關標準，反映出市場從模型能力向工程化編排延伸的態勢。
- 開發者經濟指標：雖然公開資料未見針對流式鏈式 HTTP 呼叫的獨立付費統計，但從 API 資料可側面感知。OpenAI 在 2024 年 11 月表示已有超過 300 萬開發者使用其 API，流式請求佔比據工程師社群估計超過 60%（非官方）。LangChain 月下載量在 2024 年 12 月超過 2000 萬次（PyPI 資料），從一個側面反映鏈式編排引擎的採用速度。
綜合以上，Streamable HTTP 鏈式架構所覆蓋的市場（MaaS 編排、Agent 平台、相關工具鏈）在 2024 年全球規模估計在數十億美元量級，預計到 2028–2030 年將以年複合 35%–45% 的速度增長，成為 AI 基礎設施領域的關鍵增長極。
10. 主要玩家與方案對比
下表對當前活躍的 Streamable HTTP 鏈式呼叫相關方案進行橫向對比，聚焦於流式協議支援、編排抽象、工具生態和適用規模。所有資訊基於 2025 年初公開文件與官方公告。
| 玩家/方案 | 型別 | 流式協議支援 | 編排抽象 | 工具/模型生態 | 可靠性與可觀察性 | 典型適用場景 |
|---|---|---|---|---|---|---|
| LangChain + LangServe | 開源架構 | SSE (aiohttp/FastAPI) | Chain, Agent, Graph (LangGraph) | 海量整合（OpenAI, Anthropic, Google, 百+工具） | 通過 LangSmith 提供追蹤與評估 | Python/JS 應用中定製化鏈式應用；中小到複雜 Agent |
| Semantic Kernel (微軟) | 開源 SDK | SSE (ASP.NET Core) | Plugin, Kernel, Planner | 微軟生態（Azure AI, OpenAI）, 可擴充套件 | 依賴 Azure Monitor/Application Insights | .NET 與 Python 企業應用；與 M365 Copilot 深度整合 |
| 阿里雲端百鍊工作流 | 雲端平台 | SSE（API 閘道器） | 視覺化 DAG 工作流, DSL | 阿里系模型（千問）及主流第三方，工具少 | 平台自帶日誌、監控、告警 | 無程式碼/低程式碼企業應用；國內高併發場景 |
| 百度智慧雲端千帆 AppBuilder | 雲端平台 | SSE（API 閘道器） | 工作流、Agent 畫布 | 文心繫列模型及自定義外掛 | 平台監控，部分開源監控整合 | 中文場景 Agent 開發；與百度搜索生態結合 |
| Google Agent-to-Agent (A2A) | 協議標準 | SSE / HTTP | 不直接提供編排，強調 Agent 通訊 | 較新，初期基於 Google 模型和合作夥伴 | 待定 | 跨組織、多 Agent 互操作；供應鏈、多方協作 |
| Anthropic MCP | 協議標準 | SSE | 工具/上下文接入標準 | Anthropic Claude、B 端工具先行 | 待架構實現 | 統一模型-工具介面；降低整合負擔 |
| 自研中介軟體（事件驅動） | 定製化 | SSE 聚合 + Kafka | 自定義流程引擎 | 全定製 | 自建觀測棧 (Prometheus/Grafana) | 超大規模網際網路平台、金融核心系統 |
此對比體現不同方案的側重：架構/平台注重開發效率和託管運維，協議標準試圖打通互操作，自研中介軟體追求極致可控。實踐中，企業常組合多種方式，例如用 LangChain 開發鏈邏輯，通過阿里百鍊暴露 API，同時遵循 function calling 規範確保工具相容。
11. 風險與挑戰
Streamable HTTP 鏈式架構帶來靈活性，也伴隨多重風險：
安全攻擊面擴大：每一步模型互動、工具呼叫都可能成為攻擊入口。提示注入（Prompt Injection）風險由單體模型擴充套件到全鏈：惡意輸入可以滲透到工具