AgentOpt 論文不是在說「便宜模型規劃、貴模型執行」一定更好

這篇討論指出，AgentOpt 的實驗限制不能直接套用到 Claude Code 的 opusplan 工作流；真正重點是角色與模型組合要實測，而不是只看模型貴不貴。

【日期不明 AI模型與技術】【Anthropic】【主題：AgentOpt 論文不是在說「便宜模型規劃、貴模型執行」一定更好】發布者：anson4139 最近有人把 AgentOpt v0.1 Technical Report 解讀成：「Opus 太聰明會偷懶跳步驟，所以應該用比較弱的模型 plan，再讓強模型 execute。」但這個結論不能直接套到 Claude Code 的 opusplan 工作流。🧠 原文指出，AgentOpt 在 HotpotQA 上採用的是嚴格 planner-solver 兩階段 pipeline：planner 只負責規劃 search queries，solver 再根據 search 結果回答。當 Opus 當 planner 時，可能直接憑 parametric knowledge 回答，反而繞過 search tool，導致 solver 拿不到 search context，整個 pipeline 失效。但 Claude Code 的 plan mode 不是同一種架構。Plan mode 允許 read、grep、search，產出的是自然語言計畫；退出 plan mode 後，Sonnet 接手時可以看到完整計畫與探索結果，不只是拿到 search query。因此，plan 文件是否完整、是否基於實際 codebase，才是關鍵。💻 HotpotQA 屬於封閉式多跳問答，答案多半是知識性事實，Opus 可能真的「記得」。但寫程式不同：模型不會記得你的 codebase、service contract 或 bug repro 步驟。若專案有非標準架構、特殊命名慣例或內部 framework，plan 階段就應該要求 Claude 先 read 關鍵檔案，並引用具體 function name。這篇論文更值得帶走的重點是：角色匹配大於單一模型強度。不能預設「Opus plan + Sonnet implement」永遠最佳；CRUD 或 boilerplate 可能 Sonnet plan + Sonnet im

https://blog.buclaw.org/posts/agentopt-mp9qre95