[2026 實戰筆記] 當 AI 開始替你跑長任務，人類還有沒有可操作的控制權？前幾篇把不可信的「程式碼」關進了沙盒，這篇把問題換到執行中：任務跑到一半，你攔得住嗎？我在設計這段架構時，一開始想要的其實不是「計畫」，而是一顆按得下去的暫停鍵。文末有完整章節連結。

上一篇聊沙盒，結尾留了一個問題：把不可信的程式碼關進沙盒是一回事，那一串要在沙盒裡跑的「步驟順序」由誰拍板，是另一回事。是 AI 一邊聊一邊即興決定，還是先攤成一份計畫、讓你過目批准再動手？這篇就來還這筆債。

先把這篇的結論一句講完——

「先計畫、再執行」從來不是目的，是手段：為了讓執行中的 AI，隨時攔得下來。

起點：我要的是暫停鍵，不是計畫

這段架構的起點說出來有點反直覺。上一章把「大腦」（負責想的 Brain）和「手」（負責跑的 Worker）切開之後，多出一個當時沒特別留意的副產品：既然每個動作都得由大腦「派」給手去執行，那動作與動作之間，天然就存在縫隙。我看著那條呼叫鏈想：這些縫隙，不就是現成的檢核點嗎？

我想要的使用情境很具體。叫 AI 規劃一趟旅遊，它開始查天氣、查旅館；查到一半突然想到「對了，景點也幫我查一下」，不用取消重來，直接把新任務補進去。或者下完指令才發現整個下錯了，需要強制終止，已經查完的結果照樣保留。任務在背景跑、可以隨時插話，這才叫真正的多工。

但把「隨時暫停、中途加菜、強制終止」往下拆，會撞到一個繞不開的前提：系統得先知道「接下來要做什麼」，才有「中斷在哪」可言。

為什麼主流的 ReAct 給不了你暫停鍵

許多 Agent 框架與教學範例裡，最常見的工具執行風格都接近 ReAct：LLM 想一步、做一步，看結果再想下一步。它在探索型任務（修 bug、查資料）上很好用，但有個結構性的問題：下一步在 LLM 吐出來之前，連系統自己都不知道。 你要暫停，暫停在哪個動作之後？要加任務，插進哪兩步之間？沒有計畫，就沒有把手。

放進生產環境，ReAct 還有三個硬傷：同一個任務跑兩次，工具呼叫順序可能完全不同（軌跡不可重現）；出錯時「規劃」和「執行」混在同一個黑箱裡，你分不清是計畫錯了還是資料髒了（難除錯）；最要命的是，帶副作用的動作是即時盲發的：在你看見它犯錯之前，那封不該寄的信已經寄出去了（人類沒有停損點）。

我的答案：四階段分權

所以我把「先計畫再執行」包成一個工具，觸發後系統切進四個階段，每一階段的權力都被刻意切開：

1. 規劃：把 LLM 的工具清單設為空，逼它只能輸出一份結構化的 JSON 計畫書：每一步呼叫哪個工具、傳什麼參數、資料怎麼接。這份計畫不是寫給人看的，是寫給程式碼看的。
2. 審閱：計畫先過風險分級。低風險（純查詢）自動放行，但推一張唯讀卡片讓你知情；中高風險先凍結，彈出面板等人裁決：批准、用自然語言修改（上限 3 輪，防止永不收斂）、或取消。
3. 執行：人類批准的那一刻，LLM 被請出執行迴圈。接手的是一段零隨機性的純程式碼分發器，照著凍結的計畫逐步派發。這在架構上切斷了一條攻擊路徑：AI 在執行中途讀到網頁裡藏的提示詞注入、被誘導臨時改計畫。注意用詞：切斷的是「注入影響流程」的路，髒資料仍可能污染單一步驟的輸出，但它再也改不動接下來要執行什麼。
4. 合成：全部跑完，才把 LLM 請回來，把結果寫成人話。它只有「整合與包裝」的權限，沒有「我覺得資料不夠、再多跑一個工具」的權力。

有個常見的誤讀值得先拆掉：「大腦退場」退的是流程決策權，不是禁止任何步驟使用 LLM。計畫裡可以有一步是「叫 LLM 摘要文字」，那時它是被計畫書指名呼叫的工人，跟「抓網頁」沒有本質區別；下一步走哪，永遠由程式碼決定。

死板怎麼辦？三個介入點把彈性補回來

「計畫凍結」聽起來很死板：萬一第 3 步抓回的資料出乎意料，後面的步驟不就白跑了？所以在純程式碼的執行骨架上留了三個介入口：

• 執行前直接編輯：審閱面板上改參數、刪步驟、調順序，零 token 成本。
• 步驟間的斷點：在任一步前埋一枚斷點，跑到就停下來，把剛抓回的資料攤給你看，人決定繼續、提前結束、還是改寫剩下的計畫。系統也可以依過去的操作習慣，嘗試建議斷點位置。
• 半路自然語言攔截：計畫跑到一半，你在聊天框丟一句「等等，行事曆先不要建了，改寄信問 Tuna」，訊息先過一層便宜模型的意圖分類（改計畫／問進度／寒暄），真的要改，才喚起一次規劃呼叫，局部改寫剩餘步驟。已完成的結果原封保留。

再加一顆真按鈕：執行中隨時可按 Pause 和 Stop。開頭想要的三件事（隨時暫停、中途加菜、強制終止）到這裡全部落地。

寫到這裡的一個體會，跟一條沒走的路

很多人以為 Plan-Execute 的價值是「讓 AI 比較聰明」，但我最後得到的答案剛好相反：它最大的價值不是增加 AI 的能力，而是增加人類中途介入的能力。一個能連跑十步的 Agent，不一定比一個只跑五步、但第五步可以被你叫停的 Agent 更值得信任。

其實我也想過另一種設計：乾脆讓 ReAct 自己跑，等真的碰到高風險工具再停下來詢問。最後沒有選它，原因很單純：到了第五步才停，你已經失去整份計畫的全貌。你知道它現在要寄一封信，卻不知道前四步到底做了什麼、這封信是在什麼脈絡下長出來的。所以我還是選擇先攤開整份計畫，再決定要不要開始。（事中攔截這條路不是沒價值，它是整個業界都還沒答好的開放題，我留在完整章節的延伸討論裡。）

誠實帳：它現在還不完美

照這個系列的慣例，把醜話攤開。審閱面板等人裁決，目前逾時 5 分鐘會自動放行（fail-open），這是現況不是理想終局；「含高危副作用步驟一律 fail-closed」還在 roadmap 上。對照組是改 AI 自己原始碼的那道批准閘：30 分鐘逾時一律拒絕（fail-closed）。同一套系統、兩種逾時策略，對應的是兩個量級的波及半徑：日常排程卡死的維運成本，比放行一份已校驗計畫的風險更高；改原始碼則反過來。

另外兩筆：Pause 的最小生效粒度是「執行層」，正在跑的步驟不強殺，等它自然結束；審閱面板上「預估耗時、預估 token 成本」兩個欄位還沒做。

說到底，這章在講信任的第三種形態

這個系列一路都在講信任：不要信 AI 的答案（第四章）、不要信它會乖乖改自己（第五章）、不要信它執行程式時永遠善意（第六章）。這章講的是第四件事：連「它會照著好計畫跑完」都不要用信的，要用看的。

ReAct 把彈性留給 AI，Plan-Execute 把控制權還給系統；我想做的是第三種——讓彈性存在，但每一次彈性的行使，都必須經過人類可見、可審、可追溯的介入點。

2026 年的今天，暫停與審批的「原語」其實各家框架都陸續有了（LangGraph 的 interrupt、OpenAI Agents SDK 的 approvals、MCP 的 elicitation）。差別在於：業界給的是積木，你得自己組裝；而我想要的是出廠就按得下去的暫停鍵。

如果把前幾章串起來，我才發現自己一路都在做同一件事：不是讓 AI 更自由，而是讓它的自由，可以讓人隨時按得住。

下一個問題

寫到這裡，這個系列的架構主線差不多走完了。下一篇換一種讀法：把整個專案攤回時間軸上，回顧這一年架構推倒重來、與 LLM 反覆對撞的日子：哪些設計一開始就對，哪些是繞了遠路才修回來的。

這篇是我設計日誌第七章〈我想要的不是計畫，而是一顆按得下去的暫停鍵〉的獨立版。底下完整的工程落地（四階段管線的循序圖、JSON 計畫書格式、DAG 校驗與風險評估、斷點與半路攔截的 Redis 通道設計、3 輪修正斷路器、「肥回合」context 漏洞、為什麼不選 ToT/LATS），我都留在完整章節，中英雙語都有：

👉 完整章節：https://fibon.stepbyday.com/chapters/07-plan-vs-improvise/

fibon 是一個白箱、可稽核、本機自部署的個人 AI Agent 基礎設施，預計 2026 年 7 月開源。這篇若有戳到你，留言區聊。祝你這週順利。