我們 2026 年第四季在跑什麼模型，以及我們悄悄停用了什麼

2026 年第四季——我們用什麼、成本多少，以及技術在變、我們怎麼跟著決定。

開發工具是加速器，模型才是判斷力的所在。好的工具配上錯的模型會浪費成本；前沿模型用在簡單任務上會浪費時間。我們是一間由資深開發人員主導、AI 加速的產品工作室，所以每個模型選擇都要回答一個問題：這項任務需要深度，還是需要速度？

模型陣容會換、價格會變，工作室使用 AI 的方式也得跟著變。這是我們為 2026 年第四季調整出的配置——是快照，不是建議，但如果您自己也在用 AI 輔助工作，背後的判斷邏輯應該用得上。我們之前談過如何選擇開發工具，這篇是那個決定的另一半。

我們也會點名兩個停用的模型，以及它們各自被什麼取代。這部分通常不會寫出來，而它往往就是「這個模型適不適合您」與「它只是看起來適合」之間的差別。如果您也在跑自己的 subagent workflow，我們很想跟您交流。

我們在優化什麼

我們按任務風險挑模型，不按名氣。

沒有一個模型能同時做好這兩種工作，所以我們不強求。策略性工作——架構決策、品牌願景、複雜的代理協作——是我們為深度付費的地方。每個 token 較貴，但因為模型一次就做對，總用量反而更少。

高量執行——檔案編輯、程式碼搜尋、例行 subagent 循環、context 收集——是我們為用量付費的地方。token 用量多，但每個都便宜到用量不再是問題。

路由的失誤兩個方向都會發生。因為任務聽起來重要就拿前沿模型出來，您會看著它花四美元去談一個檔案改名；把真正困難的判斷交給最便宜的模型，您會拿到一個興高采烈產出、但必須丟掉的架構。兩者都不是模型問題，都是路由問題——這就是為什麼我們看的是自己的營運成本，而不是牌價上的每個 token。

下面的候選名單裡，您不會看到閉源的前沿模型——這是刻意的。開放權重模型才是價格競爭真正激烈的地方，而成本效益會直接轉成槓桿。我們花這麼多時間審查模型，為的就是壓住營運成本；營運成本越低，一個專案能部署多少 AI 就由工作本身決定，而不是由帳單決定。

為什麼這個價差值得管理

我們目前評估的八個模型，在撰文當下的牌價橫跨相當寬的區間：

輸入：每 1M tokens 由 $0.14 到 $3.00——相差 21 倍。
輸出：每 1M tokens 由 $0.28 到 $15.00——相差 54 倍。

輸入 token 是您送進去的東西：檔案、指令、檢索回來的 context。輸出 token 是模型產生的東西：推理過程、工具呼叫、程式碼、文案。代理式工作是輸出密集的，因為代理要不斷判斷與產出。所以真正反映在我們營運成本上的，是輸出價格。

因此對我們來說，關鍵從來不是「找一個更便宜的模型」，而是「別把昂貴的工作交給昂貴的模型」。這是兩個不同的問題，而只有後者有結構性的解法。

為什麼我們的錢主要花在 subagent 上

單一長時間的對話只有一個模型、一份 context。它讀過的每個檔案、每次失敗的嘗試、每條死胡同，都會留在那個窗口裡，並在下一輪重新送出。到了第三個小時，等於在用前沿模型的價格重讀自己的歷史——而這時 context 往往已經腫脹到模型開始走樣。

這也是兩個表現很好的模型被我們移出陣容的原因，下面會說。

Subagent workflow 改變的不是單一 token 的價格，而是我們整體開支的形狀：

偵察交給最便宜又夠用的模型。 讀檔案、搜程式碼庫、總結重點，這些不需要深度推理，需要的是速度與大 context window。
判斷留在昂貴的模型上。 架構決策、最後審查、決定交付的那個判斷——這才是前沿模型值得它那個價錢的地方。
每個 subagent 都拿到一份全新的 context。 偵察讀了二十個檔案，只回傳三段話。上層從來不用背著那二十個檔案。

第三點最容易被忽略。Subagent 不只是並行處理，它是一種買 context 壓縮的方式——我們付錢給便宜的模型去吸收雜訊，昂貴的模型永遠只看到訊號。

這就是我們為什麼要做分層，而不是只用一個好模型。也是為什麼我們的開支降了而品質沒降：我們沒有讓前沿模型變好，只是不再叫它做檢索。

我們為什麼停用它們

Kimi K2.5 與 K2.7-code 是我們停用得最刻意的兩個模型。原因跟跑分無關，跟 context 有關。

有一段長時間我們大量使用它們，而它們表現很好——寫程式碼扎實，輸出品質沒什麼好挑剔。問題出在它們怎麼花預算：兩個模型都會把相當大比例的 context window 花在 thinking token 上，而當這些思考把窗口填滿之後，session 會以一種很難察覺的方式劣化：context 腫脹，然後走樣，最後模型在一個過時的畫面上安靜地推理。

這件事發生的時候不會報錯。產出看起來正常，模型照樣回答，只是它已經不再追蹤您真正要求的那件事——而您會在審查時才發現。

於是我們在長時間的代理式 session 中放棄了它們——不是因為它們是弱模型，而是因為它們的 context 經濟不適合我們的做事方式。決定一個模型能不能撐過真實任務第三個小時的，是它的 context 經濟，不是它的跑分。

我們採用任何新東西之前會檢查兩件事：

它花多少窗口在自己身上？ 一個思考慷慨的模型，不會因為單價低就等於免費。
第三個小時的 session 長什麼樣子？ 跑分量的是第一個答案，不是第四百個。

如果您也撞過同一道牆，我們很想知道您怎麼繞過去。

我們怎麼分類

我們只用兩個桶，而且很堅持一項任務該落進哪一個。

第一層：前沿——我們為判斷付費的地方

參數量大、推理深、單價高。當犯錯的代價高於 token 成本時，它們就值得這個價。下面四個裡，今天只有一個真正在我們的路由裡——其他三個都是強模型，只是它們的深度不是代理商工作真正需要的那種判斷。

Kimi K3。 頂級多模態視覺合成與敘事文案能力。原生 1M context window。輸出每 1M 為 $15.00——我們評估中最貴的模型。我們只在約 5% 的工作量中精準使用：初期品牌指南、視覺 mood board 拆解、創意願景設定。
GLM 5.3 Max。 出色的跨語言邏輯與深度代理推理，在複雜數學與多代理協作上可與旗艦模型匹敵。僅支援文字輸入。評估過，留在候選：推理確實出色，但不是我們創意與策略任務需要的那種。
DeepSeek V4 Pro。 對新演算法與複雜程式碼重構有深度邏輯能力，zero-shot 指令遵循表現出色。單價低於 Kimi K3 而推理能力相當——評估過，留在候選，因為我們的工作中硬除錯太少見，它始終沒有贏得一個路由位置。
Qwen 3.8 XHigh。 推理深度極高，具備加長的思維鏈預算。在複雜數學證明與深層嵌套邏輯上表現優異。評估過，留在候選——我們的 oracle 與審查角色跑在 Qwen 3.7 Plus 上，費用只是零頭。

第二層：主力——我們為用量付費的地方

低輸入輸出成本、低延遲、大 context window。日常由它們撐起。

DeepSeek V4.1 Flash。 我們成本效益最好的一員：輸入 $0.15 / 輸出 $0.60 每 1M tokens。1M context window 搭配壓縮 KV 快取。終端與 repo 層級編碼能力頂尖。我們互動式工作的驅動。
GLM 5.3 Flash。 推理速度極快，輸入 $0.15 / 輸出 $0.50 每 1M tokens，多輪工具呼叫與代理 context 處理表現出色。評估期間它跑過我們的 scout 與 context-builder 角色，表現確實亮眼——我們只是最後落腳在別處。
MiMo V2.5。 我們目前陣容中最便宜的一員：輸入 $0.14 / 輸出 $0.28 每 1M tokens，1M context window。我們的 scout 與 context-builder subagent 就跑在它上面，在那些角色裡速度與成本比推理深度更重要。
Qwen 3.7 Plus。 多功能的中量級選手：輸入 $0.40 / 輸出 $1.60 每 1M tokens。在結構化編碼、工具呼叫與文案品質之間取得良好平衡，多語言表現出色。是我們需要中度推理的分析型 subagent 預設選擇。

候選名單，並排來看

這八個裡面，真正扛起我們日常工作的只有四個。其他的留在候選名單上——都是我們喜歡的好模型，只是路由始終沒有選上它們。

我們實際在跑什麼

兩個桶是我們的思考方式。以下是撐過真實死線之後還活著的設定。

它對我們為什麼這樣分：

便宜又快的眼睛負責偵察。 Scout 與 context-builder 跑在 MiMo V2.5，我們陣容中成本最低的模型。這些角色負責讀檔案、搜程式碼庫、回傳壓縮過的 context。它們不需要深度推理，需要的是速度與乾淨的交接。
中量級推理負責分析與審查。 Planner、advisor、researcher、reviewer 全部跑在 Qwen 3.7 Plus，思考層級按任務調整。這個模型在結構化編碼、工具呼叫與文案品質之間取得平衡，成本在長時間 session 中仍然可預測。
高思考留給負責交付的那一個。 主要驅動跑 DeepSeek V4.1 Flash 配 high thinking——這是我們快速切換選單中唯一預設帶高思考預算的一員。它接觸客戶的程式碼、執行終端指令，做出交付的判斷。
Reviewer 拿到最高的旋鈕。 每個變更在合併前都要經過 high thinking 的 reviewer。資深開發人員監督每一個代理，但 reviewer 是最後一道自動化關卡。

我們評估過 GLM 5.3 Flash 作為 scout 與 context-builder 的替代驅動。它極快也極便宜，而且真的做得好。我們最後還是選 MiMo V2.5，因為價差不大，而現行路由一直很穩定。這是本文最不浪漫的一句，也是最誠實的一句：決定我們路由的，往往不是跑分表，而是慣性和一個乾淨的 diff。

思考層級是第二個旋鈕

模型選擇只是一半的決定，思考層級是另一半。

同一個模型在 low 與 high thinking 下表現差別很大。Low thinking 消耗較少輸出 token、回應更快。High thinking 花更多在內部推理上，但複雜任務的結果更可靠。由於我們的錢主要花在輸出 token 上，這個旋鈕對營運成本的影響不亞於模型選擇。

我們把它設在哪裡：

High thinking——DeepSeek V4.1 Flash（主要驅動）與 Qwen 3.7 Plus（reviewer）。答錯代價最高的兩個角色：寫客戶程式碼的模型，以及在合併前審查它的模型。
Medium thinking——Qwen 3.7 Plus（planner、advisor、researcher、oracle）。分析與協作所需的深度足夠，又不必在每次呼叫上付 high thinking 的成本。
Low thinking——MiMo V2.5（scout）與 Qwen 3.7 Plus（worker、delegate）。又快又便宜，對已經有資深開發人員監督輸出的執行任務來說已經足夠。

我們整套設定的預設是 low。我們按角色刻意調高——當任務風險需要時。把所有旋鈕都轉到 high 不叫嚴謹——那叫沒有節制的成本，而且會讓昂貴角色跟便宜角色變得沒有分別。

創意與品牌工作

大量執行與創意指導需要不同的模型，而我們在這兩者上的分歧比任何地方都大。

設計專案啟動時，我們會把主要驅動切換到 Kimi K3——陣容中最貴，但也是多模態視覺合成與敘事文案最強的一員。它的第一項工作其實不是視覺，而是整個工作流程賴以建立的策略基礎：文案、願景探索、問題陳述、品牌訊息——這些策略文件會在任何一個顏色被選定之前完成，告訴下游每一個代理該往哪裡走。我們之前寫過，為什麼這些策略文件是 AI 加速設計的前提。在此之後，才是設定視覺方向、拆解複雜的 mood board。

設計語言鎖定之後，我們就切回 DeepSeek V4.1 Flash 進行實際的前端開發。Kimi K3 定願景，DeepSeek V4.1 Flash 交付。輸出成本相差 25 倍，所以我們把溢價花在會複利的地方——前 5% 的創意工作——其餘 95% 的大量執行則省下來。

這跟分層是同一套邏輯，只是用在單一專案上：頂部為深度付費，中間為速度付費，而我們不會用前沿模型去做 Flash 模型就能做好的事。

這對客戶意味著什麼

每一單專案都有三個關鍵結果。

可預測的營運成本。 讓昂貴模型遠離高量工作，是我們最有效的控制方式：用 DeepSeek V4.1 Flash 配 high thinking 做一整天的互動式開發，成本只是同一天用 Kimi K3 的一小部分；跑在 MiMo V2.5 與 Qwen 3.7 Plus 上的 subagent 循環，每個 session 都維持在不到一美元的範圍——因為偵察工作根本不會碰到昂貴的模型。
資深監督保持完整。 每個模型選擇都是人的決定。Planner 在動工前以 medium thinking 運作，reviewer 在合併前以 high thinking 審查。AI 加速樣板與例行工作；資深開發人員掌握每一個架構與品質決策。
交付產品，而不是停滯的實驗。 快速模型處理快速任務，讓互動循環保持流暢；前沿模型處理前沿任務，讓困難決策得到需要的深度。結果是一間能交付的工作室——由資深開發人員監督，由每個任務的正確模型路由。

換您分享

我們把我們的攤開了，也想看看您的。

我們特別好奇這幾件事：

您把哪些模型路由到哪些角色，而這個對應在真實死線之下還撐得住嗎？
您有沒有撞上跟我們一樣的 context 稅？後來怎麼處理？
您在哪些地方決定不用 subagent——因為編排的 overhead 已經超過省下來的成本？
有沒有哪個模型您興高采烈地採用，然後悄悄退役了？

最後兩點我們最有興趣。市面上談代理 workflow 的文章大多記錄什麼行得通，很少記錄什麼被放棄——而被放棄的那一半，通常才是更值得讀的。

我們會在 LinkedIn 與 X 分享這篇。歡迎在那邊回覆，告訴我們您的配置長什麼樣——每一則我們都會看。如果您想私下聊，我們的工程團隊在 hello@onioncreative.com。

準備實現您的願景？

AI 應該加速執行，而不是取代背後的判斷。如果您想要一個由資深開發人員主導、在嚴格人工控管下把正確模型路由到正確任務的團隊，歡迎與我們聊聊。

與我們討論您的項目