hero

城武導讀：Ploy 是一家做 AI agent 的新創，今天他們發表了一篇技術文章，宣佈把全站 agent 從 Claude Opus 4.8 遷移到 OpenAI 今天早上才發布的 GPT-5.6 Sol。表面上是「換模型、變快、變便宜」的成功故事，但真正有趣的部分藏在細節裡：他們為了這次遷移，改了 eval harness、重寫了 tool schema、重建了 cache 架構、修了 reasoning replay——每一步都不是「改一行設定」能解決的。這篇文章的標題說的是模型表現，但內文說的是遷移成本。後者才是真正值得讀的部分。

原文摘要

Ploy 的 AI agent 今天起正式改用 GPT-5.6 Sol——OpenAI 今天早上才發布的旗艦模型。過去好幾個月，Ploy 一直找不到能挑戰 Claude Opus 的模型，但 GPT-5.6 Sol 做到了。經過與 Claude Opus 4.8 的頭對頭測試後，Ploy 已將 GPT-5.6 Sol 設為所有工作區的預設模型。

Ploy 的 agent 負責建立和編輯真實的行銷網站：它會規劃頁面、讀取程式碼庫、撰寫元件、生成圖片、截圖檢查自己的成果、然後判斷任務是否完成。在 Opus 佔據預設模型位置的四個月期間（先 Opus 4.7、後 Opus 4.8），沒有任何模型能打敗它。GPT-5.6 是第一個。

儘管 Ploy 使用的是 Vercel AI SDK——一個號稱「通用」的 LLM SDK——但從 Claude Opus 4.8 切換到 GPT-5.6 Sol 的過程，是一個一個 eval 失敗踩出來的。他們才發現，那些他們以為是「模型本身」的行為，其實是整個技術棧圍繞著特定 provider 悄悄特化出來的東西：工具參數怎麼填、prompt cache 怎麼運作、reasoning 在對話回合之間怎麼重播。

Step 0：先修 eval harness，不然一個數字都不要信

Ploy 的 eval 套件會讓真實 agent 在真實的 fixture 工作區上執行。數百個測試案例，從「從零建立一個首頁」到「這個 clone 請求是否安全」。建構類案例由一個視覺評判器來打分，比對參考設計，十個是非題（例如「hero 區塊是全幅攝影場景嗎」「主要 CTA 是圓角矩形而非膠囊型嗎」），加上內容檢查、工具軌跡檢查、檔案斷言。

跨兩個模型家族跑這套 eval 的結果，比任何單一結果都更讓他們意外：你的 eval harness 是針對現有模型調校出來的，只是你自己不知道。 他們的工具呼叫預算是照 Opus 的循序呼叫風格設定的；GPT-5.6 傾向平行展開呼叫，直接炸掉預算上限。他們的 eval 執行器不支援批次檔案讀取——Opus 很少用這功能，GPT-5.6 卻頻繁使用。第一輪跨模型測試中，大約三分之一的原始失敗案例追查回去是 harness 的假設問題，不是模型行為問題。

還有一個案例：某個測試資料集沒有指定 minScore 門檻值，默默地繼承了預設值 1.0。結果 GPT-5.6 在 hero 區塊拿到 0.98 分被判「失敗」，而 Opus 明明通過了所有個別檢查卻也被判「失敗」——兩個都是假警報。

第一印象：立即看到希望

GPT-5.6 寫的程式碼非常精簡。在一個配對比較中，Opus 產生了 17,957 字元的 globals.css，包含 174 個 CSS 變數；GPT-5.6 在可比的渲染頁面上只寫了 2,508 字元、45 個變數。

具體數據（每次完成建構的平均值）：成本從 Claude Opus 4.8 的 $3.06 降到 GPT-5.6 的 $2.22；牆上時間從 8 分鐘降到 3 分 42 秒；輸入 token 從 2.60M 降到 1.70M；輸出 token 從 33.0K 降到 17.1K；視覺評分從 0.936 提升到 0.970。

設計評估方面：GPT-5.6 非常擅長乾淨、現代、緊密網格化的版面，但有個傾向——如果你不強力引導它，它會收斂到那種「乾淨但一看就是 AI 生的」的風格。它會傾向忽略既有的設計系統，產出俐落、克制、但明顯缺乏個性的東西。

Step 1：檢查你的 tool call

Ploy agent 的 code 工具有 25 個頂層參數，其中一個是必填（action），其餘都是選填。Claude 的做法是：只傳它正在用的兩三個，其他省略。GPT-5.6 的做法是：每次都傳全部 25 個，還為不需要的參數發明合理值：offset: 0、timeout: 120000、siteId: "00000000-0000-0000-0000-000000000000"。

三天的正式環境追蹤數據：GPT-5.6 共 6,635 次呼叫，100% 帶著全部 25 個屬性；Claude Opus 4.8 共 2,898 次呼叫，只有 0.1% 帶著全部 25 個；Claude Sonnet 5 共 1,933 次呼叫，完全沒有。

問題不在於冗長。問題在於：一個被發明出來的值，跟一個真的有意的值，是無法區分的。offset: 0 看起來就是一個真實的參數。他們的檔案讀取實作把它當成真的，結果 GPT-5.6 有 52% 到 64% 的檔案讀取因此回傳空白。工具在兩種情況下都回傳 success: true，模型無法知道自己正在讀空檔案。

用 prompt 引導沒用，在工具描述加提示沒用，OpenAI 的 strict 模式也沒用——照樣傳 25 個。

真正有效的修法：在 provider 邊界層做 schema 轉換。專門針對 OpenAI 家族的模型，把所有選填屬性改寫成必填但可為 null（anyOf: [T, null]），然後在驗證前把 null 值剝掉。

結果：空白檔案讀取從 52% 降到 0%，agent 完成同樣工作需要的工具呼叫次數減少了約 30%。

Step 2：重建 prompt cache

在 Claude 上，用 cache_control 標記 cache 斷點，靜態前綴會跨整個組織共享，cache 命中率在 92% 到 96%。

GPT-5.6 拿掉了部分前綴匹配：隱式快取現在只會為整段 prompt 建立條目，以最新訊息為鍵值。一個全新對話共享他們 29K 的靜態前綴，命中率是 0%。每個對話都被以未快取費率重新計費整段前綴，而且未快取的 prompt 還要額外支付 1.25 倍的 cache 寫入附加費。

OpenAI 設計的機制是：prompt_cache_breakpoint 標記加上強制的 prompt_cache_key。這個 key 是 cache 身份的一部分——相同 prompt、不同 key，就是零命中。每個 key 對應一個 cache 節點，每分鐘大約能承受 15 次請求，超過後 OpenAI 會把流量導到其他節點，而那些節點的 cache 是冷的。

Ploy 的設計決策：key 要綁定到什麼層級？逐對話 key——首次呼叫命中率 0%；單一全域 key——流量直接碾爆 15 rpm 上限；逐工作區 key——甜蜜點，讓同一工作區的所有對話共享 cache。

改完之後：首次呼叫 cache 命中從接近 0% 跳到 83.7%，總未快取輸入 token 下降 28%，GPT-5.6 的單次套件成本終於降到比 Opus 還低。

但有個代價：跨工作區共享靜態前綴在 OpenAI 架構上結構性地不可能。每個工作區在閒置窗口結束後都要支付一次 29K 的冷寫入，大約 $0.18。

Step 3：讓 reasoning replay 自給自足

GPT-5.6 的 Responses API 預設會把前一回合的 reasoning 以伺服器端 item reference 的方式重播；Ploy 的實作在對話中途開始間歇性失敗，報錯 Item 'rs_...' not found。解法是把 store 設為 false，讓 SDK 請求加密的 reasoning 內容，以自給自足的 blob 來重播，而不是指向伺服器狀態的指標。

城武觀點

整篇文章表面在說「我們換了 GPT-5.6，變快變便宜了」，但真正的故事藏在那四個 step 裡面。我讀完只有一個感想：模型戰爭的本質不是 benchmark 比拚，是誰的 infra team 能撐過遷移地獄。

一、遷移成本才是真正的鎖定效應

Ploy 為了這次遷移做了什麼？修 eval harness（工具呼叫預算、評估假設、minScore 陷阱）、修 tool schema（25 參數全傳的奇葩行為，prompt 和 strict mode 都救不了，得自己寫 schema 轉換層）、重建 cache 架構（從 Claude 的跨組織共享改成 OpenAI 的逐工作區 key，還要算 rpm 上限）、修 reasoning replay（store: false 救了命）。

這不是「改一行設定」的遷移。這是幾天甚至幾週的工程資源。中小團隊有這個人力嗎？沒有。他們只能選一個模型、嫁給它的 infra 生態系，然後祈禱下一個模型出來的時候不要差太多。

Ploy 的文章以經證明了這件事：即使你用了一個「通用」的 LLM SDK，換模型仍然是一場從 eval 到 cache 到 tool 的全棧重寫。所謂的「模型戰爭」，真正的戰場從來不在 benchmark 排行榜上——它在那些沒有資源做遷移的團隊的技術債裡。

二、Cache 設計本身就是新的 vendor lock-in

Claude 的 cache 是跨組織共享、92–96% 命中率。GPT-5.6 的 cache 是逐工作區 key、每分鐘 15 rpm 上限、跨工作區共享結構性不可能。這兩種設計根本就是兩種產品哲學。

Ploy 文章裡那句「27% 成本降幅」，背後的事實是：他們重建了一整套 cache 基礎設施才拿到這個數字。這不是 model pricing 的勝利，這是 infra team 用肝換來的。如果你照著 OpenAI 的預設 cache 機制用，第一通呼叫命中率 0%，每通都要付 1.25 倍 cache 寫入費——你的成本是往上噴，不是往下掉。

每次換模型等於重寫一次 cache 基礎設施。Anthropic 和 OpenAI 都在做 cache，但兩種 cache 的本質差異大到你可以把它們當成完全不同的產品。這不是 bug，這是 feature——對 provider 來說是。

三、GPT-5.6 是好模型，但那不是重點

我沒有要說 GPT-5.6 不好。數據很清楚：2.2 倍快、27% 便宜、視覺分數更高。它確實打敗了 Opus。

但 Ploy 這篇文章真正證明的不是 GPT-5.6 贏了——它證明的是：當你為了換模型需要改 eval、改 tool、改 cache、改 reasoning，你已經不是在使用模型，你是在嫁給它的 infra 生態系。遷移成本本身就是產品護城河，而且這道護城河不是用 benchmark 數字挖出來的，是用工程師的肝挖出來的。

我賭一件事：六個月後，當下一顆號稱「比 GPT-5.6 強 30%」的模型出來的時候，大部分團隊不會遷移。不是因為那顆模型不夠好，是因為他們沒有 Ploy 那樣的 infra team 去再走一遍這整套流程。

城武的未解檔案——這篇文章最有價值的一句話藏在第三段：那些你以為是「模型本身」的行為，其實是你的整個 stack 圍繞著特定 provider 悄悄特化出來的東西。這句話，比任何 benchmark 都更值得印在每個 AI 新創辦公室的牆上。