從一個招聘系統看多Agent落地：Token帳單與降級設計，才是企業採購真正在意的兩欄

2026年9月21日，掘金平臺上「蘇三說技術」專欄發布一篇約28分鐘閱讀量的長文，展示了一套基於AgentScope 2.0多智慧體編排框架搭建的企業智慧招聘系統。文章本身屬於開發者實戰分享，但攤開其中的技術選型與架構細節，能看到的多Agent應用從 demo 走向企業採購清單時，繞不開的幾本帳：模型路由的成本結構、可用率風險的定價、以及框架選擇背後的鎖定效應。本文以回顧角度，從成本結構與定價權的透鏡拆解這份樣本。

先看這套系統把錢花在哪幾層

依該文自述，這是一套覆蓋職位發布、簡歷篩選、面試、Offer、合同、入職全生命週期的招聘平臺。技術堆疊本身值得逐層拆解，因為每一層對應一種不同的成本形態。

基礎架構層採用 Spring Cloud 微服務，Nacos 做註冊與配置中心，後端為 Spring Boot 4.1 加 Java 25 虛擛線程，資料庫為 MySQL 8.0 的8個業務庫共71張表，搭配 Redis 與 RabbitMQ。這一層是傳統企業軟體的固定成本：開發人力、伺服器資源、維運投入，邊際成本隨用戶數線性增長，屬於可預測的資本支出結構。

真正的變數在 AI 層。系統接入了阿裏雲百煉的 Qwen 系列與 DeepSeek，採多廠商路由加自動降級。依文中列出的能力矩陣，不同環節掛不同等級的模型：JD 生成用 qwen3-max，簡歷圖片解析用 qwen-vl-max，AI 面試官用 deepseek-v4，Offer 接受度與留任預測用 deepseek-v4-flash，內推匹配用 deepseek-chat。這種按任務分層掛模型的設計，本質上是把 Token 單價與任務複雜度做匹配：高單價模型只用在產出直接影響決策品質的環節，批量、低風險的預測任務交給 flash 級模型壓低成本。

文中還提到一個「AI 成本大盤」，做 Agent 級 Token 消耗、模型價格、調用量的即時統計。這個功能的出現本身就是訊號：當 AI 能力滲透到業務全流程後，成本核算的顆粒度必須下沉到單一 Agent、單次調用，否則毛利率無法管理。這與企業導入雲服務後要建 FinOps 團隊的邏輯相同，只是帳本上的單位從虛擬機小時換成了 Token。

「LLM 優先、啟發式兜底」：降級設計是一種保險定價

整篇文章在架構上最值得注意的一句話，是所有能力遵循「LLM 優先、Agent 啟發式兜底」，大模型不可用時自動降級到確定性實現，任何配置下業務都能跑通，不會因為模型掛了導致招聘流程停擺。

這條設計原則對應的是一個已被驗證過的痛點。2025年9月初，美國頭部 AI 服務發生約3小時40分的全線中斷，當時產業討論的焦點之一就是可用率成本與 SLA 賠付機制，可參考我們先前的美國 AI 集體宕機事件分析。那次事件之後，把 AI 服務商的可用率假設寫進系統設計，從最佳實踐變成了基本要求。這套招聘系統的降級機制，等於在架構層為模型故障買了一份保險：保費是雙軌實現的開發成本，理賠是業務不中斷的營運連續性。

從採購方視角，這份保險的價值可以粗估。招聘是強時效業務，面試與 Offer 環節中斷一小時，直接損失的是候選人流失率。行業慣例上，中高端職位候選人從面試到入職的窗口期以週計，任何環節卡住都會推高漏鬥損耗。雙軌實現的額外開發成本若能壓低這類損耗，就是一筆可算的投資回報。

框架選擇：AgentScope 2.0 的編排帳

文章特別強調這套系統「不是調一個 API 包裝成 Agent」，而是接入了 AgentScope 2.0 編排框架：HarnessAgent 作為主控，負責統一調度、上下文管理與子 Agent 協作；同時透過 LangChain4j 到 AgentScope 2.0 的 Model 適配器，讓既有的 LLM 網關無縫接入，多模型路由能力不因換框架而丟失。

這個細節牽涉框架市場的競爭格局。目前多 Agent 編排框架大致分幾類：LangChain 系在英語生態佔據先發優勢，AgentScope 由阿裏主導、在中國開發者生態滲透較快，另有 OpenAI 的 Agent SDK 等廠商綁定型方案。企業選框架時真正的考量不是功能清單，而是兩個成本：一是學習與遷移成本，決定團隊是否被鎖定；二是適配器成本，決定換底層模型時要改多少程式碼。文中那個 LangChain4j 適配器的存在，說明作者所在團隊選擇保留雙框架的互操作能力，這是一種對鎖定風險的對沖。

這與 AI 工具市場近期的另一個教訓形成對照。智譜 ZCode 的靜默上傳事件後，企業採購清單上多了一欄合規與信任成本的評估，相關分析見ZCode 事件後的企業採購帳。框架與工具層的信任折價，正在成為 AI 軟體估值的正規化變數。

誰受惠，誰承壓

傳導鏈可以拉直來看。第一層受惠的是模型廠商中被寫進路由表的那幾家：Qwen 系列與 DeepSeek 在這個樣本裡拿到了從生成到預測的多個環節，且按任務分級付費的結構對模型廠商意味著穩定的階梯式用量，而非單點的大額調用。

第二層受惠的是向量檢索與語音等周邊服務。該系統用 Elasticsearch 做題庫與 JD 的向量檢索，阿裏雲 NLS 做語音識別與合成，RustFS 做 S3 相容的音視頻歸檔。多 Agent 應用每多一個環節，周邊中間件的用量就多一份，這部分受惠的確定性甚至高於模型層，因為不涉及模型間的替代競爭。

承壓的一方，首先是傳統 ATS（求職者追蹤系統）廠商。當簡歷解析、篩選評分、出題、面試評估、Offer 預測都被 AI 原生功能覆蓋，傳統招聘 SaaS 的功能溢價會被壓縮，只能靠合規、審計、電子簽章等企業級能力守住客單價。文中列出的頁面浮水印、審計日誌、合同電子簽章，恰好就是這些守城功能的清單。

另一個承壓方是未做多模型路由的單一模型代理商。當企業端把「模型掛了業務照跑」寫成採購要求，只賣單一模型接入的中間商價值會被壓薄，價值往有能力做編排與降級的框架層移動。

收束判斷

一篇開發者實戰文的價值，往往不在專案本身，而在它無意間記錄了企業級 AI 應用的成本結構正在長成什麼形狀。這個樣本給出的輪廓是：模型用量按任務分級定價、Token 成本核算下沉到 Agent 級、可用率風險用雙軌實現對沖、框架選擇保留互操作以避鎖定。這四項都不是功能創新，而是財務與風險管理的正規化。

至於這套系統本身的商業可行性，單篇文章無法驗證。文中提到作者累積了14個 SpringBoot 專案含7個 AI 專案，這種以量取勝的專案產出模式，更接近技術課程與內容變現的商業邏輯，而非產品化路徑。真正值得追蹤的，是這類按成本結構設計的多 Agent 架構，何時從技術專款示範變成企業採購的標配要求。在那之前，AI 應用的帳本仍然主要由敢先付 Token 費用的早期採用者在寫。