Anthropic 釋出 Claude Sonnet 5.5，從釋出頁看仍是一輪常規升級：API 單價未變、生成速度更快，Terminal-Bench、CursorBench 等 Agent 基準成績明顯上漲。但把幾組執行資料放在一起，變化並不只發生在模型輸出層。Lovable 的測試中，Tool Call 數量減少約三分之一、Shell Run 接近減半；Base44 的應用構建任務裡，平均迭代次數從 7.7 次降到 3.6 次。Anthropic 還提到，新模型更頻繁地把多個工具呼叫放在同一批執行。

這意味著 Agent 成本不能只看 Token。一次任務真正消耗資源的地方，還包括工具等待、狀態回填、重新規劃、上下文增長和失敗恢復；只要 model—tool 迴圈足夠長，這些成本就會持續疊加。在“模型變聰明了”的背後，工程上對應的是模型具備了靜態依賴分析與執行圖壓縮的能力，使原本笨重的 Agent Runtime 架構得以瘦身。

Agent 與聊天模型的工作方式不同。聊天模型一次請求結束、計算基本結束；Agent 則需要持續維護一個會變化的工作狀態，包括使用者目標、已驗證假設、工具返回、程式碼改動、環境狀態和未解決問題。每完成一次 Tool Call，runtime 都要把新結果合併進當前狀態，再讓模型重新判斷原計劃是否仍成立。這裡有一層很實際的成本，可稱為 state rehydration：模型下一輪不只需要讀一段剛返回的測試日誌，還要知道為什麼執行這項測試、此前動過哪些檔案、哪些假設已被排除。隨著任務推進，工作狀態不斷膨脹，每次重新進入 reasoning 都要恢復與當前決策相關的那部分狀態。

失敗路徑會進一步放大問題。假設程式碼 Agent 一開始判斷錯誤，把問題歸到認證中介軟體，於是搜尋相關 symbol、讀取檔案、修改邏輯、執行測試，最後發現真正原因來自 session serialization。前面的程式碼、修改記錄、測試日誌和中間判斷已經進入上下文，如果 runtime 只是不斷追加歷史內容，後面的正確路徑仍要在這批殘留狀態裡繼續工作。所以長上下文本身並不能解決 Agent 成本問題：上下文視窗變大解決的是歷史能不能儲存，runtime 更難處理的是哪些內容還應留在當前 working set。穩定的長期 Agent 需要把當前節點直接依賴的資訊留在活動區，把已形成穩定結論的內容壓縮成結構化狀態，而原始日誌、重複搜尋結果和已失去依賴關係的 observation 應儘快退出工作集。這也解釋了為什麼一次無效 Tool Call 的代價通常高於它本身——錯誤搜尋不僅浪費一次工具執行，還會製造額外狀態。

傳統 ReAct 的執行方式是一條嚴格序列鏈：模型決定動作、工具執行、結果返回、模型再判斷。這種方式預設每個工具之間都存在依賴，即使很多操作本可同時進行。程式碼排障就是典型場景：搜尋異常字串、讀取 package 配置、定位測試檔案、檢查幾個 symbol 的引用關係，很多時候只是讀取當前程式碼狀態，彼此沒有必須等待的順序。Batch Tool Call 要求模型在進入工具層之前先做一次區域性依賴判斷，把可共同執行的動作放到同一批裡。真正被壓縮的是 synchronization barrier：原來模型每拿到一個結果都要停下來恢復狀態並重新規劃，現在先確定這一階段需要哪些資訊，中間多個 barrier 可直接消失，工具並行執行後結果再一次性交回模型。

這要求模型具備 partial-order planning，判斷哪些動作存在先後關係、哪些只讀狀態、哪些會改變狀態。只讀操作容易並行，寫操作則必須考慮 read-after-write 和 write-after-write 關係，比如測試必須看到修改後的程式碼，兩個 subagent 同時編輯同一檔案還會產生寫衝突。因此執行圖能不能壓縮，關鍵不是一次發出多少 Tool Call，而是同步點放在哪裡。批次執行還有反向問題：fan-out 太大以後會產生很重的 fan-in，一次併發十幾個工具雖減少等待，但模型下一輪可能收到大量程式碼、日誌和搜尋結果，若原樣進入上下文，前面省下的同步成本又會以 observation 膨脹的形式回來。runtime 還需要在工具返回後做 result reduction，合併重複內容、把長日誌縮成與當前決策相關的片段、過濾低價值結果。Sonnet 5.5 同時出現更頻繁的 batch 和更少的 Tool Call 總量，說明變化不只是併發更多，而是模型在一些任務裡更早形成了一組相對完整的資訊需求。

當模型開始參與決定執行圖怎麼展開，effort 的作用也隨之變化。在單輪任務裡，提高 effort 主要增加模型內部的 test-time compute；進入 Agent 場景後，內部 reasoning 會直接改變外部動作。如果模型在修改程式碼前多做一輪依賴檢查，發現兩個 change-set 存在介面順序關係，後面可能直接避免一次衝突、一次測試失敗和一次回滾，這種額外 reasoning 雖增加內部計算，卻減少了外部執行。反過來，如果證據已足夠而模型仍繼續擴充套件分析，就可能啟動更多 code review、subagent 和驗證，把額外計算變成更多執行節點。Anthropic 在 FrontierCode 上出現過 Max effort 低於 Xhigh 的情況，一種解釋是高 effort 讓模型更頻繁呼叫 code-review skill 並拆給多個 subagent，部分分支隨後超時或產生超出任務邊界的修改。這不是某個 benchmark 的高低，而是 effort 改變了 branch factor。

更合理的 effort 策略應落到節點級，而非整條任務固定一個檔位。讀取倉庫、搜尋 symbol 這類低風險步驟可用較輕 reasoning 快速生成查詢集合；準備跨檔案寫入、修改 schema 或執行高副作用動作之前，可增加 reasoning，把計算放在依賴檢查和 change-set planning 上；程式碼寫入後儘快進入測試，因為真實環境反饋比繼續內部推演更有效，驗證失敗再根據新 observation 提高 reasoning。這裡還需要 checkpoint：如果每次失敗都從任務開頭重新恢復狀態，retry 會把執行鏈重新拉長；若 runtime 在關鍵寫操作前儲存穩定狀態，失敗後只回退最近一次變更，影響就能侷限在較小範圍。程式碼 Agent 可藉助獨立 worktree、臨時分支或沙箱隔離候選修改，讓 subagent 在獨立環境驗證，通過後再合併進主工作區。

到這一層，Agent runtime 已不再只是一個 model—tool 迴圈，而更像一個動態 controller：維護工作狀態、決定同步點、控制 fan-out、為高風險節點分配更多 reasoning、在寫操作前儲存 checkpoint，再根據驗證結果決定繼續、回滾還是提交。Sonnet 5.5 這次變化裡值得保留的結論或許是：模型能力開始直接影響 Agent runtime 的結構。如果模型能在動作之前更好地判斷依賴，runtime 就可減少同步點；如果 observation 能被及時壓縮，working set 就不會隨任務長度持續膨脹；如果 effort 被放在錯誤代價更高的節點上，額外的 test-time compute 就有機會換掉後面的失敗執行，而不是繼續擴大搜索空間。

因此後續衡量 Agent，輸入輸出 Token 只是底層計量。更有用的指標會是一次任務經歷多少 model—tool barrier、batch 中多少結果真正被後續決策使用、失敗以後需要回退多遠、active working set 在執行過程中增長到什麼程度，以及 subagent 產生了多少最終沒有提交的分支。這些資料能直接判斷一套 Agent 系統的問題出在模型、執行器、狀態管理還是 controller 本身。Sonnet 5.5 帶來的變化，最終仍落在同一個工程問題上：如何把更多計算放到真正能消除後續執行成本的位置，而不是讓 Agent 用更多 reasoning 去製造更大的執行圖。