Claude Fable 5 是 Anthropic 2026 年 6 月 9 日推出的旗艦模型,主打 1M context、多天無人監督自主運作、xhigh effort 級推理。Fable 5 曾於 6 月 12 日因商務部出口管制暫停,6 月 30 日解除禁令重新上線,是 Anthropic 目前 API 可用的最高等級模型。
本篇彙整 Anthropic 官方《Prompting Claude Fable 5》handbook 精華,拆解 Fable 5 相比 Opus 4.8 的核心行為改變,以及對應的 prompt 與 harness 調整方式。適合開發者、AI Agent 建構者、企業技術決策者作為 Fable 5 上手的第一份中文完整指南。
Fable 5 是什麼：1M context、xhigh effort、多天自主運作
Fable 5 API 型號claude-fable-5,同時具備以下規格：
Anthropic 官方對 Fable 5 相對 Opus 4.8 的改進定調為 7 項：長時序自主(Long-horizon autonomy)、複雜問題單次通過率(first-shot correctness)、視覺、企業工作流、程式碼審查與除錯、模糊需求處理、併發子代理。這 7 項改進的共同底層邏輯是同一件事：Fable 5 可以在用戶不看的時間裡持續穩定產出。
核心典範轉向：從 Prompt Engineering 進到 Loop Engineering
Fable 5 最大的心法轉變不是 prompt 寫更好,而是從 prompt 步驟改成設計 loop。過去 Opus 4.6/4.7 的心法是：寫一個好 prompt、Claude 回一個好答案。Fable 5 的心法是：設計一個能讓 Claude 自我修正的環境迴圈,讓它反覆 plan → act → review → improve,直到任務完成。
Anthropic 在官方 handbook 明確給出這條 loop 設計指令：
Establish a method for checking your own work at an interval of [X] as you build. Run this every [X interval], verifying your work with subagents against the specification.
這一段的翻譯:「建立一套自我檢查機制,以 [X] 為間隔驗證你自己的工作。每 [X] 間隔跑一次驗證,用子代理對照規格檢查。」關鍵是用一組獨立 context 的驗證子代理(fresh-context verifier subagents),而不是讓主 agent 自我批評—因為主 agent 已經有偏見。
這個轉向也回應了 abmedia 過去報導的「Harness Engineering」概念—AI 的下一個戰場不是模型,而是模型外面那層架構;以及 Akshay 提出的「模型只是迴圈中的一個節點」觀點。Loop engineering 是 Anthropic 對這條思路的官方版本。
Effort 參數分級：5 級控制 Fable 的 token 花費
Effort 是 Fable 5 最重要的成本控制旋鈕,分成 5 級,由高到低影響 Claude 願意花多少 token 在 thinking、tool calls、text response 上：
Anthropic 官方對 Fable 5 的建議是：從high(預設)開始,對能力最敏感的工作用xhigh,例行工作降到medium或low。官方特別強調：Fable 5 在 low effort 下的表現,常常超過前代模型的 xhigh 表現—這是 Fable 5 世代模型能力提升的直接證據。如果任務完成但比預期慢、或想要更互動的工作節奏,直接降 effort。
另外 Anthropic 提醒：在high與xhigheffort 下要設較大的max_tokens,因為這是 thinking + response text 的總硬性上限;起始建議 64K tokens,再依實測調整。
官方 8 大 Prompt 範本：handbook 精華整理
Anthropic handbook 提供了 8 段可直接複製的 prompt 範本,涵蓋 Fable 5 最常出現的行為偏差。以下逐條整理與翻譯。
When you have enough information to act, act. Do not re-derive facts already established in the conversation, re-litigate a decision the user has already made, or narrate options you will not pursue in user-facing messages. If you are weighing a choice, give a recommendation, not an exhaustive survey.
翻譯:「當你有足夠資訊執行時,執行。不要重新推導對話已建立的事實,不要重議用戶已做的決定,不要在給用戶看的訊息裡條列你不會採用的選項。若要判斷選擇,給出建議、不要窮舉分析。」
Don’t add features, refactor, or introduce abstractions beyond what the task requires. A bug fix doesn’t need surrounding cleanup and a one-shot operation usually doesn’t need a helper. Don’t add error handling, fallbacks, or validation for scenarios that cannot happen. Trust internal code and framework guarantees.
Before reporting progress, audit each claim against a tool result from this session. Only report work you can point to evidence for; if something is not yet verified, say so explicitly. Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that.
When the user is describing a problem, asking a question, or thinking out loud rather than requesting a change, the deliverable is your assessment. Report your findings and stop. Don’t apply a fix until they ask for one.
Delegate independent subtasks to subagents and keep working while they run. Intervene if a subagent goes off track or is missing relevant context.
Store one lesson per file with a one-line summary at the top. Record corrections and confirmed approaches alike, including why they mattered. Don’t save what the repo or chat history already records; update an existing note rather than creating a duplicate; delete notes that turn out to be wrong.
You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking “Want me to…?” or “Shall I…?” will block the work. For reversible actions that follow from the original request, proceed without asking. Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done, do that work now with tool calls.
You have ample context remaining. Do not stop, summarize, or suggest a new session on account of context limits. Continue the work.
Skills 與記憶系統：讓 Fable 累積跨對話知識
Fable 5 相比前代最重要的差異之一,是它能主動使用外部記憶。Anthropic 官方推薦的做法是給 Fable 一個可寫的 Markdown 檔案作為 memory store,讓它把每次對話學到的教訓寫下來、下次對話再讀取。
官方 bootstrap 指令：
Reflect on the previous sessions we’ve had together. Use subagents to identify core themes and lessons, and store them in [X]. Make sure you know to reference [X] for future use.
對已有專案的實務做法：讓 Fable 5 用併發子代理去分析過去的 session 紀錄(如 Claude Code 的~/.claude/projects/底下的 JSONL 檔),抽取核心主題與教訓,儲存到指定 memory 檔案。往後每次啟動時,Fable 會自動 reference 這個檔案作為背景。
Skills 是與 memory 平行的另一套機制。Skills 是可執行的技能檔案(通常是 Markdown + 相關資源),讓 Fable 5 在遇到特定情境時觸發特定行為。Anthropic 官方警告：為前代模型開發的 Skills 對 Fable 5 常常過度規範,反而降低輸出品質。遷移時應該檢視舊 Skills、移除過度指令、讓 Fable 5 用預設能力發揮;Fable 5 本身也能在執行任務中即時更新 Skills。
併發子代理：Fable 5 最強的差異化能力
官方明確指出 Fable 5「dispatches parallel subagents more readily than prior models」—比前代模型更願意主動派併發子代理。這是 Fable 5 相對 Opus 4.8 最大的能力躍進之一。
Anthropic 給的實務建議：
abmedia 過去《AI Agent 工具鏈完整指南》已解析編碼、支付、託管三層工具鏈設計,Fable 5 的併發子代理能力剛好填補了「orchestrator 層」的能力缺口。
常見踩坑：Anthropic 官方點名的 4 個陷阱
官方 handbook 特別點名以下 4 個常見的踩坑情境,以及對應的解方：
陷阱 1:客戶端 timeout 太短—Fable 5 單次請求在高 effort 下可能跑幾十分鐘、autonomous 情境可能跑幾小時。舊 harness 的 timeout 設定會直接掛掉。解方：調高 timeout、啟用 streaming、加入 progress indicator;長時序任務改為非同步查詢(排程 job 檢查)而不是 block。
陷阱 2:System prompt 要求 Claude「解釋你的推理」—會觸發 refusal。Fable 5 的 safety classifier 有一條reasoning_extraction分類,若你的 prompt 明確要求「echo/transcribe/explain your internal reasoning as response text」,會被拒。Anthropic 建議：遷移時 audit 所有 skills 與 system prompts,移除 show-your-thinking 指令;若真的需要推理可見性,讀 adaptive thinking 的thinkingblock、或用 send-to-user tool 表面化。
陷阱 3:Effort 用錯—舊模型的直覺是「越高越好」,Fable 5 不是。低 effort 常常已經超過前代 xhigh。解方：xhigh 專用於能力最敏感的 workload;例行工作降到 medium/low、可省顯著成本。
陷阱 4:未處理 refusal 分支—Fable 5 拒絕請求時回 HTTP 200 +stop_reason: refusal(不是 error)。整合方要新加三段處理：refusal 回應解析、fallback 到其他 Claude 模型(server-sidefallbacks參數、SDK middleware、或手動)、new billing rules(refused-before-output 不收費、retry 有 fallback credit 補償 cache 切換成本)。
3 步驟 checklist：開始你的第一個 Fable 5 專案
綜合上述,以下是給第一次上手 Fable 5 的 3 步驟 checklist:
Step 1:選一個「以前對 Opus 4.8 太難」的任務。Anthropic 官方建議「Start at the top of your difficulty range」—挑一個原本你不會派給 Opus 4.8 的難題,讓 Fable 5 自己 scope、問澄清問題、執行到完。用簡單任務測試 Fable 5 只會 undersell 它的能力。
Step 2:建立 verifier subagent 迴圈。不要靠 Fable 5 自我批評;派 fresh-context 子代理定期驗證主 agent 的輸出。這是 loop engineering 的核心。設定驗證間隔(例如每完成一個 subtask、每 30 分鐘、每花 100K tokens 一次),讓子代理對照原始規格檢查。
Step 3:建立 memory 檔案,累積跨對話知識。給 Fable 一個 Markdown 檔案作為 memory store,把每次對話學到的教訓、修正、確認過的方法寫入;每次啟動讓 Fable 讀取這個檔案。這是 Fable 5 相對前代模型最能發揮的優勢之一。
Fable 5 的能力天花板遠比 prompt 表面看起來高。多數用戶低估它的原因,是還在用前代模型的 prompt 心法對待它—把它當一次性回答機、而不是一個持續運作的 loop 內節點。Loop engineering 是 2026 年 AI 開發的下一個學習曲線。
風險提示
加密貨幣投資具有高度風險，其價格可能波動劇烈，您可能損失全部本金。請謹慎評估風險。