Opus 4.6 → 4.7 的變化與多代理程式編碼考量

資料來源#

問題#

Opus 4.6 和 4.7 有什麼差異？在多團隊代理程式編碼環境中工作時，該注意哪些事？

第一部分 — 4.6 與 4.7 之間有哪些變化#

價格相同（輸入 $5/M、輸出 $25/M），產品定位相同，API ID 更新為 claude-opus-4-7。可直接升級。詳情與細節請見 Claude Opus 4.7：

面向	4.7 相較於 4.6	對多代理程式設定的重要性
最難的編碼任務	宣稱適合「交辦最棘手的工作」；SOTA Finance Agent 和 GDPval-AA	提高了適合由 Opus 擔任角色的上限
指令遵循	字面遵循。較少跳過或放寬要求。	為 4.6 撰寫的提示與 CLAUDE.md 緩和措辭可能出現異常，是遷移時最大的風險
視覺能力	長邊最高 2,576 px（約 3.75 MP，是先前的 >3×）	讀取高密度螢幕截圖的電腦操作代理程式表現更好
檔案系統記憶	多工作階段間的記憶更強	更適合以儲存庫內的版本化產物作為代理程式間共享記憶
安全性	提升提示注入防護與誠實度；在減害說明過度延伸方面略弱	提示注入防護對於讀取其他代理程式輸出的代理程式尤其重要
網路安全能力	訓練期間差異化降低 + 請求層級分類器（Glasswing 之後）	合法的安全自動化現在會轉交 Cyber Verification Program
努力程度	新增介於 `high` 和 `max` 之間的 `xhigh`。所有方案的 Claude Code 預設值都提升為 `xhigh`	預設情況下每個代理程式的 token 成本都增加
Tokenizer	相同輸入 → token 數增加 1.0–1.35×	若未重新測量提示，各代理程式可用的情境預算會縮小
每回合思考	高努力程度下思考更多，尤其在後續代理式回合	Tokenizer 膨脹會在多回合編排中層層累加
同步推出項目	任務預算（API 公開測試版）、`/ultrareview`、自動模式擴展至 Max	伺服器端預算控制器與自動模式同步推出，適用於無人值守執行

Token 預算衝擊疊加：tokenizer 膨脹 × xhigh 預設值 × 每回合思考增加。天真地「直接升級」會比在相同提示下使用 4.6 消耗更多情境。Anthropic 明確建議以真實流量進行測量，而非盲信其內部編碼評估中整體有利的說法。

第二部分 — 多代理程式編碼設定中應注意的事項#

這份 wiki 的研究指出，從單一代理程式工作流程轉為由 Opus 4.7 驅動的多代理程式團隊時，有六項具體風險。

1. 依角色選擇模型，而非預設使用最強模型#

根據 Client-Side Agent Optimization（AgentOpt，Hua 等人，2026）在 Opus 4.6 上進行的測量：

組合（HotpotQA 上的規劃器 + 解題器）	準確率
Ministral 3 8B + Opus	74.27%
Opus + Opus	31.71%

以 Opus 擔任規劃器會略過下游解題器的搜尋工具，直接根據參數化知識作答。正確的分析單位是組合，而不是各角色孤立的準確率。

規則：

規劃器／路由器／檔案排序器／拆解器角色，安排較小且較聽指令的模型。
保留 Opus 4.7 用於綜整、整合推理、最終答案生成，以及跨多檔案程式碼審查等角色。
將 Opus 用於某個角色前，先確認較便宜的模型是否能達到相同準確率。在 BFCL 上，Qwen3 Next 80B 以低 32× 的成本達到 Opus 4.6 的水準。4.7 的 tokenizer 膨脹會讓差距擴大，而非縮小。

關於 4.7 的開放問題：字面指令遵循可能縮小規劃器的差距。別想當然，請重新測量。各項規則對 4.7 的預測，請參見 When to Use Claude Opus 4.6 for Work 的附錄。

2. 重新調整 4.6 時代的提示#

Opus 4.7 的字面指令遵循是既有多代理程式編排程式碼遷移時最大的風險。先前在 4.6 上有效的提示，是因為它會寬鬆解讀「或類似項目」、「優先考慮 X」、「試著做」，或略過看似可選的步驟；現在可能會被僵硬地照字面執行。

稽核清單：

含有緩和措辭的 CLAUDE.md 檔案與系統提示
仰賴模型「知道何時該委派」的多代理程式角色說明
後續步驟預期前一步會被跳過的鏈式提示
假設 Opus 會修正模糊指令，而非照原文執行的提示

3. 以 harness 層級的不變條件取代提示建議#

根據 Agent Harness Engineering 與 Scale-Dependent Prompt Sensitivity：

以機制強制輸出限制 — 結構化輸出綱要、長度上限、回應驗證器、/ultrareview 式審查流程。
在 4.6 上，簡潔限制讓容易過度思考的問題表現回升 +26.3pp。4.7 的字面指令遵循可能讓這些限制更有效（模型會遵守字數上限）。請使用這些限制。
診斷例外：BoolQ 及類似的跨句整合任務 — 簡潔限制有害。不要限制推理產物的輸出。

大型模型的冗長輸出會在多代理程式管線中層層堆疊：每個代理程式的輸出都會成為另一個代理程式的情境。錯誤會累積、情境會填滿，推理品質也會下降。

4. 情境預算須逐一管理各代理程式#

Claude Code Best Practices 適用於每個獨立代理程式。4.7 預設的 xhigh、tokenizer 膨脹與每回合思考增加，會加快多代理程式交接時的預算消耗。可採取以下做法：

以摘要交接，不要傳遞完整情境
讓子代理程式在隔離情境中工作（Claude Code 模式）：分別調查，再回傳摘要
採用 Writer/Reviewer 模式，並讓審查者使用新情境 — 尤其現在 /ultrareview 已成為 4.7 專用功能
非高難度步驟降低努力程度。 Anthropic 建議編碼／代理式工作使用 high 或 xhigh；max 通常不值得
任務預算（API 公開測試版）：每個階段設定支出上限，作為 AgentOpt 預算控制器的伺服器端對應機制

5. 無人值守扇出的安全性#

根據 Claude Code Auto Mode（現在隨 4.7 一同擴展至 Max 使用者）：

對多代理程式扇出而言，自動模式嚴格來說比 --dangerously-skip-permissions 安全 — 分類器會預先檢查每次工具呼叫，並在遇到風險操作時引導 Claude 改道。
它不能取代隔離環境。Anthropic 記錄了兩種分類器失效模式：意圖模糊，以及缺少環境情境。
在非互動模式中，自動模式遇到重複封鎖會中止，而不是卡在無法回答的提示上 — 保留了扇出使用情境。

當代理程式在團隊中扇出執行具有破壞性的命令（遷移、刪除、部署）時：在沙箱容器或 worktree 內再加上自動模式。採用縱深防禦。

6. 代理程式審查模式勝過自我驗證#

根據 Claude Code Best Practices：Writer/Reviewer 模式 — 一個代理程式負責實作，另一個代理程式使用新情境進行審查 — 能減少「看不見自己程式碼盲點」的問題。使用 Opus 4.7 時：

/ultrareview 是此模式的內建版本；Pro 與 Max 使用者可免費進行 3 次 ultrareview 以供評估
檔案系統記憶改善後，審查者可以有效讀取撰寫者的進度記錄與 git 歷史，而不只檢查差異
對無人值守的多團隊工作流程：將審查代理程式的輸出再交由驗證代理程式檢查（類似 LLM-Driven Vulnerability Research 中的最終驗證代理程式模式），而不是只信任單一代理程式審查

決策摘要#

情況	行動
多代理程式團隊目前採用全 Opus 4.6 管線	不要全面遷移。稽核各角色。將規劃器／路由器降級為便宜模型，再切換解題器至 4.7
4.6 提示帶有隱含的寬鬆解讀	在信任 4.7 的輸出前，針對字面指令遵循重新調整提示
使用 4.6 時覺得情境預算吃緊	4.7 會更吃緊。使用摘要交接、子代理程式，以及非高難度步驟降低努力程度
生產環境的無人值守扇出目前使用 `--dangerously-skip-permissions`	改用自動模式（現已適用於 Max）+ 隔離環境
目前沒有 harness 層級的輸出限制	擴大使用多代理程式前，先加入綱要、長度上限與驗證器
沒有獨立審查者步驟	加入一個 — 使用 `/ultrareview`，或讓 Writer/Reviewer 採用新情境
預設「所有地方都用最強模型」	在 4.7 上重新檢查 Pareto 前緣 — tokenizer 膨脹會使其位移

兩項根本原則#

Opus 在 4.6 上的兩種特有失效模式 — 規劃器表現墊底，以及短答案過度思考 — 共用一種機制：依規模而變的過度思考。4.7 的字面指令遵循可能會減輕這種情況；4.7 的 xhigh 預設值與每回合思考增加則會推向相反方向。整體方向仍須實證確認。

多代理程式編碼團隊的安全元規則是：不要盲信並沿用 4.6 的部署決策。在你的工作負載上測量，再做決定。When to Use Claude Opus 4.6 for Work 的五項規則是目前最佳的預設做法 — 隨著多代理程式設定在 4.7 上逐漸成熟，請重新驗證這些規則。

資料來源#

Claude Opus 4.7 — 4.7 能力與 token 經濟性差異
Claude Code Best Practices — 情境預算限制、子代理程式、Writer/Reviewer、工作階段管理、擴展模式
Claude Code Auto Mode — 由分類器把關的權限折衷方案
Client-Side Agent Optimization — 組合選擇、以 Opus 擔任規劃器的失效模式、Pareto 前緣
Scale-Dependent Prompt Sensitivity — 簡潔限制、過度思考機制、BoolQ 例外
Agent Harness Engineering — 以機制強制不變條件、漸進式揭露、文件整理維護
LLM-Driven Vulnerability Research — 最終驗證代理程式模式作為多代理程式審查範本
When to Use Claude Opus 4.6 for Work — 附錄中逐項規則對 4.7 的預測
Introducing Claude Opus 4.7
Best Practices for Claude Code
Auto mode for Claude Code
AgentOpt v0.1 Technical Report: Client-Side Optimization for LLM-Based Agent
Brevity Constraints Reverse Performance Hierarchies in Language Models