Planning（任務規劃）
又稱：任務規劃 · 計畫與執行 · plan-and-execute · 任務拆解
動手之前先讓模型產出一份步驟清單，之後照著執行、邊做邊修。
你會在什麼時候遇到它
任何多步驟任務（調研、重構、部署）裡你都會遇到它。不理解規劃，會有兩件事想不通：為什麼 Agent 開頭列的計畫後面全變了（正常，世界會反饋），以及為什麼成熟的系統把力氣花在「重新規劃」而不是「一次規劃到完美」。
打個比方
像旅行前先排行程。排行程有用：知道大致順序、不會漏掉想去的景點。但下雨、店家休息、路上發現更好的地方 —— 都得現場改。沒有旅伴會怪你「怎麼跟出發前寫的不一樣」，那份行程本來就是拿來改的。
最小範例
Plan（示意）:
1. 找出所有呼叫舊 API 的檔案
2. 逐個改成新 API
3. 跑測試
4. 寫變更摘要
執行到第 3 步發現：舊 API 有兩種呼叫模式，
第 2 步只改到其中一種
→ 重新規劃：2a. 補改第二種模式 → 3. 重跑測試 → 4.重點在後半段：計畫的價值不是「預測得準」，而是提供一個可以對照、可以修改的骨架。沒有骨架，「重新規劃」無從談起。
最常搞錯的地方
- 以為計畫越詳細越好、模型照著走就行。執行中的每一步都會帶來新資訊，死守原計畫的 Agent 會在錯誤的路上走得又遠又自信。
- 把規劃能力當成純模型屬性。規劃品質有一半取決於 harness 給不給它重新規劃的機會：執行結果有沒有接回去、清單允不允許改。