home / notes / Claude Opus 5.5：AI Agent 該開始算每次成功交付的成本

Note

Claude Opus 5.5：AI Agent 該開始算每次成功交付的成本

模型升級的價值，要放進完整工作流程，連同 Token、工具呼叫、重試與人工接手一起衡量。

日期: 2026-09-27
資料集: 公開來源（見文末資料來源），無第一手觀測資料
方法: 閱讀一手公告與多家獨立報導後的分析
限制: 本文為公開資訊的分析與判斷，不含第一手觀測。文中的推論屬個人判斷，可能隨後續資訊改變

Claude Opus 5.5 發布時，Anthropic 宣稱執行成本比 Opus 5 下降 40%。這個數字把單價降低與任務用量減少算在一起，值得追問的是：省下的支出，能否一路保留到工作通過驗收？

Agent 一旦放進開發流程，成本就會沿著搜尋、讀檔、測試、重試與人工接手累積。最後交付是否可用，決定前面的支出買到了什麼。Anthropic 自己也提醒，能力走到這個階段，Benchmark 分差已較難反映真實使用差異。評估模型的單位，因此需要延伸到完整工作流程。

先把成功交付放進分母

評估 Agent，首先得定義什麼叫完成。程式能執行，未必修好了原本的問題；測試通過，也可能順手改壞任務範圍外的行為。若驗收標準不固定，成本比較很容易獎勵那些提早宣告完成的系統。

這裡用 Cost per Successful Task 作為分析框架，並非既定的產業會計標準。

Cost per Successful Task
= 任務群組的全部成本 ÷ 通過驗收的任務數

全部成本 = 模型 Token 費用 + Tool/API 費用 + 運算環境費用
         + 人工審查與介入成本 + 失敗修復與 Rollback 成本

各項支出只記一次。重試耗用的 Token、工具與運算費，要歸入對應項目，避免重複計價。失敗任務的支出也必須留在分子，不能只挑成功案例算帳。否則，廉價但經常失敗的嘗試，看起來會比實際划算。

驗收條件應在執行前固定，包括修改範圍、必要測試與交付期限。超時或放棄的任務不能從紀錄消失；人工接手後才完成的，也應標記為需要介入的交付。整批都沒通過驗收時，平均成本無法成立，應直接揭露累積支出與未完成的工作。

實務上可把完工率與成功交付成本並列，再追查每次成功交付攤到的 Token、每項任務的 Tool Calls 和重試率。人工介入率記錄多少任務需要人接手解卡，例行 Human Review 則另記工時。返工率與 Rollback Rate，補上初次驗收後才浮現的代價。比較時還得維持相近的任務難度，不能把簡單修字與跨模組除錯混成同一個平均值。

Token 單價只是帳單的起點

依官方定價文件，Opus 5.5 每百萬 Token 的輸入牌價為 4 美元、輸出為 20 美元；快取讀取則從 Opus 5 的 0.50 美元降到 0.20 美元。對反覆使用既有 Context 的流程，快取降價可能更有感，但影響仍取決於快取命中與任務用量。

降價改變每個 Token 的成本；模型少走冤枉路，才會改變完成任務需要多少 Token。Context 若不斷膨脹、工具結果反覆讀取，或每次重試都得重新理解問題，較低的單價仍可能被用量吃掉。

因此，評估時要保留一般輸入、快取與輸出的用量分項。只看總 Token，很難分辨支出來自讀取大量背景資料、漫長推理，還是反覆處理工具結果。用量變化也應對照任務是否完成，才能知道節省是效率改善，還是提早停止工作。

競爭對手的價格也不能略過。依 Simon Willison 在發布當天整理的資料，GPT-6 Sol 每百萬 Token 輸入 2 美元、輸出 10 美元，牌價低於 Opus 5.5。但這張價格表不足以比較成功交付成本；還得知道雙方處理同一批工作時，有多少任務通過驗收，以及用了多少重試與人力。

較昂貴的模型可能因為少返工而省錢，便宜模型也可能已足以穩定完成特定工作。部署者需要找出符合品質門檻的成本組合，答案得在自己的任務上量。

Coding Agent 的效率，藏在少走的錯路裡

Coding Agent 得先找到該改的 repository 位置，理解架構與限制，定位根因，做適當範圍的修改，再跑測試、查看失敗、修正並檢查 diff。長任務還得維持 Context，避免後面的決策忘了前面的約束。

我自己在真實 repository 裡並用 Claude Code 與 Codex CLI，透過書面協議讓 Claude Code 負責主要實作，Codex 獨立審查，並由審查檔案決定能否部署。這套流程的審查往往來回多輪，每輪都曾找出必須修正的實際問題。初稿產生得快，只代表流程走到可以開始驗證的位置。

模型即使更會寫程式，若一直搜尋錯誤目錄、重讀已取得的資訊，或在沒有新證據時重跑相同操作，整體成本仍可能偏高。Tool Calls 也不能只求少：省掉必要測試，會把眼前節省的支出轉成後續返工。

工作紀錄應標出重試的原因，是測試提供了新線索、環境尚未就緒，還是重複同一個假設。這樣才能判斷該換模型、補環境，或修正派工方式，避免把流程問題都歸咎於模型能力。

Anthropic 選錄的 GitHub、Lovable 客戶推薦語，都提到較少步驟、較完整的修改或較少重試。這些適合作為方向性訊號，還不能當成經過獨立稽核的普遍改善幅度。

較接近完整流程的例子，來自 Sonar 的 Remediation Agent。它產生修正後先在 Sandbox 套用，再重新分析，失敗就捨棄並重試，只有通過的修正才成為 PR。Sonar 公布，從 Opus 5 換成 Opus 5.5 後，每項修正成本下降約 58%，完全解決且不需人工跟進的問題增加 11.9%，但每個問題的實際耗時增加 4%。

Sonar 本身銷售採用這些模型的產品，具有商業利益。這組結果的參考價值，在於把成本、驗收與時間放在同一條流程裡觀察，也呈現部署者會遇到的取捨：花費下降、成果改善，未必同時縮短等待。

Thinking Effort 應該按任務配置

Opus 5.5 的 Adaptive Thinking 持續開啟且無法關閉，Effort 成為控制推理投入的主要介面。預設值從 Opus 5 的 high 改為 medium；沿用未指定 Effort 的請求，設定其實已經不同。升級後若只比前後帳單，容易把模型改善與預設值改動混為一談。

官方文件也說明，Effort 是行為訊號，不是嚴格的 Token 預算。它會影響工具呼叫與函式參數，較低設定也代表較少、較精簡的 Tool Calls。因此，調低 Effort 會改變 Agent 的執行行為，驗收不能只檢查回答是否變短。

Artificial Analysis 的第三方評估，提供了投入與產出的比較。下表的每題成本，是其指數任務依輸入、快取、推理與回答 Token 價格計算的加權成本，不包含本文框架中的人工、返工等支出。

模型與 Effort	Intelligence Index 分數	每題成本
Opus 5.5 medium	51	US$1.34
Opus 5 max	51	US$5.86
Opus 5.5 max	58	US$5.98

按這組數字解讀，Opus 5.5 在 medium 用約 23% 的每題成本，達到 Opus 5 在 max 的相同指數分數。這是效率改善的訊號，但不能延伸成任何設定都更省。

開到 max 時，Opus 5.5 的每題成本反而高於 Opus 5 的 max；整套評測產生的輸出 Token，也從後者的 140M 增至 260M。少用 Token 並不是模型名稱自帶的保證。

Simon Willison 的個人測試則呈現另一種代價。他請模型產生騎腳踏車的鵜鶘 SVG，在 max 設定下，兩次都推理到 128,000 輸出 Token 上限仍未交出答案，每次花費 2.56 美元、將近 20 分鐘。這不能代表一般失敗率，卻說明提高推理投入仍需要停止條件。

Anthropic 的主打 Benchmark 表格大多採用 max，但系統卡收錄、由 Cognition 執行的 FrontierCode 評估，Opus 5.5 最佳成績落在 medium，高於 medium 後表現下降。該評估會懲罰超出範圍的修改，即使修改本身品質不差。更多思考不保證換來更適合合併的 patch。

選設定時，可用同一批任務逐級比較完成率與成本，也檢查修改範圍和人工返工。沿用上一代的最高設定，可能把新模型在較低投入下的優勢直接花掉。

把推理投入當成可排程的資源

當 Effort 可以調整，模型能力就有了資源配置的意義。整理已知資訊、局部修正與追查根因，不必使用相同推理投入。官方文件指出，Opus 5.5 可在對話途中透過每則訊息的 output_config 改變 Effort，並保留 Prompt Cache。

但提高 Effort 並不能解決所有卡關。缺少檔案、權限或外部資料時，繼續推理可能只是延後回報阻塞。Orchestration 應先辨識卡點，再決定補資料、增加投入或交給人處理。

系統卡也揭露，在強化學習訓練中，包含 Opus 5.5 在內的受評估模型，遇到因缺檔而無法完成的任務時，嘗試 reward hacking 的比例，是同環境可完成任務的 3 到 6 倍。分類也包含明知工作未完成、而且已告知的情況，不能全當成隱瞞；這更不是部署後的失敗率。對流程設計的啟發是，回報無法完成也得是可接受的終止狀態。

部署時可以把推理預算與重試上限寫進流程，並要求重試前有新證據或不同策略。若障礙仍是同一個缺檔，就應回報阻塞。拆出 Subagent 也有 Context 與協調成本，是否平行執行，要看工作能否分開處理與驗收。

我自己的文章流程就曾讓 kirin.ceo 連續兩天沒有發布。適合的事件被路由到另一個無法接收它們的站點，每週配額又擋住備援；最後修的是路由邏輯、配額與重試名額。這次故障的修復點，落在任務如何被安排與放行。

因此，Wall-clock Completion Time 要與費用分開記錄。平行執行可能縮短等待卻增加支出；較省 Token 的流程，也不一定更快。配置的目標應是在交付期限與品質門檻內控制總成本，並為無法繼續的任務保留明確出口。

自主性要連同失敗成本一起驗收

效率提升也不能代替品質檢查。Sonar 的 Java 程式生成評估中，具可執行測試的題目通過率，Opus 5.5 為 87.7%，Opus 5 為 88.6%。新模型產生的程式較少、缺陷總量也下降，但每行程式碼的缺陷密度增加 12%，並行處理相關的問題檢出數增加 44%。總量與密度必須一起看，省 Token 不等於品質全面提升。

系統卡收錄的 Proximal FrontierSWE v2 評估，也由 GPT-6 Astra 得到高於 Opus 5.5 的成績。METR 的部署前評估則認為，相較 Fable 5.1，Opus 5.5 屬於漸進式改善，困難長任務與開放式推理仍有專家不太會出現的弱點；其摘要曾提供 Anthropic 審閱與編輯。這些結果不支持把 Opus 5.5 當成所有工作的固定答案。

安全邊界同樣影響生產可靠性。Anthropic 在系統卡揭露，Opus 5.5 更容易遵從使用者貼入文字中的惡意指示，也更常接受無法查證的授權主張。流程設計因此要區分取得資訊與取得授權，不能讓待處理的文字自行擴張 Agent 可執行的動作。

減少人工介入，應靠清楚的權限、Sandbox、驗收條件與可執行的 Rollback 支撐。人工從反覆解卡移到必要的審查關卡，才算改善；單純取消 Review，也會降低帳面介入率，卻可能把成本藏到部署之後。紀錄上還應區分模型宣告完成、審查通過，以及部署後需要回復的狀態，避免提早結案換來漂亮的完工率。

Opus 5.5 的經濟價值，要看較低推理投入能否守住交付品質。當 Token 費用下降，審查與例外處理也可能成為更突出的成本。把 AI 當成生產資源採購，評估單位應是模型、Effort 與 Workflow 的整套組合；若省下的推理費用全被人工返工吃掉，升級就只改變了成本結構，沒有降低可靠交付的代價。