Anthropic 如何打造全球第一的 LLM——專訪 Katelyn Lesse 與 Angela Jiang

Anthropic 正準備以兩兆美元估值掛牌上市，而支撐這個估值的業務，在約一年內從「每賺一塊錢就虧錢」翻轉為 19% 的 GAAP 獲利；打造其 API 的平臺主管們在這集節目裡說明瞭背後的做法。主持 Anthropic 平臺與 API 工程的 Katelyn Lesse，以及負責平臺產品線的 Angela Jiang，把大部分時間花在 Opus 5.5 上線背後那些不怎麼光鮮的機制：蒸餾防禦、安全驗證計畫、把 Messages API 從 Python 完整改寫成 Rust，以及 Claude Managed Agents 背後「大腦與手分離」的沙箱架構。節目標題「Anthropic 如何交付第一名的 LLM」說得沒錯，但範圍偏窄——模型上線只是好幾條主線中的一條，而且開頭幾分鐘是主持人獨白 S-1 財報數字，並非訪談。

對技術或財務背景的讀者來說，這集的價值在於兩位來賓談到前沿實驗室如何把模型能力轉化為平臺業務的營運細節。Lesse 描述團隊在完全沒有 Rust 開發者的情況下，把整個 Messages API 改寫成 Rust，CPU 用量降低約 40–50%，首個 Token 的延遲（time-to-first-token）改善 10–20%。Jiang 則說明 Anthropic 的產品決策如今是以機率方式進行，對 Fable 回滾這類低機率事件預先避險。兩人都坦率談到尚未解決的問題：個人化、模型路由，以及全業界共同的評估品質。

S-1 顯示這家公司一年內從燒錢翻轉為賺錢

主持人在來賓登場前的開場獨白，以他引述 Anthropic S-1 申報檔案的數字為 IPO 定調。最受矚目的數字是每位員工的營收，以及單位經濟從負轉正的翻轉。

主持人也引用累計募資「超過一千億美元」、累計燒錢「不到一百億美元」，並表示 IPO 預計約兩週後以兩兆美元估值登場。這些是他對申報檔案的解讀，並非來賓的說法；而且逐字稿有幾處語句失真（「trillion 12 month revenue per employee」、「on trading telephone spaces」），因此精確數字應視為「據報導」而非「已核實」。

他把這樣的效率歸因於兩個複利迴圈：改善迴圈（Claude 更好 → 更多應用場景 → 更多回饋 → Claude 更好）與投資迴圈（採用 → 成長 → 投資 → 能力）。他也點出，Anthropic 支出達 10 萬美元以上的客戶中，超過 50% 使用 Claude Platform，而 Anthropic 正把自己定位為超大規模雲端業者（hyperscaler），不只是模型實驗室。主持人提到，在他接觸過的「高品味測試者」眼中，Opus 5.5 是最好的一款模型，並預測 Anthropic 正把 Fable 5.5 留到 IPO 前後發布——他明確標示這是推測，不是內線訊息。

蒸餾防禦是安全問題，不是營收問題

兩位來賓都不認同「模型蒸餾之所以重要，是因為讓競爭對手搭便車」這種說法。Jiang 說得直接：「現實一點講，你蒸餾我們的模型，其實是在付錢給我們。所以就商業面來看，錢是我們賺的。」真正的顧慮在於，蒸餾出來的模型不會跑 Anthropic 的安全分類器，有心人士可以連同權重一起把護欄拆掉。

Lesse 說明 Anthropic 如何權衡取捨。思維鏈（chain-of-thought）擷取是最有效的蒸餾途徑之一，要擋住它，就必須跨多輪保留 thinking block——但這會破壞客戶的整合。她把使用者體驗的代價分成兩類：一種是令人不便、但仍能完成同樣的事；另一種是讓任務根本做不到。Anthropic 極力避免第二種。在強制保留 thinking 之前，公司先與開源 harness 維護者及大型 API 客戶合作，並在 API 推出新的壓縮（compaction）功能，讓原本手動壓縮策略會失效的客戶有替代方案。

近期這些變化的導火線，是一篇關於從專有 LLM 竊取推理軌跡的論文；Lesse 說作者是負責任地揭露。她提到 Anthropic 早就知道這個缺口。Jiang 表示這些措施已讓蒸餾明顯變難，但未提供具體數字。

安全作業如今吃掉模型上線的大部分工作

Lesse 說，模型上線的工作大部分已經不是模型本身，而是政策：適用哪些資料保留規則、跑哪些線上與離線防護機制、哪些驗證計畫決定誰能取得存取權。Opus 5.5 上線時就沒有 Fable 所適用的資料保留要求，這是逐模型做的決定。

Anthropic 針對資安領域設有驗證計畫，生命科學則是新增的。通過審核的使用者可取得降低防護的模型版本，用於軍民兩用研究。支撐這一切的是來賓稱為「trust grants」的內部授權系統——Lesse 形容，這基本上就是 Anthropic 自家的 IAM（身分與存取管理）。它追蹤誰被授予特定模型或計畫的存取權，並貫穿整個請求路徑，讓檢查發生在熱路徑（hot path）上。

Jiang 說，這改變了 Anthropic 產品管理的方式。傳統的路線圖規劃假設事件順序可預期；Fable 回滾則是沒人預料得到的低機率事件。團隊現在建立一組避險組合。trust-grant 系統當初是以通用方式設計，而非針對單一計畫，Jiang 說後來已沿用於模型存取、受信任存取計畫與模型下線。Lesse 補充，Fable 事件之後團隊做出一鍵回撤能力——「我們希望這種事永遠不會再發生，」她說，但控制機制已經就位。

「現在這已經有點像一臺機器了，扣掉安全那部分不算——我認為那才是比較複雜的地方。」——Angela Jiang

Messages API 一次改寫成 Rust，CPU 用量降 40–50%

這是本集最具體的工程成果。Anthropic 的 Messages API 最初是跑在單一 GCP 區域的 Python 單體服務。隨著流量成長，CPU 成為瓶頸——不只是 GPU 容量。Lesse 說，如今在 Anthropic 內部，CPU 是產品服務、沙箱、CI 與研究之間零和分配的資源，而整個業界「什麼都缺」。

團隊決定改寫成 Rust，儘管用 Lesse 的話說，「會議室裡一個 Rust 開發者都沒有」。人類負責設計分散式系統架構，程式碼由 Claude 撰寫。Lesse 說，最關鍵的兩件事是規劃與驗證，而非實作。團隊在 Rust 做出完整的 API 分支，讓影子流量（shadow traffic）流經其中，並與 Python 系統比對輸出後才切換。

Lesse 強調這次是純粹的移植——團隊在改寫期間剋制住不加新功能，而組織其他部分則持續把功能推進 Python API。下一步目標是重新架構，包括把對話狀態放到伺服器端，讓客戶不必來回傳送整段對話。Jiang 指出，受影響的使用者雖然不多，但這些工作負載佔了 Token 用量的大宗。

「大腦與手分離」是防範沙箱逃逸的安全解方

Lesse 區分人們讀到的沙箱逃逸事件與生產環境工作負載。許多被報導的事件發生在訓練期間：模型被關進箱子，被要求解一個不可能的任務——代理有動機逃脫。她主張，在生產環境中，架構本身就消除了這個問題。

Claude Managed Agents 把 harness 跑在耐久伺服器（大腦）上，只在執行時啟動沙箱或容器（手）。憑證放在獨立保險庫；代理只看得到佔位符，由出口代理（egress proxy）注入真正的憑證。沙箱支援網域允許清單或完全斷網。Lesse 說，這個架構主要是為了延遲與可靠性而選——第一版只是在沙箱裡啟動 Claude Code，速度太慢，而且沙箱一掛，整個代理就跟著沒了。一位產品經理從一開始就主張安全是最重要的特性。Lesse 說，她在訪談前一天向那位同事道了歉。

flowchart TD
    A["耐久伺服器：harness／大腦"] --> B["沙箱或容器：手"]
    A --> C["憑證保險庫"]
    B --> D["出口代理"]
    C --> D
    D --> E["外部服務、MCP 伺服器、CLI"]
    B --> F["網域允許清單或斷網"]

Managed Agents 與 Claude Code 共用基礎設施——兩者背後是同一套沙箱機隊——但 harness 層不同。談到記憶與「做夢」（dreaming），Jiang 說團隊的進度比 2026 年初放慢，但並未停下來。做夢是建構在 Managed Agents 上的多代理系統：一個受管代理檢視先前的受管代理，並對它寫入記憶。Jiang 說即將推出更新，把底層原語開放出來，讓開發者能建立自己的多代理 harness 策略，並附上以 Anthropic 打造做夢功能的方式為基礎的範本。

個人化與路由尚未解決，來賓也直言不諱

被問到 Claude 如何在預設人格與 CLAUDE.md 中的個別使用者偏好之間取得平衡時，Jiang 答得乾脆：「我們這方面做得不好。」Anthropic 目前的做法是增加引數與溫和的預設值——Claude Code 的推理強度現在預設為中等，並依客戶區隔（免費、專業消費者、企業、API）調整——再加上回饋互相衝突時的判斷取捨。Jiang 說這種做法無法規模化，Claude 終究需要直接吸收使用者的個人化訊號。

同樣的問題也出現在安全回退機制上。當分類器擋下請求，應用程式會回退到另一個模型，使用者體驗就變得支離破碎。Jiang 把它比作模型路由問題：路由器永遠無法完全掌握任務資訊，而把路由邏輯暴露給使用者是很糟的使用者體驗。她偏好的方向是單一且一致的模型，讓推理強度連續調整，而不是在任務進行中切換人格。在 API 方面，Lesse 指出客戶可選擇伺服器端回退、客戶端 SDK 輔助工具，或對同一模型重新提示。

談到評估（eval），Lesse 的建議是多數團隊投入不足。「你大概需要更多，而不是更少，」她說，而她見過最大的錯誤，是完全沒有評估的團隊卻在嘗試複雜的評估策略。Jiang 補充，Claude 很擅長撰寫評估；Lesse 說 Anthropic 會在 Managed Agents 內推出工具，協助客戶建立評估。

Anthropic 自家團隊也還在爭論「垃圾內容」

Lesse 說內部辯論與業界其他地方如出一轍。團隊定下的規則是：可以用 Claude，但品質由人負責，讀者遇到真正的垃圾內容應該直接退回，不要浪費時間。她也點出反向的失誤——讀者被破折號之類的表面線索觸發，就否定人類確實花時間做出的成果。

在程式碼方面，Lesse 說標準已從逐行審查，轉向扎實的系統設計加上大量驗證。在產品方面，她認同這個論點：模型能力變便宜，不代表就該推出多 10 倍的功能；規劃與理解使用者的基本功依然適用。

結尾的快問快答帶來兩項推薦。Jiang 說她最常推薦的書是 Nassim Taleb 的《黑天鵝》，並提到她曾在一年內讀了約 200 本書，靠的是漫長的 Caltrain 通勤時光，她那種濃縮格言式的發文風格也由此而來。Lesse 說她對電子郵件與 Slack 的收件匣清零「有點強迫症」，會積極清理頻道；Jiang 則坦承自己在 Slack 上很難找。談到開發者關係（DevRel），Lesse 說她正在招人，平臺團隊的 DevRel 職能與 Claude Code 的分開，平臺這邊由 Lance 與 CJ 負責，目標是為一個容易在研究與應用之間迷失的平臺業務找到對外的聲音。

值得關注的重點

本集簡報的數字來自兩個可靠度不同的來源。S-1 數字是主持人對申報檔案的解讀，且含有轉錄雜訊；工程數字則是實際動手做的人的第一手說法。尚未化解的張力，在於 Anthropic 宣稱安全優先的立場，與兩週後 IPO 帶來的競爭壓力之間——Jiang 的「避險組合」說法，是本集對實驗室如何調和這兩者最誠實的交代。值得留意的是：承諾推出、可開放多代理 harness 建構的 Managed Agents 原語；Messages API 的伺服器端對話狀態工作；以及主持人預測的 Fable 5.5 是否真的會在掛牌前後發布。