2026 年 11 月 9 日，Anthropic 發布 Claude Fable 5.2 與 Mythos 5.2。新版本把高難度推理與長時間 Agent 工作帶到企業採購桌上，也調低了標準 API 的 token 單價。但對正在跑文件分析、軟體維護或研究流程的團隊而言，值得追問的是：每一件真正通過驗收的工作，究竟變便宜了沒有？
這次更新牽涉三個決策：更強模型應該放在哪些任務、既有 Agent 要付出多少遷移成本，以及敏感資料能否在可接受的條件下處理。本文依 11 月 10 日可查證的官方資料分析，將產品規格與企業導入建議分開；不把廠商展示視為獨立實測。
一、版本更新：Fable 與 Mythos 的使用資格不同
依 Anthropic 發布說明，兩者採用相同底層模型，Fable 加上較強的資安與生物領域防濫用限制，Mythos 則須透過驗證計畫申請。這不是企業付費後就能任意切換的兩個名稱。
官方列出的 1M token 上下文與 128K 最大輸出，擴大了可放入單次任務的資料量，卻不等於模型一定能完整理解整份資料，或保證長時間執行都不偏離目標。供應商描述的能力改善，仍需用自己的文件、程式庫與驗收標準測試。
部署位置也要一起考慮。AWS 已公告 Fable 5.2 可透過 Amazon Bedrock 與 Claude Platform on AWS 使用，但特定區域、帳號與條款仍要個別確認。企業可先用 🔗雲端與地端的部署取捨 整理資料流向，再決定新模型適合處理哪一段工作。
先確認瓶頸在哪一層
假設一個採購分析 Agent 經常漏掉合約附件中的限制，原因可能是資料根本沒有送入、檢索只抓到部分段落，或最後答案沒有核對附件。這三種情況需要的修正不同。若缺的是資料，直接升級模型可能只讓錯誤答案變得更流暢；若資料完整、流程也穩定，卻仍無法處理跨文件矛盾，才值得把案例交給新模型比較。
企業可以先列出最近失敗的十幾件工作，按資料缺漏、工具失敗、推理錯誤與驗收不清分類。這不是為模型設定任意淘汰門檻，而是避免把整條流程的問題都歸給模型。更強的模型應該解決可辨認的瓶頸，採購理由才有辦法在上線後核對。
二、第一筆帳：單價降 20%，不等於總成本降 20%
Claude API 發行紀錄 列出的標準價格如下，單位均為每百萬 token 美元；快取、批次、快速模式、平台加價及其他費用不包含在表內。
| 模型 | 輸入價格 | 輸出價格 |
|---|---|---|
| Claude Fable 5.1 | US$10 | US$50 |
| Claude Fable 5.2 | US$8 | US$40 |
兩項單價各下降 20%，這是由公布價格計算出的比率。假設某個任務恰好產生 100 萬計費輸入 token、20 萬計費輸出 token，單純 token 費會從 20 美元降到 16 美元。這只是固定用量的算例，不是實測，也不代表每個企業任務都省 4 美元。
如果新模型為同一工作增加規劃、重試或平行分工，計費用量就會改變；反過來，若一次完成減少人工返工，單價較高的方案也可能划算。應同時記錄 API、工具、執行環境與人工複核費用，再除以通過驗收的任務數，得到「每件合格成果成本」。
評估平台時，可對照 🔗AI-Stack 解決方案 檢視模型接入、執行環境與既有平台的分工；不要把任何平台名稱直接當作任務品質或費用節省的保證。
分開看帳單與合格成果
再看一個包含工具、執行環境與人工檢查的假設試點：原方案花費120美元，40件成果合格，每件成本3美元；候選方案花費160美元，64件合格，每件成本2.5美元。總支出增加，合格成果的單位成本卻下降。這組數字只是說明計算方法，並非Fable的實測表現；比較時還必須確保任務難度與合格標準相同。
預算會議應同時看三張明細：模型與工具的直接費用、人員複核及返工時間，以及未完成工作造成的延誤。不要把人力時間直接當成可裁減成本；它也可能轉為處理更多案件的容量。先說清楚收益是哪一種，才不會把技術改善誤寫成已實現的財務節省。
三、第二筆帳：先與現有 Opus 流程比較
並非所有工作都需要升到 Fable。新版導入文件 建議，多數工作先從最新 Opus 開始，當較高推理設定仍無法滿足自己的評測要求，再考慮 Fable 5.2。
這個順序適合企業採用：先保留既有可驗收的基線，把困難案例交給新模型比較。選幾種真正耗費人力的工作，例如跨文件找出矛盾、修改後補齊測試，或產出可追溯來源的研究摘要，而不是只比較一段漂亮的回答。
測試時保持輸入資料、工具權限與合格條件一致，記錄完成率、人工修訂時間與每件合格成果成本。若只替新模型增加工具或額外上下文，就很難判斷改善來自模型本身，還是流程改良。這類版本與評測紀錄，可以沿用 🔗MLOps 的管理思路，保留可重現、可回退的依據。
用三種實際情境決定升級範圍
文件比對可以要求每一項差異都附頁碼與引文；程式維護可以要求修改內容、測試結果和已知限制；研究整理則要區分已證實事實、推論與待確認事項。這三種任務都能產生可檢查的交付物，比單純詢問模型「是否完成」更容易評估。
也應保留不升級的對照組。例如固定格式資料擷取若已穩定達標，就不必因新版本推出而全面替換。可先把某一類失敗案件交給候選模型，觀察是否真的改善，再擴到更多工作。這種分段導入能讓企業看見適用範圍，也比較容易在效果不佳時退回原流程。
四、第三筆帳：API 相容性與中途回退
升級不能只替換模型名稱。遷移指南 提醒，自行組裝 API 請求的程式若修改先前對話、系統提示或工具設定，再送回綁定舊前綴的 thinking 區塊，可能遇到 400 錯誤。應測試實際請求流程，不要為了消除錯誤就任意丟棄執行狀態。
模型切換也有方向差異：Fable 5.2 的 thinking 區塊不能由所有舊模型讀取。多模型路由若在任務中途降級，應重新確認交接資訊是否足夠，不能把「請求成功」當作「推理狀態完整延續」。
建議把升級測試拆成正常完成、失敗重試與回退三條路徑。每條都要保留可讀的工作摘要、已執行工具與檢查點。需要反覆比較設定時，可先了解 🔗TaaS 的測試服務模式，再依實際工作負載安排驗證；這裡提出的是導入方法，並非宣稱平台已提供特定模型或相容性承諾。
切換失敗時，要交接的是工作狀態
一個可恢復的任務，應能說清楚已讀取哪些資料、完成哪些步驟、還有哪些問題，以及哪些外部動作已經執行。假如Agent已提交一次變更，連線失敗後重跑時就要能辨認該動作，避免再次提交。這是工作流程應提供的紀錄能力，不能只寄望模型記得前一輪發生的事。
因此，移行測試不只檢查HTTP回應成功，也要在代表性任務中途模擬工具失敗、逾時與模型回退。比較恢復後的交付物、額外費用及是否重複動作。若備援模型只能接收可讀摘要，就要明確定義摘要內容，而不是默認它能接續原模型的所有內部狀態。
五、資料條件：零保留必須逐平台確認
Fable 5.2 模型文件 列有 30 天資料保留要求，除非 Anthropic 明確授權，否則不適用零資料保留。另一方面，AWS 的公告指出，在 Enterprise Frontier Safeguards 可用前，符合資格的客戶可使用零資料保留。
這些描述的適用平台與資格條件不同，不能合併成「所有企業都可以零保留」。試點前應由採購、資安與資料負責人確認實際帳號、區域、保留範圍及契約例外，再決定哪些資料可送入。若條件未明，先用合成或去識別資料驗證流程，避免把測試成功與資料核准混為一談。
資料保留與工作紀錄要分開核對
供應商的資料保留條件，只是整條資料流的一部分。企業端還可能保存檢索文件、工具回應、執行日誌與人工審查紀錄。即使取得特定平台的零保留資格，也不能因此認定自家系統沒有留下敏感內容；反過來，保留可追溯紀錄也不代表必須保存每一份原始文件。
可先畫出輸入資料、外部服務、日誌與成果的流向，逐項記錄保存位置、可讀取角色和刪除方式，再與契約條件比對。這能把「能否試用模型」和「哪些資料可正式投入」拆成兩個可回答的問題，避免功能測試通過後才發現採購或資料條件尚未解決。
六、長任務驗收：把預算、權限與成果一起測
企業試點可以分成三步，這些是本文提出的操作建議，並非模型效能測試結果：
- 固定一組代表性任務與成果樣本，先寫出合格條件。程式修改要有測試結果；研究報告要能回到原始來源；文件分析要能指出證據位置。
- 設定費用、執行時間與工具呼叫上限。涉及寫入或對外動作時加入人工檢查點，確認中止與恢復流程都能運作。
- 將成功、失敗與被拒絕的任務都納入統計，再看每件合格成果成本。低失敗率不能靠排除難題取得，低成本也不能靠省略人工複核取得。
若 Agent 同時使用自有算力與外部 API，還要分開記錄兩邊的資源與費用。🔗GPU 資源管理 的容量與排程觀念可用於自有環境，但購買更多 GPU 不會直接降低第三方 API 的 token 單價。
讓驗收有明確的失敗定義
以合約摘要為例，語句通順並不等於合格。可以預先列出必須涵蓋的條款、引用應指向的位置，以及遇到附件缺失時應如何回報。測試人員依同一份規則複核，並留下修訂原因，才能分辨模型漏讀、資料不足與要求本身不清楚。
長任務還需要分階段的停止條件。當工具連續失敗、預算即將用完或關鍵資料缺失時，先交回已完成部分與待處理事項，可能比無限重試更有價值。這些上限要依業務容忍度訂定，不能把示範中的設定直接複製成全公司的標準。
七、結論：升級決策看三個結果
Claude Fable 5.2 提供了一個值得測試的新選項。企業可以用三個結果決定是否擴大採用：困難任務是否更常通過驗收、每件合格成果是否更划算，以及資料與失敗回退條件是否可接受。
單價下降值得關注，穩定交付才值得擴大預算。若既有模型已達標，保留原流程、只把少數難題升級，也是一個合理的選擇。
想持續追蹤企業 AI 的部署與驗收實務？歡迎訂閱 AI-Stack 部落格，掌握後續分析。
採用前留下可重查的決策紀錄
一份有用的升級紀錄，至少應保存測試工作、模型與設定、資料版本、成功及失敗樣本、人工修改時間與成本計算方式。當使用量增加、供應商條款調整或任務變難時，團隊才知道要重新檢查哪一項假設，而不是只剩下「上次覺得比較好用」的印象。
擴大採用也可以是有限的：保留原模型處理固定工作，為較難案件設定升級條件，定期檢查費用與品質。這讓採購、工程與業務能針對同一份成果說話。真正要恢復的是穩定交付能力，而不是為了追上版本名稱而增加一層無法驗證的流程。
