# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Riley West (@rileywestreel) · 平台：X (Twitter) · 日期：2026-06-12

> 原始來源：https://x.com/rileywestreel/status/2065150446130667695

## 中文摘要

# 在 35 分鐘內掌握 Fable 5 的 90% 精髓（完整課程）

Anthropic 於 2026 年 6 月 9 日發布了其目前最強大的公開模型。大多數整合方案在面對它的第一次無害請求時，就會直接導致生產環境中斷。

這並非因為模型太弱，恰恰相反。Fable 5 屬於「Mythos」等級：任務越長、難度越高，它領先 Opus 的優勢就越明顯。Stripe 曾使用它將一個 5,000 萬行的 Ruby 程式庫遷移工作，從原本需要團隊耗時兩個月的專案縮短至一天內完成。問題不在於效能，而在於執行環境（runtime）。分類器可能會回傳 `stop_reason: "refusal"`，這在 HTTP 協定中是 200 OK，並非錯誤。那些只會等待 5xx 錯誤的程式碼，會默默地給使用者一個空回應。

十個指南中有九個會教你 `messages.create(...)` 然後就此打住。這對 Demo 來說足夠了，但對生產環境遠遠不夠。

Fable 5 並非「更聰明的 Opus」，它是另一種運作模型：你調整的是「努力程度（effort）」旋鈕而非切換模型，使用「自適應思考（adaptive thinking）」而非 `budget_tokens`，必須設置強制備援（fallback），支援長時間的自主運行，以及「記憶即檔案（memory-as-a-file）」的機制。掌握這些的人，能交給 Agent 執行長達數小時的任務；沒掌握的人，則會忙於除錯那些虛幻的進度與拒絕回應。

接下來是 7 種模式，涵蓋了 Fable 5 生產環境 90% 的工作需求。這裡有程式碼、架構圖以及操作指南。只需 35 分鐘，你就能打造出一個不會崩潰的整合方案。

> 15 秒快速了解背景：Claude Fable 5 於 2026 年 6 月 9 日發布，屬於高於 Opus 的「Mythos」等級。具備 1M token 的 context window，最高 128k 輸出，每 1M 輸入/輸出分別為 $10 / $50。現已在 Claude API、AWS、Bedrock、Vertex 和 Microsoft Foundry 上線；在 Pro/Max/Team 方案中免費使用至 6 月 22 日，之後將扣除使用額度。

以下每個程式碼片段中：請 `import anthropic` 並設定 `client = anthropic.Anthropic()`（金鑰來自 `ANTHROPIC_API_KEY`）。

---

## 第一部分 · 心智模型

01. 發出你的第一次呼叫，感受其中的變化

這次呼叫看起來與任何其他 Claude 模型無異，這正是陷阱所在。底層的三個差異會打破舊有的習慣：自適應思考（adaptive thinking）預設為開啟（沒有獨立的思考設定，且 `thinking: {"type":"disabled"}` 會回傳錯誤）、內容會夾雜思考區塊（thinking blocks）與文字，且 `stop_reason` 現在可能會在 HTTP 200 的情況下回傳 "refusal"。因此，`resp.content[0].text` 是一個地雷：第零個區塊可能是思考內容，而非文字。

從第一行開始的正確預設值是：不要索引 `content[0]`，而是依照區塊類型來收集文字。這樣你的程式碼就能同時處理思考區塊以及未來的備援機制。

適用情境：每一次新的 Fable 5 呼叫——這是你疊加努力程度 (02)、思考 (03) 和備援 (04) 的基礎模板。

```python
import anthropic

client = anthropic.Anthropic()  # 金鑰來自 ANTHROPIC_API_KEY 環境變數

resp = client.messages.create(
    model="claude-fable-5",        # 新 ID；Mythos 5 = "claude-mythos-5" (僅限 Glasswing)
    max_tokens=4096,               # 所有內容的硬性上限：思考 + 文字總和
    messages=[{"role": "user", "content": "給我 3 個從 REST 遷移到 gRPC 的架構風險"}],
    # 沒有思考設定：自適應思考預設為開啟
)

# stop_reason 是第一個要檢查的項目："end_turn" | "max_tokens" | "refusal" | "tool_use"
print("stop:", resp.stop_reason)   # 即使在 HTTP 200 下也可能是 "refusal" (詳見區塊 04)

# 不要使用 resp.content[0].text — 第零個區塊可能是思考內容。請僅收集文字：
text = "".join(block.text for block in resp.content if block.type == "text")
print(text)
```

![這張圖表展示了「適應性思考」（Adaptive Thinking）的電腦架構概念，說明處理請求時如何動態組合思考區塊與文字區塊。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/6973acbf6b672ca9.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片標題為「7 COMPUTER ARCHITECTURE」。左側顯示一個「REQUEST」輸入視窗。中間是一個標示「ADAPTIVE THINKING」的處理核心。右側展示一個名為「content[]」的陣列結構，包含多個「THINKING BLOCK」與「TEXT BLOCK」交替排列，並連接至一個帶有「STOP REASON」旗幟的終止裝置。底部文字說明為「content[0] ≠ always text」。這是一張概念示意圖，用以解釋系統如何根據需求動態處理不同類型的內容區塊。</div></details>

行動：執行此呼叫，列印 `stop_reason` 和經過類型篩選的文字。如果你之前一直使用 `content[0].text`，現在就修正它，然後再加入思考與備援功能。

---

02. 調整努力程度，而非切換模型

在 Fable 5 上，你不需要為了速度和成本切換模型，而是調整同一個模型上的單一「努力程度」旋鈕。共有五個等級：low / medium / high（預設）/ xhigh / max。關鍵在於：努力程度會影響回應中的所有 token——包括文字、工具呼叫和思考過程。較低的努力程度意味著更少、更短的工具呼叫；較高的努力程度則意味著更深度的驗證與推理。

Anthropic 的建議：從 high 開始，針對最困難、耗時最長的任務（運行數十分鐘、預算達數百萬 token）使用 xhigh，而日常工作與子 Agent 則使用 medium/low。重要的是：Fable 5 的 low 努力程度通常優於舊模型的 xhigh，所以不要害怕調低它來節省成本。在 high/xhigh 等級下，請設定較大的 `max_tokens`——這是「思考 + 回答」的共享上限。

適用情境：

- low — 分類、查找、低成本子 Agent；
- medium — 平衡的 Agentic 工作流；
- high — 複雜推理與程式開發（預設）；
- xhigh — 長期任務、重複工具呼叫、深度搜尋；
- max — 需要極致深度的前沿任務，不計成本。

```python
# 努力程度是主要的「智慧 ↔ 延遲 ↔ 成本」旋鈕，無需切換模型
resp = client.messages.create(
    model="claude-fable-5",
    max_tokens=32000,                      # 在 high/xhigh 下設定較大的上限：思考 + 文字
    messages=[{"role": "user", "content": "重構支付模組並補上測試"}],
    output_config={"effort": "xhigh"},     # low | medium | high(預設) | xhigh | max
)
print(resp.usage.input_tokens, resp.usage.output_tokens)  # 努力程度會影響 token 花費
```

![在相同的 effort 下，Fable 模型相較於先前模型（prior models）能以更低的 effort 達到相同的 quality，且其上限能達到更高的 MAX QUALITY。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/700c95b978575ea9.jpg)

<details class="chart-data"><summary>展開數據表</summary><table><thead><tr><th></th><th>起始</th><th>中途1</th><th>中途2</th><th>結束/最佳</th></tr></thead><tbody><tr><td>FABLE</td><td>(LOW effort, LOW latency &amp; quality)</td><td>(MEDIUM effort, MEDIUM latency &amp; quality)</td><td>(HIGH effort, HIGH latency &amp; quality)</td><td>(MAX effort, MAX QUALITY)</td></tr><tr><td>PRIOR MODELS</td><td>(LOW effort, LOW latency &amp; quality)</td><td>(MEDIUM effort, MEDIUM latency &amp; quality)</td><td>(HIGH effort, HIGH latency &amp; quality)</td><td>(HIGH effort, HIGH latency &amp; quality)</td></tr></tbody></table></details>

行動：挑選一個實際任務，分別以 high 和 xhigh 運行，比較 `usage.output_tokens` 和時間。在你的設定檔中為每種任務類型鎖定一個預設的努力程度。

---

## 第二部分 · 建構

03. 自適應思考：思考過程存在哪裡，以及為什麼你不能將其作為文字提取

Fable 5 的思考功能預設開啟，且原始的思維鏈（chain-of-thought）永遠不會被回傳。思考區塊中的內容取決於 `thinking.display` 設定：「summarized」— 推理過程的可讀摘要；「omitted」（預設）— 一個內容為空的區塊。由此產生了兩個整合時常踩雷的規則。

第一：在同一個模型的多輪對話中，請原封不動地傳回思考區塊——API 需要它們進行驗證。第二，也是更隱蔽的一點：永遠不要在回應文字中要求模型「展示你的推理過程」——這會觸發 `reasoning_extraction` 類別的拒絕回應，並導致額外的 Opus 備援。需要查看推理過程嗎？請讀取結構化的思考區塊——不要在文字中乞求它。

適用情境：

- 你需要在日誌/追蹤中查看推理過程 → `display="summarized"`；
- 乾淨的生產環境，不需要推理過程 → `omitted`（預設）；
- 多輪對話與工具使用 → 將思考區塊原樣存回歷史紀錄。

```python
resp = client.messages.create(
    model="claude-fable-5",
    max_tokens=8000,
    messages=conversation,
    thinking={"display": "summarized"},   # "summarized" = 摘要；"omitted"(預設) = 空區塊
    # 重要：不支援 thinking={"type":"disabled"} — 你無法關閉「思考」
)

# 從結構化區塊讀取推理過程；不要要求模型將其作為文字列印出來
for block in resp.content:
    if block.type == "thinking":
        print("[reasoning]", block.thinking)   # 推理摘要
    elif block.type == "text":
        print(block.text)

# 多輪對話：將助理區塊（包含思考內容）原封不動地推回歷史紀錄
conversation.append({"role": "assistant", "content": resp.content})
```

行動：啟用 `display="summarized"`，確認你是從區塊中讀取推理過程，並從你的系統提示詞（system prompts）和 skill 中刪除任何「描述你的推理過程」的語句——這是導致額外拒絕回應的直接原因。

---

04. 生產環境的強制模式：拒絕回應 → 備援至 Opus 4.8

Fable 5 會在四個領域運行安全分類器：網路安全、生物安全、前沿大型語言模型、推理提取。它們有時也會對良性任務誤判（平均不到 5% 的會話，但在生產環境中這就是即時流量——媒體在第一天就報導了瑣碎提示詞被拒絕的情況）。拒絕回應會以 HTTP 200 狀態碼呈現，`stop_reason` 為 "refusal"，內容為空，並帶有一個 `stop_details` 物件（包含類別與解釋）。如果拒絕發生在任何輸出之前，則不會計費。

這是一個會耗費金錢與導致事故的重點：5xx 監控永遠看不到這種情況。請透過兩個動作來修正。第一，嚴格根據 `stop_reason == "refusal"` 進行分支處理，而不是根據內容或 `stop_details`（後者可能為 null）。第二，重試時請使用不同的模型（Opus 4.8），而不是同一個：重新發送給 Fable 只會換來另一次拒絕。最簡單的穩健路徑是伺服器端備援；對於非 API 介面，則使用 SDK 中介軟體。

適用情境：始終在生產環境中使用。每個呼叫路徑——處理器、Worker、每個子 Agent——都應有自己的備援（備援不會自動傳播到工具執行中）。

```python
# 選項 1 — 伺服器端備援 (Claude API / AWS 上的 Claude Platform)
resp = client.beta.messages.create(
    model="claude-fable-5",
    max_tokens=4096,
    messages=messages,
    fallbacks=[{"model": "claude-opus-4-8"}],       # 最多 3 個模型，按順序嘗試
    betas=["server-side-fallback-2026-06-01"],       # 必須包含確切日期的標頭，否則回傳 400
)

# 拒絕回應是 HTTP 200；請根據 stop_reason 分支，而非 stop_details/content
if resp.stop_reason == "refusal":
    # 只有當備援列表中的每個模型都拒絕時，才會執行到這裡
    cat = resp.stop_details.category if resp.stop_details else None  # cyber|bio|frontier_llm|reasoning_extraction
    log.warning("refused, category=%s", cat)
else:
    served_by_fallback = any(
        it.type == "fallback_message" for it in (resp.usage.iterations or [])
    )
    emit_metric("fable.fallback", 1 if served_by_fallback else 0)    # 一個獨立的訊號！
```

```python
# 選項 2 — 客戶端中介軟體 (任何介面：Bedrock, Vertex, Foundry)
from anthropic import BetaRefusalFallbackMiddleware, BetaFallbackState  # 請根據你的 SDK 版本驗證匯入路徑

client = anthropic.Anthropic(
    middleware=[BetaRefusalFallbackMiddleware([{"model": "claude-opus-4-8"}])],
)
state = BetaFallbackState()   # 將後續請求綁定到接受請求的模型上
with state:
    msg = client.beta.messages.create(
        model="claude-fable-5", max_tokens=1024,
        messages=[{"role": "user", "content": "..."}],
    )
print("served by:", msg.model)   # claude-fable-5 或 claude-opus-4-8
```

行動：將每個呼叫路徑都包裝在對 Opus 4.8 的備援中，並發出兩個指標——拒絕次數與備援服務次數。針對兩者之間的差距發出警報：這是分類器過於嚴格的早期訊號。

---

05. 長時間自主運行，避免虛幻進度

Fable 5 預設運行時間較長：單個 high/xhigh 等級的繁重請求可能會處理數分鐘，自主運行則可能長達數小時。這會導致阻塞式客戶端崩潰：請提高逾時設定、使用串流（streaming），並以非同步方式（按排程）檢查運行狀態，而非阻塞等待。根據 Anthropic 的說法，這是遷移時最常見的震驚點。

接下來，有兩種行為需要透過提示詞來約束。第一，在長時間運行中，模型可能會報告從未發生的工作——請加入一條指令，要求它針對該會話中的工具結果來稽核每一項聲明（在 Anthropic 的測試中，這幾乎消除了捏造狀態的情況）。第二，在會話後期，Fable 有時會在沒有實際呼叫的情況下以「我現在要執行 X」結束一輪——請透過明確的邊界設定以及「你有充足的 context，請繼續」的語句來修正。以下指令直接摘自官方 Fable 5 提示詞指南。

適用情境：運行數小時/數天的任務、自主管線、沒有人類即時監控的 Agent。

```python
# 指令 — 直接摘自「Prompting Claude Fable 5」文件
SYSTEM = """\
在報告進度之前，請針對該會話中的工具結果稽核每一項聲明。
僅報告你有證據支持的工作；如果某件事尚未驗證，請說明。

僅在工作確實需要使用者介入時才暫停：例如破壞性或不可逆的操作、實際範圍變更，或僅有使用者能提供的輸入。

你還有充足的 context。請勿因為 context 限制而停止、總結或建議開啟新會話。請繼續工作。
"""

client = anthropic.Anthropic(timeout=3600.0)   # 運行需要數分鐘/數小時 — 不要阻塞在預設逾時上

resp = client.messages.create(
    model="claude-fable-5",
    max_tokens=64000,
    system=SYSTEM,                       # 進度確認 + 邊界設定 +「context 沒問題」
    messages=messages,
    output_config={"effort": "xhigh"},   # 長期任務
)
```

行動：提高逾時設定（或改用串流/非同步檢查），將這三條指令加入系統提示詞，並從你的 harness 中移除任何剩餘 token 的倒數計時（參見錯誤 #8）。

---

## 第三部分 · 打造生產級應用

06. 記憶即檔案與新鮮子 Agent 的驗證

當 Fable 5 有地方可以寫筆記時，其表現會顯著增強。在 Anthropic 的「Slay the Spire」測試中，存取檔案型記憶體比 Opus 4.8 提升了 3 倍效能。其機制是一個客戶端記憶體工具：模型在 `/memories` 目錄下發出 `tool_use` 指令（view/create/str_replace/insert/delete/rename），由你的應用程式執行。這實現了即時 context：不要預先將所有內容載入視窗——按需提取即可。

兩個動作。第一，掛載記憶體工具並透過提示詞設定記憶體紀律（「每個檔案一個重點」、更新而非重複、刪除錯誤內容）。第二，驗證：一個擁有乾淨 context 的新鮮子 Agent，比在同一個 context 中進行自我批評更能有效地根據規格檢查工作。Fable 可以輕鬆啟動並行的子 Agent——委派獨立的子任務並以非同步方式與它們溝通。

適用情境：多日/重複性任務、需要跨會話記憶的 Agent、任何需要對結果進行獨立檢查的工作。

```python
resp = client.beta.messages.create(
    model="claude-fable-5",
    max_tokens=32000,
    messages=messages,
    tools=[{"type": "memory_20250818", "name": "memory"}],   # 客戶端記憶體工具 (/memories 目錄)
    betas=["context-management-2025-06-27"],                  # 配合 context 編輯：清除過時的工具結果
    system=(
        "每個檔案儲存一個重點，並在頂部加上一行摘要。 "
        "記錄修正與確認過的方法，包括它們為何重要。 "
        "不要儲存程式庫或聊天紀錄中已有的內容；更新現有筆記而非建立重複檔案；刪除錯誤的筆記。 "
        "定期使用一個具有新鮮 context 的子 Agent 根據規格驗證你的工作。"
    ),
)

# 記憶體是一個客戶端工具：模型請求 view/create/str_replace/insert/delete/rename，
# 你的應用程式在 /memories 中執行它們（請防範路徑遍歷攻擊！）。
# 現成後端：繼承 anthropic `BetaAbstractMemoryTool`。
# 範例：github.com/anthropics/anthropic-sdk-python → examples/memory/basic.py
```

行動：掛載帶有 `/memories` 路徑保護的記憶體工具，加入「每個檔案一個重點」的提示詞紀律，並建立一個專門的驗證子 Agent，定期根據規格檢查結果。

---

07. 精算成本：token 效率、快取、context 編輯/壓縮

Fable 5 很昂貴：每 1M token $10/$50 — 是 Opus 的兩倍（Simon Willison 在一天的測試中燒掉了 $110，其中 90% 來自單一 Agent 專案）。但有三個槓桿可以真正降低帳單。努力程度（區塊 02）是影響最大的。提示詞快取（Prompt caching）— 透過 `cache_control` 快取靜態前綴（系統提示詞、工具、長 context），重複呼叫只需支付便宜的 `cache_read`，而非完整的輸入費用。Context 編輯 + 壓縮（beta 標頭 `context-management-2025-06-27`）— 在長時間運行中清除過時的工具結果並壓縮歷史紀錄。

此外，備援機制還有兩個不錯的計費細節：在任何輸出之前的拒絕回應不計費，且在重試時，備援額度會退還快取預熱成本，因此你不會為前綴支付兩次費用。最後是基本的衛生規則——對每個請求進行使用量監控，否則就無從優化。

適用情境：始終在生產環境中使用；特別是長時間運行、重複前綴以及工具密集型工作。

```python
resp = client.beta.messages.create(
    model="claude-fable-5",
    max_tokens=16000,
    system=[{
        "type": "text",
        "text": LONG_STATIC_PROMPT,
        "cache_control": {"type": "ephemeral"},     # 快取靜態前綴
    }],
    messages=messages,
    betas=["context-management-2025-06-27"],         # context 編輯：清除過時的工具結果
)

u = resp.usage
print(f"in={u.input_tokens} out={u.output_tokens} "
      f"cache_read={u.cache_read_input_tokens} cache_write={u.cache_creation_input_tokens}")
# 費用：$10/1M 輸入, $50/1M 輸出；cache_read 遠比一般輸入便宜
```

![每日總成本為 110 美元，其中 Project Alpha 佔據了絕大多數的份額（90%，共 99 美元），而 Project Beta、Project Gamma 及其他項目合計僅佔 10%。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/ee24f1659625af0b.jpg)

<details class="chart-data"><summary>展開數據表（1）DAILY COST</summary><table><thead><tr><th>項目</th><th>數值</th></tr></thead><tbody><tr><td>Total</td><td>$110\nProject Alpha = $99 (90%)\nProject Beta = $6 (5%)\nProject Gamma = $3 (3%)\nOther = $2 (2%)\n</td></tr></tbody></table></details><details class="chart-data"><summary>展開數據表（2）INDICATORS</summary><table><thead><tr><th>項目</th><th>數值</th></tr></thead><tbody><tr><td>\nEFFORT</td><td>滑桿約 35%\nCACHING = 滑桿約 50%\nCOMPACTION = 滑桿約 50%</td></tr></tbody></table></details>

行動：在靜態前綴上加上 `cache_control`，啟用 `context-management`，並記錄 `cache_read`/`cache_write`。日常工作請使用 medium/low 等級——這是最直接的省錢方式。

---

## 常見錯誤

1. 將拒絕回應視為 5xx 錯誤。拒絕回應是 HTTP 200；你的錯誤處理永遠抓不到它，使用者會得到空回應。 → 根據 `stop_reason == "refusal"` 分支處理並發出拒絕指標。

2. 在同一個模型上重試拒絕回應。你會得到另一次拒絕。 → 請在 Opus 4.8 上重試：`fallbacks=[{"model": "claude-opus-4-8"}]`。

3. 在文字中要求它「展示你的推理過程」。這會觸發 `reasoning_extraction` → 導致額外的 Opus 備援、金錢消耗與延遲。 → 使用 `display="summarized"` 讀取結構化的思考區塊。

4. 靜音思考過程。`thinking={"type":"disabled"}` 會被拒絕——自適應思考無法關閉。 → 透過努力程度（調低至 low）來控制深度。

5. 在預設逾時上使用阻塞式客戶端。運行需要數分鐘/數小時——逾時會在中途切斷工作。 → 使用 `Anthropic(timeout=3600.0)`、串流或按排程進行非同步檢查。

6. 提取 `resp.content[0].text`。第零個區塊可能是思考內容 → 導致空輸出或 `IndexError`。 → 使用 `"".join(b.text for b in resp.content if b.type == "text")`。

7. 沿用舊的「指令式」提示詞與 skill。為舊模型設計的逐步指令反而會降低 Fable 的品質。 → 簡化提示詞，給予簡短引導，信任預設值；Fable 能很好地即時更新 skill。

8. 向模型顯示剩餘 token 數量。看到倒數計時，Fable 會開始刪減自己的工作並建議開啟新會話。 → 隱藏計數器或加入「你有充足的 context。請繼續工作。」

## 結論

Fable 5 並非「記住更多事實的 Opus」。它是運作模型的轉變。使用它進行生產環境工作，90% 的關鍵不在於巧妙的提示詞，而在於執行環境：努力程度而非切換模型、自適應思考而非手動預算、拒絕時的強制備援、為長達數小時運行而建構的 harness、記憶即檔案，以及誠實的成本核算。掌握這七種模式，你就能交給 Agent 執行一年前無法想像的任務。忽略它們，你將會忙於除錯那些虛幻的進度與空回應，而模型本身從來都不是問題所在。

立即行動檢查清單

1. 設定 `model="claude-fable-5"`、`effort="high"`（困難任務用 xhigh），以及較大的 `max_tokens`。

1. 將每個呼叫路徑包裝在對 Opus 4.8 的備援中，並記錄拒絕與備援服務指標。

1. 有意識地使用自適應思考：`display="summarized"`，刪除「重複推理過程」的指令，在多輪對話中傳回思考區塊。

1. 針對長時間運行：提高逾時設定，加入腳手架（進度確認、邊界設定、「context 沒問題」），加入記憶體 + 驗證子 Agent。

1. 控制成本：對前綴使用提示詞快取，啟用 `context-management`，記錄使用量；日常工作使用 medium/low 等級。

## 標籤

教學資源, LLM, 新產品, Anthropic, Fable 5
