前幾天我們逐步建立了 Agent 的基本控制平面：
今天要進入另一個常被放大的能力：
Planning。
很多 Agent Demo 會先要求模型：
請先制定完整計畫，再逐步執行。
模型很快就會產生一份看起來合理的清單：
這份內容看起來像計畫。
但它可能完全沒有改變系統的執行方式。
如果 Agent 沒有保存進度、沒有追蹤每一步的狀態、沒有處理新資訊，也沒有在失敗後更新策略，那這份 Plan 很可能只是一段漂亮文字。
它看起來像 Planning，但沒有真正控制後續執行。
今天要回答三個問題：
一份文字清單只是 Plan Artifact。
它描述模型當下認為可以採取的路徑。
但 Agent 真正需要的是：
所以完整的 Planning 至少包含四層：
只有 Plan，沒有 State，系統不知道目前走到哪裡。
只有 State，沒有 Replanning，系統遇到變化時只能照舊執行。
只有 Replanning，沒有 Verification，系統可能一直換策略，卻不知道哪一步真的成功。
Planning 不是為了讓模型看起來更有條理。
它的價值是把一個模糊任務，轉換成一組可以追蹤與驗證的決策。
例如：
幫我改善這個專案的測試穩定性。
這個目標太大，Agent 很容易在不同方向之間反覆切換。
Planning 可以先拆出：
這些步驟不是為了增加形式。
而是降低每一輪需要重新判斷的範圍。
Planning 的價值可以理解成：
把大問題拆成較小決策，再為每個決策設定可觀察結果。
如果 Plan 只是把大目標換成更多模糊句子，就沒有真正壓縮決策。
一個可操作的 Plan，至少要回答：
例如「分析問題」太模糊。
更好的步驟是：
讀取最近三次失敗紀錄，找出重複出現的錯誤訊息，輸出最多三個候選原因。
這個步驟有明確輸入、行動與輸出。
Plan 的粒度不需要非常細。
但每一步都應該能被系統追蹤。
如果系統只把計畫放在 Prompt 裡，模型可能下一輪就重新描述一份不同的計畫。
更可靠的方式，是把計畫視為任務狀態的一部分。
每個 Step 可以有：
狀態可能包含：
這些狀態讓 Harness 能回答：
如果所有進度都只存在模型的自然語言回覆裡，系統很難可靠恢復。
真實環境會改變。
工具會失敗。
資料會缺失。
使用者會補充新需求。
原本合理的假設可能被新證據推翻。
所以 Plan 不應該被當成必須照表執行的固定腳本。
可以把 Planning 分成兩種模式。
先產生完整步驟，再照順序執行。
適合：
先建立初始路徑，每得到新 Observation 後重新判斷是否需要調整。
適合：
Adaptive Planning 比較靈活，但也更容易造成：
因此 Replanning 也需要條件，而不是每一輪都重新規劃。
Replanning 可以在特定事件發生時觸發。
原本以為某個檔案存在，實際上不存在。
原本路徑無法執行，需要改用替代方式。
使用者補充真正關心的範圍。
同一步驟已經多次無法完成。
剩餘時間或 Token 無法支持原計畫。
表面完成，但實際輸出不符合要求。
這些都是明確事件。
比起每輪都問模型「要不要重新規劃」，事件驅動的 Replanning 更容易控制。
一份完整 Plan 很容易讓人產生錯覺：
只要步驟完整，任務就會可靠完成。
但計畫只能描述意圖。
它不能證明執行結果。
例如 Plan 寫：
執行測試並確認全部通過。
模型也可能在沒有真正執行測試時，直接把這一步標記為完成。
所以每個重要 Step 都需要 Verification。
例如：
Planning 決定要檢查什麼。
Verification 決定結果是否可信。
兩者不能互相取代。
模型可能計畫：
修改設定檔，然後部署到 Production。
即使這個計畫邏輯完整，也不代表 Agent 有權限執行。
Planning 處理任務分解。
Permission 處理操作是否允許。
Approval 處理高風險行動是否需要人類確認。
Sandbox 處理出錯時的影響範圍。
一份合理的計畫不能跳過任何控制層。
Planning 本身也有成本。
模型可能花很多 Token 產生一份非常詳細的計畫。
之後每輪又重新讀取、更新與解釋整份計畫。
如果任務本來只需要一次工具呼叫，Planning 反而增加延遲。
因此 Plan 應該有自己的限制：
Planning 不是免費的。
只有當它降低錯誤、重工或決策複雜度時，才值得加入。
簡單任務通常不需要先建立完整 Plan。
例如：
對這些任務，Planning 可能只是額外的 Token 與延遲。
比較需要 Planning 的任務通常具有：
可以先問：
如果不先建立狀態化計畫，Agent 最可能在哪裡迷路、重複或過早完成？
如果答案不明確，可能不需要 Planning。
Plan 太粗，不能控制。
Plan 太細，維護成本過高。
例如：
每一步仍然需要大量臨場決策。
這會讓 Plan 很快失效，也增加狀態管理成本。
比較實用的粒度是：
每個 Step 對應一個清楚的中間結果，並且可以被驗證。
例如：
不一定要由同一個模型完成所有 Planning。
最簡單，但規劃與執行可能共享相同盲點。
Planner 負責拆解，Executor 負責執行。
優點是責任清楚。
缺點是增加模型呼叫與協調成本。
程式碼先定義必須經過的節點，模型只填寫不確定部分。
例如固定要求：
這能減少模型自由度，也更容易評估。
使用者提供重要步驟、優先順序或批准點，模型只負責補充執行細節。
Production 系統常常是混合這些方法。
Planning 通常由模型根據任務產生或調整。
Graph 則通常由程式碼預先定義控制節點與路徑。
如果某個流程每次都必須先驗證，再允許部署，就不一定需要模型重新規劃。
可以直接寫進控制流程。
Planning 適合不確定部分。
Graph 適合已知且必須強制執行的部分。
這也是後面 Graph Engineering 會進一步討論的核心。
如果清單不影響 State 與執行，它只是文字。
新 Observation 已經讓原路徑失效，Agent 仍照舊執行。
造成方向漂移、重複工作與成本增加。
重要步驟應有外部 Verification。
增加 Token 與延遲，沒有明顯收益。
環境稍微改變，整份計畫就失效。
Agent 可能花大量時間規劃與改寫，而不是完成任務。
合理計畫不代表擁有執行權限。
第一版可以先加入五個欄位：
再加入三個限制：
Replan 只在明確事件發生時觸發：
這已經比「先列出一份計畫」更接近真正的 Planning System。
可參考：https://github.com/hardness1020/awesome-agent-architecture/tree/main/sections/05-planning-todos
Day 5 的 Hooks 讓我們可以在關鍵 Lifecycle Event 插入自訂邏輯。
今天加入：
因此，Plan 不再只是模型輸出的一段文字。
它開始成為可以追蹤、恢復、修改與驗證的任務狀態。
Planning 的價值不是讓模型先說明自己準備做什麼。
而是把模糊目標轉換成可追蹤、可驗證、可調整的執行狀態。
真正的 Planning 至少包含：
最重要的原則是：
計畫必須能在執行中被追蹤，也必須能在現實改變時被修正。
下一篇會進入 Subagent：
把任務交給另一個 Agent，真的等於平行處理嗎？還是只是把 Context 與責任重新切分？
完整系列與範例收錄於：https://github.com/hardness1020/awesome-agent-architecture
iThome鐵人賽
看影片追技術