一個 request 的生命週期 + Models

TL;DR

• 一個 request 5 步：client → 你的 server → Anthropic API → model 處理 → response 回來
• client 不該直連 Anthropic——API key 一旦進前端 bundle 或 mobile app 就漏光
• Opus / Sonnet / Haiku 的取捨是**「智力 ↔ 速度 ↔ 成本」**的三點選擇，多數產品用 Sonnet

一個情境：為什麼前端不能直接呼叫

實作 chat app 的時候第一個誘惑：「在 React 直接 fetch Anthropic API 不就好？少一層 server。」

不行，原因很直接：

• API key 寫在前端 bundle 裡，瀏覽器 devtools 一打開就看到
• mobile app 反編譯也一樣
• 一旦漏，攻擊者可以無限刷你帳上的額度

所以永遠中間要有一台 server。server 拿 key、客戶端只跟 server 講話。Anthropic 是這樣，OpenAI、Gemini 也都是這樣。

5 步流程

1. [Client]
       │  user 輸入訊息
       ▼
2. [你的 Server]                   ← API key 在這
       │  組 request
       ▼
3. [Anthropic API]
       │  收下 → 排隊
       ▼
4. [Model（Opus/Sonnet/Haiku）]
       │  處理 → 產生回應
       ▼
5. [Anthropic API → 你的 Server → Client]
       回程把 response 一路傳回去

每一步都可以失敗、都需要錯誤處理。實務上大部分 bug 都在 step 2（你的 server 組錯 request）跟 step 5（response 沒處理好就丟給前端）。

Model 處理那一格裡發生什麼

很多人聽過「LLM 是預測下一個 token」但沒看過那是什麼意思。Model 內部走 4 步：

步驟	做什麼
Tokenization	把輸入文字切成 token（≈ 字、字根、標點）
Embedding	每個 token 變成一串數字（向量），代表它「可能是什麼意思」
Contextualization	看上下文調整每個 token 的意思（"bank" 是河岸還是銀行？）
Generation	一次預測下一個 token 的機率分佈，挑一個，再循環

這 4 步不需要記細節。只要知道「不是一個 lookup table，是一輪計算」就夠了。後面講 prompt caching 才會用到這個觀念（cache 的就是前 3 步算出來的東西）。

Stop reasons：model 為什麼停下

回 response 裡有個 stop_reason 欄位，三種值最常見：

stop_reason	意思
end_turn	model 自然講完
max_tokens	撞到你設的上限被截斷
stop_sequence	你在 stop_sequences 指定的字串出現，提早停（response 會多一個 stop_sequence 欄位告訴你命中哪一個）

production 一定要檢查 stop_reason。max_tokens 出現代表你的 response 被切一半，UI 顯示要提示，或者重發 request 加長 max。後面結構化輸出時（JSON 截一半就不能 parse）這個欄位很重要。

Models：Opus / Sonnet / Haiku

Anthropic 三個 model family，都會做同樣的事（chat、code、看圖、tool use），差別在 optimize 哪一邊：

	強項	弱項	適合
Opus	最聰明、會深度推理、長任務不掉鏈	慢、貴	複雜 agent、多步驟規劃、難 debug
Sonnet	平衡——夠聰明、夠快、夠便宜	沒有特別強項	多數產品的主力
Haiku	最快、最便宜	推理較弱、不支援 extended thinking	分類、摘要、實時 user-facing

2026 當下版本：Opus 4.7、Sonnet 4.6、Haiku 4.5。實際 model id 寫成 claude-opus-4-7、claude-sonnet-4-6、claude-haiku-4-5。版本會持續更新，寫 production code 把 model id 抽成設定，不要寫死。

實務上的混搭

「選哪個」不一定要選一個。常見組合：

• Haiku 做分類、Sonnet 做生成：客服信先 Haiku 分類，分到「需要長回信」才丟 Sonnet 寫草稿
• Sonnet 做主流程、Opus 做兜底：normal case Sonnet 解，連續失敗 N 次才升 Opus
• Haiku 做 streaming 預覽、Sonnet 做 final：user 先看 Haiku 快回答，背景 Sonnet 補一份完整版

接下來

下一篇把抽象的「組 request」變具體——messages.create 的 4 個必填欄位、system prompt 為什麼分離、max_tokens 為什麼是上限不是目標。