CMU 11-768 AI Agents 第 5 講（2026-09-08，Daniel Fried 主講；系列總覽）談 planning 與任務拆解，結尾順帶進入多 agent。講者開場就說這個主題的核心是一個取捨：agent 越死守一份計畫，人越容易理解和控制它；agent 越有彈性，越能處理途中冒出來的問題。整講都在這條軸上找位置。
開場案例：幫實驗室買 GPU 工作站
講者用一個他們幾週前真的遇到的任務開場：比較各家廠商的工作站設定和價格，對照內部 wiki 上叢集的相容性要求，最後送出採購單。
一個標準 ReAct 迴圈的 agent 會這樣跑：
- 第 1 步：進 A 廠商網站，一路點到 GPU 規格比較頁
- 第 15 步：選好設定，2 張 RTX 6000、128 GB RAM、850 W 電源
- 第 31 步：去看 wiki，「機櫃接受 4U 機箱，每個槽位 1600 W」
- 中間 context 被壓縮過一次，128k 壓到 14k token
- 四家廠商都查完，只有 D 符合，但交期 20 週
- 第 201 步：選 D？找第五家？放寬需求？
- 第 202 步：它還是選了一家，送出採購單
問題有三個：四個互不相干的搜尋被塞進同一條執行緒、同一個 context；四家都不理想時沒有機制回頭；最後一個不可逆的動作沒人把關。
把任務畫成圖就清楚了：四家廠商的搜尋可以平行，相容性檢查依賴它們的結果，採購單依賴相容性檢查，而且圖本身會變——四家都不合時，要新增第五個搜尋節點。這就是 replanning。
這講要回答四個問題：
- 價值：什麼時候規劃有用？什麼時候反而有害？
- 表示：計畫用什麼形式表示？
- 承諾：計畫什麼時候定下來？什麼可以改變它？
- 監督：人什麼時候、用什麼方式介入？
Plan Mode 與「計畫」的定義
講者先問全班誰用過 coding agent 的 Plan Mode，大部分人都舉手。Cursor、Claude Code 和 Codex 都有類似功能，流程大致是：
唯讀調查 → 釐清問題 → 寫成計畫 → 人審核 → 執行它為什麼有用？講者列了幾個候選：多花了算力、context 更好、多了一份外部檔案、任務被拆解、人批准過。學生補充的理由也很具體：
- 不信任 agent 的任務，先看計畫能建立信任。Claude Code 把 plan mode 做成一種權限模式，先只做蒐集資訊的動作。
- 先規劃再執行，總成本可能比貪婪執行低：用強模型寫計畫，交給便宜的模型執行；子任務平行跑也能省時間。
- 計畫是「做了什麼、還剩什麼」的結構化紀錄，幫助 agent 追蹤進度。這和 L3 的 context 壓縮動機相同，差別在計畫是明確、人可以編輯的。
本講的工作定義：
計畫是對未來預期行為的明確表示：agent 將嘗試的動作或子目標，以及它們之間的順序或依賴關係。
三個延伸：
- 計畫只針對這個任務。上一講的 skill 是跨任務重用的指引；計畫可以更具體，綁在特定 repo 上。
- 計畫組織未來的工作，可以指定動作或子目標，以及順序和依賴。
- 計畫是提案，不是保證。使用者、另一個模型或環境互動都能檢查和修改它。代價是能重新規劃的 agent 比較難預測。
講者引了 Mike Tyson 的話：「每個人都有計畫，直到嘴巴挨了一拳。」
規劃在整門課會出現好幾次。本講講 prompt 出來的計畫和 harness 結構；Coding Agents 那講會講 Agentless 這種固定工作流程。Interaction 兩講講多 agent 溝通與人類審核；Search 兩講講在計畫上做搜尋，並重訪本講的 MACU 和 RAO。
行動之前先拆解
Chain-of-thought 就是一種計畫
Kojima 等人（NeurIPS 2022）發現「Let's think step by step」一句話就能讓模型答得更好；Plan-and-Solve（Wang 等，ACL 2023）更直接叫模型「先理解問題、擬好計畫，再照計畫一步步解」。
講者認為 CoT 提供兩樣東西：額外的算力，以及一塊模型可以回頭參照的草稿區。但計畫和解答在同一次生成裡產出，沒有東西會明確檢查這份計畫。後來 STaR 和 DeepSeek-R1 把 CoT 訓練成能提高答對機率的樣子；講者說 agent 的規劃現在也走到這一步，本講後段的 RAO 就是例子。
Least-to-Most：先拆題，再依序解
Least-to-Most Prompting（Zhou 等，ICLR 2023）把規劃和解題分成兩個階段：第一階段寫出子問題，第二階段依序回答，每題的答案往下傳。當時的模型解不好複雜題，但解得了子題；子題需要的 context 也比較少；題目越長，改進越大。講者把 Recursive Language Models 也歸在這一類。
這些動機對今天的 agent 一樣成立：查某一家廠商的 GPU 時，不需要其他廠商的資訊，查完再彙整就好。
Decomposed Prompting：拆解帶來模組化
Decomposed Prompting（Khot 等，ICLR 2023）讓一個拆解器產生子任務，並把每個子任務送給專責的處理器。例如「1910 年出生的人製作的電影得過什麼獎？」拆成「誰在 1910 年出生」（一般 QA）和「#1 製作了哪些電影」（關聯式 QA）等步驟。
為什麼要用不同模型處理不同子任務？學生答：有些模型專精某類問題。講者補充：也可能是效率，簡單的子問題不需要昂貴的模型。模組化的另一個好處是每個處理器可以各自用範例或訓練改進。這篇也有程式化的控制，定義子任務執行順序、把前一步的答案當參數傳下去；講者預告後面的 RAO、RLM、MACU 會把這件事交給程式碼。
會動到世界的計畫
講者在這段引了一句玩笑話：「We'll burn that bridge when we come to it.」
推理和行動的差別
| CoT 的推理步驟 | 在世界中的動作 |
|---|---|
| 只改變文字 | 改變 agent 接下來遇到的狀態 |
| 多寫幾句就能撤回 | 會揭露新資訊 |
| 每個中間結果都看得到 | 可能失敗 |
| 只要模型能據此推得更好，計畫就有用 | 可能不可逆：送出、寄出 |
所以一旦要行動，計畫就必須處理可行性、後果、資訊，以及出錯後怎麼復原。
古典規劃：STRIPS
古典 AI 規劃用結構化的邏輯表示世界。以積木世界為例：
- 狀態是一組謂詞：
on-table(x)、on(x, y)、clear(x)、holding(x)、hand-empty - 動作有前置條件和效果。例如
pick-up(x)的前置條件是on-table(x) ∧ clear(x) ∧ hand-empty，效果是holding(x) ∧ ¬on-table(x) ∧ ¬hand-empty - 規劃就是搜尋：找一串每一步都滿足前置條件、最後到達目標的動作
這種「前置條件＋效果」的表示法源自 STRIPS（Fikes & Nilsson，1971）；PDDL 是它的後繼，PlanBench 就用它來評估 LLM 的規劃能力。古典規劃的主力是 BFS、DFS、A* 這類搜尋演算法。
上面的積木世界例子和謂詞寫法出自投影片，原論文的細節不太一樣。論文本身把 STRIPS（STanford Research Institute Problem Solver）介紹為一個問題求解程式（problem solver），是 SRI 機器人研究的一部分，並沒有把它當成一種規劃語言來談。論文用一階述詞邏輯公式描述世界模型，例子是機器人在房間裡移動、推箱子（goto、push），不是積木世界。每個運算子寫成前置條件，加上一份 add list（要加進模型的公式）和一份 delete list（不再成立、要刪掉的公式）；投影片裡的 ¬on-table(x) 在原論文會寫成把該公式放進 delete list。搜尋方式也不同：論文明說對每個模型套用所有可用運算子、做廣度優先展開不切實際，改用 resolution 定理證明器檢查目標是否成立，再用 GPS 式的 means-ends analysis 挑出能消除「差異」的運算子。
對 LLM 來說，難的東西變了
LLM 的世界裡一切都是隱含的：你不確定某個動作什麼時候能用、會造成什麼結果，多半只能實際試試看。但反過來，LLM 看過大量資料，寫出一份看起來合理的計畫很容易。難的是知道它對世界的理解對不對。
所以 LLM agent 的設計少做深度搜尋，多做「檢查世界」：觀察、驗證、從錯誤中復原。搜尋和動作可行性這兩個概念仍然有用（課程最後的 Search 單元會回來）。
計畫的表示：形式語言、自然語言、程式碼
形式計畫（STRIPS）可以驗證；自然語言計畫（Plan Mode 那種）很通用；程式碼介於兩者之間。
2023 年左右出現一批工作，讓 code LLM 寫出呼叫感知與控制 API 的程式當計畫：Code as Policies（Liang 等，ICRA 2023）、ProgPrompt（Singh 等，ICRA 2023），以及做半結構化問答的 Binder。例如「把積木疊進空碗」，LLM 寫出呼叫物體偵測器和機械手臂的程式。
程式能跑、能檢查，迴圈（「直到積木疊上去之前重複」）某種程度上實現了搜尋和後置條件。限制是只能做到 API 和程式結構允許的事——不過 API 本身也可以是一次 LLM 呼叫或另一個神經網路模型，這樣就同時拿到結構化控制和學習模型的彈性。講者補充，在機器人領域這條路沒有端到端訓練的多模態模型那麼熱門，但在 coding agent 上仍然很有用（下一講的 CodeAct）。
為什麼要邊做邊重新規劃
講者把決策時間點排成一條光譜：
| 開發者定義的 workflow | 先規劃再執行 | 適應型 agent | |
|---|---|---|---|
| 決策時間 | 執行前 | 執行前 | 執行中 |
| GPU 例子 | 開發者寫死廠商清單 | 模型決定要查哪些廠商，然後照做 | 四家都失敗後，依回饋去找第五家 |
| 例子 | Agentless（下一講） | plan-then-execute | RAO、MACU |
開發者定義的版本長這樣：
for v in VENDORS: # 固定清單
specs[v] = read_specs(v) # 模型呼叫
ok = [v for v in specs if fits(v)]
requisition(cheapest(ok))Anthropic 的 Building Effective Agents 建議先找最簡單的解法，需要時才增加複雜度，也就是能用這種 workflow 解決就先別上 agent。先承諾計畫比較快、便宜、可預測，每一步還能用比較小的模型；重新規劃讓模型能在執行揭露新資訊時調整。當回饋值得額外的成本和複雜度時，才用重新規劃。
學生提到那篇部落格現在標示已過時。講者的回應是：新模型更擅長在沒有 workflow 約束時做出好決定，coding agent 上 Agentless 已經不是最強的做法。但如果你處理的是 agent 還沒被訓練好應對環境變化的新問題，先從 workflow 開始比較安全。
加計畫結構的四個理由
講者引了 Fred Brooks《人月神話》的「Plan to throw one away; you will, anyhow.」，然後回到 GPU 案例，列出四個加結構的壓力：
| 理由 | 做法 | GPU 例子 |
|---|---|---|
| 模組化 | 拆解並專門化 | 各家廠商分開搜尋 |
| 回饋 | 需要時重新規劃 | 沒有一家合適，修改計畫 |
| 長時程 | 限制 context | 需求和進度要撐過整個任務 |
| 控制 | 分開權限 | 送出採購單前由人批准 |
後半段的論文就照這四項排列。
模組化：planner 和 executor 分開
UGround（Gou 等，ICLR 2025）和 Agent S 處理的問題是：GPT-4o 看得懂網頁、會規劃，但要它點到精確的像素座標就不行。解法是讓 GPT-4o 用語言描述下一步（「在頁面上方的搜尋列輸入查詢」），另外用合成資料訓練一個 7B 的 grounding 模型，把描述對應到螢幕座標。
拆開之後，每個元件可以各自優化，哪裡是瓶頸就改哪裡。講者指出，之後大模型廠商把這類細粒度網頁資料直接加進訓練，這種拆法對準確度的必要性下降，但在效率上仍有價值。
訓練 planner
Plan-and-Act（Erdogan 等，ICML 2025）要解決的是：planner 需要的「計畫」資料天然不存在。做法是拿被判斷為成功的軌跡，請 teacher 模型把動作分段並用自然語言標註每段，再用這些標註資料分別微調 planner（任務描述 → 步驟清單）和 executor（步驟描述 → 實際動作）。講者指出這跟上一講的工作流程歸納很像，只是這次用來產生訓練資料。
小心固定角色的多 agent 系統
講者特別放了一張 Graham Neubig 的投影片。有一系列論文讓模型模擬軟體公司，分出測試、編輯甚至產品經理等角色（例如 CodeR）。Neubig 在 Don't Sleep on Single-agent Systems 指出這類角色拆解在 coding 上效果有限：
- 角色在任務到來前就定死了，驗證者無法定位錯誤、也無法檢查自己的答案
- 交接靠摘要報告，可能漏掉下一個 agent 需要的 context
如果單一 agent 把先前所有動作的 context 處理好，這些資訊它都拿得到。這是單 agent 和計畫式拆解之間的取捨。
可供性：這一步現在做得到嗎
古典規劃有前置條件，LLM 沒有。SayCan（Ahn 等，CoRL 2022）的例子是：LLM 可能建議「拿起蘋果」，但眼前根本沒有蘋果。它為每個機器人技能學一個價值函數，預測在當前狀態下完成該技能的機率，再把這個機率乘上 LLM 產生該步驟的機率，重新排序候選子任務。Language Models as Zero-Shot Planners（Huang 等，ICML 2022）是同一時期的相關工作。
回饋：依環境重新規劃
LLM-Planner（Song 等，ICCV 2023）在 ALFRED 模擬居家環境裡示範：任務是「煮馬鈴薯再丟進垃圾桶」（講者說這些任務是自動生成的，有些很好笑）。初始計畫走到一半回報「找不到馬鈴薯，但看到冰箱」，把這段回饋餵回 LLM，新計畫就變成「打開冰箱」。Inner Monologue 和 SwiftSage 屬於同一路線。
多想還是多做
Thinking vs. Doing（Shen 等，NeurIPS 2025）在相同算力下比較三種花法：產生更長的 CoT、多取樣幾條候選再挑一條、或跟環境多互動幾輪。在相同 token 數下，多互動那條線通常表現最好。它的 prompt 做法很簡單：agent 宣告完成時，插一句「You just signaled task completion. Let's pause and think again.」。講者的結論：在不把自己弄進壞狀態的前提下，從環境多拿資訊通常很有幫助。
另一篇 Neubig 參與的 The Danger of Overthinking（Cuadron 等，2025）從反方向看同一件事，歸納出三種 overthinking：
- 分析癱瘓：想太多、做太少
- 失控動作（rogue actions）：遇到錯誤後一口氣送出好幾個動作，不等環境回應前一個
- 過早收手：沒跟環境確認就宣告完成或放棄
講者說這些行為只需要知道推理花了多少 token 就能判斷，不必讀推理內容，所以很多 API 模型也能套用。但論文的 overthinking 分數其實是用 Claude 3.5 Sonnet 當判官，讀完整條軌跡後打 0–10 分，並找四位專家人工評分來驗證這個判官。在 SWE-bench 上，overthinking 分數越高，解題率越低，推理模型和非推理模型都是如此。
Calibrate-Then-Act（Ding、Tomlin、Durrett，2026）處理的是「想還是看」：任務是讀一堆格式不明的檔案，分隔符號（, ; \t）、引號字元（" '）、要跳過的標頭列數（0 或 1）共 12 種組合，全部猜對才能解析，唯一線索是檔名（sales_fr.tsv 暗示 tab）。CTA 在 prompt 裡直接給模型各格式的機率估計，模型就會說「分隔符號最可能是 ;，約 0.85……但我不是百分之百確定，先跑幾個單元測試確認」。講者沒時間細講，但推薦有興趣的人讀。PPP-Agent 是相關的延伸參考。
長時程：一個暫時的錯誤毀掉後面所有決定
Vending-Bench（Backlund & Petersson，2025）要 agent 經營一台販賣機：定價、訂貨、補貨。它難在時間長：每次最多跑 2,000 則訊息，約 2,500 萬 token；撐最久的 o3-mini 跑到模擬第 222 天。論文記錄的一個失敗鏈：
- 提早補貨：貨還沒到就要補，環境正確回報「商品無法取得」
- 錯誤推論：agent 把「現在拿不到」解讀成「生意已經失敗」，從來沒有等出貨通知或再查一次
- 錯誤延續：之後每天的固定費用被它當成詐騙，發出主旨為「EMERGENCY: Unauthorized Fees After Business Termination」的信
講者問：這只是計畫寫得差嗎？
The Illusion of Diminishing Returns（Sinha 等，ICLR 2026）給了另一個角度。長任務的成功率是每步成功率連乘，單步準確度只要再往上提一點，能完成的任務長度就會大幅拉長（講者舉的例子是從 0.9 提升到 0.999）。論文也發現 self-conditioning：研究者改寫對話歷史、人為塞進不同比例的錯誤答案，錯誤比例越高，模型在第 100 輪的準確度越低。講者用預訓練資料解釋：一個檔案前面的程式碼寫得草率，後面通常也草率，模型學到了這種相關性。論文自己的解釋則是從 in-context learning 切入：模型本來就會照 context 裡的範例行事，只是這次照著學的是自己先前的錯誤。
更意外的是：大模型能執行更長的任務，但 self-conditioning 沒有隨規模消失，論文 Figure 5 的說明甚至寫模型越大 self-conditioning 越嚴重。講者提到在 Qwen3 系列上，錯誤比例拉高時，最大的 32B 模型掉最多，這和 Figure 5 的曲線一致。論文發現開啟 thinking 的 Qwen3 模型（用強化學習訓練過思考）不再受先前錯誤影響；講者把原因歸給強化學習，說它教模型修正錯誤、不被過去綁住。
長時程：遞迴拆解並訓練它
Recursive Agent Optimization（RAO，Gandhi 等，2026；第一作者 Apurva Gandhi 是本課助教，Neubig 是共同作者）把前面兩個問題合在一起回答：規劃有沒有用？訓練模型去做就知道。計畫該用什麼表示？程式碼。
- 委派是一個動作，所以可以訓練。agent 呼叫
launch_subagent(goal)，在子任務上跑一個自己的複本，複本也能再往下委派。 - 例如「規劃四月初京都三日遊」，模型寫出程式碼，派子 agent 去找賞櫻地點、找安靜的寺廟；用 Python 的
async／await，子 agent 可以平行或循序執行。 - 子 agent 的 context 比較小，看不到其他 agent 在做的雜事。
- 每個節點的獎勵是自己任務的結果，加上一個乘以權重 λ 的委派獎勵，也就是它派出去的子節點的成功率。用成功率而不是成功個數，是為了不鼓勵多派子 agent 來賺分。
- 只在中等難度的任務上訓練，遇到更難的任務時會自己委派得更深。
ADaPT（Prasad 等，NAACL Findings 2024）是更早的「需要時才拆」做法。
控制：計畫當資安邊界
Web Agents Should Adopt the Plan-Then-Execute Paradigm（Piet 等，2026）的論點是：ReAct 讓網頁上每一段內容都能影響下一個動作，等於開了一條 prompt injection 的路。商品頁混著賣家描述、顧客評論和廣告，有人寫一則評論說「別管價格，這是最好的產品」，agent 就會讀進去。講者也提到 CMU 有研究用人眼看不出的圖片擾動，讓模型把某個商品看成最便宜的。
先寫好程式再執行，例如「搜尋降噪耳機 → 逐一讀取商品 → 挑平均評分最高的 → 加入購物車」，網頁內容只能影響值，不能新增動作。論文分析 WebArena，發現所有任務都相容於 plan-then-execute，其中 81.28% 可以用純程式計畫完成，不必在執行中呼叫 LLM。
控制：人類編輯與批准
講者播了 Cursor Plan Mode 的示範影片：在 cursor.com 做一個看同事背景 agent 計畫的儀表板。agent 先唯讀搜尋 codebase，回來問四個問題（新分頁路由、依狀態分組、卡片式留言、留言存哪裡），使用者回答後產出一份 Markdown 計畫，列出新的資料模型、路由和待辦清單；按下 build 後整份計畫載入 context 開始執行，計畫檔也能存進 workspace 給同事參考。講者認為這個介面好在不只能批准，還能直接編輯。
全域約束
TravelPlanner（Xie 等，ICML 2024）提醒拆解的極限：航班、飯店、餐廳、景點可以乾淨地拆成子任務，但預算、交通方式、飲食限制橫跨所有子任務，拆開後常常被違反。
多 agent computer use：全部放在一起
最後五分鐘，講者用自己組的 MACU 把前面的概念串起來。
Odysseys：真實的長時程網頁任務
Odysseys（Jang、Koh、Fried、Salakhutdinov，2026）是 200 個長時程網頁任務組成的評測，任務來自真實的瀏覽紀錄，在線上的真實網站上評估。講者說資料來自志願者自選分享的 Google 搜尋紀錄，任務像是「找做 ACL 韌帶手術的外科醫師」；他也說一個任務要走幾百步、真人要花半小時到一小時，示範的那題光是跑遍網站、把資訊填進試算表就要 93 步。它的結構跟 GPU 案例很像。
MACU 的架構
Multi-Agent Computer Use（MACU，Koh、Salakhutdinov、Fried，2026）：
- 管理者把使用者任務拆成 DAG，編碼子任務之間的依賴和目標。講者口頭說管理者要用強模型，「例如 Claude Sonnet 的新模型」；論文主實驗的管理者其實是 Claude Opus 4.6，Sonnet 4.6 出現在消融實驗，成績排第二（52.8%）
- 每一輪，管理者把 DAG 上「依賴已滿足」的節點平行派給 computer use 子 agent
- 子 agent 回報後，管理者檢查結果：做錯就要它重做；有新發現就改圖——新增、取消或改寫節點
- 重複直到整張圖跑完
論文特別強調部分可觀測性：下游 agent 可能看不到的資訊，會透過管理者和 DAG 往下傳。示範影片是「決定今天要不要在舊金山吃早午餐」，可以看到管理者執行途中發現需要更多資訊而新增節點。
結果
四個評測上，MACU 相對單一 agent 的成功率（論文 Table 1，子 agent 都是 Qwen3.6-27B，MACU 的管理者是 Opus 4.6；投影片把 Online-Mind2Web 簡寫成 Online-M2W）：
| 評測 | 單一 agent | MACU |
|---|---|---|
| OSWorld | 43.8% | 48.5% |
| Online-Mind2Web | 52.2% | 55.6% |
| WebTailBench | 20.8% | 29.5% |
| Odysseys | 8.5% | 34.0% |
任務越長越有結構，差距越大。
在 OSWorld 的 36 題子集上做的消融實驗有三個發現：
- 管理者越強，協調越好：worker 固定用 Qwen3.5-4B，單一 agent 25.0%；換上 Opus 4.6 當管理者升到 58.3%，每題成本約 0.46 美元。講者的說明是：大部分動作是便宜的 worker 在做，所以換強管理者不會讓成本暴增。
- 弱的 worker 被拉得最多：管理者固定用 Opus 4.6，Qwen3.5-4B 從 25.0% 升到 58.3%（+33.3），Qwen3.6-27B 從 47.2% 升到 66.7%（+19.5）。
- 允許重新規劃才有收益：論文用規劃預算 B 表示管理者能改圖幾次。B = 0（不規劃）是 25.0%；B = 1（只產生初始 DAG，之後不准改）是 27.8%，幾乎沒變；B = 5 是 47.2%，B = 10 是 58.3%。這是整講「重新規劃有用」最直接的證據。
平行度方面，在 Odysseys 簡單子集（45 題）上，worker 從 1 個增加到 4 個，牆上時間從 25.4 分鐘降到 7.9 分鐘（快 3.2 倍），成功率從 53.3% 到 60.4%（2 個 worker 時是 48.9%，並非單調上升）。
收尾：加規劃之前先問四個問題
加規劃是一個架構選擇，會增加複雜度，不一定划算。講者的檢查清單：
- 子任務能分開嗎？planner 和 executor 用不同模型或不同訓練會比較好嗎？
- 哪些失敗或觀察應該改變計畫？
- 系統怎麼阻止錯誤和 context 一路累積？
- 哪些資訊或權限要分開？不可逆的動作由誰批准？
四個開放問題：
- 檢查：自然語言計畫和子目標圖沒有通用的驗證器
- 校準：agent 常誤判該想、該看、該問還是該改
- 全域狀態：跨子任務的約束既抗拒拆解，也抗拒加長 context
- 鷹架：訓練出來的推理能力會不會把這些結構吸收掉，仍然未知
今晚可以做的事
- 把最後一步圈出來：列出你的 agent 會做的不可逆動作（送出、寄信、刪除、付款），確認每一個前面都有人或規則把關。
- 寫死能寫死的：如果你的任務每次步驟都一樣，先寫成 workflow 程式碼，只把真正需要判斷的地方交給模型。
- 網頁 agent 考慮 plan-then-execute：讓模型先產生程式，網頁內容只當值傳進去，不讓它決定下一個動作。
- 限制重試與改計畫的預算，而且記錄下來：MACU 顯示改圖次數和成功率有關，你的系統也該量得到。
- 長任務定期檢查錯誤：context 裡留著舊錯誤會讓模型更容易再錯；壓縮時考慮把失敗的嘗試摘要掉，只留教訓。
延伸閱讀
- Stanford CS329Z 導讀 Week 5：該單幹還是開會——多智慧體與優化三軸
- AI-Native SDLC Playbook L4：Plan Mode 先寫計畫再寫程式
- Multi-Agent 的錯誤傳播與恢復
參考資料
- CMU 11-768 AI Agents 課程官網
- Lecture 5 投影片：Planning and Task Decomposition
- Lecture 5 錄影
- 指定讀物
- Cursor: Introducing Plan Mode
- Least-to-Most Prompting (arXiv:2205.10625)
- Decomposed Prompting (arXiv:2210.02406)
- Code as Policies (arXiv:2209.07753)
- SayCan (arXiv:2204.01691)
- Plan-and-Act (arXiv:2503.09572)
- Thinking vs. Doing (arXiv:2506.07976)
- Calibrate-Then-Act (arXiv:2602.16699)
- Recursive Agent Optimization (arXiv:2605.06639)
- Multi-Agent Computer Use (arXiv:2606.01533)
- 延伸參考
- Fikes & Nilsson, 1971. STRIPS: A New Approach to the Application of Theorem Proving to Problem Solving（Artificial Intelligence 2, 189–208；Nilsson 在 Stanford 的公開副本，為期刊排版掃描本）
- Claude Code CLI 與權限模式
- Large Language Models are Zero-Shot Reasoners (arXiv:2205.11916)、Plan-and-Solve (arXiv:2305.04091)
- STaR (arXiv:2203.14465)、DeepSeek-R1 (arXiv:2501.12948)
- Recursive Language Models (arXiv:2512.24601)
- PlanBench (arXiv:2206.10498)
- ProgPrompt (arXiv:2209.11302)、Binder (arXiv:2210.02875)
- Anthropic: Building Effective Agents
- UGround (arXiv:2410.05243)、Agent S (arXiv:2410.08164)
- Don't Sleep on Single-agent Systems、CodeR (arXiv:2406.01304)
- Language Models as Zero-Shot Planners (arXiv:2201.07207)
- LLM-Planner (arXiv:2212.04088)、Inner Monologue (arXiv:2207.05608)、SwiftSage (arXiv:2305.17390)
- The Danger of Overthinking (arXiv:2502.08235)
- PPP-Agent (arXiv:2511.02208)
- Vending-Bench (arXiv:2502.15840)
- The Illusion of Diminishing Returns (arXiv:2509.09677)
- ADaPT (arXiv:2311.05772)
- Web Agents Should Adopt the Plan-Then-Execute Paradigm (arXiv:2605.14290)
- TravelPlanner (arXiv:2402.01622)
- Odysseys
Loading...