跳到主要內容

AI 202 · 模組 2

Goal Decomposition 與 Planning Fundamentals

Agent 如何把一個目標拆成可執行的計畫?

開始第一節
已完成 0 / 6
同步我的進度加入梯次後,進度可跨裝置保存,講師也能看到

資訊

加入後,你已完成的模組編號會連同「學員代碼」傳送給講師,講師可以看到你的進度。請使用講師提供的代碼,不要輸入姓名、公司機密或其他個資。進度資料與該梯次的其他資料一起保存。

學習目標

  • 把 Goal 拆解為 Subgoals、Candidate Plan、Actions 與 Expected Outcomes
  • 說明設計 Workflow(AI 104)與 Agent 選擇或修訂 Plan(AI 202)的差別
  • 使用規劃問題,包括哪些 Action 可以還原,以及什麼會讓 Plan 失效
  • 辨識一個 Action 的 Preconditions、Constraints 與 Dependencies
  • 選擇合適的 Planning horizon,並判斷 Plan 是否仍然有效
  • 用模擬資料為自己的使用案例產出 Goal & Plan Map

問題與需求

8 分鐘

Goal 還不是 Plan

在模組 1 你看到 Adaptive Agent 會根據情況選擇下一步。但要選得好,需要有東西可以對準。「解釋報名人數為什麼下降」是一個 Goal,不是 Plan:它沒說要先做什麼、接著做什麼,也沒說怎麼知道有沒有進展。本模組的核心問題是:Agent 如何把一個目標拆成可執行的計畫?

工作情境(模擬)

一位規劃助理被告知:「準備新教室預約系統的各個選項。」它立刻開始閱讀產品頁面。兩小時後,它有 40 則開著的筆記,沒有明確的比較標準,也從來沒有確認系所實際被允許採購什麼。工作本身沒有錯,但它沒有 Plan:沒有 Subgoals、沒有順序,也不知道「完成」長什麼樣子。

  • 沒有 Subgoals,力氣會花在最容易開始的事,而不是最重要的事
  • 沒有 Dependencies,工作順序會錯,還得重做
  • 沒有 Success Criteria,沒有人能判斷進展是否真實
  • 不知道哪些 Action 可以還原,一個小錯誤可能變成昂貴的錯誤

注意

相反的錯誤是規劃過度:為一個不斷變化的情況寫出非常詳細的 Plan,很快就會失效。好的 Plan 要詳細到可以行動,也要輕到可以修訂。

重點: Goal 說明要去哪裡;Plan 說明先做什麼、接著做什麼,以及如何知道它有效。

核心概念

9 分鐘

從 Goal 到 Subgoals 再到 Actions

Planning 是把 Goal 拆成更小的部分,直到每個部分都是 Agent 真的能做、也能檢查的事。五個層次描述了從 Goal 往下到應該發生什麼的路徑。

Planning 模型
  1. Goal:要達成的結果
  2. Subgoals:合起來能達成 Goal 的較小結果
  3. Candidate Plan:為達成 Subgoals 所提出的工作順序
  4. Actions:Agent 可以採取的具體步驟
  5. Expected Outcomes:每個 Action 之後應該成立的事,讓進展可以被檢查

文字說明:五個層次由上到下排列。Goal 被切成 Subgoals;Candidate Plan 提出如何用 Actions 達成它們;每個 Action 都有一個 Expected Outcome,Agent 之後會拿它與實際的 Observation 比對。之所以叫 Candidate Plan,是因為它只是一個可能被修訂的提案。

範例:教室預約選項(模擬)。Goal:一份主管可審閱的簡短比較
層次範例
Goal一頁三個教室預約選項的比較,供主管審閱
Subgoals掌握需求;掌握預算與規則;找到候選選項;比較它們
Candidate Plan先確認需求,再檢查規則,再搜尋選項,最後比較
Actions閱讀需求筆記;檢查採購準則;搜尋產品頁面;填寫比較表
Expected Outcomes一份五項需求清單;一個預算上限;三個選項;每個選項一列的表格
自我檢測

下列哪一項是 Expected Outcome,而不是 Action?

下列哪一項是 Expected Outcome,而不是 Action?

重點: Plan 中的每個 Action 都應有 Expected Outcome,Agent 才能判斷它有沒有成功。

10 分鐘

設計 Workflow 與選擇 Plan 的差別

你在 AI 104 已經學過如何拆解任務。差別在於:誰產生並修訂 Plan,以及什麼時候。

AI 104:設計 Workflow

  • 由人事先設計步驟、順序與檢查點
  • 路徑在執行前就固定
  • 適合路徑寫得出來的情況
  • 問題是如何把流程設計好

AI 202:Agent 選擇或修訂 Plan

  • Agent 根據 Goal 與目前的 State 提出 Plan
  • Plan 會隨 Observation 出現而在執行中改變
  • 適合路徑無法完全事先定義的情況
  • 問題是 Agent 如何在限制內選擇或修訂 Plan

一組好用的規劃問題可以維持紀律。在行動之前,Agent 或設定 Agent 的人應該能回答所有這些問題。

八個規劃問題
問題為什麼重要
Goal 是什麼?一切都拿它來判斷
我們處於什麼 State?Plan 取決於已知與已完成的事
有哪些 Constraints?資料、時間、成本、權限與隱私的限制
有哪些 Action 可用?Plan 只能使用存在且被允許的 Action
什麼必須先發生?Dependencies 決定順序
哪些 Action 可以還原?可還原的 Action 可以嘗試;不可還原的需要更謹慎,通常要有人參與
什麼證據顯示有進展?定義要檢查的 Expected Outcomes
什麼會讓 Plan 失效?指出哪些變化會迫使 Plan 修訂

資訊

Human–AI–Human:人設定 Goal 與 Constraints,Agent 在其中提出並修訂 Plan,包含不可還原或高影響 Action 的 Plan 則由人核准。
自我檢測

AI 104 的 Workflow 設計與 AI 202 的 Planning,最清楚的差別是什麼?

AI 104 的 Workflow 設計與 AI 202 的 Planning,最清楚的差別是什麼?

重點: AI 104 事先設計路徑;AI 202 讓 Agent 在人設定的限制內選擇或修訂路徑。

9 分鐘

Preconditions、Constraints、Dependencies 與可還原性

Plan 的好壞取決於其中的 Action。Agent 採取每個 Action 之前,都要檢查四件事。

每個 Action 的四項檢查
檢查意義範例(模擬)
PreconditionsAction 要能運作,事先必須已經成立的事要比較選項,需求清單必須已經存在
ConstraintsAction 必須遵守的限制只用核准的產品清單;不處理個人資料;在預算內
Dependencies這個 Action 等待哪些其他 Action 或結果比較表需要搜尋結果與預算上限
ReversibilityAction 可以還原或安全地重試嗎?閱讀頁面可以還原;把比較表寄給供應商則不行
  • 把可還原、低成本的 Action 放在前面:它們能便宜地讓 Agent 認識情況
  • 把不可還原或對外的 Action 放在後面,而且要等人核准之後
  • 若某個 Precondition 未滿足,就不應該選這個 Action
  • 缺少 Dependency 是重新排序 Plan 的理由,不是用猜的理由

注意

不要把聽起來很有把握的 Plan 當成已檢查過的 Plan。Agent 可能提出忽略某個 Constraint 或未滿足 Precondition 的 Plan。在有實際影響的 Action 之前,應由人或明確的檢查來確認 Plan。
自我檢測

一個 Plan 有兩個 Action:「閱讀系所採購準則」與「寫信給三家供應商索取報價」。應如何排序與處理?

一個 Plan 有兩個 Action:「閱讀系所採購準則」與「寫信給三家供應商索取報價」。應如何排序與處理?

重點: 為每個 Action 檢查 Preconditions、Constraints、Dependencies 與可還原性,不可還原的放最後並由人核准。

Horizon 與有效性

9 分鐘

Planning horizon 與 Plan 的有效性

Agent 應該往前規劃多遠?這就是 Planning horizon。規劃太遠,Plan 充滿猜測;規劃太近,Agent 會漫無方向地遊走。

Short-horizon planning

  • 只規劃接下來一到三個 Action
  • 每次 Observation 之後修訂成本低
  • 適合不確定或快速變化的情況
  • 風險:局部很好的步驟,加起來卻不通往 Goal

Long-horizon planning

  • 往前規劃很多步驟以通往 Goal
  • 提供方向並及早顯示 Dependencies
  • 適合穩定且步驟已知的情況
  • 風險:建立在最後被證明是錯誤假設上的長 Plan

實務上,Agent 常常兩者並用:把 Goal 與 Subgoals 固定作為長期視野,詳細規劃接下來幾個 Action,並在每次 Observation 之後修訂。

Plan 可能不再有效的徵兆(模擬範例)
徵兆範例該怎麼做
某個假設被證明是錯的筆記中的預算上限已經過時暫停並與人確認後再繼續
某個 Precondition 不再能滿足需要的資料來源無法使用選擇其他 Action 或請求存取權
Observation 與 Plan 矛盾兩個來源對某項關鍵需求說法不同修訂 Plan 或升級給人,不要默默選一個
Goal 或 Constraint 改變了主管把範圍縮小為兩個選項對照新的 Goal 更新 Plan
自我檢測

情況經常變動,每次 Observation 都可能改變重點。哪一種做法最合適?

情況經常變動,每次 Observation 都可能改變重點。哪一種做法最合適?

重點: 規劃得夠遠以保持方向,夠近以便宜地修訂,並知道什麼會讓 Plan 失效。

實作與應用

10 分鐘

實作:Goal、Subgoal、Action

活動 2 要你拿一個真實的任務,把它變成 Plan。先用下面的範例練習,再對你在模組 1 選定的使用案例做同樣的事。請勿在此練習中輸入真實的公司機密、客戶個人資料或任何未經授權的敏感資訊。

示範範例(模擬):準備新教室預約系統各選項的簡報
項目範例
Goal本週內產出一頁三個選項的比較,供主管審閱
Subgoals需求已掌握;預算與規則已掌握;選項已找到;選項已比較
Candidate Actions閱讀需求筆記;閱讀採購準則;搜尋產品頁面;建立比較表
Constraints只用核准的產品;不處理個人資料;未經核准不得聯絡供應商
Success Criteria三個選項,每個都對照五項需求與預算檢查過,並列出來源
可還原嗎?所有閱讀與草擬步驟都可以還原;聯絡供應商不行,需要核准
什麼會讓 Plan 失效?預算上限或需求改變;採購準則無法取得
  1. 寫下你的 Goal
    為你的使用案例寫一句話:結果是什麼、誰審閱、何時完成。
  2. 列出 Subgoals 與 Candidate Actions
    把 Goal 拆成三到五個 Subgoals,每個列出一到兩個 Action,並依 Dependencies 排序。
  3. 加入 Constraints 與 Success Criteria
    寫下限制(來源、隱私、時間),以及你如何知道每個 Subgoal 已完成。
  4. 標出可還原性與失效條件
    標出哪些 Action 不可還原或屬於對外、需要核准,並寫下什麼會讓你的 Plan 失效。

資訊

成果:Goal & Plan Map,一頁包含 Goal、Subgoals、Candidate Actions、Constraints 與 Success Criteria。它會成為你的 Agent Planning & Reasoning Canvas 的一部分。
自我檢測

下列哪一項最能描述一份好的 Goal & Plan Map?

下列哪一項最能描述一份好的 Goal & Plan Map?

重點: Human–AI–Human:人設定 Goal 與限制,Agent 提出並修訂 Plan,人核准不可還原的 Action 並審查結果。

接下來做什麼?