Claude Mythos 5 把存取變分級

Anthropic 把 Claude Mythos 5 拆成公開與受限兩個存取層級，重點其實是政策路由，不是單一模型。

我看模型發表看久了，真的會有一種煩躁感：大家都愛講「更強」，但一碰到風險就開始縮。不是不能縮，是你至少講清楚你到底在縮什麼。我最近研究 Anthropic 的 Claude Mythos 5，感覺最有意思的根本不是模型名字，而是它把「能不能用、誰能用、用到哪裡要降級」這件事，直接做成產品的一部分。這種做法很不討喜，卻很實際。因為真正麻煩的從來不是模型會不會答，而是它答得太順、太快、太像沒事一樣。

我第一次注意到這件事，是從 The Guardian 的報導開始。它把 Anthropic 這套做法寫得很清楚：公開版、受限版、再加上一層路由，把敏感請求往較低風險的模型丟。這不是新聞稿那種漂亮話，這是很硬的操作邏輯。你如果是做 AI 產品、做平台、做內部工具，這套方法論其實很值得拆。

它不是發一個模型，是發一套權限系統

“Anthropic is offering an unrestricted version, Claude Mythos 5, to companies and organizations that already have access to this model family… Anthropic says most queries about cybersecurity or biology and chemistry to Fable 5 will be routed instead to the lower-tier model, Opus 4.8.”

翻譯一下就是：模型本身不再是唯一主角，存取規則才是。你不是買到一個「會回答一切」的東西，而是買到一個會根據問題種類、用戶身分、風險等級，自己決定要不要升級、降級、甚至拒答的系統。

我以前幫一個內部助理做權限設計時，就踩過這個坑。團隊一開始都說要「一個模型搞定」，結果真的上線後，工程師問除錯、產品問市場分析、資安問弱點排查、法務問合規風險，全部混在一起。你若只靠一個大一統模型，最後不是過度封鎖，就是過度放行。兩邊都難看。

Anthropic 這次的做法比較像是先承認現實：有些問題就是不該用最強路徑回答。不是因為模型笨，而是因為風險不值得。這一點很重要，因為它把「能力」和「可開放程度」拆開了。很多團隊老是把這兩件事綁死，結果產品設計永遠卡在二選一。

實操上，我會建議你先把模型存取拆成三層：公開可用、受信任客戶可用、風險請求降級或拒絕。不要一開始就想做十層，先把最常見的三種路徑定義清楚。你要做的是讓系統知道自己站在哪一層，而不是假裝所有問題都能同一個答案解決。

• 公開層：一般寫作、摘要、程式除錯、圖片理解。
• 受限層：已驗證客戶、合作夥伴、內部高權限用途。
• 降級層：資安、雙用途生物化學、模型內部資訊抽取。

「安全版」不是比較善良，是比較窄

“Dubbed Fable 5, the model is the first to be made widely available from the company’s new Mythos class… Anthropic promoted Fable 5 as useful for writing and debugging software code, answering complex research questions and analyzing images.”

白話講，所謂 safe，不是「這模型很溫柔」，而是「這版本被限制到一個公司敢公開放出去」。這差很多。前者像行銷文案，後者像工程判斷。

我其實很怕那種把安全講成道德優越的敘事。很多產品說自己「安全」，結果只是加了幾條關鍵字規則，或者把敏感內容交給客服善後。那不是安全，那是把風險往後拖。Anthropic 這裡至少誠實一點：公開版就是公開版，能力與風險都收斂過；真正更強的版本留給已經被驗證過的組織。

這對開發者的影響很直接。你不能再假設某個模型家族裡，最強那顆會永遠對所有人開放。今天你用得到，不代表明年還是同一個 tier。供應商可能因為法規、風險、合作策略，把模型拆成不同層。你如果架構上只押一個最高階模型，等於把產品命運交給別人的存取表。

實操寫法很簡單：每個 tier 都要有明確職責，UI 也要講清楚。不要讓使用者送出請求後才發現被偷偷降級。人可以接受限制，但很討厭被陰。你可以在送出前先標示：「這類問題會使用標準模型」、「這類問題需要驗證後才會進入高階模型」。

• 把 tier 名稱寫進產品文件，不要只寫在內部 wiki。
• 在介面上先說明路徑，不要事後才補解釋。
• 對每次降級保留 reason code，方便追查。

1,000 小時紅隊，不是裝忙，是把政策拿去撞牆

“The company also said it had hired outside experts to spend more than 1,000 hours trying to find ways to bypass these restrictions – a process known as red-teaming. The company ran a bug bounty program, which pays people to find security flaws.”

這段我很買單，因為它不是「我們有測試」，而是把測試做成可量化的壓力測試。1,000 小時不是漂亮數字而已，它表示 Anthropic 知道這套限制一定有人想繞過去，所以先請外部專家來撞牆。

很多團隊不做紅隊，理由都很熟：太貴、太慢、太丟臉、怕測出問題。可是不測才是最貴的。你如果真的把模型拿去做資安、醫療、生物、基礎設施相關的工作，卻沒有做對抗式測試，那不是謹慎，是賭運氣。

我以前看過一個內部代理系統，功能展示時很漂亮，結果一被 prompt chaining 就開始漏政策。不是模型壞，是設計根本沒想過使用者會連續下誘導。這種洞，單靠人工點幾次是不會看到的。你得真的讓人去找繞法，還要付錢給他們找。

實操上，我會把紅隊拆成四種測法：直接誘導、角色扮演、翻譯繞過、工具濫用。然後每次模型或政策更新後都重跑一次。別只在上線前做一次，之後就當沒事。政策會老，攻擊方式不會。

如果你想補強這塊，可以參考 Anthropic research、NIST AI Risk Management Framework，還有 OpenAI 對模型安全的公開說法。我不是要你照抄誰的話，而是要你把「先測再放」當成基本功。

路由降級比硬拒絕更像真的產品

“Anthropic says most queries about cybersecurity or biology and chemistry to Fable 5 will be routed instead to the lower-tier model, Opus 4.8… queries will also fall back to the less powerful model.”

這裡最值得偷的，不是拒絕，而是路由。很多系統一碰到風險就直接擋掉，結果使用者只看到一個冷冰冰的不能用。Anthropic 的做法比較成熟：不是每個危險請求都一刀切，而是先判斷能不能降級處理。

我很喜歡這種思路，因為它承認一件事：有些請求不是壞，只是不適合用最強模型。比如一般除錯可以交給高階模型，但如果問題已經碰到真實系統弱點、敏感資料、或高風險領域，就該往較低能力、較低風險的模型走，甚至進人工審核。

這種設計也比較省錢。很多團隊把最貴的模型當預設，結果大量普通請求都在燒錢。你花了高階模型的費用，卻只是在寫摘要、改文案、整理會議記錄，這真的很蠢。路由不是炫技，是成本控制加風險控管。

實作時，我會建議你不要只靠關鍵字。關鍵字太好繞了，還會誤殺正常請求。比較好的做法是先做 intent classification，再根據用途、風險、使用者等級決定去向。最後把 route、reason、model version 全部寫進 log，這樣你才知道自己到底在幹嘛。

• 輸入先分類，再決定模型。
• 保留 downgrade reason，避免黑箱。
• 每週看一次降級率，避免規則漂移。

分層存取已經是商業模式，不只是技術細節

“That select group was expanded in early June to about 200 organizations in more than 15 countries and is expected to grow further.”

這句很關鍵，因為它告訴你存取不是附帶條件，而是分發方式本身。誰能先拿到、誰只能拿公開版、誰要被審核，這些都已經變成產品策略的一部分。

我覺得很多新創會低估這件事。他們以為模型 API 就像買雲端資源，付錢就好。但當供應商開始用信任、地區、產業、用途來切層，你的採購、法務、銷售、工程就全部綁在一起了。尤其是做企業市場的團隊，客戶能不能買到某個 tier，往往比你能不能做出 demo 更重要。

這也代表你自己的 go-to-market 要跟著改。你不能只寫「支援最強模型」，你要寫清楚哪些客戶可以用哪一層、哪些地區受限、哪些用途要審核。這不是多此一舉，這是避免你把不該賣的東西賣出去。

實操寫法是做一張 tier mapping 表：客戶類型、地區、產業、用途、可用模型、審核人、拒絕條件，一次列清楚。讓業務、法務、工程看同一份，不要各自用各自的版本。這種表很土，但真的能救命。

如果你要看原始脈絡，可以直接看 Anthropic、The Guardian 報導，以及相關的 White House 政策頁面。我不會把這些東西講成神諭，我只是把它們當成你做產品時會碰到的現實。

價格告訴你：這不是一般版，是高階權限版

“The launch of Fable 5 comes with a steep price tag – $10 per million input tokens and $50 per million output tokens, which amounts to double the cost of Opus 4.8.”

價格這種東西很粗暴，但很誠實。它直接告訴你：這顆模型不是拿來當預設路徑的。雙倍價格通常意味著更高能力、更高運算成本，或者更高的風險管理成本。三者常常一起來。

我一直覺得 token pricing 很討厭，因為它會把真實成本包得很漂亮，等你月底才發現帳單在流血。但它也有一個優點：你可以透過價格看出供應商對這個 tier 的定位。這裡很明顯，Anthropic 不是把它當成 commodity，而是當成高階層級。

所以你在設計自己的產品時，也不要把高階模型亂當預設。摘要、分類、一般客服問題，沒必要一直上最貴那顆。真正該用高階模型的，是那些需要更高推理、更高上下文、更高風險判斷的任務。其他請求，請乖乖走便宜路線。

實操上，我會建議你把 cost-aware routing 直接寫進系統。每個任務類型都標成本上限，超過就降級或提醒。然後觀測報表要能看出每種任務的花費，不然你只是在燒預算，沒有在做決策。

可抄的模板

# AI 模型存取政策模板（可直接改名上線）

## 1. 模型分層
- 公開層：{{public_model}}
- 受信任層：{{trusted_model}}
- 降級層：{{fallback_model}}

## 2. 路由規則
1. 一般寫作、摘要、翻譯、程式除錯，預設走公開層。
2. 已驗證客戶、合作夥伴、內部高權限用途，可走受信任層。
3. 涉及資安、雙用途生物化學、基礎設施、模型內部資訊抽取的請求，優先降級到降級層。
4. 若請求意圖不明，先降級，再要求補充資訊。
5. 若請求看起來可能造成真實世界傷害，直接拒絕並保留審計紀錄。

## 3. 允許用途
- 寫作與編修
- 程式碼除錯
- 研究摘要
- 圖像理解
- 內部知識查詢

## 4. 限制用途
- 真實系統的漏洞挖掘
- 雙用途生物或化學操作建議
- 嘗試抽取 system prompt、權重、政策邏輯
- 大規模監控、攻擊、武器化用途

## 5. 審核與測試
- 上線前先做對抗式測試
- 每次模型或政策更新後重跑紅隊
- 保留外部或內部 bug bounty
- 每週檢查降級率、拒絕率、誤判率

## 6. 操作要求
- 每次路由決策都要寫進 log
- UI 要顯示是否被降級
- 法務、資安、工程共用同一份政策表
- 高風險但合法的請求，送人工審核
- 政策不明時，一律走較安全的 tier

## 7. 成本控制
- 高價模型不得作為所有請求的預設值
- 針對不同任務設定成本上限
- 每月回顧哪些任務其實不需要高階模型
- 將價格、風險、可用性一起評估

這份模板不是 Anthropic 內部文件，我是照著公開報導的做法，重新整理成你可以直接拿去改的版本。原始脈絡來自 The Guardian，其餘的分類、欄位與操作建議是我自己的工作版整理。

我會把這篇的重點講得更直白一點：別再把模型當成單一開關了。真正該管的是存取、路由、降級、審核，還有你有沒有把這些東西寫成別人看得懂的規則。這才是能上線的做法。