Anthropic 發佈了面向 Claude Fable 5 和 Claude Mythos 5 的提示工程指南。這篇文件的重點不是介紹模型能力本身，而是告訴開發者：如果把舊的 Claude Opus 4.8 工作流遷移到 Fable 5，提示詞、Agent harness、逾時策略和安全回退都可能需要調整。
Fable 5 的變化可以概括成一句話：它更適合長時間、複雜、端到端的任務，但也更容易在高 effort 下花更多時間規劃、檢查和擴展上下文。用好它，關鍵不是把舊提示詞原封不動搬過去，而是重新設計任務邊界、驗證方式和長任務互動。
先把任務難度拉上去測試
Anthropic 建議，不要只用簡單任務測試 Fable 5。它的優勢更容易出現在過去需要人工花數小時、數天甚至數週完成的工作中，比如大型程式碼遷移、多階段分析、複雜 Agent 流程、跨文件研究和高精度視覺理解。
如果只用短問答、簡單摘要或一次性小函式來評估，容易低估 Fable 5。更合理的測試方式是拿一類舊模型做起來費勁的任務，讓模型完成從理解、計劃、執行到驗證的完整鏈路。
適合測試的任務包括：
- 讓模型閱讀程式碼庫並完成跨模組修改；
- 讓模型根據目標規格實作功能、補測試、跑檢查；
- 讓 Agent 處理多天級別的研究或分析流程；
- 讓模型從截圖、表格、PDF、圖表中提取結構化資訊；
- 讓多個子 Agent 分工完成獨立任務，再由主 Agent 彙總。
effort 是主要控制旋鈕
Fable 5 中，effort 是控制智能程度、延遲和成本的主要參數。官方建議，大多數任務可以從 high 開始，最重的能力敏感型任務再用 xhigh，常規任務則可以用 medium 或 low。
一個值得注意的點是，Fable 5 的低 effort 檔位也可能強於舊模型的高 effort 檔位。也就是說，遷移時不一定要預設把所有任務都拉到最高。更好的策略是：
- 難題和高價值任務優先用
high； - 最關鍵的複雜推理或長任務用
xhigh； - 常規問答、輕量改寫、簡單工具調用用
medium或low； - 如果任務能完成但耗時過長，就降低 effort；
- 如果輸出驗證不足、推理不夠深入，再提高 effort。
高 effort 的好處是推理和自檢更強，代價是模型可能多做上下文收集、額外解釋或不必要的整理。對編碼任務，提示詞裡最好明確限制範圍：
|
|
長任務要改逾時、串流和進度展示
Fable 5 在困難任務上的單次請求可能執行很多分鐘，自主任務甚至可能持續數小時。這是遷移時最容易踩坑的地方。
如果你的應用原來按短請求設計，需要優先檢查：
- 客戶端和服務端逾時時間；
- 是否支援 streaming；
- 使用者介面是否能展示進度；
- Agent harness 是否支援非同步檢查；
- 是否需要用定時任務輪詢，而不是一直阻塞等待。
為了避免模型在模糊任務中過度規劃，可以加一條簡短約束：
|
|
這類提示比寫一大段行為清單更有效，因為 Fable 5 的指令遵循能力已經更強。
讓進度彙報基於真實證據
長時間 Agent 執行中，一個常見問題是模型可能給出聽起來合理、但沒有工具結果支撐的狀態彙報。Anthropic 建議在提示詞中要求模型先審計進度，再向使用者彙報。
可以使用類似約束：
|
|
這對程式碼 Agent、資料處理 Agent 和長時間研究任務都很重要。使用者真正需要的不是樂觀狀態，而是可追蹤、可複核的進展。
邊界要說清楚
Fable 5 更主動，也更可能在沒有明確要求時做額外動作，比如順手草擬郵件、建立備份分支或擴展任務範圍。遷移舊提示詞時，需要把「什麼時候只給判斷，什麼時候可以動手」說清楚。
例如：
|
|
這條規則對客服、維運、開發工具和企業知識工作都適用。模型越能幹，越需要清楚地定義權限邊界。
子 Agent 要更主動地使用
官方文件提到，Fable 5 比舊模型更擅長調度和維持並行子 Agent。對複雜任務，不需要所有步驟都由主 Agent 順序完成。更好的模式是把獨立子任務分出去，主 Agent 繼續推進主線，並在子 Agent 偏離目標時介入。
適合分派給子 Agent 的任務包括：
- 在程式碼庫不同模組中查找相關實作；
- 獨立驗證某個修復是否滿足規格；
- 分析不同文件或資料源；
- 對前端實作做視覺對照；
- 對最終輸出做 fresh-context 審查。
對於長任務，Anthropic 還建議使用獨立驗證子 Agent，而不是只讓模型自我批判。可以在提示詞裡要求：
|
|
這能減少「模型自己覺得自己對了」的問題。
記憶系統會提高長期表現
Fable 5 適合有記憶的工作流。官方建議給模型一個可以記錄經驗的位置，哪怕只是 Markdown 文件。關鍵是記錄可複用的教訓，而不是複製聊天記錄。
一個簡單規則是：
|
|
這對持續維護程式碼庫、長期研究專案、企業知識庫和複雜自動化流程尤其有用。Fable 5 不只是一次性執行器，更適合在多次任務之間積累上下文。
不要要求模型複述內部推理
遷移到 Fable 5 時，要檢查舊 prompt、skill 和 system 指令裡是否有「展示思考過程」「複述推理」「解釋內部 reasoning」之類要求。官方文件明確提醒，這類指令可能觸發 reasoning_extraction 拒絕類別，從而導致更多請求回退到 Claude Opus 4.8。
如果應用確實需要推理可見性，應該讀取結構化的 thinking blocks，而不是要求模型把內部推理作為普通回覆文字輸出。長任務中需要把進度展示給使用者，也更適合建立一個 send_to_user 之類的工具，讓 Agent 在不中斷執行的情況下發送必須原樣展示的資訊。
注意安全分類和 fallback
Fable 5 會執行面向高風險領域的安全分類器，重點包括攻擊性網路安全技術、生物與生命科學內容，以及提取模型總結思維的請求。即便是正當的網路安全或生命科學任務，也可能觸發保護機制。
如果請求被拒絕或分流，API 側需要配置 server-side 或 client-side fallback 到 Claude Opus 4.8。也就是說，遷移到 Fable 5 不只是換模型名，還要重新檢查失敗處理、stop_reason: "refusal"、使用者提示和計費路徑。
給使用者的最終回覆要更清楚
在長時間工具調用和 Agent 工作流之後，模型可能積累很多內部上下文，最終總結容易變成只有執行者自己看得懂的 shorthand。Anthropic 建議給模型單獨約束最終回覆風格：先說結果，再說關鍵支持資訊，不要把工作過程中的縮寫、箭頭鏈和內部標籤直接丟給使用者。
可以把最終回覆要求寫成：
|
|
這條對產品裡的 Agent 體驗很關鍵。使用者不需要看見模型所有工作痕跡，只需要知道結果、證據、風險和下一步。
遷移時最該先改什麼
如果你已經有 Claude Agent 或提示詞體系，遷移 Fable 5 時可以按這個順序檢查：
- 把測試任務換成更難、更長、更完整的任務；
- 重新評估
effort，不要所有任務都預設最高； - 調整逾時、streaming 和非同步任務檢查；
- 給長任務加上基於工具結果的進度審計；
- 明確模型什麼時候能動手，什麼時候只能報告判斷；
- 把獨立驗證交給 fresh-context 子 Agent；
- 增加簡單記憶系統，保存跨任務教訓；
- 刪除要求模型複述內部推理的舊指令；
- 配置 Fable 5 拒絕或分流後的 Opus 4.8 fallback；
- 重寫最終總結風格，讓使用者能快速看懂結果。
Fable 5 的提示工程重點，不是寫更長的規則，而是把工作流設計得更適合強模型：任務更難、邊界更清楚、驗證更真實、互動更非同步。舊模型需要很多細碎約束才能穩定完成的事，在 Fable 5 上往往可以用更短的原則來控制；但長任務、權限邊界和安全回退，反而更需要在 harness 層面提前設計好。