動態規劃器（Dynamic Planner）：把複雜請求變成一步步計畫的 AI

多數對話不需要計畫。有人來問你的智能體一個價格、一個營業時間，或一個單一的操作問題，該得到的是一個直接的答案，而不是一個專案。但有些對話不一樣：使用者想把一整件事辦完——註冊一家公司、申請一張簽證、處理一件家具損壞的理賠——而且他明顯不知道該從哪裡開始。動態規劃器就是為那個時刻而存在的：它把那一段對話變成一條臨時故事線（一份巢狀、以清單驅動的計畫），接著由智能體一步一步走完。

它是一項 Pro 能力，可按租戶開關。負責做規劃的模型由平台營運方按租戶指派，而不是在對話中臨時挑選——正因如此，有資料落地限制的租戶可以被指到本地或區域模型上，其他租戶則繼續使用託管模型。

什麼時候才會觸發一份計畫？

絕不是模型「自己決定」，也不是靠一個讓使用者隨意下單要計畫的開放文字框。進去的路徑剛好只有三條，決定性由高到低排列：

1. **一個可展開的故事線步驟。**租戶把一條自己撰寫的故事線中的某一步標記為可展開。使用者走到那一步時，智能體會提議把那一步展開成一份子計畫。判斷在設計階段就由作者做完了，沒有任何東西留給運氣。
2. **使用者接受提議。**每一份計畫都從一張確認卡片開始（就是站上其他地方一樣的詢問表單介面）。使用者永遠可以拒絕，而智能體在這段工作階段裡不會再問第二次。
3. **升級判定器。**在故事線之外，一個小型的專用模型呼叫會盯著每一輪對話，並就三個維度為它評分——下面會說明。三項全部通過，使用者才看得到那個提議。主聊天模型從來不被信任「記得去觸發」任何東西；判定是引擎強制發出的一次結構化呼叫。

租戶自己撰寫的故事線永遠優先：當有一條故事線正在主導對話時，規劃器保持沉默。手工打造的流程勝過生成出來的流程。

三個維度的升級測試

判定器評估的是任務複雜度、使用者困惑度與領域相符度——而且三項必須同時成立。這是整個功能的核心，所以下面把實際的邏輯連同例子攤開來講。

**1. 複雜度——這件事真的是多步驟的嗎？**這件任務應該需要好幾個步驟、好幾份文件或好幾輪對話才做得完。一個問題不是一份計畫。

• ✅「我想開一家做電商的美國公司，但完全不知道這中間有什麼事要辦」
• ❌「德拉瓦州註冊要多少錢？」——這是查價格，直接回答就好
• ❌「SS-4 表格第 7b 欄該怎麼填？」——這是使用者本來就在跑的流程裡的某個具體步驟

**2. 困惑度——使用者希望有人帶他走一遍嗎？**訊號像是：「我到底該從哪開始」、「我需要準備什麼」、「整套流程帶我走一遍」、「這麼多東西我根本記不住」。一個熟悉流程、只是來問其中某一環的使用者並不困惑——給他那一環，不要給他一份計畫。

• ✅「老闆叫我去設立美國子公司，我從來沒做過這種事」
• ✅「註冊辦完了——接下來是什麼？年度申報？稅？我實在理不清楚，寧可請你幫我盯著」
• ❌「我的文件都備好了，直接告訴我去哪送件」——他清楚狀況，不是困惑

**3. 領域相符度——這是這個智能體的工作嗎？**使用者說出「計畫」兩個字，並不會把閘門打開。租戶是按對話付費的；一個做公司註冊的智能體會拒絕變成通用的私人助理，不管請求包裝得多客氣。

• ❌「幫我排一份三個月的健身計畫，細到每一週」——不在領域內，回絕
• ❌「幫我一步步規劃十天的歐洲行程」——不在領域內，回絕

生成出來的計畫本身同樣受領域約束：規劃器會收到智能體的職責範圍，並且必須讓每一個步驟都留在裡面。

說「好」之後發生什麼

規劃是唯一帶機率性的時刻，而它只發生一次：一個規劃模型把計畫起草成結構化資料——步驟、每一步的指示、一份要蒐集什麼的清單、一個完成準則。這份草稿會像任何一張故事線圖那樣被驗證（格式有問題的計畫會重試，接著交給備援模型；始終驗證不過的計畫就根本不會執行）。一套固定的邊界範本會以有決定性的方式蓋進每一個步驟——遇到矛盾必須提出質疑、不得推薦步驟清單以外的東西、不做核准或價格的承諾——所以這些護欄從不必仰賴規劃模型記得把它們寫進去。

從這裡開始，執行就是故事線引擎在做它一向做的事：每一輪專心處理一個步驟、有證據才勾掉清單項目、進度顯示在橫幅上、一條細細的進度條，以及一份由引擎渲染的步驟清單——所以你看到的是實際的狀態，不是模型對狀態的回憶。計畫以巢狀方式執行：如果是某個故事線步驟展開成計畫，那麼計畫完成時，母故事線會剛好從離開的地方接續。