你讓 AI Agent 獲得連夜遷移一個代碼庫。第二天一早，滿懷期待地打開終端，沒想到只看到這樣一條消息：

已完成3個接口的遷移，接下來我將處理剩餘的兩個端點，並進行測試。

然後，就沒有下文了。如果你想讓它完成剩下的工作，你還得再輸入兩個字：繼續。本以為它會一口氣做完，結果它只給你畫了一張「下一步」的圖標，程序就代替它「打卡」下班了。這可不是某一個人的不幸經歷。

Opus 5.5 一發布，跑 Agent 的開發者就發現，模型能力確實強大了，但運行起來卻容易停下來，不催促它就會一直不動。

Anthropic 自己也看到了。發布沒幾天，配套的提示詞指南就出來了，專門為這類問題打補丁。

在開篇的排查清單裏，官方直接點名了這種「半路溜號」的情況：

無人值守的 Agent 報告完進度後，直接在半路停下了。

背後的原因，你可能想不到：Opus太愛彙報了。

幹長活的時候，它會主動向你同步進度。問題是，有些報告發完之後，它就不再繼續動作了，API 發出的信號是「end_turn」，意思是「這一輪我說完了」。

仍有不少沿用舊邏輯的 Agent 程序只認一條死規矩：模型不再調用工具，就算活幹完了。

一份進度匯報，就這樣被當成了交差。

這一點，官方指南說得也很清楚：

純文本的回合結束，應該被視為一份報告，絕不能當作任務完成的憑證。

所以，真正的问题是，AI根本沒有想偷懶，而是你的程序先為它按下了下班卡。

害人的優等生習慣

官方將這種中途停工的情況歸結為四種類型，只要你經常參與 Agent，很有可能就曾經遇到過。

第一種，紙上談兵。

寫了一大長篇總結，結尾宣告下一步要做什么，卻根本沒有使用任何工具，下一步永遠只停留在口頭上。

第二種，過於客氣。

幹著幹著，突然停下來問一句「如果你不介意的話，我接下來繼續處理某某」，然後就當場「掛機」，等著你這個根本不在電腦前的人去回覆它。

第三種，假裝請示。

列出一大串需要你拍板的決策項，但实际上按照它自己的說法，這些決策根本不影響它繼續幹剩下的工作。

第四種，報告強迫症。

模型覺得當前回合的字數夠多了，或者剛好完成了一個小階段，非得停下來向你做一個總結。

有點讽刺的是，在 Opus 5.5 的官方宣傳中，“溝通更主動、總結更清楚”恰恰是它的核心賣點。

誰能想到，這些優等生們的好習慣，一放到舊的無人值守程序裏，反而成了停工的誘因。

官方三招：把驗收權從 AI 手裏拿回來

如何讓它繼續運作，同时又不會陷入無限死循環？

官方提出了三招。

第一招，任務清單。

將大任務拆分成細項，交給待辦工具或文本來管理，讓模型在處理的同時進行勾選。

回合結束時，如果清單上還有未完成的任务，而模型也沒有解釋是什麼原因卡住了，那你的應用就必須自動發送消息，點名讓它繼續完成這些任務。

官方給出的續跑示範：“你的任務清單還有未完成項：遷移剩下兩個端點，並更新它們的測試。繼續做。如果有哪項卡住了，說明卡在什麼地方。”

第二招，鐵面驗收員。

事先定好完成的标准。每次回合結束後，將工作交給一個較小的模型去對照檢查。沒達標？就把沒達標的原因當成下一條訊息再塞給它，讓它重新做。

第三招，硬剎車。

同一個任務如果自動續跑兩三次還卡在原地，必須強制停止並交給人員重新檢查。真的卡死的任務，千萬不要讓它把你的 API 權限額度白白消耗掉。

除此之外，提示詞也必須跟上。

官方給了一段可以直接抄的系統提示詞，說白了就是兩頭堵：

既要有明確表示絕對不想要上述四種停止方式的說法，也要說清楚什麼時候才准停止，比如離開用戶後真的無法繼續推進，或者遇到了被刻意保護的核心資源。

舊代碼為何突然報出 400 錯誤？

如果說幹了一半就停工只是磨洋工，那麼以下這些遷移陷阱就會直接讓程序崩潰了。

從 Opus 5 切換到 Opus 5.5，有四處 API 的改動。原本是為 Opus 5 記錄的請求，如果不進行修改就發送給新模型，會被直接拒絕，並返回 400 錯誤。

1. thinking 参数不能再關閉了。

如果你將 thinking 設為 disabled，或手動指定 budget_tokens，系統將直接拒絕請求。要么不要傳入 thinking 字段，要么設為 adaptive，讓 effort 参数來控制思考深度。

2. tool_choice 不能再強制調用工具。

將 `tool_choice` 設定為 `any` 或者指定某個 `tool`，都會報出 400 錯誤。官方建議使用 `auto`，並結合嚴格的工具調用或結構化輸出，在提示語中說明何時使用哪個工具。

3. thinking 模塊綁定了模型和上下文。

2026年8月31日之後創建的賬戶，若在中途更改了系統提示詞、工具或歷史消息，再回放舊的 thinking 條塊，則會直接報錯。只有新增、不修改的用法不受影響。

4. 舊版電腦操作工具下線。

在 Claude API 和 Google Cloud 上，需要更換為 computer_toolset_20260801。在 Amazon Bedrock 上，舊的 computer_20251124 依然可以使用。

還有那些不報錯的隱藏陷阱

第一，看不到工作過程。

在 Opus 5 上，模型在兩次工具調用之間寫的進度文字，是普通的正文（text 條）。

到了 Opus 5.5 的時候，這些文字被移動到了思考區塊（thinking 區塊）中，而思考區塊的默認設定是不顯示內容的（display 就是 omitted），因此返回時該區塊是空的。

如果你的界面只顯示正文，長任務運行起來就一片安靜。請求一個都沒有失敗，用戶卻以為它卡死了。

解法是将 display 设為 updates（beta），只取進度摘要；或者設為 summarized，進度和推理摘要一起返回。

第二個，回答被截斷了。

`max_tokens` 控制的是思考內容加上正文內容的總量。過去設定的上限可能現在已經不夠用了，有時回答寫到一半就會中斷。

第三個，看不到推理，還是一樣燒 token。

思考內容就算不返回給你，也照样會按照 token 的費用標準計費。

在處理返回結果的代碼中，還有兩個地方容易忘記修改。

一是讀取結果時要分清類型。模型返回的內容中，思考和正文是分開的，不要想當然地將第一段當作回答。

二是當在工具之間進行來回調用時，模型中的思考記錄必須原封不動地傳回來。如果刪除了一段內容、修改了幾個字、或者調換了順序，都會被拒絕。

這份清單是針對那些自己調用 Messages API 來編寫代碼的開發者而言的。

使用 Claude Managed Agents 的，只需要改個模型名即可。

同樣的 medium 檔案，已經不是當年的味道了

既然思考關不掉，effort就成了調控成本的唯一旋鈕。

Opus 5.5 支持從 low 到 max 的五檔調速。

官方說，現在開啟 medium 档案，就能追平甚至超越之前 Opus 的 high 档案；如果是用 low 档案處理簡單任務，成本更是低得驚人。

聽起來像是白白賺到的便宜，但官方立刻補充了一句：在相同的檔位下，Opus每回合的思考量比Opus的5大很多，尤其是在高檔位。

也就是說，如果你把舊項目的 high 檔原封不動地搬過來，不僅回合會變長，輸出的 token 數量也會暴增。

也叫 high，但它現在所想的已經完全不同了。

一個實用的建議是：從 medium 開始，用自己的數據來試試看，確實需要提升智能指數（IQ）的地方再進行調整。

如果想讓它少琢磨一點，直接降檔就夠了，這比你在提示詞裏苦口婆心地喊「別想太多」要有效多了。

消除 AI 味，全靠拉黑列表

最後，指南裏還有一個製作前端頁面的絕招。

如果你不給出明確的設計方向，讓模型自己發揮，它多半會做出那種千篇一律的 AI 風格的界面。

這個時候，如果你在提示詞中寫「請避免使用通用的 AI 感覺」，它只會從一套 AI 模板切換到另一套 AI 模板而已。

真正有效的辦法，就是直接加入黑名單。

官方示範中直接列出：不要使用奶油色或灰白色背景，不要在標題中使用斜體強調字詞，不要使用 01/02 這種章節編號，不要使用等寬字體標簽，不要使用膠囊形按鈕。

模型能聽懂具體的「我不要什麼」，但聽不懂抽象的「我要好看一點」。

翻完這份官方指南，最大的感触是：

模型一路狂奔，很多應用的腳手架卻還停留在上一代。

過去怕它不動腦筋，逼著它把推理一步步寫出來，現在反而得勸它少想點；過去費盡心思讓它按時匯報，現在它匯報得太勤快，工作反倒停在了半路。

一個 Agent 要否能夠完成工作，模型能力只佔了一半。另外一半，則取決於你如何定義「完成」、如何保存上下文、以及如何分配推理預算。

下次你的 Agent 再做到一半就溜掉，別急著罵它偷懶，先回頭看看你自己寫的那段循環。

參考資料：

https :// platform.claude.com / docs / en / models / _EP_0 %20

https :// platform.claude.com / docs / en / build-with-claude / _EP_0 __BJW_BOLOKA_00007__ # __BJW_BOLOKA_00008__