https://yennj12.js.org/yennj12_blog_V4/tags/tree-of-thought/Recent content in Tree of Thought on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSun, 21 Jun 2026 23:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part2-planning-zh/Sun, 21 Jun 2026 23:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part2-planning-zh/大多數人讓 Agent 直接呼叫工具，期待 LLM 自己想出下一步。 正確答案是：把規劃與執行分開，先產出可驗證的計畫，再逐步執行並動態修正。 差別不是「能不能完成任務」，而是「失敗時能不能恢復，成功時能不能解釋」。 規劃層是 Agent 系統從玩具走向生產的分水嶺。 面試情境：你的 AI Agent 需要完成一個多步驟任務：先查詢資料庫、再呼叫外部 API、最後產出報告。目前用 ReAct 架構，任務完成率只有 62%，主要失敗原因是中途走錯路、無法回頭。你的架構師問你：要如何重新設計規劃層，把完成率提升到 90% 以上？ 一、核心問題：為什麼 Agent 需要明確的規劃層 1.1 ReAct 的天花板 ReAct（Reason + Act）是目前最普遍的 Agent 架構。模型每次都先思考（Thought），再行動（Action），再觀察（Observation），循環直到任務完成。 這個架構對簡單任務效果不錯，但在複雜任務上暴露出結構性缺陷： 問題一：局部最優陷阱 每一步只看到當前狀態，無法預見三步後的死路。走進死路後，大多數 ReAct 實作只會繼續往前走，而非回頭。 問題二：無法並行 ReAct 是嚴格序列執行：Thought → Action → Observation。即使兩個子任務完全獨立，也必須依序完成，浪費延遲。 問題三：失敗後沒有恢復策略 工具呼叫失敗時，模型只能靠 prompt 裡的指示決定要不要重試。沒有系統性的回滾（rollback）或替代路徑（fallback path）機制。 問題四：無法事前驗證 計畫執行到一半才發現前提條件不成立（例如：所需的 API key 不存在），已經消耗了大量 token 和時間。 1.2 規劃層解決什麼 明確的規劃層把「想清楚要做什麼」和「真正去做」分開，帶來四個核心收益： 問題 規劃層的解法 局部最優 先展開搜尋樹，評估多條路徑後再執行最優解 無法並行 計畫產出 DAG，識別可並行的子任務 無法恢復 計畫有版本，失敗後 replan 而非從零開始 無法事前驗證 pre-condition 在執行前檢查，不滿足就不執行 關鍵數字：在 WebArena benchmark 上，純 ReAct 完成率約 14%；加入規劃層（Plan-and-Execute）後可達 26–35%；加入動態重規劃後可達 40–50%。複雜度越高的任務，規劃層的收益越大。