Kimi K3 把模型熱度變成編排工作

以前我只盯模型分數，現在我先看編排、成本和能不能換模型。

我用大模型做產品一陣子了，最煩的就是每次新發布都像在比誰的海報比較會講話。分數很高、demo 很順、logo 很亮，結果一接進真實流程就開始鬧脾氣：工具亂叫、上下文爆掉、成本飆到你想關機。那種感覺很差，因為你明明是在做產品，最後卻像在供奉模型。

這次我會注意到 Moonshot AI 的 Kimi K3，不是因為我突然信了某個模型會把誰打趴。真正有意思的是，它把討論拉回我一直在乎的地方：模型底下那層怎麼接、怎麼編排、怎麼切換、怎麼控成本。觸發我整理這篇的外部來源是 CNBC 的報導，它把這些問題講得很直接。

別再把模型卡當產品說明書

K3 demonstrates that pre-training scaling, paired with architectural innovation, can still deliver step-change gains for flagship Chinese models.

這句話翻成白話就是：模型本身還是重要，但你不能只看參數數字跟榜單名次。CNBC 提到 Kimi K3 是 Moonshot 目前最大模型，參數量到 2.8 兆，還說它在某些 coding 和 agent benchmark 上表現不錯。這些數字很容易讓人上頭，可是我最在意的不是它「有多大」，而是它「在哪些任務真的比較好用」。

我以前也踩過這個坑。看見一個新模型很強，就想把整個產品線統一到同一顆模型上，圖表看起來很整齊，實際上卻是災難：有的流程只需要分類，有的流程要長推理，有的流程根本只是做摘要。你拿最貴的模型去做這些事情，等於拿跑車去送外送，帥是帥，帳單也很帥。

實操寫法很簡單：你不要先問「哪顆模型最強」，你先問「這個任務需要什麼」。把任務拆成幾類，然後替每一類定義成功條件，像是正確率、工具呼叫成功率、延遲、每次成功的成本。模型卡可以看，但不能拿來直接決策。

• 先做任務分類，再做模型選擇。
• 把 benchmark 當參考，不要當採購依據。
• 每個任務都留一個 fallback。

2.8 兆參數不是你會不會賺錢的答案

Moonshot 說 Kimi K3 是中國目前最大 AI 模型之一，2.8 兆參數這個數字確實很嚇人。可我現在看到這種數字，第一反應不是「哇好強」，而是「這東西要怎麼進 production」。大模型常常有一個毛病：展示時很漂亮，落地時很重。重到你要重新想路由、想快取、想 fallback、想延遲預算，最後你發現產品不是被模型能力限制，而是被你自己的架構拖住。

CNBC 也提到，中國模型之所以開始被西方公司注意，很大一部分原因是它們在追近美國模型，而且使用成本通常更低。這點我很認同。便宜不是小事，便宜會直接改變系統設計。當一次呼叫不再那麼肉痛，你才有空間做多步驟流程、做多模型路由、做更細的驗證。你也才有可能把高成本模型留給真的需要它的地方。

我之前幫一個產品做模型統一，前期大家都很愛，因為管理起來簡單。後來才發現，簡單是簡單了，錢也多花了，延遲也變差了。那次之後我就學乖了：模型層要分級。粗活給便宜模型，難題給強模型，出錯時再切備援。

實操寫法：把你的工作流拆成「便宜處理」、「高品質推理」、「失敗重試」三層。不要每個請求都上最貴的模型。你要看的是每次成功的成本，不是每次呼叫的成本。

• 用成本分層，不要用一顆模型包山包海。
• 把延遲預算寫進 routing 規則。
• 高風險任務才用高成本模型。

真正值錢的是 harness，不是模型名

Perplexity 執行長 Aravind Srinivas 在 CNBC 裡講了一句我很認同的話：

the model alone is no longer the product.

我現在看 AI 產品，第一個問題都不是「這顆模型多強」，而是「如果我把它換掉，產品會不會整個壞掉」。如果答案是會，那你做出來的多半不是產品，是 demo。真正能上線的東西，應該是模型可替換，流程可維持，工具可控，輸出可驗證。

這也是為什麼我會把 LangChain、LlamaIndex 這類工具拿來當參考。不是因為它們神，而是因為它們提醒你一件很現實的事：模型只是其中一個元件。你要管的是路由、工具呼叫、記憶、重試、停止條件，這些才是讓系統能不能活下來的東西。

實操寫法：把 provider adapter 跟產品邏輯拆開。模型只負責回應，編排層負責決策。你未來要換模型，最好只改設定，不要改業務邏輯。

benchmark 會騙人，真實流程不會

CNBC 提到 Kimi K3 在 coding 和 general agent benchmark 上壓過一些模型，但整體表現還是落後 Anthropic 的 Claude Fable 5 和 OpenAI 的 GPT 5.6 Sol。這種分裂很正常，也很重要。因為一顆模型在某個榜單上很漂亮，完全不代表它在你的產品裡就順手。榜單只測幾種固定題型，真實世界卻充滿髒資料、工具失敗、格式漂移、上下文過長、使用者亂問。

Simon Koser 在 CNBC 裡那句話我也很買單：

not every AI model excels in every task despite what the initial benchmark tests may show.

我自己遇過一個案例，模型在 code generation 測試裡分數很好，實際接到 repo 後卻一直假設檔案結構正確，然後吐出一堆看起來合理、其實不能跑的 patch。最後救回來的不是換更大的模型，而是加了 repo 狀態檢查、縮小 context、把任務切得更窄。

實操寫法：你要做一組自己的 eval。不要只測 happy path，要加上工具失敗、格式錯誤、重試、缺上下文、長對話。你自己的產品流程才是唯一有意義的 benchmark。

中國 AI 的故事，本質上也是成本故事

CNBC 把 Kimi K3 放在美中 AI 競爭的大框架裡，這沒錯，但我覺得更實際的切角是成本。報導提到一些分析師認為，K3 顯示即使在算力受限的條件下，透過架構和訓練方式調整，還是能做出很有感的提升。這句話聽起來很分析師，但翻白話就是：資源少一點，不代表只能做爛東西，反而會逼你把系統設計得更精。

這對開發者的影響很直接。當模型便宜，你就敢多呼叫幾次；當模型便宜，你就敢把難題拆成幾步；當模型便宜，你也比較敢做多供應商策略，不會每次切換都像在搬家。這些都不是抽象優勢，這些都會直接影響你產品的成長速度和毛利。

我還滿在意報導裡提到美國政策可能會去限制本地公司採用中國模型。這種政策風險你不一定能控制，但你可以控制架構。如果你的應用一開始就把 provider 綁死，哪天價格、法規、採購條件一變，你就只能重寫。如果你一開始就把模型當可替換元件，風險會小很多。

實操寫法：把提示詞、工具 schema、eval、provider adapter 分層管理。不要把 vendor-specific 的東西寫進核心流程。你要的是可切換，不是可展示。

我會怎麼把這篇變成工程決策

看完 Kimi K3 這類發布，我現在的結論很簡單：模型發布再吵，最後還是會回到系統設計。你可以關心誰的分數高，但你真正要做的，是把模型放進一個能路由、能切換、能驗證、能控成本的 harness。這才是產品團隊該花力氣的地方。

我甚至覺得，很多 AI 團隊現在卡住，不是因為模型不夠聰明，而是因為他們把太多控制權交給模型本身。結果就是一切都像在賭。賭它會不會懂，賭它會不會乖，賭它會不會突然變貴。這種產品我不太想做，因為太像在靠運氣吃飯。

如果你要從這篇拿走一個做法，我希望是這個：別再問哪顆模型最強，先把你的工作流做成可切換、可觀測、可回退的系統。模型會換，價格會變，政策會動，只有你的 harness 能不能撐住，才是真的。

可抄的模板

# Model-agnostic harness for AI features

## Goal
Build an AI feature where the model is swappable and the product logic stays stable.

## What this is for
- model routing
- tool calling
- retries and fallbacks
- cost control
- evals that match real product flows

## Architecture
1. Input normalization
   - clean user input
   - detect task type: answer, summarize, code, multi-step, fallback

2. Router
   - choose model by:
     - task complexity
     - latency budget
     - cost budget
     - context length
     - required tool use

3. Orchestration layer
   - owns tool calls
   - owns retries
   - owns stop conditions
   - owns memory selection
   - owns response validation

4. Model adapters
   - one adapter per provider
   - same request/response shape
   - no business logic inside provider code

5. Eval layer
   - run the same tasks across candidate models
   - track:
     - task success rate
     - tool-call accuracy
     - latency
     - cost per successful task
     - format validity
     - hallucination rate

## Routing rules
- cheap model for:
  - intent detection
  - classification
  - summarization
- stronger model for:
  - coding
  - multi-step reasoning
  - tool-heavy tasks
- fallback model for:
  - low confidence
  - invalid output
  - tool execution failure
  - timeout

## Pseudocode
function handleRequest(userInput):
  task = classifyTask(userInput)
  model = selectModel(task)
  context = buildContext(task)
  plan = orchestrate(task, context, model)
  result = executePlan(plan)
  validated = validateResult(result)

  if validated.failed:
    fallback = selectFallbackModel(task)
    result = retryWithFallback(task, context, fallback)

  return result

## Prompt pattern
You are a task-specific assistant inside a tool-based workflow.

Rules:
- Use tools when needed.
- Do not invent tool results.
- If the task is ambiguous, ask one clarifying question.
- Prefer the cheapest model that reliably completes the task.
- Return output in the required schema only.

## Eval checklist
- Does the model call tools in the right order?
- Does it stop when the job is done?
- Does it recover from failed tool calls?
- Does it stay within budget?
- Can I replace the model without changing orchestration code?

## Deployment rule
If switching models requires changing business logic, the abstraction is wrong.
If switching models only changes adapter config, the abstraction is working.

來源致謝：本文的觸發點來自 CNBC 對 Kimi K3 的報導，以及文中引述的 Perplexity、LangChain、LlamaIndex。我上面的拆解、判讀和模板是我自己整理出來的，可直接拿去改成你的工作流。